

Ruby and the Opposite of Momentum - KirinDave
http://kirindave.tumblr.com/post/60776407/the-opposite-of-momentum

======
ohhmaagawd
I don't think JRuby gets enough credit. He pretty much dismisses it because it
uses a lot of memory and starts too slow for simple scripting. The JRuby team
have done some tricks to speed up startup time, seems to respond almost as
fast as MRI to me now. Haven't paid attention to memory though, but if you are
launching a script big enough that memory is a factor I don't think the JVM is
going to matter.

With invoke dynamic around the corner (Java 7), it seems that JRuby is Ruby's
best hope for a decent runtime.

What I don't get is why all there is such a strong anti-java sentiment in the
ruby community. Everyone wants to speed things up by writing native C code. I
for one would much rather write java code than C code. It's just as fast and
much less shitty. And it runs pretty much anywhere.

~~~
jimbokun
Seems like the good and crappy things about Ruby and Java, respectively,
complement each other well. Ruby is a high productivity language, Java not so
much. The JVM is a very well engineered run time engine, Ruby's MRI not so
much. Unicode, threading, fast, reliable, portable, well understood and
supported. Pluses for Java, minuses for Ruby.

So in principle it seems JRuby could have the best of both worlds. But for now
I'm having more fun with Clojure. :)

~~~
blasdel
You're absolutely right about Ruby & Java being a great _Odd Couple_

What I find interesting is that most of the JRuby users are first and foremost
Rubyists. The JVM users seem to gravitate more to Scala, Groovy, Clojure,
Rhino, etc.

------
petercooper
Not to rub salt into this whole pile of hurt in the Ruby world lately, but I'm
shortly going to be promoting (on Ruby Inside) some rather damning news from
the Windows camp in relation to how many significant Ruby libraries are either
ignoring Windows or not being transparent enough to make it easy to patch the
issues.

(I'm not a Windows user, but if Windows is treated like a third world country
by Ruby users, it's going to bite us _all_ in the ass.)

~~~
palish
That is the primary reason I chose not to use SBCL (Lisp) to implement the
game engine I'm building. I really wanted to, but SBCL leaks memory on
Windows. When I asked their mailing list about how to fix it, the community
was silent. Those two issues make it impractical to use SBCL to develop a
product.

~~~
Hexstream
How do you prevent unfortunate GC pauses for your game engine? I have two
conflicting thoughts lately:

"I want to use Lisp for _everything_! Oh but what about GC pauses in games?"

~~~
LogicHoleFlaw
Lua is used in games often. It does have GC, with an incremental non-
compacting generational GC. If you _do_ get pauses then there are various
methods of forcing GC on a regular basis, or just generating less garbage. It
works well in practice.

------
evdawg
I think it's very unfair of him to be criticizing and writing off Rubinius.
"Rubinius looked like the light and hope of the Rubyverse, but their team has
been slashed..."

Just because it was financially responsible for Engine Yard to cut back from 6
to 2 fulltime developers does _not_ mean that Rubinius is dead. Rubinius has
as and always will be a community project.

Furthermore, the author states "But the problem is that [ruby is] essentially
stagnant." Because of Rubinius, Ruby finally as a proper spec. This means we
_will_ see an "arms race" as he calls it, and it's because of Rubinius. PLUS,
4 implementations under active development (Rubinius, 1.9, MacRuby, JRuby)
hardly seems stagnant to me.

Bottom line: this is FUD.

~~~
KirinDave
Maybe it is FUD, but that is because _I_ am experiencing Uncertainty, Doubt,
and at least a little bit of Fear on the subject of what high-level dynamic
language I am going to work with next. I certainly have carried a lot of water
for the Ruby team, and I'm worried what I'm going to do with all my free time
if I don't have a language to idolize! ;)

I don't want to have to write off Rubinius, and I have a lot of respect for
Evan and the members of his team that I know. But can we be brutally honest
for a second? The only independent Ruby implementation to have delivered
goods, of any sort, is JRuby. I will trust Rubinius when it is publicly
released. Until then, it's just another one of several projects claiming that
Christmas will bring me a new, faster Ruby. And I've been hearing that same
promise before, again and again.

And saying that the Ruby spec is somehow unbroken Ruby stasis? We damn well
better have a spec! Ruby has been essentially unchanged for at least 2 years.
Saying, "Well at least we have a spec now!" seems like the lowest possible bar
for success.

P.S. MacRuby is fascinating, but let's see it on more than 1 of the Big Three
before we start saying it's a serious competitor.

------
thomasfl
Ruby has had huge impact on the way I write software. Whatever programming
language or tools I'll use tomorrow, it will be dynamic.

Without Ruby on Rails there would have been no Groovy on Grails web
application framework. But rubyist keep pushing limits, creating new kinds of
database orm libraries like sequel and new web frameworks like sinatra.

Sinatra makes me write web applications that looks like haiku:

    
    
      require 'rubygems'
      require 'sinatra'
    
      get '/' do
         "This is a web application!"
      end
    

Sequel makes me write SQL queries that don't look like SQL:

    
    
      dataset = DB[:managers].where(:salary =>   5000..10000).order(:name, :department)
    

And haml makes html tagging look pretty:

    
    
      %h1 Markup
       %p
         .my_id Look ma, no end tags!
    

When you first got a taste for this style of programming, there's no going
back. I don't now if I'll be coding Ruby, JRuby, JavaScript, Scala or Groovy
tomorrow, but it will be done Ruby style.

~~~
neilc
ORM examples that feature single table selects are unconvincing: the true test
of an ORM is whether it can do joins (outer + inner), aggregation, and
subqueries. Otherwise it is little more than syntax sugar, IMHO.

~~~
litewulf
Honestly, I think the syntax sugar is great because thats what I need the vast
majority of the time.

And the scaling aficionados probably prefer single table selects anyway. ;)
(Not that it makes a difference given how little traffic my blog gets)

------
blasdel
The Ruby Language itself has plenty of warts, but the implementation problems
are far worse. The MRI is awful, and 1.9 isn't much of an improvement at all.

The best hope I see for Ruby's future is embodied in re-implementations like
MacRuby, JRuby, and Rubinius. MacRuby could totally become the popular way to
write new Cocoa applications.

If MRI can be effectively displaced, Ruby can really break out of the "Perl
that people write better code in" ghetto.

~~~
jrsims
_cough_ Parrot! _cough_

But seriously, anyone know if Parrot is a realistic vehicle for this?

It's just puzzling to me that with all the demand for a better interpreter,
there really aren't any available options that are going to satisfy the
community at large, and there's no visible light at the end of the tunnel. Is
this because Ruby is a particularly difficult language to implement? Is it
because there is no formal spec? Lack of leadership (compare with Guido and
Larry)? All of the above?

~~~
blasdel
All of the above!

Parrot is never going to be viable -- 'flexible' platforms are only so when
there are piles of diverse users. Specifications do not make reality.

Ruby has a huge advantage over Perl in that there are a number of groups
successfully working to reimplement, specify, and reform it. There are visible
lights at the end of the tunnel, they're just for specific communities --
JRuby and MacRuby. Hopefully Rubinius (or a successor project) succeeds in
replacing MRI, but it's a pretty damn hard problem.

~~~
jrsims
All of the above = a huge bag of hurt that presents some damn near
insurmountable problems (leadership, on its own, is a huge issue).

To be honest, I don't know how one would get past those things without first
deciding, with a clear conscience, to hijack Ruby from Matz. I know that
sounds malicious, but even Dave Thomas is calling for a fork of the language.
Seems to me that forking is not quite what we need, as it keeps the language
rooted in the past, bringing the performance baggage with it (you're still
having to re-implement the loose idea of the Ruby spec, which as you pointed
out, presents some really hard problems).

No, maybe we need someone smart, loud, and with balls big enough to arbitrate
their way through whatever gray areas are left with Ruby's loose idea of a
spec, perhaps make some tough calls on what language features can reasonably
be supported, decide what needs to be cut, and break compatibility with
existing Ruby code if necessary. To top it off? This person forms a foundation
around it, a la Python.org, to ensure that the language is left in good hands,
gets proper funding for new development, patches, etc (hell, I would love to
donate to Ruby development if I knew the money would be put to good use. I
don't have that confidence now).

Of course, what I'm talking about now is not Ruby, but a new thing. This new
thing could be quite awesome. Whatever this new thing would be is still years
out, even if someone decided today that they would do it.

Python in the meantime?

~~~
blasdel
Exactly, Python wins.

There's a massive gulf between Matz and Guido as far as decision making, even
when you only look at the Languages and not their imperfect Implementations.
Just for example, look at how executable objects work:

* Guido made a hard+pragmatic decision that there are only Functions. Methods and Class Methods are functions that take their binding as an explicit argument (which is inferenced when called with the . selector). Lambdas cannot contain statements and simply yield to a Function. Functions are recursively defined as objects with a __call__ method.

* Matz tried to make everything _hugs all around_ and the result is that there's no straightforward Function type -- there are Methods, Blocks, Procs, Lambdas (1); which yield into one another bafflingly and retain scope in untoward ways. This makes some simple use cases very straightforward, but at a terrible cost.

(1). Are there more? The lack of certainty with which I can answer this
question is alarming.

------
spenrose
Maybe this comment is already here and I just missed it, but languages
naturally have life cycles, and thinking in terms of Ruby's life cycle might
explain both some of your early enthusiasm and your current discontent. (I'm
going to draw in broad strokes here and will probably get some details wrong.)

In 2002 Ruby was young: half-formed and exciting. It's problems didn't really
look like problems: they looked like things Matz hadn't gotten to yet (and,
even better, opportunities for other programmers to get to first). In late
2008 Ruby is established; the problems come with a set of reasons why they
aren't likely to be solved. (The other problems _were_ solved.)

This is natural and normal for any multi-year group endeavor, be it a company
or a rock band: it starts with a world of potential. If it is one of the lucky
few to survive for any length of time, it becomes mostly a specific reality,
with a humdrum future. (More often it goes from having a world of potential to
not having any future at all in short order.)

You cite as counter-examples Javascript and Scheme. Javascript is benefitting
from the HUGE externality of being the client-side language for the single
most important application category going. As for Scheme ... there's a
paraphrase of "Brazil is the country of the future, and always will be" that's
escaping me, but suffice to say that if the 73d time is the charm for Lisp's
taking over the world, I won't be too embarrassed to have bet against it.

Ruby's momentum 2002-2007 was like Python's momentum 1999-2004 was like Perl's
momentum 1993-1998: the momentum of a firework or a homerun. It was glorious
to watch them rise; it shouldn't be sad to see them return to earth.

------
tocomment
He's saying Ruby needs a better VM, no? I think the real problem is that there
are only 10-50 people in the world that know how to make high quality VM's. We
probably just need to get more open source people trained up in this.

For my part, I tried reading that Dragon book recently but it just didn't
click for me. It seemed way too low level, without teaching me the high level
first. Or maybe compiler/interpreter design just isn't an easy thing to teach
yourself?

What are your thoughts, HN?

~~~
rcoder
There are probably more than 50 "decent" virtual _machines_ in production use,
many of them open source. Anyone who completes a graduate-level course in
language and compiler design should be able to create a decent bytecode-based
VM, and should be able to make a good start on a simple JIT.

Here, in no particular order, are the ones I can think of off the top of my
head:

* Tamarin * OpenJDK * Squeak * Parrot * Python * Self * SpiderMonkey * PLT Scheme * CLisp * V8

(...etc., etc.)

The problem is not a lack of VM designs, implementers, or experience. It comes
down to two factors:

* Ruby is a _weird_ language, compared to most -- it wasn't so much designed as composed (in the sense of art/music). Normal compilation, optimization, and type-safety rules just don't apply, so even clever VM hackers are sort of left scratching their head when it comes time to optimize or deal with harder problems like serializing closures.

* The Ruby community is deeply bifurcated into two mutually-suspicious subgroups: the Rails users, and everyone else. Rail people hate (or at least mistrust) backwards-incompatible innovation in the language itself, because it breaks Rails, and (at least some of) the other group resents the Rails guys for holding the language back.

If you don't believe me on this second point, look at Ruby 1.9. If 1/10th the
energy went into testing and patching new Ruby releases as goes into a minor
point-release of Rails, we'd all be running nice, fast, bytecode-compiled Ruby
scripts with full Unicode and fiber support. Instead, we're stuck and 1.8.6
for anything "serious", because it's the last release Rails supports well.

------
subbu
I have used a number of languages/tools/technologies in the past. Whenever I
felt the existing choices don't meet my needs I have simply moved on. I never
had to bash my old choices because they are not good anymore. They have served
me pretty well so far. The community has helped me find answers. I didn't find
it right to laugh at the current community and tell them you are no good
because I am not there.

Move on and embrace the new coolness when you are done with your job.

------
luckystrike

      Perhaps the most frustrating part about Ruby, to me, 
      is the outrageously outdated state of the current Ruby interpreter.
      <snip>
      I wish we could change all that. I wish that we had a new, 
      exciting Ruby engine that began to rapidly iterate, was extensible in Ruby itself, 
      and really started to live the dream that Smalltalk failed to achieve in the enterprise: 
      being both cutting edge and mainstream. 
    

I agree with the above sentiment. A good VM is 'the' need for Ruby right now.

This is where i think Rubinius holds great promise. When Engine Yard started
supporting it officially, it started looking like we would finally have a good
VM 'soon', eliminating the single biggest issue with Ruby at this point. With
the recent cut-down in the size of that team, we are kind of at an infection
point. Either this project would flicker out (i really hope it doesn't happen)
or the community kicks in a big way to help it pick up pace.

------
tocomment
I think the time is ripe for a server/desktop side Javascript language to come
along. Rhino?

It's my humble belief that Javascript will be the most popular language within
10 years.

~~~
randrews
I would like you to be correct but I don't think you are.

Javascript with minor syntactic sugar for making DSLs, and with the stupidity
around scoping ironed out, that might win out, though.

~~~
tocomment
Why do you think I'm not correct?

~~~
randrews
For the reasons lined out here:

<http://javascript.crockford.com/javascript.html>

Don't get me wrong, it's my favorite language. I don't want to bash on
Javascript. Most of the coding I do for fun is in Dashcode, which I never
understood why isn't pore popular. But JS has big problems in public
perception.

Stories on new things done in Ruby tend to elicit "cool, I can use that", but
new things done in JS tend to elicit "what a waste, why use such a crappy
language".

------
schtog
Why choose Ruby in the first place?

I tried both at the same time and granted haven't coded anyhting real in Ruby
but Python just won handsdown on every point that mattered for such a
language:

    
    
      * Readability
      * Libraries
      * Rapid protoyping
      * Integration and support with other platforms, bindings   to libraries n other languages
      * Documentation
      * Support form industry(while Ruby is pretty much only used in webapps Python is used in bioinformatics, engineering, GvR works at Google hacking on Python, it is used at NASA, has numpy+scipy+matplotlib).
    

I just don't see much reason to hang on to Ruby. Switch to Python and let Perl
and Ruby die.

~~~
joshwa
please watch your line lengths in code blocks... you're making my browser
scroll.

------
markessien
You know what really bothers me about ruby? It seems like it's the smaller
companies who are behind it - like EngineYard and 37Signals. None of the
heavyweights seem to be interested in Ruby.

This seems to me to be a bad thing for the long term prospects for the
language. Big companies think long term, small companies tend to change their
focus often. If I'm going to invest my time in a language, I want it to stick
around for long.

~~~
moonpolysoft
Microsoft pays John Lam and the DLR team to work on IronRuby full time. Sun
pays Charles Nutter and Thomas Enebo to work on JRuby. Thoughtworks pays Ola
Bini to work on JRuby as well. So there are some larger companies that are
investing in Ruby implementations.

~~~
markessien
They are paying people to add support for niche languages to their tools.
IronRuby sells Visual Studio, JRuby promotes Java. MS and Sun are interested
in their tools, not in Ruby.

~~~
moonpolysoft
Of course. They can't make money directly off of Ruby. Neither can EY or
37signals. For that matter, Sun doesn't directly make money off of Java
either. And Microsoft doesn't make a lot of money from .Net (it's arguable
over whether you'd consider visual studio sales directly attributable to
.Net.)

The point here is that for EY, Sun, and MS their platforms are loss leaders
for very profitable goods and services. And if those companies are paying
people to work on Ruby for their platforms, that means they're betting that
Ruby support will lead to greater platform adoption, which then leads to
greater server sales.

------
kuniklo
It would be nice to see some progress made on the interpreter but I think it's
to Ruby's credit that the language design hasn't changed that much in the last
several years. A lot of the activity on the Python side has been fixing things
that weren't well thought through in the first place.

~~~
blasdel
You don't seem to understand that "language design hasn't changed" tends to
preclude "progress made on the interpreter".

Python's warts have been fixed and will continue to be fixed. I cant really
say the same for Ruby, especially for MRI.

~~~
litewulf
Honestly, I'd say the opposite is true. The more the language design changes,
the more implementor time is going towards servicing the changes and not
squeezing the fat out of the implementation.

That being said, the two often occur together because changes are exciting and
attract effort.

------
henning
So, does this mean you're going to use other languages more often? If so,
which?

~~~
jmtulloss
For me, python, but that's not exactly a change ;).

I've always felt that python offered the same benefits as ruby accept with a
simpler syntax, better cross platform support, better performance, and a more
organized community.

~~~
tocomment
I find the "there's only one way to do it" philosophy of Python to be really
important. That's the main thing that kept Ruby off my radar.

~~~
nihilocrat
I feel it diverges a little bit, actually. In many cases it provides the "C
style" way of doing it and the "functional style" way of doing it. Thankfully,
in many cases one of them is much faster than the other, but it's not obvious
to the novice and they will probably use the "C style" for years in ignorance
of the alternative.

Example:

    
    
      mylist = []
      for char in "foobar":
          if char == "f":
              mylist.append(char)
    

vs.

    
    
      mylist = [ char for char in "foobar" if char == "f" ]
    

The latter is supposedly much faster, and as you can see, much more succinct,
but I hadn't learned about it until about a year ago. I have been programming
in Python since about 2002/2003.

~~~
NyxWulf
It's pretty hard to believe you've been using Python seriously since 2002/2003
and had never heard of list comprehensions. They are a pretty big staple of
most Python programmers.

~~~
nihilocrat
Then you can call me out for being a noob, if you wish. :)

------
viggity
I wonder if IronRuby will have the same memory problems. Not as though the
Rubyists will really give it twirl anyway.

~~~
blasdel
Microsoft already put their real weight into IronPython

------
bhiggins
ruby is slowly but surely showing itself to be the next PHP - popular for all
the wrong reasons, terrible implementation and a foolish philosophy

~~~
MrRage
Please, elaborate. What wrong reasons is Ruby popular for? What is the foolish
philosophy around Ruby?

~~~
mechanical_fish
I don't know, but if the secret to PHP's enormous success is its foolish
philosophy then the Ruby community needs more fools.

There is one thing to observe here: Ruby will not become as widespread or as
popular as Perl, PHP, or Java without also becoming as unfashionable as Perl,
PHP, and Java. When an invention becomes successful and established,
eventually everyone comes to take its good parts for granted, while its flaws
become famous and are an eternal topic of discussion.

