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 Lyonreplied to Jenniferplusplus on last edited by
@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 Lyonreplied to Jenniferplusplus on last edited by
@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)replied to Jenniferplusplus on last edited by
@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.
-
@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 @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)replied to Jenniferplusplus on last edited by
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.
-
@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.
-
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.
-
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
-
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!)
-
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.
it’s such a weird bias!
-
Johana Linda Starreplied to Matthew Lyon on last edited by
@mattly @jenniferplusplus When all you have is a Ruby hammer, every problem looks like a Rail.
-
Matthew Lyonreplied to Johana Linda Star on last edited by
