Live data from Hacker News

Why we still build with Ruby

getlago.com

71–80 of 94 posts

Re: Why we still build with Ruby

#71

With rails you'd always have to pay for absence of strict types with extensive testing where you'd basically have to verify that data structures match. I don't buy it anymore

This is where I landed too.

Type system support, and the tooling around that support, has gotten SO much more powerful in the last decade or so.

Lots of the warts also got burned off with better support for smart typing, auto vars, duck typing for inputs, etc.

That tooling covers a HUGE swath of bugs that I just don't have to worry nearly as much about, and it makes quick refactoring less painful and less risky.

Going back to Rails feels like stepping back into the dark ages. So many stupid repeated tests/specs for things that should just be in a type system. The tests are slower to write, cover less ground, and are much more brittle.

My tooling isn't as capable, my feedback loop is slower (hard to beat instant type hinting for errors/mismatches right in my editor as I type), and I feel like I'm working with a blindfold on.

---

Yes, parts of Rails are great, yes - if you know it already it's a very productive environment. But man do I absolutely hate the lack of interest in type systems from the majority of Rails devs.

It's hard to overstate how valuable it is to be able to change a data structure and have all 29 places you might have broken immediately presented to you with basically no effort on your end outside of some minor type work.

I will pick it every time over having to write 29 specs in rails to get even close to the same safety.

Re: Why we still build with Ruby

#72

Earlier quoted context omitted.

Surely language preference factors in somewhere. Python is opinionated and not everybody’s cup of tea.

I prefer Ruby because of it's flexible meta-programming capabilities, like I would easily draft my own DSL if I have an idea of how I want the syntax to look like. This is such a powerful and underrated feature of Ruby in my opinion

Funny, I don't like Ruby because it has easy access to metaprogramming. It's powerful, yes, but in my experience it's a powerful footgun that makes the code very difficult to understand and debug 6 months down the line. And if you have a bunch of "clever" programmers working on the codebase, the horror...

Re: Why we still build with Ruby

#73

Some questions for those with RoR experience… 1. If you know Python, Lua, JS and C, how hard would it be to learn Ruby? 2. What’s the best way to learn Ruby and Rails today? 3. How important is it that you know the previous versions of Rails? I remember looking for some resources a while ago and got a sense that there’s a lot of history that you need to know to really grok the latest version of Rails. 4. I’m worried…

It's not hard to learn just takes time. Easiest route is to find a job that wants experienced programmers but doesn't care if you have rails experience, there's plenty. Second best route is to just build something with it. For context, personally I hate it 3.5 years in, but I can see why people like it. I would learn it because you have colleagues that use it, or there's companies you like that require it. Most people that think it's a silver bullet are just hopping from something they don't like; you'll find just as many people doing the opposite if you ask around.

On point 4 it does make you more productive for run of the mill CRUD work, but now that AI has gotten so good, I'm not actually sure that's a major benefit. I.e. it replaces configuration / boilerplate with magic, but AI can write boilerplate / pattern match really really well. I bet writing in Go saw a huge boost from AI.

Re: Why we still build with Ruby

#74

A language intentionally designed for DX + a pragmatic, stable, well organized framework minimizing boilerplate and BS are still the winning formula for fast web app development. The productivity and joy I get from working with this stack are immeasurable. I’ve been ruined in terms of having zero tolerance for the agony that comes with the JS ecosystem for example.

I think it's the Toyota Camry of languages. No, it's not the cool thing and won't turn heads or get you compliments. But it'll take you very, very far for a very, very long time.

I expect a Camry to keep on working with regular, normal maintenance.

I'm probably doing something wrong, but in my experience the amount of magic that Ruby allows (and RoR and library creators use), create for situations where updating code is extremely risky. It can be mitigated by having an extensive testing-codebase, but those only tell you if your assumptions still hold up, they don't help you in fixing your issues per-se.

And half of these tests are checking that your invariants are being upheld, things that you get for free with statically typed languages.

Re: Why we still build with Ruby

#75
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.

This is anecdotal, but one thing I do when comparing languages and frameworks, is browse the most popular libraries on GitHub from that ecosystem, and see how much maintenance they're getting. I usually use the contributors graph, as well as review how/when issues are handled. Ruby projects seem to have the most contributors maintaining the "deepest" libraries of any ecosystem I've seen, consistently, for the longest time. In other ecosystems I keep seeing one guy trickle-maintain some massively popular (based on stars) project that fizzled out over time. You could argue that some of that is due to "completeness", but I keep seeing evidence to the contrary: still many unsolved issues, but the initial activity spike subsides down to a trickle. To me that's what represents the health of an ecosystem: not how many new projects are created, but rather how well supported existing projects are.

Re: Why we still build with Ruby

#76
post #40
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.

Since it doesn't have as much interest from FAANG people treat it like its dead meat. Rails powers a ton of smaller apps (and some very large ones) but everyone thinks their idea is the going to be the second coming and therefore it needs all the insane optimizations that power Google etc.

The money is in working for a FAANG. So that's what Devs trains for.

There's not much money in working for a small saas unless you're the founder.

Re: Why we still build with Ruby

#77

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…

Postgres didn't really become the darling of SQL databases until rather recently.. i'd say the last 5-10 years. It was a clunky DB back in the day compared to MySQL.

It was clunky because it actually enforced rules.

Re: Why we still build with Ruby

#78

> - Rails handles our API, domain logic, and billing workflows. > - Go powers services that need high I/O concurrency or long-lived network connections. > - Rust handles CPU-bound jobs. It's always amazed me than the discourse around dynamic vs. static languages is that you can't have both. Like, dynamic languages are literally built on a foundation of static, compiled languages. Ruby's source is C and now some Rust.…

> So just build in Ruby and when you hit a bottleneck, rewrite that bottleneck in C or Rust Nowadays, yjit is so good that there is no real reason to use c extensions

That's an exaggeration. This can be true in certain cases, but it is not a general rule. YJIT is still orders of magnitude slower than C.

Re: Why we still build with Ruby

#79

Earlier quoted context omitted.

True. Ruby JIT has increased performance for some tasks you'd drop down to C for back in the day... All the gains Ruby has made in the last few years are pretty incredible. I never picked it because of performance reasons but it's pretty nice that it's getting faster. Either way though, Ruby FFI is super super easy. Just for fun, because of this thread, I spent a whole 2 minutes (lol) linking an Odin (my new low-leve…

> I spent a whole 2 minutes (lol) linking an Odin (my new low-level hobby language) library to Ruby. Would you mind creating a gist of your steps?

Odin code:

    package main

    import "core:fmt"

    @export
    sayhi :: proc() {
      fmt.println("Hello World")
    }
Key is the "@export" statement. Then build Linux dynamic library by doing "odin build main.odin -file -build-mode:shared". -file flag is since I'm just building a single Odin file, didn't set up a project structure or anything. -build-mode:shared is pretty obvious, there's separate build mode flags for Windows or Mac platforms (called "dll" and "dynamic" I think).

Ruby code:

    require 'ffi'
    module MyLib
      extend FFI::Library
      ffi_lib "./main.so"
      attach_function :sayhi, [], :void
    end

    MyLib.sayhi
That's literally all there is to it. Odin lib is a single file. Ruby code is a single file. Don't even need a project setup since Odin can compile single files into programs or libraries and Ruby can of course link to a shared lib that's anywhere.

Re: Why we still build with Ruby

#80
post #4
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.

It’s the same thing with php. I would say it’s probably because they are languages from the 90s, but then you have python and JavaScript which are from the same era too and people never question their relevance or “modernity”. All of these languages (even java) have been in constant development since then and all of them have modern features. Why are some considered modern and some outdated when they are all basicall…

> A truly modern language is Rust.

Don't recent PHP releases actually have a pretty good selection of nice, modern features? Union types, JIT compiler, pattern matching against types, nullsafe operator, gradual typing, etc. It seems like FP style is better and better supported with each new release, which is another hallmark of modern languages like Rust.

If you're stuck on some cursed, barely-maintained PHP 6 legacy codebase, you can't enjoy these things, but when it comes to choosing PHP for new projects it seems like it's more modern than its reputation.

Post reply on HN