
Why Ruby? - DanielRibeiro
http://www.codinghorror.com/blog/2013/03/why-ruby.html
======
Xion
As a member of Python community, I hereby congratulate Ruby for joining the
ranks of pretty-cool-but-not-so-hot-anymore technologies. There are years of
Getting Stuff Done ahead of you. Way to go!

~~~
shanelja
I wonder how you fall in to these categories, for instance, Ruby and PHP were
developed around the same time (though Rails obviously came later) yet Ruby is
such a "cooler language" so it can't be due simply to age.

I think a lot of it is Silicone Valley's attitude to being different to the
rest of the world, the majority of sites are built in PHP? Sweet, let's go
with something funky and different!

It's a great attitude to have for creating cool new things, I suppose, but it
feels like it's moving too fast for me to keep up, is Node.js not cool
anymore? What about Backbone? Lua? what the hell is Hadoop? How about a new
Lisp?

~~~
doktrin
I don't think it's "just" SV. On the whole, IME, Ruby (and Rails by immediate
extension) appears to be a little more popular in the US than in Europe. I
can't speak to other developer communities.

For instance, I was immediately struck upon visiting family in Norway that
_vanishingly_ few shops use Ruby, and surprisingly many use .NET. I had also
just finished interviewing for an opportunity on mainland Europe for a shop
that uses Perl as its production language.

~~~
Ovid
There are actually tons of shops that use Perl here in Europe. It's quite
popular, though it's not going to hit Java or C levels of popularity.

I lived in London and there were always _tons_ of Perl jobs there and here in
Paris, I'm shocked to find out that there are far more Perl jobs than I
expected. It also appears to be moderately popular in Germany.

So yeah, Perl may also be "off the radar" for many people, but it's still a
strong market. Interestingly I'm seeing Perl dev pay scales getting pushed up
because because there was a rush of devs going to other languages a few years
ago. Now there's a shortage of Perl devs but the code hasn't gone away.

~~~
kamaal
Curious to know how many new Perl projects are started these days, compared to
something like say Python.

Its not very interesting to be known as a Perl developer if all there is left
to do is maintain legacy code.

~~~
doktrin
My _hunch_ , based in part on a few single point observations as well as this
thread, is that not too many _new_ projects are using Perl.

When I asked a prospective employer why they were using Perl, the answer was
in effect that it was legacy from the late 90's. I never got the impression
that this legacy was an onerous impediment, however. Given the scale at which
they operate, switching languages & ecosystems would be costly - and (again,
due to scale) they've built up a number of customized solutions using Perl
that would be time consuming to port.

IMHO, given the state of the language & its ecosystem as compared to its
closest cousins (Ruby & Python), I can't really see why any _new_ projects
would be started in Perl. If anyone has a counter point I would certainly love
to hear it, as I will freely admit to not having had much interaction with the
Perl community as of late.

~~~
kbenson
> IMHO, given the state of the language & its ecosystem as compared to its
> closest cousins (Ruby & Python), I can't really see why any new projects
> would be started in Perl. If anyone has a counter point I would certainly
> love to hear it, as I will freely admit to not having had much interaction
> with the Perl community as of late.

I might, if I knew what your point was. There's just a vague implication that
the language and it's ecosystem are substandard to Ruby and Python. Apparently
you think it's self evident, so doesn't require explanation, but I don't feel
that way, so I'm not sure what to address.

Mind supplying some examples of what you feel Perl is lacking in comparison?

To jump start it, I've been using Mojolicious[1] lately, and find it a dream
to work in. And of course, being able to pull from CPAN is a plus.

[1]: <http://mojolicio.us/>

~~~
doktrin
> _There's just a vague implication that the language and it's ecosystem are
> substandard to Ruby and Python. Apparently you think it's self evident, so
> doesn't require explanation_

To turn the question on its head, why _should_ anyone choose Perl over the
alternatives? I honestly have never seen a reason to switch. Not terribly many
others have either, as of late. I will attempt to lay out some of my
reasoning.

When evaluating a new language & ecosystem, I tend to look for an active and
welcoming community, a large selection of actively maintained libraries, and
lastly a language that is interesting and/or fun to develop in. I can't really
pontificate with authority on how Perl fares with regards to the above 3, but
I will share my perception. Feel free to contradict (of course).

1\. Community : there's no doubt Perl's community has taken a bit of a hit
over the last n years population wise. In addition, the Perl community has,
anecdotally, a reputation for being a bit terse [1]. Nothing cut and dry here,
but again nothing that stands out IMHO.

2\. Libraries : by extension of a diminishing pool of active contributors, it
stands to reason some modules may not be as actively supported as their
counterparts in other languages. This is compounded by the uncertain state of
the language's version (5,6,7?)

3\. Language : I personally have enjoyed coding in Perl, and am not really too
intimidated by its historical warts. It's quite possible to write readable
Perl, so write-only accusations are of little concern (to me).

Notes :

* Versioning : As an outsider, the current state of Perl's versioning is confusing. Perl 6 has been in development for over a decade, and I've seen mention of Perl 5.2 being released as Perl 7. None of this reflects positively on the language as a whole as it raises concerns about future proofing and maintainability.

* Mojolicious : Looks nice. My only concern would be that, based on the GitHub commit history, it is overwhelmingly governed and contributed to by a single individual. More so than even Rails, and significantly more so than Django. This isn't necessarily a negative, but I'd certainly want to trust him before building a production app using his tool.

[1] [http://blogs.perl.org/users/joel_berger/2012/10/why-
people-d...](http://blogs.perl.org/users/joel_berger/2012/10/why-people-dont-
like-mojolicious.html)

~~~
kbenson
> To turn the question on its head, why should anyone choose Perl over the
> alternatives? I honestly have never seen a reason to switch.

Was that the implication of the original statement? When you said you didn't
see much reason for a new project to be started in Perl, I took that as any
new project, even in a shop that has prior Perl experience, not a project
where you are specifically looking for something different than our prior
language.

Indeed, if you are already using one of Perl/Python/Ruby, I'm not sure I see a
reason to switch from any one of those to any other.

If on the other hand you actually meant "When starting a new project, I see no
reason to use Perl regardless of whether that's where you have experience",
then we still have a discussion worth having.

> 1\. Community : there's no doubt Perl's community has taken a bit of a hit
> over the last n years population wise. In addition, the Perl community has,
> anecdotally, a reputation for being a bit terse [1]. Nothing cut and dry
> here, but again nothing that stands out IMHO.

Did you actually read that link, or just read a section title and assume it
made your point? Because the author updated that section saying that he really
can't talk much on that point, because he wasn't there, and the evidence shows
it to have been fairly civil.

That said, Sebastian does have a bit of a reputation for being "terse". But
that's one person. Since when does one person define a whole community?

> 2\. Libraries : by extension of a diminishing pool of active contributors,
> it stands to reason some modules may not be as actively supported as their
> counterparts in other languages. This is compounded by the uncertain state
> of the language's version (5,6,7?)

You have a lot of assumptions, and are using them as the basis for more
assumptions. How much has the community decreased? What percentage of the
community that are still active are contributors of modules, compared to
similar communities of other languages?

Or, just look at some data: <https://metacpan.org/recent> Feel free to change
the filter on the left to new distributions, not just new releases, to get an
idea of how much active development is going on. It may be more or less than
other languages, but I think what's shown should be sufficient to disabuse you
of the notion that no development is going on.

As for the the version number, this is a non-issue. There is no issue of
version numbers, it's a solved problem. Some people in the community
occasionally bring it up because it's a _sore_ spot, and it gets a lot of play
in the tech media sites, but it's really rather simple (if different than most
other languages). Perl 5 is Perl 5, and will stay so unless someone forks it
and competes. Perl 6 is a new language, intended as _both a successor and a
companion to Perl 5_. People are _NOT_ expected to migrate Perl 5 code to Perl
6, it is a _different language_. This has nothing to do with the state of the
language's future. Perl 5 is still being developed. Perl 6 is still being
developed. Both are available, and useful, for specific subsets of uses. For
Perl 6 that happens to be a somewhat smaller subset currently because of
performance issues, and some portions of the spec still being fleshed out
(this is a different discussion).

> 3\. Language : I personally have enjoyed coding in Perl, and am not really
> too intimidated by its historical warts. It's quite possible to write
> readable Perl, so write-only accusations are of little concern (to me).

Agreed.

> * Versioning : As an outsider, the current state of Perl's versioning is
> confusing. Perl 6 has been in development for over a decade, and I've seen
> mention of Perl 5.2 being released as Perl 7. None of this reflects
> positively on the language as a whole as it raises concerns about future
> proofing and maintainability.

Blame tech media sites for taking an internal community discussion,
misunderstanding the state of things, taking random suggestions from people as
real community movements, and playing it up for page views. I'm sure we can
agree the media isn't infallible.

I'll agree that Perl 6 is unfortunately named. If you know the eventual goals
(Perl 5 interoperability) the name makes a bit more sense, but it has caused
some in the Perl 5 community to feel constrained to a version number (thus the
talk of Perl 7). In the end, this is a marketing problem (which is why you see
it from the outside).

> * Mojolicious : Looks nice. My only concern would be that, based on the
> GitHub commit history, it is overwhelmingly governed and contributed to by a
> single individual. More so than even Rails, and significantly more so than
> Django. This isn't necessarily a negative, but I'd certainly want to trust
> him before building a production app using his tool.

There's a fair number of other people that have committed[2], but I won't
argue the impression that it looks to be primarily Sebastian (even if there's
supposedly 4-5 core developers, according to changelog notices). That said,
from your earlier link that explained him leaving the core Catalyst team[1],
he _started_ Catalyst, so he's got some experience in this area.

I feel fairly certain others would step up to the plate if he couldn't commit
as much.

[1] [http://blogs.perl.org/users/joel_berger/2012/10/why-
people-d...](http://blogs.perl.org/users/joel_berger/2012/10/why-people-dont-
like-mojolicious.html)

[2] <https://github.com/kraih/mojo/contributors>

~~~
doktrin
> _Was that the implication of the original statement? When you said you
> didn't see much reason for a new project to be started in Perl, I took that
> as any new project, even in a shop that has prior Perl experience, not a
> project where you are specifically looking for something different than our
> prior language._

Yeah. This wasn't about a Perl shop switching gears, but rather seen from the
POV of a blank slate. I tend to think in terms of new startups, and put myself
in the shoes of someone trying to bring a new product to market.

> _Did you actually read that link, or just read a section title and assume it
> made your point?_

I did. A lot of the back-and-forth in the comment section helped me make the
decision to include that link as illustration.

> _It may be more or less than other languages, but I think what's shown
> should be sufficient to disabuse you of the notion that no development is
> going on._

I never said "no development" was going on. Please don't put words in my
mouth.

My concern is that upon requiring a module for purpose X, to find that
libraries A B and C are poorly supported / no longer supported. This isn't
really as simple as counting global library updates on a given day.

For what it's worth, roughly twice as many new modules were added to ruby gems
during the equivalent time period [1]. The data isn't made accessible anywhere
near as neatly as on metacpan, and requires futzing with the API.

> _You have a lot of assumptions, and are using them as the basis for more
> assumptions... Did you actually read that link..I might, if I knew what your
> point was...Apparently you think it's self evident_

Feedback : you've spent a lot of time talking about me and my perceived flaws.
Not sure if this is what you intended, but this conversation feels hostile. My
intention is certainly not to be on the offensive, and I hope the same holds
true for you.

[1] <http://guides.rubygems.org/rubygems-org-api/#activity>

~~~
kbenson
> I did. A lot of the back-and-forth in the comment section helped me make the
> decision to include that link as illustration.

Ah. I assume when linked to an article that the article itself is the intended
object of my attention. The comments are indeed a valid source of community
info, but I also imagine an article title of the format "Why people don't like
X", you're going to get some polarized views.

> I never said "no development" was going on. Please don't put words in my
> mouth.

You're right. My apologies. I know you weren't implying that. That was a
sloppy turn of phrase on my part.

> My concern is that upon requiring a module for purpose X, to find that
> libraries A B and C are poorly supported / no longer supported. This isn't
> really as simple as counting global library updates on a given day.

Indeed, I agree with that assessment. I struggled with a way to provide the
links as a way to indicate there _is_ development while also alluding to the
fact that I think number of updated and new modules over time is a bad metric
for _quality_ of modules, as well as being misleading as the number may change
over time as many of the common, core needs are met, and those modules
stabilize.

That said, CPAN module pages show the last updated time, as well as the dates
of previous commits. The dependency (and reverse dependency) graphs available
on metacpan also go a long way towards letting you know how much else a module
relies on (for the purpose of assessing possible problem modules farther
downstream), and how stable and mature a module is (to some degree,
considering how many other modules rely on it).

> For what it's worth, roughly twice as many new modules were added to ruby
> gems during the equivalent time period. The data isn't made accessible
> anywhere near as neatly as on metacpan, and requires futzing with the API.

Yeah, I did some research, and found it a bit harder to get counts for Python
and Ruby. But we agree raw count isn't all that useful, I was just including
it to show that there was activity, and of a level that I would consider
significant.

> Feedback : you've spent a lot of time talking about me and my perceived
> flaws. Not sure if this is what you intended, but this conversation feels
> hostile. My intention is certainly not to be on the offensive, and I hope
> the same holds true for you.

It's definitely not what I intended.

> I might, if I knew what your point was

Intended literally. I thought the statement was vague, and I wasn't sure the
actual point, but it appeared to indicate something regarding the desirability
of using Perl for new project due to the state of the language in comparison
to similar languages. I was trying to be explicit.

> Apparently you think it's self evident.

Not meant to be snide, although I can see how you could take it that way. I
assume assertions without explanations are put forth because the reasoning is
self evident (or discerned easily enough to be self evident to those
familiar). There were no explanations put forth, and if you _did_ think it was
self evident, that expresses something in itself. I have no doubt there are a
great many people that will argue similar points to your original statement
with little to no experience, by simple repeating claims they've heard as
though they are fact.

> You have a lot of assumptions, and are using them as the basis for more
> assumptions

I'm not sure how you think this is hostile, but obviously by it's conclusion
you do. it was in reference to a statement where you seemed to assume the Perl
community was in decline, and used that to make more assumptions about module
quality. You can't use community population and involvement decrease to
indicate module decline because of lack of people without first qualifying
community population and involvement decrease. That's what I meant about
making assumptions, and using those to make more assumptions.

> Did you actually read that link, or just read a section title and assume it
> made your point?

A poor choice of words, but meant literally. The only portion of the article I
found that might support your point there was replaced by a retraction that
reversed the stance. I felt compelled to ask whether you had actually read
that, or just went by the section title "The Developers are
Mean/Antisocial/Stubborn/Other". A poor choice of words on my point, and you
clarified your point to reference the comments, which indicates why you
included that link.

> My intention is certainly not to be on the offensive, and I hope the same
> holds true for you.

No, I enjoy a good discussion, and actually attempt to monitor my speech
(written or verbal) closely to try to avoid misunderstanding, but that's _so_
hard to do with a natural language. :)

P.S. While it may seem like I'm trying to defend myself overly hard by
addressing each point where you interpreted me as possibly hostile, I think
it's important to explain my true point in each case to accurately reflect
what I was trying to convey. If you interpreted them as hostile, it's possible
you may have also misinterpreted my point, as tone often affects meaning.
Individually addressing each allows you to look at each one anew.

Okay, that's enough meta. I do find examining the misunderstandings of an
argument/discussion fascinating though...

~~~
doktrin
I appreciate you taking the time to address the statements I was not
interpreting correctly. It goes without saying, but communicating over text
always leaves some small room for misunderstanding.

This discussion has certainly left me interested in re-exploring the world of
Perl. As minor as it sounds, I really enjoyed playing with metacpan, which as
mentioned is definitely more fleshed out than its counterparts.

In addition, while perusing various Perl repos I remembered how much I once
liked writing Perl, and will probably revisit it in a side project (if not
production just yet).

~~~
kbenson
> It goes without saying, but communicating over text always leaves some small
> room for misunderstanding.

Definitely. Even spoken English is rife with misunderstandings, and when the
tone is almost entirely removed as in writing, that just makes it all the
harder.

> In addition, while perusing various Perl repos I remembered how much I once
> liked writing Perl, and will probably revisit it in a side project (if not
> production just yet).

Nice to hear!

Re: metacpan, it's amazing what interesting modules show up when you follow
some of the metacpan dependency graphs. IMHO, once you're above a certain
number of modules, the problem starts becoming less of whether a solution
exists and more about how the candidate modules rate WRT reliability, platform
compatibility, dependencies you do or do not already have, etc.

------
lloeki
> _you really need to throw fast hardware at it for good performance._

That's where — non syntetic benchmark, anecdotal real-world use — Python rips
Ruby apart. I cringe every time I wait for "bundle exec {rails console|rails
server|rake|cap}". At every point in development, tests and production, ruby
execution _feels_ sluggish. Our routine Python dance on my 4 years old Core 2
Duo laptop runs circles around our Ruby stuff on my desktop i7-2400.

2.0 brought Ruby into decent land, but there's _so_ much more to do. Future
developments look interesting but I fear about the performance impact of new
features (such as refinements).

I'm definitely keeping an eye on Topaz.

~~~
vidarh
Topaz won't help for the case you describe.

 _The_ big problem with bundle exec (or Ruby startup times in general), is the
ludicrous amount filesystem access because of searching through a ridiculous
large number of files for each "require". E.g. if you have a ton of gem's
installed, most "require" calls will look for the files you require relative
to the root of _every_ gem....

Much more extensive use of require_relative, and fewer search paths can fix
that entirely.

Try an "strace 2>&1 -e last64,stat64,lstat,stat bundle exec [yourcommand] |
less" and be prepared to be shocked at the waste.

(EDIT: This of course assumes you have strace; on most Linux distro's that's
just a package install away - I don't know about OS X, and I've got no idea
how to make dtrace do the same)

~~~
nikcub
> I don't know about OS X

DTrace, eg.

    
    
       $ sudo dtruss -d -f script/rails server
    

you can also attach to a PID. If you are a developer on OS X it is good to
know DTrace and what it is capable of. There are a lot of default scripts
installed in OS X and you can write your own (if you have ever run iosnoop or
execsnoop then you have already used DTrace scripts), see:

[http://dtrace.org/blogs/brendan/2011/10/10/top-10-dtrace-
scr...](http://dtrace.org/blogs/brendan/2011/10/10/top-10-dtrace-scripts-for-
mac-os-x/)

[http://hints.macworld.com/article.php?story=2007103112182371...](http://hints.macworld.com/article.php?story=20071031121823710)

<https://wikis.oracle.com/display/DTrace/Introduction>

~~~
vidarh
Thanks. I don't actually run much stuff on OS X - I use it as my work desktop,
but all my "real work" is done via ssh to Linux boxes, so the OS X box is
rarely running more than a browser, iTerm 2 and Thunderbird, all maximized. I
only "see" OS X when something crashes....

EDIT: Completely unrelated, I just noticed who you are. We met in Mike's house
when I came over for the launch of Edgeio. And I just realized how long ago
that is.

------
jongalloway2
I'm happy you did something different, even though your reasons are of course
all wrong. I do wish it had been Node and not Ruby - JavaScript fits most of
your reasons for going with an open source stack a lot better than Ruby does.
Why not Node was the post I was hoping to read.

But back to why you're wrong on the internet:

1\. .NET licensing isn't complicated, SQL Server is. There's an easy fix for
that.

2\. I don't think StackOverflow really participates in the best that the .NET
open source world has to offer. From the information I can read, you (and
team) published a lot of the code you wrote under open source licenses, but as
far as I know the StackOverflow stack didn't really interact with many (any?)
open source .NET projects that weren't run by StackOverflow - e.g. writing
MiniProfiler instead of working with Glimpse, working with Mono, etc.

3\. There's a lot that's changed in the .NET web space in the past year as
they've moved from just releasing the code (see 2 above) to accepting pull
requests. This has resulted in a good amount of accepted pull requests -
community contributed features which ship "in the box" and are officially
supported by Microsoft. Sometimes that's lines of code, but more often it's
integration of popular community libraries. If anything, that trend is
accelerating.

(also posted on blog comments, but nobody reads those)

Coding Horror Fan, Jon

~~~
davesims
Are you trying to say that _both_ node _and_ C# are better open source options
than Ruby? Or rather that node is better and C# is not as bad as Jeff says?

Either way -- to say that C# would be a better platform for developing an open
source project is far-fetched at least (the developments of the last year
notwithstanding, although agreed that MS has come light years in that
direction from where it was just a short while ago), and to say node would be
better is, well, _not uncontroversial_.

I understand, given your position, this is a point of view you must advocate
(although...node? really?), but neither point makes Jeff's rationale anywhere
near " _all wrong_."

Agreed re: SQL Server vs., say, postgres. I'm actually not sure why we don't
see that option (ASP MVC + postgres/mysql) a lot more often than we do.

~~~
jongalloway2
Let's start with the "must advocate" part. I work for Microsoft because I
really like their web products. They don't tell me to comment on Hacker News,
I don't get a HN comment bonus. The only possible impact commenting on HN
could have on my job is negative. I'm just saying what I think.

I said that given a move away from .NET, Node would have been a better choice.
I think Node is more open source friendly for a lot of reasons. For one thing,
if cross platform friendliness is a primary driver, the Rails stack doesn't
run easily on some of the most popular operating systems. The dev setup
instructions are getting better, but they all began with "step 1. buy a mac".
Is that really more enabling to the 2nd and 3rd world developers Jeff
mentions? It's admittedly gotten better as they've added some Linux docs.

I also listed some reasons that C# is not really a non-starter for open
source. Jeff's first two points don't really sell Ruby over .NET + Mono to me,
and I explained that I don't think Jeff or StackOverflow really participated
fully in the .NET open source ecosystem in a way that gave them a lot of
value. There are a lot of self fulfilling prophecies in the .NET open source
world.

~~~
davesims
> I work for Microsoft because I really like their web products.

Cool! Good to have gigs we like.

> "step 1. buy a mac". Is that really more enabling to the 2nd and 3rd world
> developers Jeff mentions?

Eh. Linux is just fine for Rails dev. The Mac thing is mostly a hold-over from
earlier days when TextMate was the default editor, and because most Rails
shops expect it. In fact one of the most "enabling" scenarios here is to take
a cheap, lightweight Ubuntu dev laptop and ssh into a dedicated development
server, do all your editing on vim or emacs.

> I also listed some reasons that C# is not really a non-starter for open
> source.

Yeah, but it's a hard sell is it not? When considering tech stacks to risk
your entire project's future on, what's the _practical_ difference between
"Not Really A Non-Starter" and "Really, Really a Non-Starter"? Not much.

~~~
jamesgeck0
I develop Ruby on OS X using Ubuntu running in a Vagrant VM, just because
package management and configuration is so much easier that way (although
Boxen may change that soon). Well, and also because we use Linux in
production, and platform specific bugs, though rare, are not unheard of.

Windows is acceptable for Ruby development if Vagrant or JRuby is used,
although the platform is admittedly not a first class citizen.

------
rurounijones
> Ruby is a decent performer, but you really need to throw fast hardware at it
> for good performance.

Everytime a performance thing comes up I still think "Try JRuby if it is that
much of a problem"

Of course there are downsides but the code itself is not one of them. Most
apps will run on JRuby without trouble without any conversion work.

The biggest obstacle I think is the switch from things like passenger /
unicorn to totally unfamiliar servers like trinidad or torquebox (and the
inevitable breakdown of jruby to java abstractions when you want to try
advanced stuff and you have to learn java'isms like JMX etc.)

It didn't actually occur too strongly in this case but if ever I see a blog
post about "Ruby didn't perform well enough" and they DIDN'T give jruby a try
then my forehead gets a slapping.

JRuby - The forgotten option between more hardware and switching to a
different language.

[Edit] Actually I should clarify, I have not yet compared ruby2 vs jruby and
the applications I write tend to be very multi-threaded which plays into
jruby's hands.

~~~
bad_user
JRuby is really cool, however whenever I tried using it, well it was painful.
It's not JRuby's fault as the devs did a phenomenal job on making it a first-
class Ruby implementation, but you always have issues with its startup time
added on top of the already awful startup time of Bundler/Rails, or with
incompatibilities with libraries, or with libraries behaving differently or
being incomplete on top JRuby versus Ruby MRI, or with instances in which you
have to mix Maven or Jars with Bundler / RubyGems and so on.

In the end, for new projects if you want to use the JVM, it's way better to
use a language that was grown on top of the JVM. Like Scala or Clojure, or
maybe even Java 8 when it comes out. Which is exactly what I personally did,
being tired of the limitations that the reference Python/Ruby interpreters
have.

~~~
rurounijones
I actually know of a few people who use MRI on their local machines and JRuby
on the servers.

Not ideal but one option.

Regarding mixing jars / maven and bundler. Well to be honest I have never been
in that position w.r.t maven but including jars in a project has never really
been a problem for me. (Plus on MRI those jars wouldn't have been available in
the first place!)

~~~
bad_user
I ended up with a mix when I wanted to run my app on top of a Jetty server.
There are projects like jetty-rackup, but when you're on top of the JVM
sometimes you feel the need to throw a servlet for a problematic endpoint in
there, or some middleware like a filter that you could use for websockets or
some library that doesn't already have wrappers packed up as a gem and so on.

JRuby is great, all I'm saying is that when you feel the taste of a competent
virtual machine there's no going back :-)

------
RyanZAG
Curious as to why Java didn't feature in the choices - considering just how
similar Java is to .Net yet having none of the licensing issues and a huge
(the biggest?) set of freely available high quality libraries...

~~~
jiggy2011
The problem is choosing a framework for Java. Most of them are just big ,
unwieldy and force overwrought abstractions and 1000+ line XML files on you.

The big exception is Play! Framework but that seems to have mainly shifted
over to the Scala side of things.

~~~
thebear
I've heard great things about Play. When I had to choose a Java framework
about 2 years ago, I chose Stripes, and I've been very happy with it. But I
notice that it doesn't even get mentioned in discussions like this one. Wonder
why that is.

~~~
RyanZAG
One of the biggest (maybe the biggest?) contributions to language and
framework adoption is marketing in the form of blog posts, training sessions
and quality tutorials. This is why RoR is so popular even when it isn't all
that great (there are many technically superior alternatives across many
languages) - it has amazingly good marketing for a framework.

So to answers your question: you don't hear about Stripes because Stripes is
bad at marketing. Just look at their website - it looks like its from the 90s.
A small bit of CSS work is probably the best thing Stripes could do to
increase user base.

------
anonfunction
_Ruby isn't cool any more. Yeah, you heard me. It's not cool to write Ruby
code any more. All the cool people moved on to slinging Scala and Node.js
years ago._

This made me happy.

~~~
rmoriz
Jeff is so 1990ish. Cool hipsters do Erlang and Go nowadays!

~~~
Ygg2
Future proofed hipsters write in assembly and machine nowadays ;)

Also don't forget Haskell.

~~~
DanWaterworth
Haskell is also rapidly becoming uncool. The cool kids use Coq, Agda or Idris.

~~~
bjterry
Hilariously, there actually is an Agda web framework in development[1],
although it seems like more of a research project than a serious effort. If
there were a web framework in Coq, that would really be something. Idris is
intended to be more general purpose, so hopefully one will be written someday.

For those not in the know, these are programming languages used mostly for
developing mathematical proofs. They are all dependently-typed languages,
which means that a type can depend on the values it contains. For example, you
can constrain a function to only accept lists of a given length in a way that
can be type-checked.

1: <https://github.com/larrytheliquid/Lemmachine>

~~~
DanWaterworth
The vector type is always given as an example, but I find the ability to give
a type to printf more mind bending.

Just in case that went over your head and to reiterate, that means that:

    
    
        printf "Hello %s" 4
    

would generate a type error, so would:

    
    
        printf "Hello %s" "wor" "ld!"
    

and:

    
    
        printf "Hello %s! %s" "world"
    

but:

    
    
        printf "%s %s!" "Hello" "world"
    

wouldn't.

------
mmahemoff
Jeff is really comparing the wrong things here. Whether Ruby, Python, or even
ASP.net, it's all asking for Discourse to be a niche product only used
sparingly by enthusiasts and in the enterprise.

Which was maybe the goal, but I don't think so.

The obvious choice IMO was to suck it up and live with PHP. Nowhere near as
nice as the other options, but exponentially less friction for people to set
up on a LAMP stack. I'm not going to all-out defend PHP, but it's not as bad
as it used to be; and you don't have to use it as much as you used to, given
that Discourse is heavily a client-side JavaScript app anyway.

~~~
dpritchett
Jeff claims that they want to make the Ruby install story as easy as PHP's
(e.g. download and unzip into a directory accessible via mod_php). I'd love to
see that happen but it strikes me as a bit of a risk to their business. I
guess Jeff is independently wealthy already, though his team may not be.

~~~
jmcqk6
The thing is that ruby is actually easier to install than php - on your own
computer. Having a rails hosting environment as ubiquitous as php is a
completely different story. I don't see how any single person would be able to
do that.

------
Swizec
Pfft, some of us moved to node.js straight from Python and skipped the whole
Ruby thing.

~~~
spoiler
Although I love node.js, but you are missing out on not using Ruby. I used
both Ruby (eventmachine) and node.js on a recent project and it was a total
_awesomegasm_. I admit that the Ruby side had some Ruby code converted to C
for performance reasons (parsing binary blobs), but we are not rubysts because
performance is the only thing we care about. I find Ruby incredibly sexy, be
it still cool or not.

~~~
Swizec
Yeah I actually did start working on a Rails project a month or so ago.

Ruby is okay. I like how extremely easy it is to pick up. I don't like that
this probably leads to similar problems the PHP ecosystem developed
eventually.

------
michaelwww
It's nice to see Anders Hejlsberg getting some love. Truely one of the greats.

------
floydpink
Good read. Makes me want to learn Ruby!

One query though: All that talk about the shiny new hardware and Ruby being
slower in rendering pages under 50ms and the comparison to StackOverflow;
isn't that a little unfair? I am trying to understand better and not making
claims of knowing better than Jeff. :)

How can you compare a completely server side solution (in ASP.NET MVC) to an
almost completely client side solution (in Ember.js), which only uses the
Rails API for the backend alone and say .NET is superior to Ruby? Especially
when the page rendering time seems to be the only profiled checkpoint for the
performance.

Wouldn't JavaScript and the whole Ember.js be adding to the slowness at all?

~~~
EvilTrout
He's talking purely server times here. And it shouldn't be pages so much as
"JSON Blobs" :)

~~~
floydpink
Ah, ok. Makes sense now. Got caught up a little too much on "page" :)

------
mathnode
Why not mono?

For not using .Net I can understand the his detailed reasons, Java because
it's a grumpy old man, Haskell because it's a paradigm shift etc...

~~~
trailfox
> _Why not mono?_

Surely you jest?

~~~
voidlogic
I wouldn't use it, but I know people have had great success with Mono + .NET
MVC + nHibernate/PostgreSQL on Linux. Now I personally would rather use
Go/Java/Haskell, but I would take the above stack over Ruby any day.

------
_pmf_
> There are maybe fifty world class computer language designers on the planet.
> Anders is the only one of them who built Turbo Pascal and Delphi.

The Pascal _syntax_ was designed by Niklaus Wirth.

> It is thanks to Anders' expert guidance that .NET started out such a
> remarkably well designed language

.NET is not a language.

~~~
jablan
TurboPascal departed a lot from standard Pascal syntax, especially in very
popular versions 5.5 and 6. IIRC, standard Pascal didn't even support
modularity (importing symbols from other files). Pascal was mostly academia
language, suitable for learning imperative programming (Wirth later designed
Modula-2, which was capable for industry). TP 5.5 introduced OO, pretty much
what we see as Java-style mainstream these days. Also, the IDE itself was
incredibly nice to work with. Not to mention Delphi.

------
fijal
Geez, this post is full of complete nonsense and FUD when it comes to
programming languages and their performance characteristics. I won't comment
about the language design (I kind of like C#, but it's beyond the point), but
the facts:

* C#, and specifically microsoft implementation of it is absolutely horrible. The AOT part is ok, but the JIT is incredibly dumb. There are good reasons why it is the way it is, but it's ridiculously slow compared to Java (and yes, you're legally obliged not to do this comparison)

* MRIs Ruby GC collector until 2.0 had bugs which prevented it from having good performance, even asymptotically. To be honest, CPython had it until 2.6 too. That means that if you allocate objects rapidly you can end up in a O(n __2) situation where each n allocated objects end up taking more and more time.

* Ruby and MRI in particular is nowhere near good performance. But you can throw more hardware on the problem always.

* I would like to see some data about "StackOverflow is fast because it's on .NET", it definitely does not fit with my view of how fast/slow libraries/VMs perform.

To be honest, language speed often does not matter. Java has pretty decent
VMs, like hotspot and yet a lot of Java code is horribly slow, because
libraries are badly written (think eclipse).

Also I'm personally terrified with ruby's security stories recently (and yes,
it's both ruby and rails at fault)

~~~
kvb
For a post accusing another of FUD, it would help if you got more of your own
details right: C# doesn't have an AOT or JIT compiler - all compilers that I'm
aware of always compile it to IL. You're right that the .NET JIT has
historically focused on startup speed rather than pure speed, but there are
many factors that affect performance (e.g. C#'s defaulting methods to non-
virtul may mitigate the lack of hotspot-like optimization; value types and the
resulting lack of boxing/unboxing may likewise have a positive impact; ditto
for reified generics). What in particular strikes you as "horrible" about
Microsoft's implementation?

~~~
fijal
We did quite a lot of benchmarks about various programs (like Python
interpreter written in RPython compiled to C#) and the performance was pretty
bad. There were various issues, some avoidable some unavoidable, like
Exceptions being very very slow (and being essentially for free on Java). I
don't think it's possible to summarize it without writing a small novel and I
don't care enough, but the JIT is as far as I know a direct IL-to-ASM compiler
with very little optimizations or not at all. This puts a serious ceiling on
what can be fast and what cannot be fast. In particular the escape analysis is
either non-existant or very weak.

The AOT part is exactly C# -> IL and then it's later compiled to assembler.

------
devniel
I have just started to learn Python and Django after read a lot of questions
about "Ruby/Rails vs Python/Django". I worked with Node.js since 2011 and with
Play last year.

~~~
AndreasFrom
Play with Java or Scala? What did you think about it?

~~~
devniel
With Java. IMHO Play framework make more agile the web development with Java,
I think that it's similar to Rails. I had some problems with its Ebean ORM and
MySQL, also the scala templates have some limitations (e.g. I couldn't declare
a variable). I chose Play because in my college all knows Java, and at that
moment Play was the better framework for web development with Java. It's my
project with Play Framework 2 : <http://www.youtube.com/watch?v=i5Uf3N1rgWc>
and I'm going to still work with Play sometimes.

------
eric970
No matter what language or VM you choose, there are going to be tradeoffs. A
good engineer understands these tradeoffs well and makes opinionated decisions
with all the knowledge he or she has.

All the "my language is better than yours!" bashing is a result of being
stubbornly opinionated and not willing to look at things from another
perspective. There are always things that one VM will shine with where another
will fall flat at, at vice versa.

Also, I don't think Ruby is nearly as bad as most people think. It's not as
monolithically slow and vulnerable to exploitation as some people on HN claim.
The VM is decent, and there are ways to tune the performance up that make it
even "good". See, there's a tradeoff. The language is, IMO, fantastic, but
you're going to take a performance hit for that that you need to deal with in
some way or another. You're trading execution speed for "developer happiness",
whatever that means anymore.

------
dave_sid
I think there's too much talk about which language is the best, which
framework is the best, .NET vs node.js vs ember vs Java.

Okay I get the issues with licensing for .NET but in terms of functionality,
most languages and frameworks that developers are using are stunningly good.
We're lucky so have so many and most of this stuff doesn't cost a penny.

I think people should get less caught up in what tools they are using and
focus on making a decent application. A great application could be made from
any language mentioned here and so can bad application.

I like the comment about Ruby not being cool now. Too many developers get
caught up chasing the latest language and framework, continuously climbing the
learning curve of the latest offering.

------
Paul_D_Santana
Alright, this post convinced me! I'm going to start learning this weekend!

I did some searching around and found these classes:

<https://www.udacity.com/course/cs253> <http://www.codeschool.com/paths/ruby>
[http://ureddit.com/class/40250/web-programming-with-ruby-
on-...](http://ureddit.com/class/40250/web-programming-with-ruby-on-rails)

My goal is to learn web development, preferably Ruby but I'll make an
exception for the Udacity course because I like Udacity.

Of the above courses, which one would you recommend and why? Or is there a
better one? I am a C# and ASP.NET developer.

------
Mahn
_I'd also be lying if I didn't mention that I truly believe the sort of
project we are building in Discourse does represent most future software._

You know, it's great to believe in what you build and all, but being modest
sometimes would be nice.

~~~
ben336
I think he's referencing the "built on an open source language" model, not
saying that everybody will be emulating discourse. Its not immodest to say
that you're switching to something that you believe is the future. Its not
like he's claiming that he invented "open source languages" or was the first
to claim that as the future of programming.

------
prezjordan
Sarcasm aside, what are some benefits of .NET? I've only briefly used it, and
I hated the whole experience (probably because I really don't like Visual
Studio). I want to keep an open mind though, what am I missing out on?

~~~
tarr11
Most .NET devs (myself included) really enjoy the Visual Studio Environment.
So, if you prefer a text editor like vim, it may not be the right tool for
you.

The debugger is hard to beat (as Jeff mentions). C# has kept up with most
features (LINQ, dynamic, async/await, etc) that are available in Ruby, and the
CLR is quite fast. The core libs are also very solid. ASP.NET MVC is very
comparable to Rails.

There are a bunch of downsides as well, but they are well-covered by OP.

------
ksec
I still dont get the drift about Ruby being fast enough. Ruby is slower then
CPython, PyPy, Lua, LuaJit, and literally majority of other popular dynamic
scripting languages.

The argument that keeps being throwing up is that It is fast enough for most (
actually only for Rails related ) things and is mostly limited by SQL, but
that is like saying my Toyota Prius is fast enough since the high way speed is
limited anyway.

I meant most of the complain aren't really about Ruby getting LuaJit speed (
is that even possible? ) or JS V8 engine. Just at least it is on par with
Python ( not talking about PyPy either )

------
pjungwir
To return the compliment, as a now-mostly-Ruby programmer with experience on
most of the other open source stacks, when I built a C# desktop app a few
years ago, I fell in love with the language. The APIs for Collections and IO
aren't as clean as Java's, but the language is great. In many ways it felt
like I was still in Ruby. I'm super-impressed how Microsoft was able to out-
innovate Sun, since starting with basically a Java clone. If you haven't ever
tried C#, I encourage you to whip up a quick desktop utility and give it a
try.

~~~
sourc3
I have developed with C# since it was in beta. I absolutely love the language.
Prior to that I had done extensive C++ and some Java.

Last year I gave Ruby a try (for an ambitious project) and I have to say that
it felt like going back in time to my C++ days. The syntax is very, very
different and the environment support (command line + sublime) is clearly not
something that I have done in the past 10 years.

I like the flexibility of it but coming from statically typed languages I find
myself trying to replicate the same way of thinking in Ruby. Which in turn is
making me less productive. Given the mental blockage and fear of productivity
loss I am not certain I can push through to get to the point of productivity
with RoR.

I am giving Python a try next! I would also appreciate any pointers to get me
up to speed w/ Python frameworks for web development.

PS: The rails part is just fine, I have developed an Active Record based
framework to do web development on C# in 2003. So I am more specifically
talking about Ruby the language.

------
Offler
(However, It's also worth mentioning that Discourse is, if anything, even more
of a JavaScript project than a Ruby on Rails project.

So why not Node.js? Presumably it's down to maturity.

~~~
devniel
I think that "node.js" is excelent for build real-time applications in a few
days but for huge projects is a little difficult to handle all the "callback-
style" and async results, IMHO it's about readable code , a key factor in
developer teams.

~~~
anonfunction
It's certainly a departure for many, but any code can be hard to read
depending on how it's architected and who's writing it.

------
kayoone
Isnt discourse mostly an EmberJS app with a rails REST backend? Seems like the
big frameworks are slowly loosing relevance as more development moves client-
side.

------
j_col
> Of course, we went on to build Stack Overflow in Microsoft .NET. That's a
> big reason it's still as fast as it is.

Wow, that claim could really do with some qualifying.

~~~
CodeCube
Their architecture has been pretty well documented, and can and has handled a
good amount of traffic with relatively small resources -
[http://highscalability.com/blog/2009/8/5/stack-overflow-
arch...](http://highscalability.com/blog/2009/8/5/stack-overflow-
architecture.html)

------
yock
_Now is a fantastic time to get into Ruby, in my opinion, whatever your
background is._

As someone who starts his first Ruby gig on Monday, this puts a smile on my
face.

~~~
heidar
Good luck! I can't wait to be in the same boat. :)

------
ameen
As someone who is trying to wean himself off of .NET I'd say Ruby isn't
exactly the best choice out there. I could jump over to any JVM language (even
hip ones) or convert into a Pythonista.

Ruby is hardly efficient and with better(and efficient) alternatives out there
I wonder why do people still flock to Ruby/Rails.

------
donebizkit
node.js is great when building rich client applications. At the end of the day
you only need your back-end to grab and serve data as fast as possible and you
delegate all the parsing to the browser.

------
Maven911
And where is php in all this, is it really considered a dead language?

~~~
voidlogic
While not sexy and hip, remember 35 percent of web traffic is handled by
PHP... PHP is still a player. I'm not a huge fan of either PHP or Ruby, but
with HipHop PHP apps seems to have a path to higher scalability. All languages
eventually decline and die, and while PHP might be declining (and as of this
year maybe Ruby too) PHP's death is going to be extremely slow, probably
decades. In 30 years I would not be surprised if PHP is the COBOL of web
development.

------
trailfox
_> Ruby isn't cool any more. Yeah, you heard me. It's not cool to write Ruby
code any more. All the cool people moved on to slinging Scala and Node.js
years ago._

~~~
MrBra
This part seems to have given peace of mind to so many ruby avoiding people.
Now you can finally discover ruby. You'll finally find out it's cool :)

------
tenpoundhammer
I just started using scala on the job and have never been more confused in my
life. I wish I was getting stuff done instead.

------
systems
Off Topic:

What is that editor in the screenshot?

~~~
pjmlp
Turbo Pascal, one of the best Pascal dialects with fast compilation times,
modules and everything you need for doing systems programming.

The IDE was also quite good for the time.

It was my favorite programming language until I was forced into C and C++
land.

Nowadays I am just another polyglot developer, but the Pascal family of
languages has a special place on my heart.

I think the software would be safer would one language of that family be the
default systems language for mainstream operating systems.

~~~
danieldk
_Turbo Pascal, one of the best Pascal dialects with fast compilation times,
modules and everything you need for doing systems programming._

And a great built-in debugger. And Borland Pascal 7 even had protected mode
support. I still get nostalgic when I see screenshots of Turbo Pascal.

 _I think the software would be safer would one language of that family be the
default systems language for mainstream operating systems._

Indeed, there were better languages in the Pascal family (e.g. Modula-2 and
Oberon), but they gained much traction. I did write some OS/2 programs with
the Canterbury Modula-2 compiler.

~~~
pjmlp
Have you ever used Native Oberon or his successor AOS operating systems?

A nice experience that it is possible to have desktop operating systems
written in GC enabled system programming languages, contrary to what many
people think.

Sadly not well known outside the Zurique's Technical University (ETHZ) or the
institutes that work with them.

I liked in the experience back in the mid-nineties and I am a bit of Oberon
collector.

~~~
willvarfar
There is precious little exposure of Oberon.

What you need to do is make a decent 'unwrapping' video and then talk about
how the object system worked e.g. widgets.

That'd get some attention here.

~~~
pjmlp
Yeah, I am actually planning to do something like this, but so far real life
keeps getting in the way. :)

------
sigzero
Use it if you like it and be done with it.

------
chris123
"Why Python", anybody?

------
martinced
_"I'm not inclined to make grand pronouncements about the future of software,
but if anything kills off commercial software, let me tell you, it won't be
open source software. They needn't bother. Commercial software will gleefully
strangle itself to death on its own licensing terms."_

If there was no open-source alternative companies like MS could have continued
for ever and ever with ever more convoluted licensing terms and people
wouldn't have had the choice...

------
papsosouid
The popularity of the idea that a language becomes "mature" when it is no
longer the popular fad makes me sad. Ruby was already a mature language before
it become a fad. Evaluate the language, don't avoid a language just because it
is trendy, and then jump on it after the bandwagon has moved on.

------
fakeer
Not again Ruby. Please.

PG needs to put in a filter over there, just like he deleted Adria's firing
posts yesterday. Though the contexts are different.

>> _that .NET started out such a remarkably well designed language – literally
what Java should have been on every conceivable level_

I am glad Java didn't turn out to be that way.

>> _Argentina, or Nepal, or Bulgaria_

Why has he mentioned all of them in one line/context? I don't see them at a
similar level either in education, wealth/poverty or so.

~~~
tuzemec
Being from Bulgaria: .net is widely used over here. Most of the companies that
I've worked for do relay heavily on MS stuff.

------
smoyer
"Ruby is maturing up nicely" ... They've certainly learned about security
recently and the response to the incidents was reasonably "enterprisey".

~~~
rimantas
Ruby != Ruby on Rails

~~~
smoyer
I wasn't aware that the rubygems.org exploit was limited to libraries that are
used in RoR.

As an aside, I'm not quite sure why I'm being down-voted since I meant the
original comment as a compliment. Shutting down the package site and quickly
cleaning up the vulnerabilities are (IMHO) a sign of a more mature platform. I
guess the first rule about Ruby is that you can't talk about Ruby (unless
you're one of the chosen few).

