Live data from Hacker News

Why we still build with Ruby

getlago.com

61–70 of 94 posts

Re: Why we still build with Ruby

#61
post #50

Earlier quoted context omitted.

In that case, it'll only take 8 years.

We need a new 80/20 rule. I propose a 90/0. You get 90% done quickly and the other 0% over the next few years .

We actually already have one of those, and it still fits just for a different reason:

> The first 90% is easy/fast/cheap, it's the second 90% that's hard/slow/expensive

Since most of the generative approaches treat code as disposable, then the second (and subsequent) 90% approaches just throw it away and start over. It's like all the awesome parts about a rewrite, with all the awesome parts about "it was rewritten because no one understood it"

Re: Why we still build with Ruby

#62
post #5

Earlier quoted context omitted.

Rails has bad spa suppott.

SPAs are one of those things that few apps truly need. And honestly, these days, if I thought I truly needed an SPA I'd probably just write it in a compiled language that spits out WASM. But Rails is hard to beat for CRUD apps.

> But Rails is hard to beat for CRUD apps.

I'm honestly surprised it didn't take off massively for internal enterprise CRUD stuff. It's by far the most productive stack I've ever used, the second closest being .NET w/ EntityFramework.

It was the darling of the early SaaS explosion of the early 2000s, and then just kind of died off in hype.

I like that it's opinionated, stops be from going down rabbit holes, and batteries included. There's nothing in the JS/TS framework of the day world that leaves me wondering "hmm, maybe I should stop using rails for this." It all seems worse, somehow, despite being more "modern."

Re: Why we still build with Ruby

#63

Earlier quoted context omitted.

PHP typically required a web-server, system administration which is old fashioned. No one wants to do that which is fine as it keeps me employed. When Ruby made western presence it was clunky. No one knew what it was and it got stuck with that personality. It had an ecosystem too but never hooked in to the western world. Java is tainted by Oracle and seen as "business". And it's also weird how Postgres has made an up…

How is it possible that we have this many programming languages and every single one is worse than the other?

My theory is that this world is actually some other world's hell.

Re: Why we still build with Ruby

#64
post #61
post #50

Earlier quoted context omitted.

We need a new 80/20 rule. I propose a 90/0. You get 90% done quickly and the other 0% over the next few years .

We actually already have one of those, and it still fits just for a different reason: > The first 90% is easy/fast/cheap, it's the second 90% that's hard/slow/expensive Since most of the generative approaches treat code as disposable, then the second (and subsequent) 90% approaches just throw it away and start over. It's like all the awesome parts about a rewrite, with all the awesome parts about "it was rewritten be…

I always heard it as "The first 90% of the work takes the first 90% of the time, the remaining 10% of the work takes the other 90% of the time." But yeah.

Re: Why we still build with Ruby

#66
My team mostly writes glue code and infrastructure, occasionally the odd web service that runs in an AWS Lambda. We have a few small CLI tools as well. Most of what we have that isn't written in Bash is written in Python.

The other day I wrote a small script in Ruby, because I wanted to use a first-party SDK in a language I'd at least dabbled in before, and for GitHub, the only such candidate language was Ruby. This tiny little script doesn't do much, and its real (non-dev) dependencies are very few. There's no big framework like Rails.

(I don't have a lot of experience in either Ruby or Python— in school I wrote chiefly Java, and when I was an application engineer, I worked primarily in Scala. I'm more accustomed to statically typed languages.)

I set up more of less all the same stuff for this Ruby project as I did for our Python projects: linters, LSP, code navigation tools, an isolated development environment supplied in part by Nix and in part by language-specific tools, and integrated everything with my Emacs config (with direnv doing most of the heavy lifting; everything should be easy to integrate with VSCode as well). Like some of our Python scripts, it does most of its work with libraries but occasionally shells out to an external command line tool.

From top to bottom, the tooling was better. Choices were simpler and fewer. The default linting rules come from just one place, and are comprehensive and opinionated. The REPL is better and integrates better with my editor. Getting a complete debugger set up was trivial. There's even a gradual typing system that actually does something at runtime, instead of a useless joke that just gives (potentially bogus!) completion hints to your editor. The runtime may be slower, but startup time is better, which is a better fit for our main use cases (CLI and AWS Lambda).

At the same time, the code is better, and effortlessly so. Things that require third-party libraries to do ergonomically in Python (like calling external programs) are just built in and feel good to use. The code feels more concise and the expressions more natural, thanks to small things that have been in Ruby forever, like the "unless" keyword. Exception handling is very concise and doesn't always require breaking things out into multiple indented lines. Passing contexts around is less annoying (though it can't be done as implicitly as in Scala). Besides my code, the language itself feels cleaner. Actually everything is an object. Even statements are expressions.

Are there things I miss? Sure. I'd rather be working in a language with static typing and immutability by default. I'd probably rather work in a compiled language. Maybe what I really want is Gleam or something.

But tbh, our single Ruby codebase feels more modern than anything else we've written, not less. My team has predominantly chosen other languages because "it's more popular" and "it's easier to hire for", but I think that was a mistake.

Re: Why we still build with Ruby

#68

I wonder how much can be attributed to liking vs disliking low level things. Some people like knowing which register their data is in (and sometimes it actually does matter) while others just don't want to get into those details. I'd say, don't fight this bias - choose the tools that resonate with you.

I think this is true about many different aspects of programming languages

There are many things that ultimately come down to personal taste more than some sort of objective pros and cons list, as much as people will attempt to argue otherwise

Re: Why we still build with Ruby

#69

Earlier quoted context omitted.

I've been toying with Perl+CGI-scripts lately and find its super productive with the benefit that I can do serverless without the lock-in. I don't think the software engineering field is particularly rational and mostly follows trends or what looks good or familiar. We have a proclivity to assume that anything old is legacy. Most developer have never studied any CS history and are quite young, so they're bound to rei…

I'm old enough to have been using Perl with CGI in the waning years of the old millennium. I loved it then, but it's not just hype cycles that caused people to move on to different solutions: Modern stuff is better in a bunch of very real ways.

I found that with CGI::Application, and similar Perl modules you get the facilities of the modern stuff, as well as the portability and simplicity of a simple index.cgi script.

Two things I think Perl always had a good reputation for was CPAN, providing interfaces to "everything", and a high degree of testing. I love that golang and rust both emphasize testing in modules/crates/packages. Writing perl CGI scripts I always had test-cases for the whole lifecycle, and that's something that isn't so common these days writing handlers in other languages.

Re: Why we still build with Ruby

#70
post #2

I don’t understand why Ruby and Rails get a reputation for being outdated or “legacy.” Over the last several years both have seen massive numbers of contributions, both in improvements and new features. I’d be surprised if any tool for building a new web app could even come close to what Rails has to offer across the full stack.

I've been toying with Perl+CGI-scripts lately and find its super productive with the benefit that I can do serverless without the lock-in. I don't think the software engineering field is particularly rational and mostly follows trends or what looks good or familiar. We have a proclivity to assume that anything old is legacy. Most developer have never studied any CS history and are quite young, so they're bound to rei…

> Most developer have never studied any CS history and are quite young

Even the ones who studied it still fall into the trap of novelty for novelty sake. I'm guilty of that as well 20+ years ago at the start of my career, I believe it's one of those wisdom rites of passage someone needs to go through to value the lesson.

Boring old tech that works is pretty good, if it's not unmaintained, gets updates while keeping a stable core, has an ecosystem of good libraries and documentation, I'll always choose it over some new fangled thing from the past 2-5 years.

You need to feel the pain of depending on something that is taken away, or dies a slow but surely death, or creates massive headaches to upgrade, to value the stability of boring old tech.

I feel it's a cycle bound to be repeated by each generation.

Post reply on HN