Hacker News Reader

Comment by danenania | Hacker News Reader

This is great as compilation in ruby really is painfully slow for anything substantial, but I wonder about the choice of an independent project vs. forking the ruby compiler and optimizing the bottlenecks with C extensions. Might that allow you to fix the most serious issues without having to worry about maintaining feature parity in a completely separate code base?

In any case, nice work. I look forward to trying it out in my next project.

View on HN

One benefit of being a separate project is that it can be used with non-Ruby wrappers. See node-sass https://github.com/andrew/node-sass as an example.

And consequently from that project: https://npmjs.org/package/grunt-sass

Since I'd guess most people interested in the node version will want the grunt one.

I have been all too pleased to move away from the ruby based compiler and just use a pure grunt workflow. It is vastly faster and lighter weight.

From what I understand there are some limitations to the implementation, but I haven't encountered any so far.

The few issues I've run into are that I can't use Compass and I can't have Source Maps (yet).

Instead of Compass, I've switched to using Bourbon (bourbon.io) but may consider just using Auto Prefixer in future dev efforts.

Source maps I can live without since I haven't gotten used to them. I know it's in the works or at least being thought about: https://github.com/hcatlin/libsass/issues/122.

Ruby is fast in non-benchmark jobs like text processing. It's not ruby slow, it's sass's implementation of dependency analysis slow. Good compilers in Ruby, like Slim is even faster than most template engines in Javascript or Go.

Can you provide a source for the first statement? It seems unlikely to me that a language implementation is going to be fast on text processing which is essentially a aggregate task of what most benchmarks try to profile individually, but I could be missing something less obvious.

Ruby has many high level text operation abstractions, which is not included in most other languages. But in micro-benchmarks we need to ensure all the languages use the same algorithm, or similar code to do the job. Then the high level methods, which are usually better optimised, are usually forbidden.

In the computer benchmark games (http://benchmarksgame.alioth.debian.org), most of the benchmarks are heavy on floating-point arithmetic or raw loops, which are completely not for the case of web applications. You can also see in text benchmarks like regex-dna, Ruby performs much faster.

If you do benchmarks regardless the implementation details. You may find Ruby can be several times faster than Java in cases like AES encryptions: https://gist.github.com/luikore/7746976 --- though this is not a valid micro-benchmark, it is in fact comparing JCE and OpenSSL. But this is what real-world programs do and the speed of calculating Mandelbrot sets or simulating n-body systems really doesn't matter.

Reply on news.ycombinator.com