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 have happened.
IIRC they chose ruby because they thought it would make things easy to contribute to
I spent a lot of my early career in Ruby & have since moved on: Ruby, & Rails in particular, is not the silver bullet for “deverloper happiness” those who love it think it is
It is very difficult to build for rails in a way that’s suitable for anything but a CRUD app, & it forces design decisions that make it hard to extract things
@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
@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
For some reason Golang seems to be the most popular choice? Is it the code generation features? Because otherwise, I can only image that handling AP docs is absolutely miserable in go.
@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.
@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.
@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 :p
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
@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
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.
@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
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.
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.
@hrefna@jenniferplusplus DHH went down hill starting 2020, and i basically agree with this as i think i stated up thread:
in the past 3 years you’re likely to find it more fun to rewrite functionality in your newer more employable language of choice than to extract existing functionality out of the legacy reference implementation.
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
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.
@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.
Add comment