Hacker News Reader

Comment by whichdan | Hacker News Reader

I think Rails is a victim of its own success: many of the hot new Rails codebases from that time are now 10 year old monoliths. And those monoliths need incredible amounts of tests to compensate for the lack of compile-time type checking, Rails version upgrades are multi-month nightmares, and the object-oriented statefulness of the language means that complex load-bearing code can be extremely tricky to untangle.

There are certainly new compelling projects like Sorbet to add type checking, and the ecosystem itself is very mature, it's just that the average codebase is not going to live up the experience you might have with a brand new one.

View on HN

That ecosystem is crumbling too, unfortunately.

Where, for example, in 2015 any SaaS or API would provide a gem (lib) to interact with it, today it's no longer the case. Modern PSPs, storage, search engines, etc almost all lack an official gem. Often lack even a third party one.

And where back in 2015 there were popular systems in Ruby outside of rails, all those are crumbling and/or gone. Jekyll is no longer the go-to static site manager, Chef and Puppet no longer the obvious devops tools. And Ruby is completely absent from emerging technology (AI, blockchain, WASM, data science, etc).

I'm afraid Ruby is becoming a legacy language and Rails' will be a legacy framework soon. Where the bulk of the Ruby jobs are to keep old stuff running and maintained. Afraid, because I'm still primarily Ruby developer.

That’s been my experience too. Where is the puck going to be then? JavaScript?

I think it'll be more fragmented. For one, because major language gain more features and such start overlapping more. Making them easier to move between.

And secondly because we're now at that pendulum swing, where people realize that "write once run everywhere" has severe downsides, easily overcome by writing software in a language or framework that fits the usecases best.

The latter is easily seen in the common practice of splitting out the UI in webdev. And in using microservices. Rails stubbornly goes against this common practice (which isn't a value call, just an observation) and as such, places itself outside of what we commonly are used to .

The former is seen in e.g. typing or type hints being added everywhere, languages getting support for functional programming, generics, interfaces, class inheritance etc.

Thx for the FUD salt. Rails never left, and neither did sinatra. In fact, other frameworks came to play, like roda. Ruby is ok.

Sure, jekyll is no longer the new hotness, but I don't see a market shift towards a single tool. There's just the usual fragmentation. Hugo, next, none of them is consensual.

Ruby was one of the primary targets of wasi. It compiles to WASM since 3.2 officially, but work started more than a year ago. Ruby in the browser is possible.

Sure, not everyone is targeting Ruby. But I don't see new products targeting new stuff either. Seems that there are less oficial SDKs nowadays, usually targeting the top 3 tier 1. And that's fine, and means little about Ruby in the end.

I am not sure what sources are you using for news, but in 2023 Ruby is growing strong and faster than in other years.

There are new books written, new conferences organised, Hanami 2 is out, new organisation created by companies to support Rails docs and marketing, Phlex is a nice way to work with views, someone started to work again on Camping, someone else is working again on a new portof shoes.rb

More content is created everyday: see for example dev.to starting to have beginner articles. A very good sign.

now regarding your fear, what I can say is act like your fear is real and it will be in some way or another.

About that content: back in the days there were numerous podcasts about Ruby or Rails or both. That was when podcasts were hardly as omnipresent as they are today. There were newsletters, blogs, and every e-learning platform had many prime tutorials on rails.

Those aren't all gone. But in the grand scheme of things, Ruby, and Rails' have been relatively decimated. There now are about twice as much (web) devs as back when it started but Rails nor Ruby is hardly twice as big. It's been going strong, solid, flatline.

I wrote a longer post, a while ago, with sources and numbers on this. It was featured on HN https://berk.es/2022/03/08/the-waning-of-ruby-and-rails/ (and frankly, it's going faster and is worse than I predicted back then)

(disclaimer I am the curator of first and the maintainer of the second)

From where I am, things don't look the same as you are describing them:

1. https://newsletter.shortruby.com - it is younger than 1 year, but you can find a lot of new content there: new podcasts were released in the last 12 months, new conferences were organized, and new books were announced. When I say new = it means never done before, not new editions.

2. https://rubyandrails.info - while it is not a comprehensive directory, it has a lot of resources. Indeed the youtube courses section is empty, but that is due to my lack of time, not because they are missing

3. Also, take a look at this https://rubyconferences.org

I don't have time to debate everything you wrote in the article, nor do I think I can change your mind.

I also don't know the future. Maybe you are right, maybe you are wrong. I choose to believe that Ruby is not dying and act like it: launch a newsletter, start to write a book, and prepare some more projects.

> need incredible amounts of tests to compensate for the lack of compile-time type checking

can you explain this a bit more? it seems to me that test coverage and typing solve different problems.

When you lack a type system which catches certain errors at compile-time, you need some other way of catching them. Unit tests are the typical solution.

Give this a watch: https://www.destroyallsoftware.com/talks/ideology

If you rename a function, type checking will catch that you rename all usages of it (or fail). With a type system to catch this, you must rely on more complete unit tests to catch anything you forget.

Types do not remove the need for unit tests, but they relieve some pressure from them.

Without compile-time type checking, every single line of code needs to be evaluated with a unit test to ensure there won't be any runtime syntax errors.

Reply on news.ycombinator.com