Comment by markoman | Hacker News Reader

Comment by markoman | Hacker News Reader

Parent Full thread

Ruby is still a beautiful language, particularly for its object oriented-ness. And I think Ruby's nature, simplicity and power appeals to young people, however the resurgence of a towering Javascript/NodeJS is hard compete with. These are market forces that really matter when you're wondering what language & platform to use for your MVP. In recent surveys, Ruby & Rails has fallen to the bottom of the list among the former stars of programming languages. Python has data science & machine learning to keep it strong and new stars Elixir/Phoenix and Golang are sucking up a lot of oxygen that would otherwise go to Ruby & Rails. And let's not forget Bubble (visual app building) and the Zero Code Startup.

I really think Pedro (the blog post writer) has an excellent point about being a polyglot but trying to qualify as a Senior Engineer except I'm older and have even more platforms & languages behind me. Its a serious problem because I have the experience to easily be a Sr. Engineer or manager but my experience isn't concentrated long enough anywhere to make me useful enough to warrant the role.

Ruby also suffers from top quality JITs vs what JS has.

The only good option being JRuby, as far as I understand. I am not at all into Ruby.

Regarding being polyglot and seniority, a possible solution is to work for consulting companies that focus on multiple stacks.

Most of the time you're not using JRuby for the JIT but for threads and/or to fit into some Tomcat/other Java environment. JRuby isn't exactly fast.

JRuby is now about 3x faster than MRI, thanks to improvements in JRuby and increased support from the JVM for optimizing dynamic languages like invokedynamic.

MRI has just added a JIT, I know nothing about it other than that it exists.

MJIT works by taking MRI Ruby bytecode, replacing the instructions with the original C code, and compiling an entire method using GCC/LLVM.

Because MRI Ruby is a threaded VM, it's easy to replace jumping to an instruction which dispatches to the next instruction, with jumping to some native code which dispatches to the next instruction.

Right now, AFAIK, only very basic optimizations are enabled but just removing the overhead of VM dispatch between each instruction is a huge performance improvement.

Not so fast with Elixir. According to Indeed.co.uk's API there are 18 Ruby jobs for every Elixir job. Yes, there are 3 times as many Python jobs but Ruby isn't exactly dead.

Reply on news.ycombinator.com