As soon as everyone committing code isn't synced up with the same knowledge and solution styles, it goes to hell fast. It's bad at surviving team transitions intact, bad for onboarding once the project is past its earliest days, et c.
Discoverability problems are not specific to Rails, but may have something to do with convention over configuration, though.
It's also the case that different teams can write it pretty differently, depending on gem choices and which Rails features they lean on. Plenty of other languages and ecosystems are like that, too, but all the above stuff means Rails is exceptionally bad, in that regard.
The worst code bases I’ve worked on used statically typed Java.
Except of course that now it does.
So worst case if you inherit a codebase without static types added you can use gradual type as you get to know it.
But! Gitlab is not a LOB CRUD app. And I think a lot of people here have been burned by ending up working on bigger more complicated projects that started in Rails because it was convenient and then persisted with it because it never became clear that there was a positive ROI in migrating to something different. Some people who have had that experience tend to be skeptical of projects getting started with Rails, because it feels like starting to dig a hole that they know may be difficult to climb out of.
But! You never really know whether some application is going to remain small and simple, or whether it is going to grow and become more complex. So everyone is just guessing based on very limited information about the future.
My two cents is that I like services. Not micro-services, larger services with well-considered boundaries, but which are not a single monolith. If that structure or philosophy is in place, I worry a lot less about implementing the individual services with Rails, because the future path is much more clear. If a particular service grows too big for Rails' britches, it can be replaced with a different implementation, without reimplementing everything. I think services are an extremely useful hedge against the risk of path dependency leading to implementations that are not working well, but are very hard to fix.
pros: imutable data types. ruby like syntax. similar codebase organization. super fast. more modular than rails. the websocket system is way faster to develop in and deploy.
cons: no runtime metaprogramming but you do have a sophisticated macro system. not as many drop in libraries. not as many jobs for it yet.
I say this as a massive Elixir and functional programming fanboy.
case in point, I built my startup in elixir. completely agree on the difficulty in hiring but its not hard to teach. It was harder for me to find people who knew sql well. Unlike active record, ecto embraces sql so you have to know sql to use it.
anyways, its time will come. more and more companies are adopting it from discord to supabase to <cringe> trump media group.</cringe>
Also, I think you underestimate how many people (such as myself) who use Ruby in a very functional way already. Immutability is really not all that different. The only thing is you can't use ! methods and instead have to assign. For example instead of `array.sort!()` it's `array = array.sort()`. It's really not that hard, and in fact I found it easier because I didn't have to remember if `array.concat()` mutated or not.
IMHO the only "hard" things for a rubyist to learn are pattern matching and Actor model (OTP) concepts. Actor model concurrency is definitely different. But for an experienced programmer, that can be learned in a couple of hours (or less).
that said, elixir has excellent interrop with rust via rustler for when you need those heavy caclulations. and I trust a rust implementation long before I'll trust one in go.
and as far as lacking a vector data structure, sure but there's been a lot of work into Nx. who cares about a vector data structure when you have a full power numerical processing library complete with tensors! and unlike python, you can combine it with genstage and broadway to do all kinds of crazy shit.
why is gitlab is so surreally SLOW then ? even on simple projects on powerful hosted instances it's barely tolerable
thankfully in my country being too slow on the highway (lower limit being 80 km/h apparently) will net you a fine. It's people's right to drive whatever van they fancy... as long as this does not have any too much negative influence on society.
Okay, come on! That is fking Struts, it is hardly a fair comparison. Though otherwise I agree that Rails is a great choice for almost every CRUD app, like we really should stop overstressing it. Just use whatever one we are comfortable with and has enough internal knowledge on and with modern computers it will be plenty fast enough.
Around that same timeframe, I tried using JHipster, which sort of attempts to do for Java everything that a Rails app stack does for Ruby. It took 45 minutes for my top-of-the-line Dell laptop/workstation to bootstrap it, and it was... unapproachable.
But don’t get me wrong, I see where you are coming from, I’m just saying that your experience may not have been up-to-date even then, let alone now. In practice, with spring boot, quarkus and the like developing a backend app is plenty productive in java.
I've used Spring Boot. We'll have to "agree to disagree" that it's "productive."
All these things that people are stacking on top of Java are just trying to implement concepts and features that Rails has had for 15 years, and they're still nowhere near as "productive."
Laravel is pretty amazing, and with modern PHP the languages are pretty comparable. PHP still has a reputation problem though, and hiring has been tough because so many PHP devs haven't used Laravel (or Rails) so they have a bit of a steep learning curve. The tooling for ruby/rails is also still a bit better than laravel, but that may not be true forever.
edit: CRUD means Create-Read-Update-Delete. It's a basic programmer term for a simple application, or those simple parts of it at least. Even something big like Wikipedia, at it's core is a CRUD site. Most things are, with business logic sprinkled in; but some things aren't CRUD at all (eg a video game).
For example, if you're a car dealership your LOB CRUD API would handle stuff like submitting new cars, or staffs, or associating a sale of a specific car with a specific salesman or whatever other biz logic you have. This could be in contrast with, say, your Document Storage CRUD API which handles integrations with your document storage (eg storing things on a SharePoint, or Ceph, or S3, etc).
LOB has no inherent value with regards to microservice vs. monolith, it's simply another way to refer to the business specific logic. The term LOB is common across business as a whole, whereas "business logic" is generally a phrase used by programmers about programs.
By "LOB CRUD" GP means those fairly generic apps that are mainly a front-end to some database, with a bit of business logic or integrations tacked on. They're not the apps making money for a business, they're just helping it tick along and do the things that actually bring in revenue.
EDIT: As an example, I once rewrote a web app for a department. The original was all Java/Struts. It took a team of outsourced developers 2.5 years to write. It took me 4 months to rewrite it in Rails (having no access to the code), and mine did the main operation twice as fast, which meant that you could do it online, instead of having to wait for a backgrounded process to finish and send email.