Dirk Jonker:
I started building “version 2” of the application. I chose Rust as the
language for the backend and SvelteKit for the frontend. Initially, the new
version looked great, was blazing fast, but only had about 10% of the
required features. As Rust doesn’t really have anything comparable to Rails,
I ended up having to do a lot of plumbing instead of writing business code.
After a while, it became obvious that I could never write a feature complete
version 2 without completely freezing version 1. So version 2 got thrown in
the bin.
I did Rails professionally for more than a decade and there’s no argument that
it lets you develop functionality quickly. This is partly due to it being a very
complete framework, much more-so than all the Rust ones. Rocket comes closest
but Rails still has a lot more built-in.
Was this the end of the story? Absolutely not. Having experienced the joy of
Rust, with beautifully typed code and blazing fast performance, the feeling
of confidence you get when something compiles without errors, I knew I had to
have Rust in the application. Despite over four years with Ruby, I still
regularly wrote code that had issues at runtime. Mostly issues with null
values and unhandled exceptions. After each deploy, I would closely watch the
error reporting tools and quickly fix any issues that would occur in
production.
Runtime issues are the catch to Rails though. In every Rails app I worked on
there was always a constant stream of exceptions, many related to nil. I
eventually became quite demoralised by this, especially when on-call and having
my sleep ruined by yet another NoMethodError: undefined method for nil:NilClass exception.
When the opportunity arose, I left the Rails ecosystem. I now work on a
product that is implemented in languages that don’t suffer these
problems. This entire class of bugs almost never occurs now—and we didn’t
have to resort to heroic testing to get there, the compiler does it for you.
I build all personal web applications in Rust now too, including this very
site. They take longer to implement initially but once deployed are efficient
and stress-free.
Every project is a trade-off though and Dirk addresses some of this at the end
of the post:
But what about the downsides of Ruby and Rails then? Well, those are simply
things to take into account when writing code. Let me give my opinion here.
Have many issues at runtime? Test more. Does it turn into unmaintainable
spaghetti code after a while? Only if you let it. It’s typically caused by
developers, not programming languages or frameworks. There are plenty of ways
to nicely organize your code and you should probably spend more time
refactoring.
