Hacker News Reader

Comment by roboben | Hacker News Reader

I agree. What are options here? Rails in API-only mode?

But why? So many more performant frameworks for this in strongly typed languages to boot.

Which ones? Never saw another one which comes with the same comfort of batteries included like rails. For example having database migrations built in etc.

Yeah exactly. All that boilerplate stuff is such a pain to write or maintain long term.

Boilerplate is 1% of time, rest is solving real domain problems

ASP.NET (C#) has migrations: https://learn.microsoft.com/en-us/ef/core/managing-schemas/m...

Migrations are easy to do in literally every framework in any language

> For example having database migrations built in etc.

I actually went the exact opposite route, at least when possible: https://github.com/amacneil/dbmate

Pure SQL migrations, regardless of the back end technology that you use, completely decoupled from how each framework/library views things and therefore not dependent on them (you could even rewrite the back end in another technology later on, if needed; or swap ORMs; or avoid issues when there's a major ORM version update).

It's really nice when you can generate entity mappings based on a live database, like with https://blog.jetbrains.com/dotnet/2022/01/31/entity-framewor...

So in my case, I can have:

  * a DB that has migrations applied with dbmate, completely decoupled from any back end(s) that might use it
  * a back end that has entity mappings for ORM (if used) generated from the live local test database container during development, used for an API and not much more
  * a front end that's typically a SPA using the API, but is otherwise just a bunch of prepared files that can be served off of any web server

Of course, if you need SSR then things move around a bit, but that decoupling works great for me (but might not for others)!

That’s what a lot of people do. The value is still about convention over configuration IMO. If we are building a REST API, typical CRUD, you can go a long way with using Rails there and using something else when you need the performance or a certain feature.

The performance of Rails serializers is still a nightmare. God awful performance.

20 years on…

“Just use another framework when you need performance” they say.

Also 20 years on the http client still doesn't have proper timeouts.

> The performance of Rails serializers is still a nightmare

Well, The performance of Ruby is still a nightmare. Not just serializers. It's that serializers in Rails are the most prominent place where you'll have cpu-bound performance made visible.

But really. Just try anything cpu-bound (e.g. transform a huge list or CSV or so), and the lack of native, safe, threading, the horrendous performance of both the JIT compiler and the runtime and the language become apparent.

This isn't to criticize Ruby. Because once you see all the runtime inflection, the way it can modify itself runtime and the DSL magic it allows, the current performance is a magnificent feat! It should be impossible to have it perform at all, given these features. That people managed to make such a beautiful language, with such marvelous features and still have it perform like it does, is a true engineering marvel.

> It's that serializers in Rails are the most prominent place where you'll have cpu-bound performance made visible.

Sorry, what other interpreted language has significantly better serializiation/deserialization performance than Ruby?

Python, PHP and JavaScript have significantly better performance for cpu-bound programs.

E.g. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

And I have measured ser/de for PHP, Ruby (and Rust, we needed to know how much faster JSON serde in rust would be, and compared it to Ruby and PHP). Php is probably much faster because the JSON ser/de is apparently written in C.

I remember looking at BSON de/serializers for some perceived performance issue a while back, ruby was only marginally slower than PHP for the same task, which was just pulling big record sets back from the db. Can you elaborate?

When was that? I ask because PHP made large improvements to performance in the last few years.

Sometimes it's more than 2x faster than before. They now have JIT and are planing to have an intermediate language for even more speed.

Most PHP stdlib code is pure C/C++ so it tends to be very fast, but I'm guessing Ruby is the same.

It was about maybe late last year/Jan this year. When you say intermediate language, do you mean PHP has a bytecode interpreter instead of AST? At the time I looked at it, to convince myself there was no issue with Ruby, I actually hooked up the same table/query to PHP and used PHP's excellent profiling tools, then compared those to the Rails profiler. There wasn't a great difference. PHP was faster sure, but there was definitely no knocking Ruby's speed.

Ruby is strongly typed.

Excuse me. Statically typed.

There is no agreed upon definition of "strongly typed", so it depends on your interpretation of that term.

Ruby is not, however statically typed, nor does it have a type checker (well, there is sorbet and RBS) Those are fixed terms.

Same reason as always—it's useful for rapid prototyping. It's not like the frontend was ever rails's strong suit.

For prototyping you don’t need a back end. You barely need one for production. Just some cloud functions and a cloud database. Firestore, gcf, or equivalent.

Can't use any of them on a plane.

I think that’s pretty much it for big apps if we go with batteries included. Only Java frameworks compare on that front and if you’re a Ruby guy you likely don’t like Java.

I’ve been liking Golang but I haven’t had a job that used it in a while. Who knows what’s it’s like right now

Yeah, that’s one approach. Works great

Reply on news.ycombinator.com