
Ruby has been fast enough for 13 years - ingve
https://m.signalvnoise.com/ruby-has-been-fast-enough-for-13-years-afff4a54abc7
======
conorh
I work at a dev shop and we've been developing web apps for 10 years or so.
We've run through PHP, Rails, Node, Python (Django) and lately Go. For the
types of apps that we develop, web apps, or perhaps web apps with an API. We
have found that ruby/rails is our fastest and happiest combination. It is the
_slowest_ combination in terms of code execution speed, but in terms of speed
of development and developer happiness it Just Works (tm) and allows us to get
reasonable code developed at lower cost. We deploy many sized apps from tiny
one server apps to small/mid sized apps with 100k users, but we've never found
the speed of Ruby to be a big issue - usually it is everything else, testing,
maintainability etc. If speed is an issue we've always been able to work
around it without too much difficulty, and these days if we know we will need
the speed or scaling we'll resort to Go, but we find that our development time
increases somewhat.

~~~
collyw
The last two apps I have inherited have been in Python (Flask and Django). If
they were slow, its because they were poorly written (one page makes over 1000
database calls - it could be done in less than ten). Sort all that crap out
before worrying about the language.

~~~
hueving
I can't emphasize this enough. I'm always blown away by how quickly engineers
will chalk a slow application up to the language it's written without even
doing a minimal amount of profiling. In almost every case it has been severely
limited by waiting on a massive number of backend calls, DB reads, system
calls, etc and became orders of magnitude faster after fixing those silly
mistakes.

 _profile_ _profile_ _profile_ before you waste a ton of engineering effort on
a rewrite that may buy you absolutely nothing.

~~~
stcredzero
_I 'm always blown away by how quickly engineers will chalk a slow application
up to the language it's written without even doing a minimal amount of
profiling._

The more things change, the more they stay the same!

------
joshmn
You know what's fast? Learning Ruby. You know what's also fast? Rails
development!

I've tried Golang and played around with Node. They're fast, sure. The
respective frameworks just don't compare.

Ruby (and Rails) scales just fine for 99.281% of things. You just need to
throw money at it.

And that's a great thing.

A business's success will never depend on of the speed of a language or
framework. It just doesn't work like that. What matters is how quickly you're
able to iterate and evolve a product.

Ruby (and Rails' ecosystem) allows me to not have to reinvent the wheel for
mostly everything. Authentication? Devise. ORM? ActiveRecord. Background
processing? ActiveJob. Caching? It's there.

Want awesome front-end performance without having to basically rewrite your
entire app and learn another framework and manage its dependencies?
Turbolinks, and it has matured beautifully.

Basecamp has its performance anecdotes written in history that we can all
reference. And Basecamp also has had great success.

Point being is that a business is a business. The speed of a product cannot
and should not be blamed for how successful a business is or isn't.

I love you, DH2, and thank you Matz. I love you too.

~~~
zer00eyz
>>Ruby (and Rails) scales just fine for 99.281% of things. You just need to
throw money at it.

>> Basecamp also has had great success.

Basecamp is a great SAS business, you can tie utilization to revenue. Throwing
money at the scaling problem (horizontal) is completely realistic in that
scenario.

If you can't tie utilization directly to revenue, if your a pure service like
twitter, or an online store with a bad browse vs buy ratio ruby is a BIG
liability.

So is ruby fast enough? It depends. Its a business decision, not a technology
one, and one I would have a hard time justifying for a lot of startups.

~~~
davidw
> you can tie utilization to revenue

This is a critical aspect.

If it's purely ad-driven, you probably have very little money coming in for
the number of pages you crank out, so you need to optimize them a lot.

If you're charging for your app - which you should be in a lot of cases - then
something like Rails is likely ok.

The latter case is much more likely outside of Silicon Valley/VC-fueled
startups.

~~~
zer00eyz
Even then I think it is a hard sell.

Lets say that the gain you realize from writing in another language is 10% of
your infrastructure costs. It might not matter day one. At some point that
will represent a significant sum of money, in either absolute or relative
terms.

~~~
davidw
Premature optimization and all that... Worry about it when it looks like it
might matter.

Worry way, way more about building the right product at the right price for
your customers, and adding the right features.

------
gizmo
Didn't DHH write this post a few years ago about how layers of caching were
needed to get Basecamp to perform at an acceptable speed?

[https://signalvnoise.com/posts/3112-how-basecamp-next-got-
to...](https://signalvnoise.com/posts/3112-how-basecamp-next-got-to-be-so-
damn-fast-without-using-much-client-side-ui)

Computers are amazingly fast these days, but 99% of all CPU cycles go to waste
because of this "slow is fast enough" mentality.

~~~
sethd
Web applications are not CPU-bound, they're IO-bound. So in this scenario
caching is used to reduce the amount of requests to the database.

This can speed requests up but more importantly it allows you to more easily
scale out horizontally.

~~~
chrisseaton
> Web applications are not CPU-bound, they're IO-bound.

Is that a fact? I'm not sure anyone has ever shown numbers to back it up. It
would be an interesting piece of work to do. I can imagine it's true, but I'm
not certain.

I think Rap Genius did a blog post ages ago about being hosted on Heroku, and
they said that something like 70% of time was spent inside the Ruby
interpreter, not waiting on IO. So modest improvements in the speed of Ruby
will have an impact on their bottom line.

~~~
coldtea
> _Is that a fact? I 'm not sure anyone has ever shown numbers to back it up._

What? I've seen tons of profiling posts and articles showing just that thing,
and it's the same thing I've also seen forever on my servers' stats. I'm
obviously talking about the majority of web apps that are using DBs and doing
some kind of CRUD work -- not video processing services et al...

~~~
chrisseaton
This is the blog post I was referring to [http://genius.com/James-somers-
herokus-ugly-secret-annotated](http://genius.com/James-somers-herokus-ugly-
secret-annotated) and the key graph
[http://images.rapgenius.com/75aa2143d3e9bf6b769fc9066f6c40c8...](http://images.rapgenius.com/75aa2143d3e9bf6b769fc9066f6c40c8.798x399x1.png).

Is that non-typical? Or am I mis-interpreting the graph? (Genuine questions,
I've never done any web app operations.)

~~~
coldtea
That graph still shows time to process/respond, not CPU utilization.

From the article the slowness is when "a dyno is tied up due to a long-running
request" \-- so, we they are probably still talking about slow IO operations,
and servers running on the dyno that are not async to free it up in between.

From Heroku's one optimization page: "Most applications are not CPU-bound on
the web server".

[https://devcenter.heroku.com/articles/optimizing-dyno-
usage](https://devcenter.heroku.com/articles/optimizing-dyno-usage)

(And Heroku might be an outlier in having high real-cpu use too, as they tend
to over-provision).

~~~
chrisseaton
But the graph shows time in waiting on web requests (dark green), time waiting
on cache (teal), time waiting on the database (brown) and time queued before
the interpreter gets the request (light green) separately to time spent
running the Ruby interpreter. It's a cumulative graph.

So if the IO isn't web requests, cache, database or waiting in a queue, what
can the interpreter be waiting on? Local files?

------
out_of_protocol
Ruby performance on par with Python, PHP etc. Rails is slow but at same time
it's faster than like 80% of all the PHP frameworks. So i'd agree with DHH -
not the issue at all in most cases. Someone can choose different framework for
other reasons than plain requests per second. In case of Elixir/Phoenix it's
things that Ruby/Rails can't handle properly, like

* websockets & realtime stuff. (Rails 5 added that, i know, point still valid)

* dev mode experience. rails startup time is slow enough to add bandaids like "spring" in default installation.

* sort of "magic" that actually hurt developers

~~~
schneidmaster
> * websockets & realtime stuff. (Rails 5 added that, i know, point still
> valid)

Seems a bit dismissive. It's not like Elixir/Phoenix have really been mature
for all that long either. (Especially if your definition of "maturity"
includes a broad selection of userland packages/gems.)

> * sort of "magic" that actually hurt developers

It's not just this comment, but I don't understand why "it's magic and that's
bad" seems to have been accepted into the encyclopedia of Facts About Rails™.
I still have yet to see a particularly good argument against CoC[1]; it boosts
productivity and teaches developers to write concise, consistent, expressive
code. All good things in my book.

[1]: [http://rubyonrails.org/doctrine/#convention-over-
configurati...](http://rubyonrails.org/doctrine/#convention-over-
configuration)

~~~
silversmith
Counterexample: just yesterday I spent nearly two hours trying to understand
why a bunch of records was not being updated to database. Turns out that when
attributes on already persisted records get assigned in particular sequence,
ActiveRecord suddenly decides that there are no changes to be saved. Swap two
calls, everything suddenly works. And there was nothing to help me to get to
that solution, just groping in the dark and trusting my years of RoR
development for a general direction.

Rails is great, and I've been productive in it for a long time. But the
complexity (some would call it bloat) is real, and there are nasty edge cases.
And when you stumble upon one, well, good luck.

~~~
dopamean
I'd like to hear more about this. Is it possible you could share an example
that demonstrates what you're talking about? Thanks.

------
Practicality
This argument falls flat to me. All of Ruby's competitors ran on similar
servers 13 years ago as well (except for a few that didn't exist yet).

All of them have optimized and improved their speed since then.

In 2003, it was expected that web pages have a bit of a delay before loading.
In 2016, it is not. Ruby has not yet adapted.

~~~
kyledrake
I'm really not subscribing to your argument that every other language got
faster and ruby didn't. Ruby performance has increased significantly since
2003, and ruby has had concurrent IO using threads since 1.9. Python shares
the GIL problem, and Node doesn't even have threads (have fun debugging
events!), so you're not going to add much water to the argument in that
department.

Additionally, computers got much faster and have many more cores, allowing for
additional process concurrency. This is an argument for me to move to higher
level, more abstract languages, not to race back to lower level languages
because "they're fast". If anything, ruby/js/python aren't high level enough
and could be slower but more productive. I'd choose that over raw performance
for the vast majority of my needs.

Additionally, Rails benchmarks might show ~100 hits per second (that's
8,640,000 hits per day per process, do you _actually_ get that much traffic?),
but I can get thousands of hits per second running Sinatra. I still think
Rails is plenty fast, but it's silly to blame a language for a framework.

Ruby has for years been a victim of FUD, opinions on it's performance that
seem to have been derived from fuzzy stereotypes rather than actual
information. I think that's what the author is frustrated about, because
that's the one thing I'm pretty frustrated about too. I'll be the first person
to abandon ruby when a better language comes out for my needs, but I've still
never seen it.

~~~
jerluc
Every language that supports threads has "concurrent IO". That's what
threads/processes are for.

However, threads will never help you in an IO-bound system (unless you own
some kind of thousand-core CPU with an equal number of OS threads). Threads
will simply block at the first waiting IO call until you eventually run out of
threads. Node.js from the beginning was built for _non-blocking_ IO, as are
several Python frameworks (e.g. Twisted, or more recently, Tornado), thus the
need for more than one thread of execution was typically unnecessary (again,
provided the bottleneck was IO).

~~~
otterley
Threads can absolutely help you in an I/O-bound system where concurrency is
possible and desirable - specifically, in a RAID environment. (You can't max
out RAID throughput with a single thread - try it.)

------
rubiquity
While DHH says that CPUs in 2004 were fast enough to run Ruby, while CPUs have
relatively stayed the same speed the call stack and complexity of Rails has
probably doubled or triple in that time period.

Ruby's performance does matter. In 2016 you can't call yourself a language
optimized for developer happiness when it takes seconds or minutes (in the
case of some Rails apps - Hello routes.rb!) just to start up.

~~~
DamnYuppie
Help me understand how, in your workflow with Ruby on Rails, a few second
delay in staring up the application hampers developer happiness?

I ask because in mine I start up the application very rarely, say when
changing a gem, initialization or configuration file. All other times my
changes, in development, are automatically refreshed. Hence I rarely start and
stop my development system. Of course I am running my development locally. If
you were actually deploying your ENV out to some servers continuously for
every change then that would be annoying, yet how much of that delay is do to
Rails restarting vs doing a remote deploy....

~~~
mnutt
Running specs/tests involves reloading the environment for most people. Spring
is surprisingly good for this, but you can still run into weirdness where
spring needs to be reloaded due to some sort of state issue.

~~~
spinlock
exactly. Rspec/rails is my favorite vim plugin but I really hate the time I
spend waiting for the spec to run after I've typed \s (note: that's the actual
key sequence not an indication that I'm being sarcastic).

------
dnautics
I think the main complaint about Ruby is going to become, "it's impossible to
install". Used to be a beginner user could install a workable current version
of Ruby with one or zero commands from a Linux distro. That is no more.

~~~
moondev
docker run -it -v "$PWD":/usr/src/app -w /usr/src/app rails rails new --skip-
bundle webapp

~~~
dnautics
...and someone interested in learning ruby as a beginner is going to know (and
understand) that incantation how?

------
59nadir
Posted on the other submission:

If nothing else, I think reminding people that what they're "looking to do"
(whatever that is) most likely is something they can do in whichever language
they choose, and to somehow shoehorn themselves into a language or a set of
languages, not because they have a concrete need to, but because they think
they might need to... (Once they start... If they ever get going on it...) is
foolish and really does not contribute to execution.

Sometimes it's better to get going in the most productive language you can
find for the problem space and make a slow/inefficient implementation with few
lines of code, minimizing the risk of bugs, (call it "MVP" or whatever) if
only to find out whatever it is you're trying to do. Most languages without
suffocating boilerplate will do just fine for this, regardless of their
performance.

------
brianolson
Ruby isn't fast enough. We're getting 2-20x speedups by switching to Go. (Some
things are io-bound waiting on the database, that's the 2x end of the scale,
some things we're doing more compute on and that's the 20x end of the scale.)

~~~
nemild
Are you surprised that static type/compiled languages like Go (or C or C++ or
many others) are significantly faster than many dynamic type/interpreted
languages like Ruby and Javascript?

If performance alone is important to you (rather than many other
considerations like ease of coding, library ecosystem, number of developers
who know the language) - you'll almost always do better with compiled
languages - especially those with good concurrency support. But the power of
many of the dynamic languages is that they provide an ease of coding that
reduces the cost of development significantly, especially for earlier stage
companies where the benefits of performance may be less important than other
considerations.

For many teams I've seen, you can also rewrite the most computationally heavy
parts using FFI, allowing you to have the benefits of dynamic languages
without some of its disadvantages for computationally heavy work (though it
comes at a cost of adding a new language into your stack).

I say this teasingly, but you may want to rewrite your slow Golang codebase to
see how much faster performance you could get with C++ (but again, it comes
with a cost to your development team - and only your team can decide what
tradeoffs to make given the stage of your product/company).

~~~
brlewis
Separate reply because it's a separate topic: Dynamic types aren't the reason
for Ruby's slowness either. The Racket code that beat Ruby by 25x in the
Mandelbrot benchmark has no type annotations:
[http://benchmarksgame.alioth.debian.org/u64/program.php?test...](http://benchmarksgame.alioth.debian.org/u64/program.php?test=mandelbrot&lang=racket&id=4)

~~~
igouy
Incidentally, neither u64 nor u32q are being updated -- that data is from
before November 2015.

------
whistlerbrk
My belief is that lack of concurrency primitives is what will kill Ruby, not
today, 10 years from now. We're running on momentum alone at this point.

That said _every_ Rubyist should be following Chris Seaton's work
chrisseaton.com/rubytruffle/deoptimizing/ with JRuby Truffle+Graal. This is
our best change, imo of course, to make Ruby fast.

~~~
MrBra
You should watch the Evan Phoenix talk at RubyKaigi 2015 ("Ruby 2020")
[https://www.youtube.com/watch?v=QaLvtNpoc5o](https://www.youtube.com/watch?v=QaLvtNpoc5o).

It proposes a very interesting path for Ruby to get _way_ faster, without
resorting to the JRuby implementation.

Basically what he's proposing is we could compile all the Ruby Stdlib ahead of
time to a LLVM kind of bytecode.

Once you do that, a JIT compiler for Ruby code could perform a way deeper
optimization, because the compiler _horizon-line_ will be stretched much
further away: the compiler will be able to inspect the Stdlib bytecode and
make optimizations to your Ruby code taking all that into account!

This could be a revolutionary approach for MRI, please go see the talk, it's
really interesting!

------
joe_the_user
I know that Ruby was broadly a horrible mess in, say, 2010.

For example, the Ruby interpreter never returned dealocated memory to main, it
just kept anything deallocated by a program in it's own memory - copy a huge
file between machines, wind-up with a

The head of operations of Twitter told me that at one point they were starting
and killing ruby processes every minute because of Ruby's huge memory
appetites and they not only had to throw huge amounts of hardware at the
problem but also throw huge amounts of electricity to keep with the CPU churn.

~~~
nilved
I'm quite sure that's still the case. MRI will never return memory to the OS.
(I am open to being corrected, since it has been several major versions since
I verified this.)

~~~
nateberkopec
It's true in practice but not in theory.

Ruby can't defragment memory pages - if there is an active object in any heap
page, it cannot be released back to the OS. Technically, Ruby does release
empty pages back to the OS, but in practice, heap pages are rarely completely
empty.

------
astrodust
Ruby really needs to put performance on the roadmap as a serious project. The
work done on Python, on Perl, on JavaScript especially shows that there's huge
gains that can be made if you prioritize it.

Sadly the core Ruby team has been incredibly indifferent and at times outright
hostile to projects like JRuby and Rubinius that have tried valiantly to push
Ruby forward.

I'd rather not see people use JavaScript, Swift, or C# because Ruby wasn't
fast enough for their particular problem.

~~~
molecule
> Ruby really needs to put performance on the roadmap as a serious project.

[http://engineering.appfolio.com/appfolio-
engineering/2015/11...](http://engineering.appfolio.com/appfolio-
engineering/2015/11/18/ruby-3x3)

> At RubyConf 2015 in San Antonio, Yukihiro "Matz" Matsumoto announced Ruby
> 3x3. The goal of Ruby 3x3 is to make Ruby 3 be 3 times faster than Ruby 2.

~~~
chrisseaton
I'm not sure there are any realistic ideas to actually achieve this for MRI
though (beyond the one-sentence bullet points in that article). The roadmap
needs to have some roads on it rather than just wilderness!

That's speaking as someone who works full time on optimising Ruby, and wrote a
PhD on it.

I think the one hope is that Evan Phoenix suggested an idea that would let an
LLVM JIT optimise through the Ruby implementation, but this is a full-on
research project (he said it wasn't, I'm not sure I agree), and nobody is
working on it.

~~~
MrBra
You should watch the Evan Phoenix talk at RubyKaigi 2015 ("Ruby 2020")
[https://www.youtube.com/watch?v=QaLvtNpoc5o](https://www.youtube.com/watch?v=QaLvtNpoc5o).

It proposes a very interesting path for Ruby to get way faster, without
resorting to the JRuby implementation.

Basically what he's proposing is we could compile all the Ruby Stdlib ahead of
time to a LLVM kind of bytecode. Once you do that, a JIT compiler for Ruby
code could perform a way deeper optimization, because the compiler horizon-
line will be stretched much further away: the compiler will be able to inspect
the Stdlib bytecode and make optimizations to your Ruby code taking all that
into account!

This could be a revolutionary approach for MRI, please go see the talk, it's
really interesting!

------
Justsignedup
Anyone running a non consulting firm can talk about maintaining a ruby
application across a big development team for a long period of time? The
dynamic nature of Ruby has led me to think that it will have maintenance
problems compared to say a strongly typed language like java with the tooling
available.

------
cwisecarver
Ruby is fast enough and it's a beautiful language with a few warts, just like
any language.

Profiling and caching should be the first step to solving an existing app's
problems.

Rails is a great framework because it gives developers rules, a simple pattern
to follow.

All that being said, if I was starting an app today I wouldn't choose Rails or
even Ruby. There are plenty of other options that are __almost __as expressive
and easy to hire for without the speed penalty. If you hire good developers
they can get up to speed on any language and any framework. If you don 't hire
good developers then you're paying a 2x-10x penalty for hiring bad developers
and a slower language or framework. Who here hasn't ever worked with or hired
a bad developer?

IO is the true bottleneck in most situations but so is a developer writing a
view that queries the database for a list of things and then filters them in
code instead of letting the database do it. I can't count on two hands the
number of times I've seen a developer do this in the past 6 mo.

Your framework and your language are your platform. If you're stuck on a
platform, accept it. Rewrites are hard. Hard for the business, hard for your
users, hard for your developers. If you're starting from scratch do yourself a
favor and pick something that doesn't chop you off at the knees to begin with.
Bad code in (Go, elixir, c#, python) is faster than bad code in Ruby.

[edit] english

------
borvo
Some engineers don't want to use ruby, in some cases seeing it as "not a real
programming language" (whatever that means)

The performance FUD is probably just deflection.

As DHH himself says, engineers are in short supply - so their preferences tend
to get listened to.

------
patrickaljord
I don't know, having to port your app to the next version of rails every year
is quite expensive. My golang app however has not needed any porting to the
next version for the past 3 years and the syntax and standard libraries are
both easy to grasp and rock solid. Oh and the joy of deployment with golang.
To each his/her own I guess. Also, if I were to pick a dynamic language, I'd
probably go with node.js now.

------
hosh
The article is weird. It is presupposing that there are no other languages
that are faster _and_ makes developers as happy as working with Ruby. I count
Elixir as one of those.

------
bluedino
We converted over an API from Rails to Node (we probably should have just done
it in Sinatra but the web application was made in Rails so it made sense) and
we went from running it on a 4-core Xeon with 12GB to the _second smallest
cloud server Rackspace offered_. And it was faster.

~~~
dham
So you went from one of the largest frameworks in existence written in Ruby to
a Javascript runtime built on V8? That might be the least apples to apples
comparison I've ever heard. You do realize if you're doing an API you can just
use Grape or Sinatra and use like 90% less memory.

------
spinlock
Maybe I've missed the meme that Ruby isn't fast enough but I've always found
the ability to easily write my tight loops in C and compile it as a Ruby
module to make Ruby a go to choice _for_ high performance.

~~~
zer00eyz
Its hard to think of a scripting language where this isn't an option. But
Rails isn't ruby, and loops aren't always the problem.

The fact that just about every rails performance issue ends in another
language is the most telling part of the story. IF your php framework is slow,
you might see a BIG speed boost from native PHP, or HHVM, or last resort C.
Python has a similar option chain, and that just ISNT there for rails.

------
percept
[https://twitter.com/dhh/status/649260226521210880](https://twitter.com/dhh/status/649260226521210880)

~~~
twic
> Remember: BUT DOES IT SCALE? Basecamp is peaking at 2,000 requests/second
> against the Rails application instances these days.

Does he mean 2000 rps per instance? If so, that's not bad!

~~~
ksec
No, he replied ALL instances.... which is... pretty bad.

------
bhauer
I am biased, but I disagree. I've reviewed projects where teams have attempted
to compensate for the performance problems of Rails and Ruby by scaling
(dramatically) horizontally. Projects that are simple in functionality but
have dozens of servers and complex overall application architecture and
topology. Projects where the big guns of scalability had to be brought to the
battlefield very prematurely.

Today, I argue for quite the opposite approach. Select a high-performance
platform that is workable for your team and enjoy the _luxury_ afforded by
raising your performance ceiling. Rather than your platform and framework
creating an unreasonably low and frustrating performance ceiling—wherein you
will find yourself fussing with performance tuning and complex system
architecture way earlier than you should, use high-performance infrastructure
and defer tuning your application for a long time, if not indefinitely.

Performance is an objective measure, but what performance means to you is
potentially subjective. For my part, high performance means peace of mind. I
can write my application more quickly, using brute-force algorithms and other
quick implementation tactics. I can tune my application later, if and when the
need arises.

But if my platform is what causes my performance pain, tuning my application
is a futile exercise. I am forced to increase my system's architecture and add
more servers, load balancers, messages queues, job workers, all manner of
things that make my architecture sound awesome to a programmer but do nothing
to improve a user experience where pages are still taking 500ms of server side
processing to execute trivial operations.

Yes, with enough effort, essentially any platform and framework could service
any application's performance needs. Facebook is famously built on PHP, which
is not a fast platform (modest in raw form; slow when encumbered with a
framework). Facebook has invested untold scores of dollars into tuning. This
is what I feel is important to those of us building just average apps: you
probably won't have the money and developer bandwidth to actually tune your
platform, as Facebook has done with PHP. So you'll scale horizontally and add
a lot of architectural complexity and cost. This might more or less work, and
you may be successful in spite of the unnecessary complexity. But my opinion
is that it's easier and more comfortable to select for high-performance at the
start and just defer that complexity; defer optimization.

I find the upsides of Ruby are subjective. "Programmer happiness" is obviously
a subjective matter. I personally am considerably happier on a high-
performance platform, especially one that is easy to work with. I am not
alone.

Thank you to Ruby and Rails for pushing for a lot of great ideas we enjoy on
other platforms today. But its performance has never been good enough for my
tastes and that remains the case in 2016.

~~~
pbreit
Except that only a small percentage of projects need to scale. So you're
generally much better off trading scalability for productivity.

~~~
bhauer
That's precisely the point: a low-performance platform causes you to need to
scale and bring out complex system architecture way earlier in your project's
lifetime. Systems that would be just fine on a single cheap server using high-
performance software find themselves ramping up complexity with only very
modest usage.

I'd prefer to avoid the need to scale to deal with a few hundred concurrent
users. I'd prefer to imagine my CPU yawning and asking for more.

You may be speaking of very low-traffic systems, and I will agree that with
such a scenario, any technology could suffice. But in 2016, we programmers
enjoy a lot of options for building web applications and services, including
many high-performance platforms that are a joy to work with. Putting aside
subjective matters such as existing preferences and experience, if you've got
a new project and an open mind, why bother with low-performance when you can
have high-performance and ultra-fast response to user requests? To be clear,
I'm not saying existing preferences and experience are unimportant. But if you
find yourself entertaining the option of using something new, I recommend
factoring high-performance into the selection process to enjoy the peace of
mind that it brings.

------
ebbv
"Fast enough" is a subjective, not objective term. For some things Ruby is
fast enough, for other things it isn't. It depends not only on what you are
doing with Ruby, but also how you are using Ruby. Just like any other tool.

~~~
albasha
He said exactly that about three times in his article.

~~~
ebbv
He does but then he immediately hedges it every time by pointing out what he's
done with it in the past. As if that were proof that Ruby is fast.

I wanted to state it clearly with no equivocation; fast is relative and Ruby
might be fast enough for certain use cases, but not for others.

------
adrianlmm
My Ruby/Sinatra web app is about 2 times faster that my Asp.Net MVC app, so, I
always knew the myth of Ruby slowness was that, a myth.

~~~
tobz
I'd love to hear about the specifics for both of the projects. I have a hard
time believing that Ruby is faster than C# straight up, and would venture that
such speed differences could be easily contributed to something simple like
extraneous queries or what have you.

~~~
adrianlmm
It was hard to me to believe it too, how is my Ruby/Sinatra app faster than my
C#/Asp.Net MVC app? do not compute.

The applications are pretty similar, but request are processed faster with
Sinatra, and small queries are no different, you only note the difference when
the query returns more tan 100,000 records, but it is an exception to the
rule, I suspect it has to do with IIS modules being more heavy than Thin in
Ruby.

~~~
tobz
I was going to say: it almost sounds like something weird with IIS.

The CLR on Windows was/is top-notch. Now, with Kestrel as an option for
ASP.NET 5, you're starting to be able to get closer and closer to the metal,
so to speak, and eliminate a lot of the baggage required to actually hit your
code from an HTTP request.

At any rate, interesting to hear. :)

~~~
romanovcode
AFAIK MS are doing and will continue to do the benchmarks for the new ASP.NET
and they say that for now it's as fast as Scala/Java but that's not it yet.
They plan to make it in top5 stack on benchmarks here[0]. Maybe then people
will start believing in C#.

[0]
[https://www.techempower.com/benchmarks/](https://www.techempower.com/benchmarks/)

------
octref
I really like Zach Holman's comment on this one.

\---

[0]:
[https://github.com/holman/ama/issues/698#issuecomment-118547...](https://github.com/holman/ama/issues/698#issuecomment-118547015)

I can't remember who said it initially, but my favorite sentiment on all this
is:

> The only people still using Ruby are the ones making money.

In other words, I think it's a pretty great, stable community of people who
use it in production and have seen it all, so to speak. I kind of include
Python in this, too- besides the obvious syntactical similarities, I think
they are pretty similar in terms of ideology.

I'm in a bit of my third honeymoon with Ruby (and Rails) this summer. I've
been seeing a lot of people in the Go community, for example, talk about "just
use the http libraries, no one needs a framework" and I think they're fucking
bonkers, or at the very least write backend apps with no UI and no more than
two contributors on the project. Frameworks like Rails give you so many
security, development, and deployment niceties that I have zero interest in
rolling my own anymore. (I saw a "screw frameworks" Go talk that spent ten
minutes on how to reload code in development, for example... that was a solved
problem for me in 2005.)

I'm kind of in love with the idea of writing everything in Ruby (or something
similar) and when it makes sense and can be provably improved, extract it out
in something like Go or C. The Go+Ruby combination in particular is super
attractive to me, and it's likely going to be fine for the foreseeable future,
I think.

\---

[1]:
[https://github.com/holman/ama/issues/698#issuecomment-118958...](https://github.com/holman/ama/issues/698#issuecomment-118958873)

> The recent post from Parse Engineering Team [...] if you look at GitHub
> also, the number of Ruby repos are getting lower over these months.

I think looking at these examples don't the whole picture here. GitHub, for
example, is a fairly feature-complete product, and their next few years will
likely focus on optimization work. If you have a mature product, you have a
very clear performance profile of what's breaking, what's fast, and what's
slow. That's why GitHub, a seven year old company, is more likely to open
source Go libraries at this stage of its life rather than Ruby libraries (for
example)- it's obvious which use cases can be targeted for speed,
maintainability, and shareability.

Parse is another clear example of this- they have a codebase that they've
worked with for quite some time, with obvious spots of improvement, so they
switched to Go. If you're looking at new companies that need a fair bit of
creativity, product development, and development speed, I think Ruby makes a
lot of sense. Premature optimization is not just a waste of time, it's an
exponential waste of time, as you might head in a wrong product direction that
can potentially sink the entire company.

> I am wondering what's will be the next language gonna rule like PHP. Though
> there are JS tech is in the peak, I still not convinced to use it on server
> side. Go and Rust looks promising.

I'm really the wrong person to ask here, but I can't really imagine anything
taking over like PHP did for the next five years or so. That was a pretty
meteoric explosion, and there weren't a lot of clear and open source options
fifteen years ago. I don't see JavaScript development being a flash in the
pan, I think Go is clearly going to continue to increase in popularity, and I
think languages like Ruby and Python and PHP will probably hit a decent
cruising speed for the time being. Even .Net technologies have a brighter
future ahead of them again. There's a lot of choice right now, there's a lot
of resources flooding into open source from companies who clearly want to
compete in the community, and there's a ton of stealing of good ideas between
communities rather than getting siloed off in the past.

A decade from now, yeah, things may be completely different, but for the time
being there's a lot of exciting choices and options happening. Kind of love
it.

~~~
zer00eyz
>"and there weren't a lot of clear and open source options fifteen years ago"

Perl jumps to mind as an example, and PHP stole its lunch money, and ran off.

------
mtw
Ruby is not fast enough for machine learning

~~~
MrBra
If that's your unique concern, then you could still use Ruby and consider
using a wrapper for a ML library written in a faster language.

Unless you want to be writing ML algorithms yourself.

If that's not the case, maybe you will find this interesting: "TensorFlow is
coming to Ruby" \- [http://www.somatic.io/blog/tensorflow-is-coming-to-
ruby](http://www.somatic.io/blog/tensorflow-is-coming-to-ruby)

------
joesmo
This argument holds water until you have languages that are orders of
magnitude faster with the same developer enjoyment and experience. 13 years
ago, I'd argue that choices were rather limited. Nowadays, there are too many
choices. Fast enough is just not good enough in a market with plenty of
competition.

What is fast enough? If you're building a web app, fast enough is not the same
as if you're building a web API. The latter needs to perform much better than
the former in my experience because the former might make multiple calls to
the latter in a single request. I find it almost impossible to make an
argument for interpreted languages at this point for backend services
considering how slow they are and how few, if any, benefits they have over the
many non-interpreted languages out there. I'm thinking of languages like
Clojure and Elixir, but even Java has a framework that supports hot code
reloading (Play) thus getting rid of the last remaining benefit of an
interpreted language. Once you get rid of that, it really no longer makes
sense to use an interpreted language, all other things that DHH mentioned
being more or less equal.

~~~
vidarh
"Orders of magnitude faster" isn't possible in any case where more than 10% of
your time is spent waitin on external factors (kernel space, waiting on IO
etc.), which is the case for pretty much everything I've ever done.

There are certainly types of code that will be CPU bound, in which case, yeah,
there's a good case for using something else - or calling out to something
else -, but for large parts of what people write, not being IO bound is a
warning sign that you should take a long hard look at what you're doing,
because chances are you're doing something silly.

Webapps and typical APIs for webapps tends to be amongst those.

Of the work I've done in the last 20 years, maybe 2-3 projects have been
projects where CPU performance have been an issue. For others it will be every
project they every do. But the point is there are plenty of us for whom
language performance is not a factor we usually need consider.

~~~
joesmo
I benchmark most interpreted language http frameworks in the low tens to
hundreds of requests per minute range at best without any app code and you're
telling me that CPU performance isn't an issue?

~~~
vidarh
No, I'm telling you that CPU performance usually isn't an issue. Most sites
will never, ever need to serve enough dynamic requests for that kind of
performance to be an issue (and you can certainly do far better than that on
dirt cheap hardware).

------
nilved
DHH is ridiculous. Ruby and Rails are nowhere near fast, in the past or
present. Especially the past.

[http://harmful.cat-v.org/software/ruby/rails/is-a-
ghetto](http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto)

> The main Rails application that DHH created required restarting ~400
> times/day. That’s a production application that can’t stay up for more than
> 4 minutes on average.

~~~
pbreit
As I'm sure you know, that's wrong.

[http://david.heinemeierhansson.com/posts/31-myth-2-rails-
is-...](http://david.heinemeierhansson.com/posts/31-myth-2-rails-is-expected-
to-crash-400-timesday)

~~~
nilved
Your link doesn't say it's wrong; it argues semantics. The fact that unicorn-
killer is a real thing real developers use for real apps should be evidence
enough that Rails is a joke. Whether your app crashes after 4 minutes or you
kill it after 4 minutes is irrelevant.

