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 ...
-
-
@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.
-
Hrefna (DHC)replied to Hrefna (DHC) on last edited by
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
-
:flan_reaper:replied to Random Geek on last edited by
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.
