Live data from Hacker News

Why we still build with Ruby

getlago.com

21–30 of 94 posts

Re: Why we still build with Ruby

#21
post #4

Earlier quoted context omitted.

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…

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…

> PHP typically required a web-server, system administration which is old fashioned

IMHO deploying PHP to production is easier than Ruby/Python. You need a web-server but once it's configured (not a rocket science) you just copy all .php files. For ruby you also want to have a web-server (e. g. nginx) unless the load is negligible. If you want to deploy a project with all dependencies you probably need something like rvm but some gems would be easier to install form OS packages (like pg or other wrappers around C/C++ libraries installed from OS packages too). And then for ruby you need an additional daemon (HTTP) which will be restarted on updates (and auto-restarted if it will crash).

Re: Why we still build with Ruby

#22
I've always blamed the "rails can't scale" take on how easy it is for inexperienced devs to build full stack apps. But code gen has 1000x this so I'd imagine that will fade.

Re: Why we still build with Ruby

#23

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.

Re: Why we still build with Ruby

#24

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

This is basically what we do at my startup. Though, some things we build elsewher from the start, knowing they need language specific tooling (like Python is best for working with LLMs).

You just can't beat the speed at which you can build business logic in Rails. Most features never hit the point of needing actual, raw performance so on 95% of what you build, you get to work incredibly fast. That still makes up for the 5% of features that you rip out and move elsewhere.

Re: Why we still build with Ruby

#25
post #20

I am hoping we have even more surprises in Rails World in two weeks time. And may be a glimpse of ZJIT? It is not just Ruby and Rails has gotten faster, CPU performance and core count has been getting cheaper. One thing I forgot to post last time in the GitHub CEO step down thread. I am hoping Microsoft won't force GitHub to move away from Ruby Rails. I remember there were some noise early on during the acquisition M…

Re: GitHub.

IF they do a rewrite, that should buy us at least 5 years, based on my experience with large-scale rewrites lol

Re: Why we still build with Ruby

#26

> - 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... This is basically what we do at my startup. Though, some things we build elsewher from the start, knowing they need language specific tooling (like Python is best for working with LLMs). You just can't beat the speed at which you can build business logic in Rails. Most features never hit the point of needing actual, raw per…

> Python is best for working with LLMs

Just curious how you're integrating LLMs... Self hosting?

I've been using RubyLLM and find it pretty decent for my needs, it's also improving at a very rapid rate. But it does focus on the most common providers and tools...

Re: Why we still build with Ruby

#27

Earlier quoted context omitted.

> So just build in Ruby and when you hit a bottleneck, rewrite that bottleneck in C or Rust... This is basically what we do at my startup. Though, some things we build elsewher from the start, knowing they need language specific tooling (like Python is best for working with LLMs). You just can't beat the speed at which you can build business logic in Rails. Most features never hit the point of needing actual, raw per…

> Python is best for working with LLMs Just curious how you're integrating LLMs... Self hosting? I've been using RubyLLM and find it pretty decent for my needs, it's also improving at a very rapid rate. But it does focus on the most common providers and tools...

Basically, the entire data and language processing world works in Python.

It's not that tools don't exist in other languages. It's that Python has the most readily available tooling. That makes analysis and iteration a lot easier.

Re: Why we still build with Ruby

#28
post #20

I am hoping we have even more surprises in Rails World in two weeks time. And may be a glimpse of ZJIT? It is not just Ruby and Rails has gotten faster, CPU performance and core count has been getting cheaper. One thing I forgot to post last time in the GitHub CEO step down thread. I am hoping Microsoft won't force GitHub to move away from Ruby Rails. I remember there were some noise early on during the acquisition M…

Re: GitHub. IF they do a rewrite, that should buy us at least 5 years, based on my experience with large-scale rewrites lol

Even with AI?

Re: Why we still build with Ruby

#29
post #20

I am hoping we have even more surprises in Rails World in two weeks time. And may be a glimpse of ZJIT? It is not just Ruby and Rails has gotten faster, CPU performance and core count has been getting cheaper. One thing I forgot to post last time in the GitHub CEO step down thread. I am hoping Microsoft won't force GitHub to move away from Ruby Rails. I remember there were some noise early on during the acquisition M…

Having been on Microsoft acquisition before, generally they encourage .Net usage for greenfield if possible but it’s pretty gentle encouragement. I’ve heard they are getting pretty pushy against C++.

Re: Why we still build with Ruby

#30
post #5
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.

Rails has bad spa suppott.

There is the API only mode :-)
Post reply on HN