It's a shame the article ends with "So as usual, consider not writing Ruby, but if you do, ...". That's worthless advice and many people, myself included, have Ruby as their most beloved programming language.
I always have a fond flutter whenever I see Ruby (which I used to write, and really enjoyed) but absolutely wouldn't start a new project with it, for practical reasons. It's slow, it can turn into a big ball of mud as applications scale (there's no named imports for crying out loud, everything is just in a global namespace with side-effects everwyhere), etc.
Certainly there are still people/projects where, upon consideration, Ruby is still the best choice (eg; small Rails shop has a standard CRUD app to build quickly that will not likely ever scale to be huge). But you should still _consider_ not using Ruby.
If your business depends on having a well maintained platform, then it makes sense to invest in it. Shopify should be commended for investing in Ruby. As a former contributor to Rails and Ruby ecosystem in general - IMO I would still choose Ruby for certain kind of work. I write Go mostly these days and parsing random JSON for example is major PITA (so it would be in many other static languages).
Disclaimer, former Stripe employee.
For example, they probably spend an absolute fortune on cloud costs, especially CI. Node, Go, Kotlin, Elixir or maybe even async+jit'd Python might all be 2-10x cheaper to run.
But I bet there are other choices that would have been worse. I often enjoyed working with Ruby at Stripe, especially once Sorbet came along.
No one is born knowing how to program.
>Doesn’t ergonomics matter?
It does and Ruby does a good job with it. It is not a hard language to learn. See my response to sibling comment.
Then after that if you still choose ruby over a language that gives you more guarantees and safety then is your choice.
I am specifically calling out people that _don't know Ruby_ and complain about the language being this or that, when really their frustrations come from them being inexperienced in the language.
It is like never having used a hammer, gripping it close by the head, and complaining that it takes a lot of effort to nail things. Blame's not on the hammer, bud.
This might happen with every language. I don't know. I'm a Ruby developer and have seen this countless times. Also, none of this equates to saying that ruby is perfect. It is not.
Hiring only people who are already experts in a given technology shrinks your talent pool in an already-tight market, and training is expensive (time and/or money).
In any case I'm not saying Ruby is high barrier or anything. It isn't! It is totally viable to hire non rubyists and build them up. I have seen it before many times. Ruby is a simple, forgiving language with fantastic documentation and an excellent community. It is pretty ideal for newcomers really. Training pays off.
Yeah, this is a significant flaw. I with it had a simple module system like Javascript's require function which just returns a normal object containing functions and data.
Compare https://github.com/benhoyt/countwords/blob/master/simple.rb with https://github.com/benhoyt/countwords/blob/master/simple.go
Hoping new age compiled languages like Crystal & Nim fill the gap of performance, types & productivity. But compile speeds need to be factored in.
This is the best description of Ruby I've ever read.
Its immutability drastically reduces the search space.
I say we go back to awk and get the best of both worlds:
'{num+=NF} END{print num+0}'Yes, go is verbose at times. But the go language server for example lets you not write a lot of the boiler plate you see there.
E.g. instead of typing out a for loop, i'd just (start) typing `foo.range!`, or for sorting `foo.sort!`.
I'm not going to argue that writing it in go even with those would be more terse, just that I think it looks worse than it is.
Not disagreeing, but the nuance is productive for writing new code/features. It really feels counter productive once you have a large codebase/team and you need to refactor existing apps.
Spent 5 years at a Rails shop and it's crazy how much engineering effort was spent on keeping this app going. Adding typing seems like a nice step to help here.
Maintaining a 5k+ LoC java/c#/go/rust/crystal codebase is orders of magnitude simpler than standard ruby. Sorbet/RBS bridge that gap now, but are a pita to use compared to natively implementing a type system. I know with rust/go I get a simple binary at the end to copy over. Rust, unfortunately, has slow compilation times still compared to go, but I really can't stand error handling in go compared to rust.
That said, "ruthlessly productive" is an apt description. I just don't want to have to maintain a large rails codebase again without sorbet/rbs. I'm hoping phoenix/elixir or something in rust catches on.
Is Golang "ruthlessly productive" for interfacing with complex relational databases? No, not even with generics.
Tradeoffs, every language has 'em.
For such a language to be reasonably productive you want to be able to overload "mystruct.myvar" to not simply grab "myvar" from memory, but smartly fetch it from a remote database, cache it, etc.
It will never be perfect (blah blah impedence mismatch) but a proper ORM is so much more productive and readable than writing crap like `Manager(mystruct).GetAttr("myvar")...` or bespoke SQL composition.
neither is ruby lol.
So said that they standard library is huge, where other languages prefer to have slimmer ones and let the community build the utilities.
That being said, I still love Ruby. I have all sorts of little tools written in it that would have been a pain to do in another language.
But to borrow words from another comment I find Kotlin “ruthlessly productive”. Apart from the lambdas, functions, data classes and immutably, it’s the ability to quickly and correctly refactor that makes me feel like I can work at speed and try stuff out.
Here's where Ruby shines for me: when I'm whipping up a script, I can toss a `Bundler.setup(:default)` at the top of the script, `vim mything.rb`, `$> ruby mything.rb` (or `./mything.rb` if I hashbang at the top), and I'm off to the races.
With Kotlin, it feels like I need to set up a project in IntelliJ, `$> ./gradlew run`, wait 10 seconds for the whole thing to compile, and finally my thing is running.
Is there a streamlined way to run a Kotlin script without building a whole jar, from the command line? I know this is generally not as easy with compiled languages. The D programming language is a notable example that has a "D script" mode (hashbang with `rdmd`), which quickly compiles+runs in a single step.
Here is an example with a shebang https://github.com/Kotlin/kotlin-script-examples/blob/master...
In most ruby code I have worked with, most non trivial methods use named arguments.
Ruby is probably one of the more coherently designed general purpose programming languages (in my opinion, much more so than Python, a language that dominates the industry) but doesn't seem to get much use in that domain, which is a shame.