
Sick of Ruby, dynamic typing, side effects, and object-orientation (2014) - setra
https://blog.abevoelker.com/sick-of-ruby-dynamic-typing-side-effects-object-oriented-programming/
======
lucaspiller
I switched from Ruby (after ~8 years) to JavaScript at the beginning of this
year, and Ruby is a dream in comparison:

\- Thanks to the proliferation of Rails and similar frameworks, most Ruby apps
at least have something that resembles an MVC structure. With JavaScript, once
you move past the basic TodoMVC examples you are pretty much on your own. It
gives you enough rope to hang yourself, all you colleagues, and everyone in
the building next door.

\- The expect vs should change in RSpec is nothing compared to how fast things
are changing in JavaScript. I think there are now 7 different ways of just
defining a module.

\- The stdlib of Ruby is pretty sensible. JavaScript has many inconsistencies
(take Array.slice vs Array.splice - one modifies the original array, and the
other does not), and you usually need to rely on third party libraries, or
write the code yourself, to do pretty basic operations.

\- The JavaScript community seems to have the opposite of NIH syndrome, so
that even basic functionality is offloaded to a third-party modules (see
leftpad). The project I'm working on has over 1000 modules in it's dependency
tree.

~~~
sillysaurus3
All of these concerns are not actually concerns. They're a symptom you haven't
yet become a JS dev. You have to throw yourself mentally into the ecosystem,
wholeheartedly, as if you were diving into a pool. At that point every one of
your concerns vanish:

\- There is exactly one way to define a module. Write a file. Done. Webpack
takes care of it.

\- You were using Webpack, right?

\- The fact that Webpack either wasn't on your radar or already solving your
problems says a lot.

Look, I know this _sounds_ like bullshit, and in fact it's very difficult to
distinguish this from actual bullshit. But there are a huge number of people
here -- old fogies, stuck in the past, yearning for the old days that are
_never coming back_ \-- who _hate_ JS, and that hatred manifests itself in ten
thousand subtle ways.

Inventing the idea out of thin air that "there are 7 different ways to define
a module" is simply false. It does not resemble reality. Yes, it's true you
can point at all the dead module systems that came and went, but nobody
bothers even thinking about those systems because they're dead. They're
zombies. Yeah maybe some people use them, but realistically if you're getting
shit done in JS that means you have webpack and all of these concerns are not
actually concerns.

JS stdlib seems like nonsense? Lodash.

Feels like you're importing too much bloat? Webpack tree shaking takes care of
that. Closure compiler eliminates all the code you're not using. There's no
reason not to use a first-class stdlib, whether it's Lodash or whatever else
you prefer.

 _\- The JavaScript community seems to have the opposite of NIH syndrome, so
that even basic functionality is offloaded to a third-party modules (see
leftpad). The project I 'm working on has over 1000 modules in it's dependency
tree._

This is _the power_ of JS. It's the thing to force yourself to embrace. You
need to join the cult of bullshit and just mentally force yourself to love
this rather than hate it. It's _why JS won_. You can hate it all you want and
revel in the insanity, but there is zero reason to do that other than as a way
of making yourself feel good. Which is just another way of saying we're all
acting very selfish when we lash out at JS like this.

Yes, you're correct. Every one of your points is absolutely true. Yet it's all
so very wrong. I wish I could put it into words better than this.

Look dude. I've been around the block. I vividly remember what this shit was
like in 2008. You want pain? Holy shit, I remember trying to make a little
arrow rotate on my webapp. I wanted finder-style arrow rotations. You know how
on a tree view, each folder has a little arrow, and it points to the right
when it's collapsed? Click on it, it rotates 90 degrees and points down, and
the tree expands. YEah, I tried to do that in 2007 right when Rails 1 was
first coming out. Talk about horror. The solution -- the _only_ solution --
was to make an entire animation frame by frame, of the arrow rotating 90
degrees. Like 16 different images, just for this stupid arrow to rotate 90
degrees on command. Because CSS literally wasn't a thing back then. Yeah we
had "CSS", but for all intents and purposes we are living in the future right
now. We have tools that 2007-me could only dream of.

JS _works now_. That is not the expected behavior. It's difficult to convey
how fucking strange this is. Anyone who lived through that 2006-era transition
knows what I mean.

Right now you can drop Semantic UI into your project, hook up React to it, and
have first class testing (Enzyme) and state management (Redux).

Don't like all that bullshit? No problem. Use Vue. It sidesteps all the Redux
insanity. And the tooling is catching up.

But the way you know these things is by being a JS dev. Living and breathing
it every day. There's no way around that. You either throw yourself
wholeheartedly into the pool or keep one toe in while complaining about how
big the ocean is.

This rant came out quite a lot harsher than I intended; it's just a reaction
to the very common trope that HN throws around of "JS is shit, the web is
shit, this is shit." Yes, this is true. And yet -- simultaneously -- no. No no
no. We can do _magical things_ now. Hooking up Vue with hot reloading is
literally magic. If 2007-era me had these tools, I would have launched a
startup that could dominate everyone else _solely_ due to the advanced tooling
that we now enjoy. Our tooling now vs 2007 is like Lisp vs C++ back in 1999.

~~~
blub
That's a very interesting metaphor you came up with.

So the JS ecosystem is a giant pool right? Everyone is swimming in all
possible directions with all sorts of contraptions like rubber tires,
inflatable dinghies, pieces of wood, plastic garden flamingos, etc. A lot of
the swimmers naturally pee in the pool because it's more convenient than
exiting (that was frowned upon at the beginning, but people kinda got used to
it - and it keeps a steady development speed!).

This might look quite horrifying to those on the outside, but for the swimmers
it's nice and warm, while stepping outside is cold and scary, because they
would have to learn all sorts of complicated and frightening technologies.

For someone like me that got out when the pool was small around 2006, there is
no incentive to jump back in. I mean yes, if I closed my eyes and jumped I
would probably adjust after a while. But why jump in the JS pool when I can
swim in the open sea? :)

~~~
sillysaurus3
_For someone like me that got out when the pool was small around 2006, there
is no incentive to jump back in. I mean yes, if I closed my eyes and jumped I
would probably adjust after a while. But why jump in the JS pool when I can
swim in the open sea? :)_

I was right there with you.

If you can find a way to retain your career and not have to worry, maybe it's
not worth it.

But for me, I came precipitously close to having no marketable dev skills, by
accident. I loved gamedev, and I spent my life learning it. It's what got me
into programming.

Most cities don't have gamedev shops. And if you're not at a gamedev shop,
you're not really a gamedev. Yeah you can try your hand at indie stuff, but
that's roulette. Wanna be forced to move to whichever city has a studio? Be a
gamedev.

So... Backing out of that career trajectory led to an uncomfortable
realization: I'd amassed a bunch of low-level skills, had a deep understanding
of Unix/C, and could implement [https://lmax-
exchange.github.io/disruptor/](https://lmax-exchange.github.io/disruptor/)
without breaking a sweat. (Not merely use it; implement it.)

None of that translates into dollars. If you show up to a recruiter, they
don't know what to do with you. There are literally hundreds of Rails gigs.

One interview went like this: They sat me down, opened up postgres, and said
"Accomplish these goals." The goals were simple things like write SQL
statements to query for certain types of users, or join data together.

I never had any reason to learn any of that. I knew that I _could_ learn it if
I needed to. I understood conceptually what joins are, why to use them, and
what to avoid and _why_. The "why" is the crucial ingredient, and I naively
thought that would protect me.

No... It's not fun when you have to sheepishly admit in front of three
engineers that you have no idea how to write those SQL queries.

It was the same deal with Rails. Ditto for JS. Eventually I went through 5
interviews and struck out on all 5, in a row.

That's deep shit. When you start worrying about paying the rent, you're not in
a happy position.

The way out of this mess, and not to end up in it, is to own it. Embrace all
the shit. Become Elvis of code. Literally throw in the kitchen sink just
because you haven't tried it out yet and this new kitchen sink might help you.

This story might not seem too relatable, and you might feel like your career
is impervious. But a wise person once said that we overestimate the impact of
years, and underestimate the impact of decades. "One decade" is so powerful
that it's hard to overstate how much the world changes during that time frame.
Are you absolutely certain you can get by without swimming in that pool that
gives you the heebie jeebies?

Let go. Once you start swimming a few laps, it's not so bad. And in my case, I
discovered I kinda like it. You're not supposed to like it, but it really is
kinda fun. What other career would get to play with an endless box of legos?

~~~
blub
Can't really relate I'm afraid.

I mean I think I understand why _you_ chose JS, but we each make decisions
that can take us on different paths.

I also do systems programming and have been doing C++ for most of my career.
Instead of choosing JS I chose to invest in mobile and developed for iOS,
Android and Nokia. Then I got back to system programming and will probably
transition to software architecture.

I'm currently very interested in safety, security and reliability, which is
basically the opposite of JS development culture. It seems to me that it's a
big world development world out there.

------
bhaak
> The majority of my job consists of maintaining about a dozen legacy Rails 2
> / Ruby 1.8.7 applications, written between 2008-2010, [...]

I would be sick of that, too.

I'm also sick of criticism on Ruby when you actually want to criticize Rails.
There is a significant overlap in the two communities of course, but both have
a distinct profile and you can't just lump them together.

In this case, it's also not helping that they have to stay on an ancient Rails
version. With Rails, it's a much smoother experience if you can follow the
major releases but especially the upgrade to Rails 3 was a painful one.

Edit: I don't want to imply that you shouldn't criticize Ruby but if you do,
don't confuse issues of Rails with those of Ruby. Rails and Ruby code do have
quite a different feel to them. It goes this far that when I write a clever
little Ruby snippet in a Rails app, I almost feel dirty as it doesn't belong
in there.

~~~
mercer
I learned Ruby before I learned Rails, and the books/tutorials I followed were
pretty heavy on the metaprogramming and OO usage (inheritance, etc.).

What I find fascinating is that when I read more recent articles/books, the
approach is much more functional in nature, with the OO part sometimes seeming
little more than namespacing (Sandy Metz, for example).

I do think Rails, for all the good stuff it did, promotes 'bad' use of Ruby.
But even 'idiomatic Ruby', based on the books-you-should-read suffers from
similar problems.

It's all fun and exciting to write Ruby code, but if I hadn't been subjected
to the 'avoid too much inheritance' and 'write your OO code in a hybrid OO-
and-functional way', my output would've suffered from the same issues Rails
code does.

That's not to say that I dislike Ruby. I love Ruby. But it doesn't strike me
as a good thing that maintainable Ruby code means _avoiding_ a lot of the cool
stuff.

~~~
bhaak
> That's not to say that I dislike Ruby. I love Ruby. But it doesn't strike me
> as a good thing that maintainable Ruby code means avoiding a lot of the cool
> stuff.

Ruby is in that regard a lot like C or Perl. It gives you lots of power and
options to solve a problem your way but that doesn't mean you should always do
so. Rails has used those options extensively and that explains a lot of the
criticism you hear about it.

This also means Ruby is not for everybody but what language is? IMO you can
write unmaintainable code in any language and there is none that makes that
hard enough, so I'm firmly in the camp that I'd rather have the full power at
my fingertips when I need it than being restricted.

Although with the renaissance of functional programming, I would also love to
discover a functional language that felt as fresh, powerful, and elegant as
Ruby was for OO programming.

~~~
hesarenu
_Although with the renaissance of functional programming, I would also love to
discover a functional language that felt as fresh, powerful, and elegant as
Ruby was for OO programming._

Elixir?

~~~
bhaak
Elixir is a possible candidate, yes.

I had 2 coworkers that were fanboying over it, so I already got some opinions
but I haven't had time to look into it seriously.

------
oliwarner
If these programmers spent half as much time coding as they did bitching about
their and others' programming environments, I think they'd get a lot more work
done. Not to mention, be happier with life.

Honestly, I think part of maturing into a senior software engineer (and later,
a _good_ manager) is accepting that while things aren't perfect, they're
plenty good enough to solve your problems and make money.

I'm not saying there aren't occasionally valid complaints, and sometimes these
new tools (Docker, et al) _are_ really good, but the sorts of developers I'm
describing here always think the grass is greener when it's programmed in
another language. No, of course they aren't factoring in the months it takes
to convert over for a 1% productivity "boost". All this grumbling does is
hasten your language and tools dropping out of fashion and never improving.

If you want things to get better, contribute to your language and its tooling.
If you don't, just switch out and use something else. Can we skip the swan
song each time you decide something isn't good enough for you?

~~~
kodablah
> Honestly, I think part of maturing into a senior software engineer (and
> later, a good manager) is accepting that while things aren't perfect,
> they're plenty good enough to solve your problems and make money.

I don't think this at all. I think part of maturing into a senior dev is
having the experience to know what makes you happy, what makes you unhappy,
and still make money.

For many the journey matters, and for the more passionate, "good enough" is a
give-up mentality. And it's a good thing you don't have to keep these thoughts
to yourself...you should feel free to share.

~~~
falcolas
Happiness... Passion... these terms don't mean anything when it comes to
maturity as a programmer.

Maturity as a programmer means being able to identify and do what it takes to
get things done. Whether a developer is "happy", or "passionate" only begins
to matter when they're doing what needs being done.

A true sign of maturity is when a programmer is faced with a workload that
they are deeply unhappy about, but still get it done, because it needs to be
done. The corresponding sign of mature leadership is acknowledging that
developer's unhappiness and giving them extra money, work they enjoy, and/or
time off after the crap work is done.

~~~
kodablah
I guess we're just maturing in different ways. Your definition sounds like a
big company doing less-rewarding work and middle management. For me, it was
realizing you don't have to move towards management or dealing with lots of
"crap work" (can't avoid it all of course). Also with maturity comes the
realization that things that need to be done and being happy while doing it
don't have to be mutually exclusive.

~~~
falcolas
If you were tasked with maintaining a 10 year old codebase, your happiness
really doesn't matter. If you don't find code maintenance enjoyable work,
you're not going to enjoy the work. Sure, you might be able to make a game of
it - to make it enjoyable - but that has no real bearing on your maturity as a
programmer, just your personality.

That some programmers truly enjoy their work is a gift that they are lucky to
have; not a sign of maturity.

~~~
kodablah
> If you were tasked with maintaining a 10 year old codebase

Then I quit my job. As a quality senior you have the leverage to pick where
and how you work. Otherwise, you may be thinking of just a tenured junior or
someone who was given a title of "senior". This is why I said earlier "part of
maturing into a senior dev is having the experience to know what makes you
happy"...not just doing what someone tells you.

~~~
mdpopescu
Heh. I actually enjoy maintaining old code, as long as that means I can
improve it while adding new functionality.

If it means "no, we can't change that method with a 200+ cyclomatic complexity
because the NY office wrote it and they would be upset about it" then yeah,
that would suck. (Real story in a recent contract with a bank.)

------
artellectual
It’s a shame that people feel this way about Ruby. The thing about ruby and
scripting languages like JavaScript is their nature make them very easy to dig
in. That’s why you see these scripting languages being used everywhere. The
same problems mentioned here plagues JavaScript yet it’s the most used
language on the web.

I’ve personally built rails app that have been running for the last 5 years
with clients using it to process millions of USD and I rarely have to touch
it. And even now when I have to make changes it’s easy to fix and patch up
because it was built right.

Most founders who don’t understand development “need things done yesterday”.
If your business doesn’t take into account technical debt you are going to
skimp on things and cut corners. It’s not ruby’s fault. It’s the business
owners job to understand development and the process of building risilient
long lasting software and not put developers into impossible timeframes.

From my experience business and marketing people who “need it now” don’t know
what they are doing business wise too. Businesses take years to build. Nothing
is ever needed “right now” if business is well planned and well executed.
There is always enough time, and if there really isn’t technical debt is
accounted for and fixed quickly.

That said it’s also important that technical leadership constantly inform and
communicate with business end regarding development time and the concept of
technical debt.

Don’t even get me started on business people who “need it now” based on
“projections”, and then forget about everything they asked for the next day.
Or “I need it now” “make it happen” to stroke their ego.

When you find yourself blaming the tool look at yourself as an individual and
look at your team.

~~~
gaius
_The same problems mentioned here plagues JavaScript yet it’s the most used
language on the web._

JS achieved popularity because it was the ONLY choice in its domain. That's a
rarity in PLs, and can't be extrapolated to any other language that I can
think of offhand.

~~~
pjmlp
Some examples.

\- UNIX and C.

\- Android and Java

\- Windows and .NET/C++

\- JME feature phones

\- iOS and Objective-C/Swift

Or to taking it down to memory lane,

\- Burroughs and ESPOL/NEWP

\- IBM RISC systems, IBM zOS and PL/8

\- IBM 400 and PL/S

\- Lilith and Modula-2

\- Native Oberon and Oberon

\- UCSD and Pascal

\- Lisa, Mac OS and Object Pascal

\- Lisp Machines

\- Smalltalk workstations

\- Xerox Star and Mesa

\- SpinOS and Modula-3

\- .... (plenty more to list)

~~~
porfirium
>Windows and .NET/C++

Not true. .NET is VB, C#, which are completely different from C++, and you can
write a Windows application in almost any language imaginable.

~~~
pjmlp
.NET is VB, C#, F# and C++/CLI.

Sure you can write a Windows application in anything else, but be prepared for
a 2nd class experience, writing FFI bindings on your own for the Windows API,
without access to the tools provided by Visual Studio.

~~~
emh68
Everyone forgot about good old win32 it seems...

------
mosselman
I don't really see how this would be much more different from language to
language. The being 'sick of' part, not so much the specific irritations.
Every languages has its issues and from all the languages I have tried I have
found Ruby to be the most pleasant to work with, but I am sure this is
different from person to person.

One of the struggles that the writer seems to have is that programming
applications is not science, but he seems to think it is. DHH has a great
keynote on this phenomenon: "Writing Software by David Heinemeier Hansson"

[https://www.youtube.com/watch?v=9LfmrkyP81M](https://www.youtube.com/watch?v=9LfmrkyP81M)

As mentioned in the comments of the article you will run into issues with any
programming language. One of the tricks is to not hold on so tightly to
'rules'. Like (take from the article) 'break functionality into lots of small
objects'. This is horrible advice if applied to all situations. You should
only do this when it makes sense. I see so many programmers breaking up
everything in useless classes and methods/functions/whatever just because
someone wrote a blog post about doing so. This just makes complicated code
look simple at a glance, but when you want to find out what the code really
does you have to jump up and down through files looking at what each function
does, you have to open split screens between abstract classes that have some
dedicated piece of code in a class that had to exist in order to satisfy the
'break things up' rule, etc.

Long story short: just relax, write code (in whatever language you like, for
whatever reason), go home and enjoy your family, friends and hobbies.

~~~
adamnemecek
saying that all languages have issues is definitely painting things with a
broad brush. Why would I want to use an unmantanable slow language when I can
use a fast maintainable language.

~~~
bsmithers
If you haven't discovered issues with your language of choice then you haven't
used it enough

~~~
lloeki
Saying that all languages have some sort of idiomatic issues therefore there's
no point complaining about language X is a fallacy that attempts to completely
sidestep the issue at hand. You have to admit that although they may be Turing
complete, all such languages are not pragmatically equivalent and some have
significant pain points, possibly more impactful than others, otherwise we'd
all code in INTERCAL and be all the merrier

~~~
macintux
I once wrote (by hand, over 3 or 4 pages) a program to add (I think, been >20
years) two integers using a Turing machine. I can definitely attest that not
all languages are equivalent.

------
antirez
I've a love/hate relation with Ruby because I think the language itself, is
one of the best incarnations of modern very high level programming: the way
OOP, imperative, functional primitives are put together is great. On the other
side I don't like the programming culture that the Ruby community formed,
which is on the average not super focused on stability, quality,
documentation, essentiality, simple code. At the same time, coming from the
Tcl interpreter, I was also not super happy in the past with the Ruby C
implementation: once I rewrote certain long running tasks from Tcl to Ruby,
memory usage exploded, performances were no longer deterministic, regardless
of the fact that the two languages were more or less at a similar level of
abstraction and speed. So I love you Ruby, but it's hard to use you.

~~~
pjmlp
I think Ruby missed the opportunity to be a more general purpose language
beyond Rails projects.

Since its early days, I was hopping for it to gain AOT/JIT compilation
support, eventually by getting some inspiration from Dylan.

RubyMotion seemed to be it, but because it is commercial product, it is
largely ignored by the community.

The JRuby work is awesome, then again some in the Ruby community suffer from
Java allergy and won't touch it.

Now we have Crystal as the best way to get a bit of both worlds, AOT and Ruby
like syntax, but still alpha quality.

~~~
look_lookatme
I agree about Crystal, the way it dispenses with metaprogramming in favor of
macros is simple and elegant and optional type restrictions gives me most of
the control I want.

------
raverbashing
Ruby is "too magical" for its own sake. And then people abuse their right to
use it, things like overriding class methods, etc (the syntax doesn't help in
the least and it has some weird quirks when compared to python)

I'd take a smoke test and some high-level functionality test before the over-
testing preached by the TDD "gurus" or any crap spouted by uncle bob. 100%
code coverage is a myth, your code still can fail spectacularly with a good
code coverage and guess what, most of the software in production today was not
TDD'd let alone unit tested.

People sell TDD like a OCD inducing religion instead of something that might
be a good idea in some specific cases

~~~
crdoconnor
>Ruby is "too magical" for its own sake

Magic is extremely useful in the right place (e.g. building ORM or admin
frameworks) - these can save you from writing a ridiculous amount of code.

Unfortunately since it's an 'advanced' feature lots of programmers want to
shove it in places where it not only isn't necessary, but is actively harmful.

Python has all the same features and allows you to write code that is equally
horrible (or powerful), but it benefits from a cultural bias in favor of
simplicity.

That said, I've still seen unnecessary magic code written by people looking to
prove that they are no longer "intermediate developers".

>People sell TDD like a OCD inducing religion instead of something that might
be a good idea in some specific cases

I think TDD with integration testing works in almost all cases, but unit tests
fail or work poorly in about 85% of cases. Unfortunately, unit test driven
development is what the zealots preach.

~~~
mypalmike
> Python has all the same features and allows you to write code that is
> equally horrible (or powerful), but it benefits from a cultural bias in
> favor of simplicity.

It's not a cultural bias. It's a critical difference in the language designs.

In python, monkeypatching is scoped to a module.

In Ruby, monkeypatching is global to the execution environment.

So in Python, you can look at the source code for a module in isolation and
deterministically reason about what it does.

In Ruby, you can't. Because you can't know what the execution environment will
be.

IMO, it's the main reason why Ruby projects become harder to manage as they
grow. Somewhere, someone is monkeypatching, and reasoning about the code
becomes harder and less local. I spent 2 years with Ruby and will never use it
again if I can help it.

~~~
crdoconnor
Monkey patching can still make horrendously unreadable python code. I agree
that it's better that its scope is localized, but I still think that it's more
important that monkey patching is used sparingly, and that requires a cultural
bias against it.

~~~
raverbashing
Yes, there are few (but important) use cases for it

\- Patching a library for testing purposes

\- Fixing a bug in some library you can't change

------
skywhopper
(2014 btw)

This is all true about Ruby: the things that make it feel so powerful come at
a big cost. But of course what the best solution is depends on what you are
trying to achieve.

I'm curious if the author pursued learning Haskell and what he thinks of it
now. Side effects are inevitable in any non-trivial application that interacts
with the real world. They may only happen outside the runtime, but Haskell's
design makes allowances for the perfection of its type system when it comes to
interacting with other systems. Ultimately, the extent and impact of side
effects have everything to do with the design of the program, and your
compiler won't save a poor design. The true test of the design is years of
real use and evolution and maintenance, and so I'd love to hear from people
maintaining a huge years-old Haskell codebase how it compares to other
languages.

------
diminish
Very weird doing a lot of JS work after Ruby - I feel the same about
Javascript, ES6, ES6++, or Typescript. All the code bases I inherit appear to
be verbose, useless cruft just to overcome some limitation or to achieve some
useless pattern.

~~~
whostolemyhat
What's ES6++?

~~~
diminish
Javascript after ES6. I don't think we'll see ES7 etc - so I name them ES6++.

------
neya
While I do echo some of the sentiments of the author, I still LOVE Ruby. I use
it for small scale projects, for very quick data processing needs or on
Jupyter notebooks. I used to run a full fledged Ruby shop a year or two ago
and I have to tell you, in this day and age, even today, there is NO full-
fledged equivalent to Rails.

Having said that, now I predominantly use Phoenix/Elixir for most new
projects. And the framework is moving ahead blazing fast. It has its own pros
and cons, but overall, it's been a VERY positive experience and it actually
saves me a LOT of time because I'm able to find code errors at compile time.

It's almost the only alternative to Rails which seems like home if you're
transitioning, but it still has its own issues. For example, they screwed up
the code organization with contexts, renamed the web folder a couple of times
and so on. But these are small issues and I'm amazed at the productivity I
gained by using Phoenix.

I wrote a full fledged Stripe API library in under 12 hours. Well tested and
rock solid. Pattern matching is heaven and in many ways, your code is more
robust. I have written libraries in Ruby too, they take more time simply
because there are lot more tests that need to be written.

I would never go as far as saying "I'm sick of Ruby", simply because it's
still a great programming language, if you're getting started and also
because, I believe in the man behind it - Matz. He has a philosophy and
believes in it. It takes enormous passion and dedication to believe in what
you've created, support it over decade(s) and keep on improving it. I can
point you many languages that have died over the years because they lacked
this passion and dedication.

Same thing goes for DHH as well. I really applaud him for patiently tolerating
so many people bashing the framework he helped to create that revolutionized
web development. He's also very very chill and respectful about others'
opinions. [1]

Having said all this, I hope Ruby 3.0 has a strong come back which is much
needed at the moment.

[1] [https://www.quora.com/What-do-you-think-of-Elixir-and-
Phoeni...](https://www.quora.com/What-do-you-think-of-Elixir-and-Phoenix-in-
comparison-to-Ruby-and-Rails-Do-you-think-it-is-possible-and-even-
recommendable-that-a-lot-of-Ruby-Rails-devs-move-towards-Elixir-Phoenix-
in-2017/answer/David-Heinemeier-Hansson)

~~~
pjmlp
I don't have any idea how it looks nowadays, but Rails 1.0 wasn't that big
deal, because already in the Tcl days there were Rails like application
servers being written.

Like AOLServer, Vignette and our very own at the startup I was working on
during the first .com wave.

The big deal was that many developers weren't aware of such stacks.

~~~
mhd
I think the killer feature for a lot of developers when Rails came around was
the ORM. IIRC AolServer didn't have an equivalent to ActiveRecord, and never
having to touch SQL or know a lot about database design was a big boon for the
kind of developer who got into RoR. The rest was mostly more magical PHP.

~~~
pjmlp
AolServer might not had one, but Vignette and our in-house solution surely
did.

You would declare an "entity" type and all CRUD operations would be
automatically generated for Informix, MS SQL Server, Sybase SQL Server, Oracle
and DB 2.

With the possibility of extending with extra queries that look like entity
methods.

~~~
look_lookatme
Most ORMs I dealt with at the time were strict code generation from
configuration or db introspection, so there was essentially a 'compilation
step'. What AR had at the time was you extended a base class and directed it
to a database and your objects magically figured everything else out. Change a
table schema and refresh _only_ your browser and the new state was reflected
in your application. That was a very magical in 2006 and having a fully
working ORM with 2-6 lines of _code_ (not configuration) per
schema+relationship was incredible.

~~~
pjmlp
Our 'compilation step' was at application startup, restarting the server was
enough, in 1999.

~~~
look_lookatme
All may be true but it clearly wasn't as easy to pick up as Ruby and Rails.

[edit]

Oh right, your in-house solution. Well congrats on having it figured out in
1999.

~~~
pjmlp
Vignette could also do it.

Digging a bit on past memories,

[http://www.tcl.tk/customers/success/vignette.tml](http://www.tcl.tk/customers/success/vignette.tml)

[https://en.wikipedia.org/wiki/StoryServer](https://en.wikipedia.org/wiki/StoryServer)

------
blunte
Everyone who has used Ruby for some time (at least one full project) will have
different bad memories, as well as probably some very happy memories.

Few would dispute that Ruby is a great language for getting things done with
small, expressive code. And Rails, which is what probably brought most of us
to Ruby, was at its time the ideal web framework. It was able to be
generations ahead of most other frameworks because of the capabilities Ruby
afforded it.

However, time moves on, versions of the language, framework, and gems change.
Projects grow and evolve. These are where the pains really begin. But this is
not really so much about the language but about real world project lifecycles.

For me, the first real pain was performance. At some point, you cross a
threshold where the performance goes from reasonably ok to WTF is happening?.
Then you start profiling and discover that the wonderful collection and ORM
operations you've been doing are extremely expensive. That's when it stops
being fun.

Then, if you explore other languages, you may discover the absolute joy of
Clojure (once you devote the time to think functional and appreciate Lispy
syntax). Plus you get a big performance boost (as well as access to tons of
Java libraries that are usually very performant). But alas, then you discover
that there's no real Rails equivalent for Clojure. (I now understand that
there are great options if you're willing to cobble your own together.)

Finally, you might hear of Elixir + Phoenix. Suddenly (again, if you're
willing to learn and think functionally), you find joy. Performance is much
better than Ruby, the Phoenix framework feels Railsy, and you get the benefit
of the industrial Erlang VM underneath it. The downside, however, is that
Elixir and Phoenix are young. Fortunately the community is friendly and
helpful.

For me, it's not that Ruby is bad; it's just that I now realize how much
better functional programming is for me personally. And when I just need
something quick and dirty, Python is already installed. Ruby is like an ex-
girl(or boy)friend that you still like, but who no longer fits into your life.

~~~
emodendroket
> Everyone who has used Ruby for some time (at least one full project) will
> have different bad memories, as well as probably some very happy memories.

I feel like the happy memories are more for greenfield development than
maintenance. I don't have any particularly happy memories of Ruby anyway.

~~~
blunte
This pretty much sums it up. It's fun to write things in Ruby. It's not fun
when those things grow up and need care and support.

~~~
emodendroket
Yeah, I feel like everyone I worked with on that project (the original guys
were long gone) who wasn't a dyed-in-the-wool Rubyist just really came to hate
Ruby.

------
cobbzilla
my sense is that ruby has a perl problem. yes, you can write very beautiful
things in it, and if you follow the idioms you're generally safe. but there's
way too much rope to hang yourself with, too much "magic", and no way to
reliably refactor large codebases. As a language, it doesn't scale well into
"programming in the large" unless you really know what you're doing, and most
frankly don't.

------
wiradikusuma
I have a similar experience with Groovy, the "Ruby of Java".

I wanted to quickly prototype an app, so I used Groovy. It was very
productive, esp since I deal with lots of JSON. Over the time, the prototype
has grown to be a serious app, and boy I hate refactoring it. Stupid mistakes
such as method renaming can be a nightmare. Yes I should have written more
unit tests, but my excuse was it's just a prototype.

~~~
sgift
> Yes I should have written more unit tests, but my excuse was it's just a
> prototype.

Never understood this point "well, you don't need types, you can just write
tests for it". IMO you should never have to write tests for something a type
system can find for you. Why should I waste time with something which can be
found by the compiler?

~~~
crdoconnor
I find that strict type systems are good for 'locking down' execution space
and sanity checking but they're not effective at cleanly specifying higher
level verification even when that's possible.

I'd rather use a combination of tests and stricter type checking. There's no
sense in being a fundamentalist about either approach.

~~~
sgift
> I'd rather use a combination of tests and stricter type checking. There's no
> sense in being a fundamentalist about either approach.

Completely agreed. I tend to prefer pragmatic solutions over strict adherence
to some methodology. As a sibling comment noted the natural end of specifying
everything beforehand would be formal systems, which are usually not worth the
effort. On the other hand I don't see "let's just throw everything the
compiler could help us with out, because it's a bit more effort" as a sensible
strategy.

------
NumberCruncher
>> The majority of my job consists of maintaining about a dozen legacy Rails 2
/ Ruby 1.8.7 applications, written between 2008-2010, with essentially zero
tests amongst them (when I started).

One can write unmaintainable code in any given language/framework. I am not a
fan of OO but in this case I would not blame OO but the one who developed this
messy app.

------
randomsearch
Beware the enthusiasm of the recently converted.

~~~
iso-8859-1
But if he had been writing Haskell for 10 years, he would become humble like
most Haskellers are, and he would write no blog post at all. :P

~~~
agumonkey
They're not humble or silent, they just obfuscate insult in unicode antique
code points over the category of categories.

------
keymone
Ruby: the only problem i have with Ruby is that it is too easy to make a mess.
and i do hate rspec with a passion. it's a perfect example of a DSL done
wrong. otherwise Ruby's one of the most enjoyable language i've worked with.

dynamic typing: old debate and author contributed nothing to it.

side effects: with enough effort and discipline ruby can be very much
functional and side effects are less of an annoyance.

oop: yeah, but more specifically "what oop has become in past 30 years".

~~~
ajnin
> side effects: with enough effort and discipline ruby can be very much
> functional and side effects are less of an annoyance.

Not when importing a module written by someone else, as all non-trivial apps
need, can impact _your_ code.

~~~
keymone
true, but over time you get better at isolating these gems (pun intended).

------
throw2016
Most ruby apps have always been a complete pain to setup.

The idea of having a build environment and language specific package managers
for deploy and pulling in hundreds of dependencies directly leads to
dependency hell, a user-hostile setup process and inevitably limits the
language and apps to saas type use cases.

The only major end user focused ruby apps left are what, discourse, redmine,
jekyll? Discourse probably recognizes the complexity of their setup process
and has a docker only install which just hides and postpones the complexity,
Redmine tries to be available via distribution package managers and user
frustration with updating Jekyll is well known.

The people who benefit from this kind of adhoc ecosystem of hundreds of small
packages, package managers, anything goes are the completely self interested
jockeying for influence and move on to the next new thing, the language is
left with the debt and its entirely the fault of the language developers.

The same thing exists in Node and has now been adopted by the PHP ecosystem
taking away the easy setup benefits of PHP.

------
antod
There's dynamic typing, but then there's also all the extra stuff like mutable
global state, gratuitous monkey patching, fad following, overindulgence in
complicated implementation cleverness just to make interfaces more elegant etc
etc that the Ruby/Rails community has produced and promoted.

------
kristaps
I see the "you need to write less tests because static typing" statement
thrown around a lot (including the article), but haven't seen any detailed
discussion on why that would be so, could someone point me to a more in-depth
look at that?

~~~
bjz_
Testing attempts to pin down specific use cases to ensure that they meet
certain requirements. Alas they only single out one case at a time - there
could be a wide range of possible failure conditions you forgot to test. Types
allow you to cut down the space of possibilities to a more manageable level to
ensure that your testing can be more targeted.

To see this pushed to the extreme, and to have a glimpse of the future, check
out Edwin Brady's book "Type Driven Development with Idris":
[https://www.manning.com/books/type-driven-development-
with-i...](https://www.manning.com/books/type-driven-development-with-idris)
\- I don't expect this style of programming to become the norm until at least
another several years, but it essentially allows you to push all behavioral
specifications into the types, rendering most unit testing tests obsolete. Of
course I would still have smoke and integration tests to for sanity checking
sake.

------
blatherard
I perused the author's blog and peeked at his LinkedIn profile. It looks like
he continues to do Ruby development, and still calls himself a "Ruby on Rails
Developer." I wonder what caused him to change his mind?

~~~
jbreckmckye
Golden handcuffs? This is an industry that rewards specialisation. There's not
many jobs for Ruby-turned-Haskell developers.

------
sink
This isn't really about Ruby. It's about the other things in the title. I
suppose that calling out Ruby by name was necessary to make this blog post
concrete, and to make it easier to relate to. The author also mentions
Haskell, but that really isn't necessary to get the point across. The
comparison could have been between Python (written in an OO fashion) and ML.

You can write, 'I hate X because of dynamic typing, side effects, and object-
oriented programming' for many values of X. Similarly, the reasons why the
author is drawn to Haskell can be applied to a large number of other
languages.

~~~
lmm
Yes and no. Ruby has a particularly dynamic, side-effecty culture, even more
so than Python (where monkeypatching is less encouraged, OO is less of a
focus, and, not coincidentally, unit testing is far less a source of fuss and
trouble). Haskell goes in for stronger isolation of side effects than OCaml
does. Any given language will be at some point on the spectrum, but Ruby and
Haskell are probably the extreme ends of that spectrum as far as mainstream
languages go.

------
Doctor_Fegg
> I mean, would you be comfortable if your bank relied on software that
> behaved like this? If not, then why are you even using it for anything else

Because not everything I do impacts on the finances of a million people?

------
rdsubhas
Most problems with Rails:

\- Fat models (huge number of hooks, scopes, many methods stuffed inside in
the name of "domain-driven design", etc)

\- Fat controllers (huge number of shared methods, hooks, shared variables and
hooks, concerns, etc)

\- Fat views/helpers/templates

In multiple years of working with Ruby (+/\- Rails) - there is one talk that
changed my whole mind of scaling systems - aka ways to build the majestic
monolith [1]. And I believe the author of that talk would be laughing silently
at this post right now, thinking, "I know what you're talking about".

Models, Models, Everywhere by Chris Griego:
[https://speakerdeck.com/u/cgriego/p/models-models-every-
wher...](https://speakerdeck.com/u/cgriego/p/models-models-every-where)

Check out those slides, and check the codebase. This is not a Ruby problem.
Splitting things mindlessly into microservices, trying to go "fully
functional" (answer: nope, nothing in the world is pure or perfect),
everything has trade-offs.

[1] Majestic Monolith: [https://m.signalvnoise.com/the-majestic-
monolith-29166d02222...](https://m.signalvnoise.com/the-majestic-
monolith-29166d022228?gi=f03ff2ca413e)

------
oelmekki
I've actually moved from ruby too (although, still doing some for contract
work), but I wouldn't say the language is the problem, nor rails. I was more
tired of the community, actually (not the opensource community, but the
coworkers).

Ruby and rails were awesome in the late 2000', when most people were trying to
get their essence and do crazy and smart things with them, always focusing on
making things easier for the (dev) user.

But then, soon after the start of the 2010', it started to get really
ubiquitous, and there were a lot of people using it who weren't especially
passionate about development. They started to make everything complicated, not
bothering about trying to make things easier, and kept talking about "good
practices", following them blindly without having any clue what problems they
were supposed to solve.

This is probably something that occurs naturally for any successful tool. I'm
not even blaming those people. And it seems quite normal to me that after
spending years among passionate only people doing cool things, we feel bored
when things normalize. Time to find an other community, no hard feelings.

------
_Codemonkeyism
After 10 years of the same article over and over again I'm so bored. Or sick.

------
TimTheTinker
I feel like Ruby’s sweet spot is sort of as a cleaner, more capable, more
ergonomic Perl, with nice message-passing OO and a super-convenient standard
library. Text processing? You bet! Command-line utilities, test harnesses for
JVM-hosted APIs (using JRuby), small network services, ... in those domains I
feel very productive with Ruby.

But for core business logic? Definitely not my first choice.

~~~
meesterdude
> But for core business logic? Definitely not my first choice.

I have an alternative perspective. It's clarity, refactorability and testing
ability make it a great choice for core business logic. In fact, I am yet to
see a cleaner alternative. I've seen rails app's go from monolith to Go
microservices, and the clarity of whats going on and agility for change is
just gone. It becomes a nightmare to work with.

~~~
TimTheTinker
Interesting... I personally prefer C# for core business logic. OO where you
need it, great libraries & interoperability, functional programming support...
good stuff.

Wish I had time to look into Clojure. Excellent programming paradigm along
with the interoperability, libraries, and platform support of the JVM.

------
noncoml
Never used Ruby really, apart from some Rails programming here and there, but
I completely agree: dynamic typing + side effect + OO patterns => technical
debt.

On the other hand I think pure languages, like Haskell, take it too far.

My ideal language would be something like Haskell + limited side effect
support(for IO) + ecosystem of something like Python or Java or Golang.

~~~
halotrope
Check out [https://elixir-lang.org](https://elixir-lang.org)

~~~
tigershark
Although I really like elixir, I thought he asked for something with static
typing?

~~~
dnautics
elixir is sufficiently close. It's reasonably strongly typed under the hood
and although the spec syntax is a bit awkward, it can give you compile time
assurances of correctness in a majority of cases if that's what you want
static typing for.

There is an argument for performance, but static typing really gets the
performance benefit when you have fixed size data type arrays. Elixir has
powerful bit and byte manipulation in the standard library for many such
operations, and if you're really looking to do mathematical transformations of
arrays and matrices, you shouldn't choose elixir.

~~~
dinduks
> It's _reasonably_ strongly typed

> time assurances of correctness _in a majority of cases_

So basically, _let 's do it and pray it works, maybe_?

~~~
dnautics
You don't have to pray. In elixir/erlang the motto is let it fail. If it
fails, it crashes, and you have supervisors that are nearly free, and your
service will resume itself noncatastrophically. You're generally free to code
the happy path.

------
riffraff
missing in title: [2014]. Though I've heard the same things a lot longer than
that anyway :)

------
dzink
I switched from Ruby to Go and could hardly be any happier. Go feels powerful
and simple at the same time. I code whatever i need to code easily, instead of
hunting for frameworks and evaluating dependencies (or dreading the next
deployment when a dependency changes unexpectedly). The code is easy to read
and maintainable due to the lack of multiple layers of abstractions and
inheritances. It's refreshing.

------
solnic
s/Ruby/Rails/g in the article and it makes more sense. You can write pretty
good Ruby code, which avoids side-effects, monkey-patches and is easy to test.
All you need to do is abandon Rails. There are many modern Ruby projects which
make it simpler, see dry-rb.org, rom-rb.org, hanamirb.org and trailblazer.to

------
AznHisoka
Ruby is a not a great language but my main complaints are:

1\. installing rvm breaks sometimes due to random code changes (i think the
maintainers fix them recently)

2\. they seem to think every app has just 1 database so they dont support db
sharding themselves without a third party gem.

3\. Net::Http is probably the most unintuitive api for crawling web pages.

------
neilwilson
I'm old enough to remember sick of static typing, pointless indirection and
mixed paradigm code.

And thus the centralisation/decentralisation wheel turns again because the new
generation think they have discovered something new but ignore the lessons
learned in the past.

If only we could fix that human tendency with a code upgrade.

~~~
lmm
No, we really have discovered something better. We oscillate but we are
converging: these days all serious statically typed languages have some level
of type inference, and all serious dynamically typed languages have some level
of optional type checking. We end up overcorrecting each time - Ruby was an
overly dynamic, unmaintainable response to the strictness of Java, and no
doubt some post-Ruby languages go too far in the straitjacket direction - but
at the same time languages on both sides are better than they were previously.

~~~
neilwilson
Ruby has optional type checking. What do you think the testing regime is
about?

It's a compiler that is built for each project with types specific to the
domain problem being solved.

Language type checking misses the point. The types I want to check, and the
extent I want to check them, are in the spec files.

Go type inference, for example, is deeply primitive and an awful lot of Go
code seems to spend its time implementing duck typing via work arounds. It
looks an awful lot like dependency injection for the 2010s.

~~~
bjz_
Go is a terrible example of a statically typed language. Now that is an
example of a bunch of people not learning from the past - ie. the entire
lineage of ML-based languages!

A rich type system lets you mold and shape the types to fit nicely over your
domain, effectively becoming a machine-verified DSL for your business problem.
It will catch flaws in your mental model before you even begin to write tests
or an implementation, and is a cheap way of sketching out your ideas and great
documentation to have over the lifetime of your project. Of course you can't
fit it exactly, so you need a smattering of spec tests, and probably some
property-based tests for good measure to fill in the gaps.

~~~
neilwilson
Go is what people are using. And python for some reason which amuses me
greatly given we have Julia.

------
mattbillenstein
... from 2014

~~~
tree_of_item
Well, it hasn't gotten any better since then.

------
joaodlf
In all fairness, this applies to any dynamic language - Especially scripting
ones. Python, Ruby, PHP... It doesn't matter really, it's so easy for a
project to grow out of control. I have growing insecurities when I program in
these languages.

------
jchw
On a sort of similar note, I've been teetering between Python and Go. On one
hand, clearly you can move faster in Python. On the other hand, Go is faster
and I can be more sure that code that compiles and passes tests actually
works.

------
nanodano
This is part of the reason Go is gaining so much popularity. It gives you back
all the power and speed of typed, compiled language but without all the
tedious parts of C like managing memory and complicated threading.

------
thrownaway954
Now that .Net is cross platform, I've been switching everything over to C#.
Besides the fact that it's compiled, Visual Studio is a dream to work with.

------
andruby
This needs 2014 in the title. Can someone update?

------
jrs95
My experience with switching from static to dynamic or dynamic to static
typing is that it I've always missed the other at times. The flexibility of
dynamic languages is especially nice when your requirements change a lot,
which is a huge problem with what I'm doing now. I probably prefer static
generally, but I'm glad I'm primarily working with a dynamic language at the
moment.

------
souenzzo
As a clojure user, I think that testing is easy, even race condition goes
trivial with clojure +datomic.

------
erik_landerholm
If you can’t be successful writing ruby...I don’t know what to say. I’m a
manager/exec at a medium sized public company. Recently, I got to code in ruby
again after a long time. It was great. It’s still my favorite language. I try
to quit it, leave it for another newer, sexier language, but I just can’t.
Maybe crystal, but then you can have both!

------
emodendroket
Ruby makes it really easy to write code at the cost of making it much harder
to maintain.q

------
tomerbd
You are right.

------
KeitIG
"There are two kind of programming languages: the ones everybody hates and the
ones nobody use."

------
emacsgifs
2014

------
edu
2014!

------
megaman22
Ruby-style monkey-patching just seems like an awful idea. I cringe when I see
it used in JavaScript, though it is less and less often seen in the wild now
that browsers are less terrible and we tend to use babel and other transpilers
instead of having to shim and polyfill around the more broken parts of the
language.

~~~
hxegon
It's really not as bad as people make it out to be. Really handy when you need
it, and there are limiting mechanisms (refinements) for when you don't.

------
draw_down
It’s a lot easier if you cut it out with the types everywhere, and just focus
on writing functions that return values. Values! Pass around values, not weird
bespoke type instances everywhere. If that’s not OO, too bad. Above all, keep
it simple.

