Hacker News Reader

Comment by DevFactor | Hacker News Reader

Crazy thing is, Ruby is already so much more powerful than Javascript. Javascript is fast, easy to implement and relatively easy to learn - but it is so limited.

As a programming language, Ruby really pushes the limits of what we are used to.

View on HN

Ironically, that power has its costs. The ability to be made fast is one of those costs.

The thing is though, if you have a super performance-critical bit that you can't make fast in Ruby, you can still drop down to C if you really have much to gain. For a lot of what it gets used for, though (system scripting, web apps, automation), it's fast enough that the language niceties trump raw speed.

That's nice but somewhat irrelevant. The discussion is about how to make Python or Ruby fast, your solution is basically "just rewrite it in C, lol". It's a workaround but ideally you should not have to do that.

Ah the hot spot fallacy. I don't mean that Ruby / Python don't have their place, I'm using a lot of Python myself. However, the notion that you could always just reimplement a few places here and there in C is mostly false IMO. In these cases where the interpreter itself is the bottleneck (as opposed to I/O), you'll often find that the performance is spread out over dozens or hundreds of sections in your code - for non trivial projects. When that happens and you really need an order of magnitude or more speedup, you basically have to reimplement.

What I want to say is: In many cases starting with a scripting language makes sense, just to get a working prototype quickly, but when you know beforehand that performance is critical, don't overestimate the ability to just patch it up later. The whole 'premature optimization' viewpoint should (if at all) only be applied up to a certain experience level, after which it's rather damaging than doing any good.

It would only be a "fallacy" if it were literally not possible to optimize using C extensions. It has been done, many times, for many real jobs. There is no fallacy.

Did I write that it's impossible? Of course you can always reimplement code with C extensions. The fallacy I was talking about is the assumption that it will be limited to a few hotspots. For non-trivial work it's either not true or if it's true it can hardly be shown before starting the implementation with high certainty - meaning that you don't know whether the faster time to get a working prototype won't be offset by a longer period of optimization (and possibly less maintainable code, because you now have two layers interacting with each other, with the interface being boundaries between performant and non-performant code, instead of logical ones). All I'm saying is that one should think a bit further ahead when choosing the implementation language / frameworks / persistency layer - how important is performance (e.g. how many requests per seconds do you want to serve per node)? How important is it to have a working prototype quickly? How important is fault tolerance? How much computation are you doing anyway, rather than doing I/O bound ops? Depending on these answers, the solution could be python/ruby, or Erlang, but it could also be java/scala or even C/Fortran. Always going the dynamic language route first might hold up in 95% of cases, but the remaining 5% could hurt a lot (or be a big missed opportunity of doing something with high impact, because these 5% of cases are often not touched by most programmers).

You can have power + fast: Haskell, Clojure, SBCL, Ocaml, Scala

Dylan and Lisp/Scheme are way more powerful than Ruby and compile to native code.

Ruby pushes what?! I bet you never used a commercial Smalltalk system.

There are always touchy Lisp and Smalltalk fans who must vent their spleens at the earliest opportunity, but barely a sliver of active developers today have used a Smalltalk system and only marginally more, even with Clojure, have used a Lisp in anger. So, when you are not actively trying to read the literal worst into something, you will see that Ruby does in fact do quite a lot that "we," in the general case, are not terribly used to. That's a major reason I use it, for example, where performance isn't a big deal.

It's not a surprise with attitudes like that!

Ruby is popular because it's powerful and expressive in a way that many other environments are not. 'Power' isn't everything - ability to easily use it is equally important. Hell, it's a direct spiritual descendent of Smalltalk to a greater degree than any other popular language!

The performance of Ruby caused by the extensiveness of its dynamism had definitely been one of the downsides of the language, and the fact that newer languages place more emphasis on that while learning from Ruby is great - it's how the field evolves!

Given you mentioned Smalltalk, you might be interested in this LtU post: http://lambda-the-ultimate.org/node/2606

It has always been this way. Two decades ago ASM was fast but limited; BASIC was expressive but slow. Today, JavaScript is fast but limited; Ruby is expressive but slow. What a wonderful transition; it means our fast language du jour is growing more and more expressive. Another two decades of compiler and optimization research and we may yet have fast languages that are so expressive they negate the need for anything more powerful.

Reply on news.ycombinator.com