Hacker News new | ask | show | jobs
by martingordon 3029 days ago
I've been doing Rails development for ~10 years and maybe it's just a sign that I'm getting older, but for me the biggest problem isn't Rails, it's Ruby.

In the past year or so I've done a lot of more modern JS development (with Babel and Flow) and toyed around with Elixir and ReasonML. Ruby hasn't seen much change in the past couple of years (granted it's much more mature than Elixir/Reason) and while it was a boon to developer productivity and happiness compared to the languages of the time, I think we've probably found a better balance in type systems these days than Ruby and the like did at the time.

Maybe it's just legacy codebases, but manually reasoning about types is huge time sink and are one of our leading causes of production errors. Explicit typing also informs better design (I've seen many a Ruby method have return type of `String | Array | nil`). Unit tests help, but why outsource that to tests and guard statements (where you have to check every type) when a computer can do that for you?

5 comments

> I've been doing Rails development for ~10 years...

I'm a long time Rails dev as well. IMHO the main problem with the Ruby ecosystem is that the libraries haven't moved on into the current day and age. I find myself building more and more projects in something like Java or Python because those ecosystems have the firepower of the ML, AI, data processing libraries. And while I'd still say Rails is the best for building pure web and rest API stuff, Java and Python have gained a lot of ground and when all your real app power is in Python or Java a lot of times its not worth wrapping your core apps in another runtime just to provide a rest interface.

Any other rails / ruby devs experiencing this?

I hesitate to even say that I'm a Rails guy anymore because I've modified it for my own purposes so heavily that it's fundamentally a different thing[0] but I'm also a data scientist and when I need data science I just use python. It's so much easier to just have python / cython / numba and Rails share databases and just communicate through that when needed. For the stuff that can't communicate through the DB I can either fork off traffic to python in nginx or communicate through something that unix provides (pipes, ports, files, 0mq, whatever).

Ruby / Rails is so much more productive for me. No other language nails so many features as well as Ruby. Blocks are great, the meta-programming is natural and easy to debug, c-extensions are easy, and I generally like the balance it strikes with types. Couple quibbles here and there, to be sure, but usually the DB acts as my type enforcer and the high degree of test coverage covers the rest. Plus whenever I think something is risky I just throw in an explicit type coercion or exception, but it is rare.

I find people generally fall into one of three categories: Documentation enthusiasts, type enthusiasts, or test enthusiasts. Because I prefer human readable code I prefer meta-programming and because I prefer meta-programming I prefer tests over types or documentation. Though I don't pretend it's drawback-free, it is the environment that makes me happiest.

I think my next major thing will be to modify ruby itself because there are things that are missing that I feel could make it even better, but I'm trying to figure out if I can get away with just doing it in a really powerful gem.

[0] Designing for billions of writes per day, JSON API 1.1 + auto linking and pagination, dead simple defaults for controllers, lots of extra methods for better code legibility, etc. I've been thinking of extracting it all out into its own thing but I don't want to deal with the headaches of communicating breaking API changes.

Absolutely. Another 10yr Rails dev here. I believe that rails is untouchable as far is it comes to the ecosystem of gems and getting something quickly built and online, however I’m now moving all future apps to Django/ flask in python to take more advantage of the serverless ecosystem, and all of the data processing libraries out there. I’ll miss you Ruby
You may enjoy using Contracts and the Dry-rb suite. It makes ruby behave in a more functional way without sacrificing the extreme flexibility that is inherit in the language.

There was a good blog post about this from Thomas Reynolds the developer of Middleman a little while ago[0]

[0] https://awardwinningfjords.com/2015/03/03/my-weird-ruby.html

Nope, sorry but just nope. I use dry-validations and it’s fine for what it is, but unless this stuff is at the language level it’s just a hack and janky to use, which sacrifices one of ruby’s main attractions - language aesthetics.

I agree with parent, ruby is a pain to work in, especially if you’ve drunk the FP koolaid. I’m back doing rails again after a while doing react front end stuff and a bunch of own time elixir. Ruby needs to allow more functional programming imo.

Sure, it's definitely a hack on top of the language, but sometimes you don't have the option to rewrite and those tools can make your code more functional without having to switch stacks. It's not perfect, it's just a bit better than the alternative in many cases.
Careful, the dry-rb people are very sensitive. I posted a similar "nope" comment on r/Ruby a few years ago and now I have massively negative karma on that sub.
In my personal experience, Dry-rb is the "bargaining" stage of grief over the current state of Ruby and Rails. When you finally reach "acceptance," you move on to another stack entirely.
Exceptions are also problematic in Ruby. It quickly becomes impossible to look at any method and answer the question "what exceptions can this raise?"

Ruby has rich exception handling mechanisms, but everyone just uses "rescue" without any arguments (or worse, "rescue Exception") because of the elusiveness of the answers to that question.

Most of these problems arise from bad engineering cultures though, not the language itself.
Discipline can only get you so far. If you call a method coming from a third-party gem, you will still have no idea what exceptions could be raised by it no matter how well you've handled exceptions sourced from your own code.
That's true, but it's also possible to prevent these problems within a language, as Java does: https://docs.oracle.com/javase/tutorial/essential/exceptions...

(Not trying to start Java v Ruby here, just looking at how exceptions work)

It definitely is, but what happens when you'd like to use the other behavior? There's definitely certain occasions in which you want to use the not-best way to do thing. Leaving the choice to the programmer rather than removing the feature from the language is the way to go imo.
Yes, you can absolutely make Exceptions a first-class domain concept, I've been doing this in a worker instrumentation that I've been doing. I have a custom error class that inherits from StandardError, and the exception handling code handles these custom errors differently than other errors.

This way knowledge can be slowly wrapped around the failure modes as they get seen.

> Ruby hasn't seen much change in the past couple of years

This is the complete opposite of my experience as a Ruby developer. Ruby performance is starting to get really good!

Performance in Ruby has improved. What people are using Ruby for seems to be constrained to "Rails" and Chef. At least going off the job ads in my area.

Meanwhile, Python, JS, Go, Java jobs run the gamut from webdev, ML, to game programming, and custom BI.

Not saying people aren't using Ruby out there, but 5-6 years ago it was all the rage. Couldn't turn around w/o bumping into a Ruby shop.

It seems to have settled into a Niche of "Rails devs" and Ruby fans using it.

There was a post about this a while ago but that's pretty US-centric.

In Japan there is a lot of attention on Embedded Ruby (hence the performance improvements). 99% of the professional Ruby work that I've done here in NY is not Rails. I've done everything from webdev (Jekyll, Sinatra), ETL work, to systems engineering all in Ruby. I've toyed around with Ruby & SDL but the performance at the time (4 years ago) was not good.

I've been doing Rails development since the day it was originally open sourced and while I agree about your sentiments about Ruby, I think Rails is also really starting to really show its age. It was a great leap forward at the time, but we've learned a lot of lessons in the meantime.