
Happy Birthday, Ruby - _quhg
https://github.com/ruby-no-kai/ruby25/blob/master/dave_thomas.en.md
======
kemenaran
I'm currently working on a Ruby project, and I love the language so much! It's
elegant, fast enough for me, and the ecosystem rocks.

It seems that, after Ruby borrowed from many previous languages, a lot of
rubyisms went into Rust (the nice functional-style enumerations, the awesome
package manager inspired by Bundler). And I'm thrilled the best of the Ruby
world found its way into other languages.

A future where the elegance of the Ruby language is available both as an
interpreted-scriptable tool (Ruby) or a compiled-statically-typed language
(Rust) looks like a nice place to me.

~~~
marcolussetti
Wouldn't Crystal fit the bill for a fast compiled language explicitly designed
to emulate Ruby's syntax? (I don't have any significant Ruby or Crystal
experience, so if there are reasons why that doesn't fit the bill, I'm sorry)

~~~
eropple
So I do have a lot of Ruby experience, and I have used Crystal, and I've found
that Crystal being Ruby-ish in syntax doesn't help with the fact that it _isn
't_ Ruby and doesn't work like Ruby. Nor does Rust, of course, though I do
appreciate how Rust has liberally taken after Ruby in a lot of other ways. But
I find Crystal mostly frustrating in many ways related to how it looks and
presents itself. It wants to look like Ruby and it wants to court Ruby
developers--by not being Ruby, but also not providing enough reason to use it
over other languages.

There are tons of uses for non-Ruby languages. These days I'm primarily in
TypeScript and Kotlin, even though I really, really like Ruby; as-is it
doesn't scale, from the perspective of somebody who likes manageable code, as
well as I'd like it to. But when I want a non-Ruby language, I am not tied to
Ruby syntax (and I kind of think that Ruby's syntax works almost exclusively
_for_ Ruby? I think a lot of the expressivity of the Ruby language loses
something when you don't have its dynamic approach to the world) in a way that
makes Crystal, with its lack of libraries or maturity, not an appealing choice
of tooling.

(I also feel similarly about Elixir, though in Elixir's case there are also
some interesting things around BEAM that I might like to leverage. And I think
that a typed Elixir would get my attention _right quick_.)

~~~
andjd
> And I think that a typed Elixir would get my attention right quick.

Elixir _is_ statically typed, it just uses strong type inference so you rarely
have to explicitly type things out.

A key difference between Crystal and Elixir is that Crystal tries to replicate
ruby syntax in a more performant language, whereas Elixir tries to apply the
sensibilities of Ruby and the Ruby community to the Erlang VM.

~~~
eropple
I was using "typed" as shorthand for "statically typed", but Elixir is not
statically typed. Typespecs aren't static typing and IMO they get messy when
you want to do more than specify primitives.

[https://elixir-lang.org/getting-started/typespecs-and-
behavi...](https://elixir-lang.org/getting-started/typespecs-and-
behaviours.html)

~~~
dnautics
Dialyzer is indeed a pain in the ass, but what is not a pain in the ass is
vscode's elixir_ls plugin which incrementally dialyzes and gently nudges you
into making static type declarations (your code shows up uglier when you don't
do it).

Life changing. It's stopped me from pushing runtime errors probably about 20
times now, in the last few weeks that i've been using it. At this point I'd
say that it's strong enough to close 95% of the difference between static and
dynamic typing.

Elixir's (maybe going to be merged into the standard library) property
checking semantics (ExUnitProperty and StreamData) are quite amazing and super
easy[0], and will catch whole classes of things that your compiler won't so I
would strongly suggest checking out Elixir now.

[0] today I implemented in an hour a property check that makes me confident
that a mathematical algorithm that I implemented for a fuzzer is ok (my first
attempt was wrong), and then a property check that demonstrated that that
algorithm applied to a stateful set of events doesn't violate critical
invariants.

Also, you will almost certainly never get a statically typed Elixir, because
it makes a lot of things like hot updates hard or inelegant. Sending
interprocess/internode messages is something could be extremely intolerant to
a static type system, because, in a way you're breaching the purity of the
functional paradigm (it's the BEAM language's "one big lie"). Go struggles
with this a lot in its channel semantic, and it's why there is a ton of
boilerplate in gRPC (and almost no boiler plate in erlang RPC).

Also gently breaching the type system is incredibly useful in mock tests - for
example, in my current project I do about 60 high-load end-to-end tests in
parallel with clones of my central scheduling algorithm - this is possible
because my test suite reaches into the main body, dynamically creates a new
scheduler, and appends that information into an HTTP request, which is passed
into a "plain old map" and intercepted _only_ in test environment. This not
only greatly accelerates the end-to-end tests (I run the full suite as a
matter of course before each commit) but it also gives me confidence that my
system will run under a load that is greater than I can manually trigger.

------
pavlov
Ruby is the very least favorite of all the programming languages I've had to
use regularly over my career.

Its syntax strongly favors cuteness over familiarity. Wherever Ruby can
diverge from expectations to give you a pointless little tickle of whimsical
inventiveness instead, it seems to do so.

Visually it looks like an unwanted love child of Pascal and Python. There's no
clear rhyme or reason to the use of sigils and keywords.

The standard library and built-in types are acceptable for a mediocre '90s
scripting language, I guess. The difference between symbols and strings as
hashmap keys is a footgun that opens up endless bugs for the type of glue code
that you'd often be writing in Ruby.

Probably the only thing that keeps Ruby afloat is Rails, an extremely
resource-intensive web server framework built around assumptions of what web
apps were like in 2003. Everything in Rails seems to happen by pooping magic
keywords in your code or in file names according to mysterious conventions, so
when something goes wrong, you'll have a hell of a time figuring out why Rails
isn't calling your code or is generating broken SQL. OTOH it honors the Ruby
tradition of doing lots of unexpected and useless cute things like pluralizing
words in your database migrations [1].

[1] [https://stackoverflow.com/questions/1185035/how-do-i-
overrid...](https://stackoverflow.com/questions/1185035/how-do-i-override-
rails-naming-conventions)

~~~
TheRealDunkirk
So, I'm old, and have done lots of stuff in lots of languages in frameworks.
For about a dozen years, Rails was my go-to toolkit. I've written a couple
dozen production applications with it. Unfortunately, Rails has really fallen
out of favor lately. Even a Rails-specialty shop I worked for briefly has
pivoted to using ASP.NET. I've played around in that stack, and found it
lacking. (EF just doesn't compete as an ORM.) However, they've moved on to
bigger corporate customers, and those places just don't use Rails.

Recently, and because of this same we-don't-"do"-Rails sentiment, I was forced
into using Java for a web application. So I prototyped a site with Spring and
Angular 6, thinking this -- arguably -- represents the "state of the art" when
doing a Java web app. Out of frustration, I also cranked up a prototype with
Rails. What was taking me literally 160 lines of Java and JS, to build two
related models and a form to edit the relationship, took me 3 lines with
Rails. Nothing else I've found allows me to be as productive as Rails for
writing web applications.

I can understand criticizing Ruby for being clever. There are still magic
tricks you can do with it I've never even tried to understand. I can
understand criticizing Rails for being obscure. I realize that it took me MANY
years to be REALLY effective with it. But if you're telling me the alternative
for web applications is ANYTHING related to Java, I'll call you crazy.

I've just inherited a Laravel-based PHP site, which is so old I can't download
the version of the framework it uses. Yikes. I did PHP for about 10 years, 20
years ago. It doesn't feel like a lot has changed.

So, I'm honestly asking, as someone who hates Rails: What framework, out
there, somewhere, allows me to be as productive as Rails, but which is are
"better," somehow?

~~~
eropple
So...eh.

Ruby has the easiest data access tools, between ActiveRecord and Sequel (which
I prefer), out there. I don't know too many folks who'd disagree with you
about that. But where you're happy with Rails taking a few lines, I am as of
late big on Kotlin (because I agree with you regarding Java) encouraging me to
be _correct_. I'm building a new product using Spring Boot, Kotlin, and JDBI
and while, yes, there's boilerplate - it's not the thing that slows me down. I
liken it to touch typing; I don't worry if a programmer can't touch type
because getting text onto a screen is never the slowest part of the process.

The thing that slows me down, as it does whenever I'm programming, is
_thinking_ , and I've learned over time that Ruby doesn't really help me with
that. (A lot of other toolchains, both statically and dynamically typed--
hello, TypeScript!--do.) I just don't worry about writing a query with a join
- it forces me to understand my domain while I'm writing it, not when it runs
and bombs out with an error because I mistyped something or got the
relationship wrong in my head because my IntelliSense doesn't exist.

It depends on what you're prioritizing. I went back to the JVM for this
project in part for perf, but also because I have a pretty high bar for
correctness and I want to make sure my stuff works without writing in/out
tests for something as simple as types.

Horses for courses.

(Also, I would submit that the frontend SOTA for "Java" is React, FWIW, same
as almost anywhere else.)

~~~
joelbluminator
It's not just code bloat, typed languags and frameworks like spring have to
dance through hoops to allow for easy testability. Spring is founded on the
idea of dependency injection that's supposed to overcome that. In Rails/Python
and friends you just don't need that, and consequently things have much less
bloat.

~~~
eropple
...at the cost of globals all over the place and significantly fewer code-to-
interface (rather than code-to-implementatation) moments.

I'd rather test a well-factored JVM or .NET application than I would _any_
Ruby application I've ever seen in my life, to be frank. I've never, not once,
had to write a _mock_ (awful) for a test in a JVM or a .NET application, and
the quality of my tests reflect that.

------
thunderbong
I discovered Ruby in 2005 and immediately fell in love with it. Then came
across Rails which really tested that love, what with it's opinions and
everything!

And finally reached Sinatra, then Roda and love prevailed! Along the way,
discovered and enjoyed working with so many gems both in Ruby as well as part
of it's packages!

So, after 13 years now, I'm glad I chose the right language. A language which
always asks, is there a simpler, more beautiful way to do the same thing?

So, Happy birthday, and thank you.

~~~
colinbartlett
I’ve also been using Ruby full time for 13 or 14 years and I am really hoping
its popularity and commercial viability continues for another 13 years (or
another 25).

I’m certain my level of mastery contributes to my enjoyment. And it’s not that
I don’t like learning new things, I do! But Ruby is just an absolute pleasure
to write, and it’s hard to imagine spending 8+ hours a day living in any other
ecosystem.

~~~
taf2
definitely - it's not getting slower it's getting faster and more stable.
ruby's here to stay

------
sho
> Ruby isn't the most beautiful language out there

Huh, I sure think it is. I wonder what the author thinks the competition might
be? Ruby has its issues for sure, but aesthetics ain't one of them - far and
away my favourite out of any major language.

~~~
empath75
I'm not sure what language would be more beautiful than ruby, to be honest,
and it's not even my favorite language to use.

Let's do a mini code challenge in the thread -- implement fizzbuzz in the most
beautiful way you can, in the most beautiful language you know:

~~~
christophilus

        (defn fizz-buzz [n]
          (map #(cond (= 0 (mod % 15)) "FizzBuzz"
                      (= 0 (mod % 5))  "Fizz"
                      (= 0 (mod % 3))  "Buzz"
                      :else            %)
                (range 1 n)))

~~~
Slackwise

        (def fizzbuzz-nums (range 1 101))
    
        (defn fizz? [n] (zero? (% n)))
    
        (defn buzz? [n] (zero? (% n 5)))
    
        (defn fizzbuzz? [n] (and (fizz? n) (buzz? n)))
    
        (defn fizzbuzz [n]
          (cond (fizzbuzz? n) "FizzBuzz"
                (fizz?     n) "Fizz"
                (buzz?     n) "Buzz"
                :else         n)))
    
        (def fizzbuzz-list (map fizzbuzz fizzbuzz-nums))
    
        (apply println fizzbuzz-list)

~~~
christophilus
Simple.

But this brings up a debate I've been having with some folks. I have the
memory of a gnat, so I can't keep a lot of context in my head. I prefer the
previous two examples to this one, simply because with this one, I have to
remember a lot more contextual vocabulary.

It's a pet-peeve of mine to pull up a source file, and then have to ping-pong
around between 50 different function calls, when the entire thing could have
been written linearly in fewer than 50 lines of code.

On the other hand, small functions like yours are easier to verify at a glance
and move on. I haven't figured out what the right trade-off is.

Anyone else want to weigh in on this conundrum?

~~~
evdubs
Well, I would say that the primary refactoring done in Slackwise's example is
just to assign names to the different conditions and the list produced by
range. I think it makes most sense to break these things out and assign them
to names when they both become a common idiom in your code (it is used in
multiple places) and the logic spans a few lines or has sufficient complexity.
I, too, would rather look at one piece of code than have to find out what each
function is attempting to do if the name is perhaps ambiguous. For Slackwise's
example, I would say that that is too much abstraction because you've
basically created as many pieces of abstraction (the conditionals and list) as
there were lines of code without them. Maybe the decision for when to abstract
can boil down to:

* Is a common idiom in the code base / same logic used in multiple places

* Has "sufficient" complexity

* Can be replaced with a good name that is generally clear with what it will achieve

For Slackwise's example, I think that the names used in the abstractions are
exactly what I would use, but I also think that they're not really descriptive
enough. If I wasn't the original author and thought I should refactor the
names, I would probably try to choose divisible-by-3?, divisible-by-5?, and
divisible-by-15? because what the hell is a fizz or a buzz anyway? Maybe you
had already thought about all of this and wanted a deeper response; sorry to
disappoint.

------
loktarogar
Ruby was my re-entry into programming. Before it, I had tried programming in
highschool (c++) and, while I did well at it, felt like it wasn't for me. I
was going to go into some other field like Photography instead.

By chance I had to do a programming class in college, and they had put me into
the wrong one by accident - a final year software project in Ruby. I did
really well at it, fell in love with the language and got into other
programming languages from there.

I've been doing Ruby for 12 years now and it's my go-to language when I can
choose. My entire programming career has Ruby to thank.

~~~
sho
Me too actually. I flirted with programming around uni-time and after - PHP,
java, friggin' _ada_ \- and just couldn't see myself enjoying it so I went
into network management instead.

10 years later I was thoroughly sick of that, so started to look around and
heard about this little language called Ruby - and it was love at first sight.
Then this little software project called Rails started to gain momentum and
there was no looking back. 13 or so years and counting.

And now funnily enough just when I feel like Ruby is lacking a few necessities
in our always-connected world, along comes a project which is basically
reworking Erlang to look a whole lot more like Ruby - Elixir. I'll always love
Ruby but Elixir feels right for the next step, that kind of instant attraction
I never felt for the likes of golang. Here's to the next 13 or more years of
Ruby-like programming joy!

~~~
cutler
I don't get this Elixir as the natural progression for Rubyists. OO/mutable
Ruby and functional/immutable Elixir are worlds apart beyond the superficial
syntax similarities.

~~~
sho
> worlds apart beyond the superficial syntax similarities

I never understood this argument. That "superficial" syntax is what I have to
stare at, reading and writing, for 8 hours a day. That I actually enjoy doing
so is therefore hugely important to me.

I mean, you can make the same argument against Elixir itself, and I've seen it
done - Erlang old-timers arguing against the necessity of these "superficial"
syntax improvements. Suffice to say that I profoundly disagree.

~~~
cutler
I didn't say the syntax is superficial - I'm an Elixir fan, in fact. I meant
the similarities with Ruby syntax are superficial.

------
nickdrozd
> Ruby changed my life. Ruby gave me a whole new way of looking at things, and
> a whole new set of friends.

Matz himself said something similar about Emacs / Lisp [1]:

> Emacs made me realize anything can be changed by a programmer...Emacs taught
> me freedom for software...Emacs has changed my life

[1]
[http://ergoemacs.org/emacs/Matz_Ruby_how_emacs_changed_my_li...](http://ergoemacs.org/emacs/Matz_Ruby_how_emacs_changed_my_life.html)

------
katabasis
Years ago, as a (traditional) designer trying to learn how to code, I spent
what felt like an eternity trying to wrap my head around JavaScript. This was
in the ES5 days. After a lot of effort I could usually do something
approximating what I wanted, but there were a lot of stumbling blocks that got
in the way of really understanding what was going on.

Once I learned Ruby, the fog parted and everything started making sense.
Compared to JS, Ruby was transparent. Everything was just a bunch of objects
sending messages back and forth to one another. The simplicity of defining
classes and methods made it easy to think about how a program could model
aspects of the real world – domain modeling, abstraction, etc. One early
experiment I recall was using Ruby's built-in Enumerable and Comparable
modules to represent a deck of playing cards in code (complete with > and <
methods which respected suit, royalty, etc) – this was a real "aha" moment in
my learning process.

Reading code written by others was much more straightforward (making it easy
to learn from the masters), and writing extensions/plugins to existing tools
to add features that I needed suddenly became feasible. Books like David
Black's "The Well Grounded Rubyist" and Sandi Metz' "Practical Object Oriented
Programming in Ruby" were great, accessible introductions to the art of
programming.

I don't write much Ruby any more, but I'm in total agreement with Dave Thomas
here. Ruby for me was the "royal road" into learning how to program, and it
continues to inform the way I think and write code in other languages. As a
non-CS person, I can't think of a more accessible way to learn about software
development.

------
barbecue_sauce
There is one thing I really dislike about Ruby (and other languages like Scala
that have the same feature), and it's non-parenthetical function invocation. I
get that it's good for writing DSLs and similar endeavors, and you're only
supposed to use them where its implicit what you're doing, but in my opinion,
it really hurts readability (though Scala is much worse when it comes to
flexible yet opaque syntax).

~~~
jaggederest
Unfortunately you really can't get the refactoring capabilities without being
able to substitute a method for a local variable transparently, which is
extremely useful over the long run.

------
rufus_2
In July 2009 around Rails 2.1.2, I decided I'd be happy if I could write Ruby
for a living for the rest of my life... So far so good!

------
mberning
It seems like it is currently Ruby's turn to take a beating just like Java
before it. I guess people relentless hate on Java even to this day, so maybe
it will never get much better. But Ruby certainly holds a special place in my
tool box. Here's to another 25 years.

~~~
erik_seaberg
Most of the Java complaints date back to the [https://steve-
yegge.blogspot.com/2006/03/execution-in-kingdo...](https://steve-
yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html) era. A lot of
things were needlessly painful before Java 8.

------
BlameKaneda
Ruby's readability has been a huge plus for me, and I love working with Rails.
I've only completed one Rails project, and I want to work with it again in the
future.

------
weeksie
This makes me wistful for the 00s and Ruby back when people like _why were
around doing fun, weird stuff that felt more like art than engineering. Of
course much of that is mixed up in my own early 20s and Ruby as the first
language I truly fell in love with. I'm sure just as much (probably more)
great weirdness is going on right now, so maybe I'm not mourning that as much
as experiencing a maudlin touch of nostalgia.

------
aboutruby
> > Matz is clever so we can all feel a little smarter, too.

> (OK, I just made that up)

I liked it :).

~~~
hirundo
Careful, Oscar Wilde said something like (can't find the exact quote) "I
always feel smarter after listening to you." It wasn't a compliment.

------
skywhopper
Great writeup! I agree that Ruby is a remarkable language. One that changed my
perspective about what a language could be while at the same time combining
some of my absolute favorite ideas from Perl, Smalltalk, and Scheme into a
syntax far cleaner and more satisfying than almost any other language I've
worked with.

Dave Thomas's Programming Ruby was a fixture on my office desk for a decade.
One of the best programming books I've ever read, with a fantastic reference
section (built from Ruby's own excellent baked-in docs), my copy is well worn,
and I still find reasons to dig it off the shelf from time to time.

I can't give enough Kudos to Matz, Dave, and the rest of the Ruby community
for bringing this language into my life. The community they've built is truly
amazing, and the language has endured even as it's grown with far fewer bumps
and jolts as compared to other similar languages over the same time period.

In summary, quite simply amazing! Happy Birthday, Ruby!

------
claudiug
All my accomplishment happen because of ruby. I've been unhappy and depress
with java(2006-2010) and then I manage to move to ruby. And I totally like the
language. I'm sad when people say python is more nicer, or the nicer and
better language there. I've done python and I never find it appealing as ruby

~~~
gnulinux
What about people liking python makes you sad?

------
joelbluminator
Hope for another good 25 years :) if I can I will keep programming in it in my
50s and 60s.

------
seanhandley
This should have " (2018)" in the title.

~~~
freehunter
My first reaction was "2018 was only 10 days ago!" But then I clicked the link
and saw the article is from February 2018, so Ruby is nearly 26 now.

~~~
thisispete
unless you go by the actual release date of dec 1995..

------
tomphoolery
> Ruby is the Katamari Damacy of programming languages

love it.

~~~
ken
Sounds like they're trying to borrow-and-modernize the "Lisp is like a ball of
mud. Add more and it's still a ball of mud" metaphor.

------
mcv
After getting tired of Java's verbosity in 2008, I switched to a Ruby job,
where I was fortunate to work with an incredibly talented developer and Ruby
expert. It was a joy coding in Ruby after 4 years of Java and XML.

After that, I moved to Groovy, which seemed like a nice middle ground between
Ruby and Java, or as I called it at the time: Java as it should have been.

I don't hear much about Ruby and Groovy lately, and while I focused more on
front-end development, my back-end work rolled back into Java, which, I admit,
has gotten slightly less painful with Java 8. At least in some ways; in other
ways, it's just become an even bigger mess where some parts are sensible while
other parts are dragging the weight of decades of poor choices with them.

I hear Kotlin is nice, though.

My Ruby skills have gotten a bit stale, sadly. The last thing I did with it
was in 2013 I think, when I ran into trouble with Ruby's handling of unicode.

~~~
imhoguy
Java may suck to some, but it pays huge chunk of corporate salaries. Although
there is the best of both worlds: JRuby! Scripting JMX and some heavy JDBC
stuff with Ruby saved me so much time.

------
jrvarela56
I love the syntax, but I'm hating the debugging. Feel like a big chunk of my
time is wasted chasing after errors that a compiler could catch for me.

Would love to have optional some kind of optional typing. Has anyone tried any
of these? [https://github.com/soutaro/steep](https://github.com/soutaro/steep)
[https://github.com/plum-umd/rdl](https://github.com/plum-umd/rdl)

Any other suggestions?

~~~
aaronmacy
I've not personally tried it, but I remember thinking rdl sounded promising
after seeing this talk (looks like there's a video online):
[https://www.thestrangeloop.com/2017/type-checking-
ruby.html](https://www.thestrangeloop.com/2017/type-checking-ruby.html)

------
sevensor
The decision to implement DSLs by overriding method_missing seems to have
opened a can of worms and the community has never managed to put the lid back
on. More than anything else, this is the thing that seems to cause no end of
consternation with Rails. At the same time, it's pretty much the defining
feature of Rails.

~~~
sethrin
I'm not aware that this has caused much consternation. I disagree that DSLs
are a defining feature of Rails. There are other ways to implement DSLs
besides `method_missing`, and rubocop and other style guides warn against
using this method.

~~~
sevensor
I'll admit to not having used Rails, but I was under the impression that Rails
itself was a DSL.

~~~
sethrin
Rails is a web framework. It's an easy one to use, and often the way to
express something is concise enough that I would feel okay saying that "Rails
is a DSL for web applications". That would be a simile, however, and not
literally correct. It would be more literally correct to suggest that Rails
was composed of several DSLs, but that probably stretches the definition as
well.

The routing system in Rails is definitely a DSL. You might say that defining
model properties was a DSL. You can probably call an ORM query interface a
DSL. The controller and view layers are going to look like just about any
other framework. Rails is a full-featured framework, which can be configured
with a minimum of fuss, bother, and actual code-writing. For toy apps I don't
think there's anything else that's faster for development, and for real apps
I'm pretty sure that all frameworks are roughly equivalent.

There are Ruby projects which do provide a "DSL for web apps", of which I
believe Sinatra is the most popular. Rails incorporates some DSL-like
features, and I would agree with anyone who said that it "is basically a DSL
for web apps", but I would consider that a figure of speech.

------
ausjke
After 25 years it seems Ruby is in gradual decline these days? You will find
one ruby related post at HN after reading 500 of Javascript and/or Python
posts here for example.

~~~
ashelmire
I agree with the other poster who says it's mature, not in decline (so maybe
that's boring to the crowd that likes to always hop to the latest tech).
Basically most of the kinks have been fixed and desired features have been
added, and now it's about gradual improvements and adding new functionality as
it comes. Students also commonly learn Python and Javascript in college and
are probably more active on social media like HN.

I think Rails is the obvious choice for backend apis these days. It's robust,
takes care of most of the hard stuff, saves you time and mistakes. Use
whatever you want for frontend (React for me) in tandem with it. Many of the
job postings I've seen have listed Rails + React.

It used to get accused of scaling poorly, but tell that to Github, Gitlab, and
other large-scale sites with millions of users. It's true that bad Ruby is
slower than bad Java, but the solution is to write cleaner code.

I know this was all about Rails. I use Ruby for scripting work as well, and
it's enjoyable to use.

~~~
Rooster61
> It used to get accused of scaling poorly, but tell that to Github, Gitlab,
> and other large-scale sites with millions of users.

I've worked on one such large-scale enterprise-level web app, and it really
does scale poorly in some areas, specifically database management.
ActiveRecord tends to get extremely expensive when db's take on large amounts
of records and complex relationships start forming between those large tables.
You need VERY good software engineering practices and understanding of which
choices will utterly kill you down the line in terms of performance when using
this ORM, and it's hard to see those consequences at the outset due to the
fact that Rails code is so easy to pick up and understand.

~~~
taf2
Isn't this true of any language? I mean the language isn't what decides how
you connect or build your sql queries? In rails I could choose to write a
pretty scary join

```

    
    
       User.joins("left join ponies on ponies.user_id IN (select id from foobars where user_id=users.id").group("so_funny").count
    
    

```

or I could have a policy to avoid joins at all cost and reject any commit that
uses a join and get fun things like:

```

    
    
       users = User.all # all fucking hell
    
       JSON.parse(HTTP.get("http://your-things.json"))['results'].select {|r| 
    
      users.detect {|u| u.id == r['user_id'] } # for realz??
     }
    
    
    

```

[edit]: cause formatting

~~~
Rooster61
You are right, but aren't really attacking the point I was making. Even with
totally optimized sql, one language's ORM will be inherently slower than
another due to the intrisics of how the records being operated on are
represented in that particular language. In Rails's case, EVERY single record
pulled out of a database gets its own object. There is overhead to being able
to represent table members from a relational database in a language with all
of the lovely convenience methods tacked on to the resulting object (things
such as treating ranges of records pulled like a hash, for instance.

This is compounded by the fact that ActiveRecord obfuscates much of the sql
code you posted above (not always, but in many cases). When a user new to
Rails goes in and sees "Oh, all I have to do to set up foreign key relations
is to just say this model belongs to this other one? NICE!", it isn't
immediately clear what the implications of whats happening under the hood to
accommodate that are, and all of the ways which this can quickly be misused to
cause a huge performance bottleneck. That syntactic sugar smooths over some of
the pitfalls of efficiently interacting with a relational DB.

It's important to note that these things do not make ActiveRecord a bad ORM in
and of itself, as many users will not build projects large enough to have to
worry about such bottlenecks, but it CAN and DOES cause problems when projects
get larger and have to start taking on overhead from the resources allocated
for all those records. That is what people are complaining about when they
mention Rails doesn't scale well (or at least one of the reasons).

~~~
taf2
That is why we have pluck

~~~
Rooster61
> it's hard to see those consequences at the outset due to the fact that Rails
> code is so easy to pick up and understand

Yes, there are tools in ActiveRecord that can help mitigate some of the
performance issues, but as I noted above, it's extremely easy to overlook such
tools until you are too far down stream to really do much about it. The
symptoms of not using such features may not show up until much later when the
number of records swells, and some code someone wrote 2 years ago starts
slowing down the whole shebang simply because they used a select rather than a
pluck. This is ESPECIALLY true in large corporate web app environments where
the number of records is large and the number of people with their fingers in
the code base is equally sizable. And good luck convincing management to go
back and fix old ORM tech debt until the whole thing starts falling apart at
the seams.

Hell, pluck didn't even exist until 2012 with the release of 3.2.1.

~~~
ehsanu1
Might depend on the amount of spaghetti, but I've typically been able to
retroactively fix bad AR patterns backwards compatibly, and get huge speedups.
The only time it's a real issue is when an API endpoint is just returning way
too much and you have a lot of clients depending on that API returning all
that data.

What's a lot harder to deal with is AR callback hell, which can be very slow
if you have enough nested callbacks, and can be really hard to fix without
breaking everything. Using many AR callbacks is just a bad idea for a big app!

------
thisispete
"First appeared 1995; 24 years ago" Wikipedia who's right?

~~~
fouc
>The name "Ruby" originated during an online chat session between Matsumoto
and Keiju Ishitsuka on February 24, 1993

>The first public release of Ruby 0.95 was announced on Japanese domestic
newsgroups on December 21, 1995

------
thisispete
Wikipedia says it came out in 95..?

------
thrownaway954
If it wasnt for Ruby and DHH, I doubt web development would be where it is
today.

------
aantix
.. Quickly Googles “Katamari Damacy“..

------
stevebmark
Ruby's bare word syntax, while sometimes clunky, is usually nice to read.
Other than that, Ruby is a stain on software engineering. If you have the
choice, don't make it your first language! Ruby has the most fundamental flaws
of any of the scripting languages.

~~~
busterarm
WAT?

Have you looked at the array_* methods in PHP?

~~~
stevebmark
yes, php's standard library is bonkers. but at least you can tell where a
variable is defined.

