Given how many fedi servers are out there, it's interesting to me that I can only find one written in Ruby. You'd think that a long running successful project would just naturally produce resources that other projects can use. But that doesn't seem to ...

Matthew Lyon

@jenniferplusplus I spent a bit of time last week reading through Masto’s source while trying to implement message signing for an implementation of the inbox on my static site + “functions”, and tailing through the key management code reminded me a lot of why I left that world behind

The thing to understand about rails is that it was designed for Basecamp, and things shaped like it, and in 2010 at least people doing rails would tell you your problem was a bad one if it wasn’t rails-shaped

Jenniferplusplus

@mattly I'm no fan of Ruby as a language or ecosystem. Even less so of rails. I just think it's notable that Mastodon doesn't seem to have produced any local benefits for working with activitypub, or any of the other specs involved in real world federation. Or if they did, it didn't foster any kind of locally favorable micro climate, as it were

Hrefna (DHC)

@jenniferplusplus This is purely guesswork, but I suspect part of it is that golang is a relatively popular shop language (along with Java, C++, C#, etc)—the languages that people use to Get Things Done and you barely have to justify using them—and its structure encourages a kind of modularity that is appealing.

It just fits well as a "good enough" choice that is accessible for a lot of people.

Outside of Ruby, Rails is basically multidimensionally the wrong choice for this kind of project.

Jenniferplusplus

@hrefna But for different kinds of projects that just use the same federation protocol? I've never found AP macro blogs or bookmarkers, or etc written in ruby, either.

Matthew Lyon

@jenniferplusplus Go is attractive to a lot of people coming from interpreted languages or the JVM; it makes it dead simple to compile a binary & it’s designed for network plubming the way rails is designed for CRUD

Code gen isn’t rely useful if your data structures are already defined

Its *incredibly* hard to do something “clever” in Go; the language is straightforward & has a consistent style, making it a decent choice for projects with a lot of contributors with varying project familiarity

Matthew Lyon

@jenniferplusplus I think this is another facet of Ruby culture

early on in rails culture there was the joke that ruby had one obvious framework to go with while Python had three or four, so that’s why you should choose ruby; there are some other alternatives there now but most serious people left outright

rails also encourages designs that make it extremely difficult to extract some bit of logic for re-use outside of a rails context. Think of it like wordpress plugins, vs php/nodejs libraries

Hrefna (DHC)

@jenniferplusplus I mean to be slightly cynical I don't think rails is the correct choice for basically anything, so I'm not sure my evaluation there is going to be particularly fair

More seriously: IMO part of this is Ruby has been in a sort of decline for a long time as one of the major languages. Since before it was chosen for mastodon (c.f. https://www.tiobe.com/tiobe-index/ruby/ and https://octoverse.github.com/2022/top-programming-languages).

There's also been the, uh, trajectory of DHH.

So at a guess: others are just more appealing.

phillmv

@hrefna @jenniferplusplus this perspective is so biased!

Rails is a great choice for exactly this kind of project: a speculative app whose requirements were not yet fixed, and where the design needed to be flexible to accommodate as of yet undetermined needs.

if you tried to get this off the ground in Java or C++ or Go we wouldn’t be having this conversation; there’d be a cool TODO in a forgotten repo somewhere

Jenniferplusplus

@phillmv @hrefna At the risk of getting into a programming language flame war, I think pretending it's okay to skip domain modeling is a pretty big anti-feature

phillmv

@jenniferplusplus @hrefna i have a whole blog post queued up on this exact topic, but domain modelling is a lot easier to do in hindsight, after the app is successful, than when you’re starting out & the exact dimensions of the requirements are fuzzy.

making an app from scratch is a lot more iterative and speculative than we give it credit for. lotta programmers want to pretend they’re coding to exact, well defined, specs instead of fumbling in the dark

Hrefna (DHC)

@jenniferplusplus

That.

Also if you are struggling to build an app with speculative requirements in Java then you are building Java wrong. If that flexibility is desired then that flexibility is part of your needs and you design for it.

There are advantages and disadvantages there and there's certainly some things that would be easier or harder as tradeoffs, but you can do inflexible design in any language, and flexible design in pretty much any shop language.

@phillmv

Random Geek

@mattly @jenniferplusplus Rails used up all the oxygen in the room early on, a lot of us gave up, and now even though there's intriguing projects like Hanami, the broader Ruby ecosystem is still pretty much Rails in a room by itself, breathing heavy.

So yeah most of the folks who think "I'd like to do this but differently" have long since moved on to other languages and workflows.

Hrefna (DHC)

@phillmv

I am intimately aware, and I'm sure that @jenniferplusplus is also intimately aware, of what is required to build something from scratch and how to do domain modeling with flexible requirements.

I've built data warehouses, one of the most rigid areas, with "uncertain requirements and a need for flexibility." There are entire books on how to do this effectively

Domain modeling is not equivalent to "we have a detailed specification ahead of time," nor does it imply waterfall design.

Hrefna (DHC)

@phillmv

All of this is besides the point, however, which is that Ruby has been in decline for a long time, since before Mastodon was started, and DHH's behavior since 2016 has not helped make Rails more popular.

Also that if you are looking for reasons why an ecosystem hasn't developed around mastodon saying "ruby is great for prototyping" is not helping the case that people are just preferring other things now that the primary part of the domain model is sorted.

@jenniferplusplus

phillmv

@hrefna @jenniferplusplus

a data warehouse is way more well defined than a consumer oriented cat picture website!

i’ll bet you a large sum of money that i can prototype a website faster, and iterate on its functionality faster, than with your “shop” language of choice.

i’m just deeply irritated by these macho nerd arguments. i too work at Pretty Large Scale & i’ve written enough Go to be aware of its limitations

:flan_reaper:

@randomgeek

I hitched my wagon to PHP instead of Ruby back in the day.

And I PHP went through the kind of phase that Javascript did where everyone and their mother built their own framework (even I did!)

@mattly @jenniferplusplus

Hrefna (DHC)

@phillmv

Let me be blunt: I really do not give a damn if you can "prototype a website faster," you could probably "prototype a website faster" than me in languages I work in every day, and I don't see the value in having that argument. I also consider ruby a shop language and _also_ am not defending or endorsing go.

I am trying to analyze _why_ something is true, and outside of my one snarky comment not weighing in on whether it _should_ be true or what is good or bad.

@jenniferplusplus

phillmv

@hrefna @jenniferplusplus i don’t think your analysis is incorrect, but “rails is not the correct choice for basically anything” — oof that gets my hackles up.

it’s such a weird bias!

Johana Linda Star

@mattly @jenniferplusplus When all you have is a Ruby hammer, every problem looks like a Rail.

Matthew Lyon

@johana @jenniferplusplus