3 ms·

Those might be complementary but they are still other languages. They have completely different semantics, performance characteristics, deployment stories, etc

Those might be complementary but they are still other languages. They have completely different semantics, performance characteristics, deployment stories, etc that will need to be learned, developed and supported internally. It seems like they like ruby and appreciate what it allows them to do. There's no particular reason to think that the strengths they value in ruby will be present in those or any other languages either. They mentioned metaprogramming for example and it truly does feel easy and powerful in ruby in a way that I've only felt in certain lisps otherwise. Presumably they're heavily invested in certain techniques and powers, have earned and maintain internal expertise in them and find them valuable. Moving the critical functionality into a language where they'd be giving up that hard-earned expertise is a bold move. It may be the standard move, but imo it's pretty radical and a fairly significant gamble. If you're pushing the limits of a language that otherwise works very well for you, expanding those limits does seem wise, even the conservative choice.

ilrwbwrkhv 5y ago
Metaprogramming, yes but also pure objects. Ruby has that Smalltalk heritage in a way no other language has. Also the fact that it focuses on developer happiness makes it a way more pleasant language to use compared to say Golang or Rust.
- pjmlp 5y ago
  Other than SELF, Objective-C, Dylan or Common Lisp.
specialp 5y ago
I have been working with Ruby for over a decade and IMO most metaprogramming is the worst part of Ruby code. It makes code very difficult to reason about outside of runtime and makes unclear traces when something does go wrong. Now I know it can be done right, but I think the Ruby community ran too much with DRY (Don't Repeat Yourself) and "clean" minimal syntax at the cost of maintainability and readability. It also makes it hard for tools to reason about what is being run as well when you have stuff running in `instance_eval` contexts and `method_missing` being abused. So now here we are trying to unravel that by trying to make the interpreter smarter with caching to improve performance but if I had to turn back time, I would reverse every instance where one tried to be clever with metaprogramming in the name of syntax.
- giraffe_lady 5y ago
  Yeah I kinda knew I'd regret mentioning any specific feature of ruby that one in particular. Anyway it doesn't matter. The point was that they presumably have identified certain things ruby does well for them and have invested heavily in them. If ruby does other things less well then abandoning ship for an unknown set of tradeoffs is a riskier move than improving the specific weaknesses that are their obstacles. What ruby's inherent strengths are or even if they exist at all doesn't matter as much as their investment and expertise in them does.
jimbokun 5y ago
> They have completely different semantics, performance characteristics Many times it is the different semantics that allow for better performance. If you can add new methods or change their implementation at runtime, performance optimizations get a lot trickier, for example. The immutability that's foundational to Elixir and Erlang enable the incredible scaling capabilities of the Erlang VM.
- pmarreck 5y ago
  > The immutability that's foundational to Elixir and Erlang enable the incredible scaling capabilities of the Erlang VM This. If you want at least one order of magnitude of scaling to come "for free" (note: further orders of magnitude may still cost you), the BEAM VM will hook you up thanks to this fundamental design decision
- chrisseaton 5y ago
  > If you can add new methods or change their implementation at runtime, performance optimizations get a lot trickier This particular example is a non-issue though - it's completely solved through dynamic deoptimisation (as in the machine code with and without method redefinition is exactly the same.)

ilrwbwrkhv 5y ago

Metaprogramming, yes but also pure objects. Ruby has that Smalltalk heritage in a way no other language has. Also the fact that it focuses on developer happiness makes it a way more pleasant language to use compared to say Golang or Rust.

pjmlp 5y ago
Other than SELF, Objective-C, Dylan or Common Lisp.

specialp 5y ago

I have been working with Ruby for over a decade and IMO most metaprogramming is the worst part of Ruby code. It makes code very difficult to reason about outside of runtime and makes unclear traces when something does go wrong. Now I know it can be done right, but I think the Ruby community ran too much with DRY (Don't Repeat Yourself) and "clean" minimal syntax at the cost of maintainability and readability. It also makes it hard for tools to reason about what is being run as well when you have stuff running in `instance_eval` contexts and `method_missing` being abused. So now here we are trying to unravel that by trying to make the interpreter smarter with caching to improve performance but if I had to turn back time, I would reverse every instance where one tried to be clever with metaprogramming in the name of syntax.

giraffe_lady 5y ago
Yeah I kinda knew I'd regret mentioning any specific feature of ruby that one in particular. Anyway it doesn't matter. The point was that they presumably have identified certain things ruby does well for them and have invested heavily in them. If ruby does other things less well then abandoning ship for an unknown set of tradeoffs is a riskier move than improving the specific weaknesses that are their obstacles. What ruby's inherent strengths are or even if they exist at all doesn't matter as much as their investment and expertise in them does.

jimbokun 5y ago

> They have completely different semantics, performance characteristics Many times it is the different semantics that allow for better performance. If you can add new methods or change their implementation at runtime, performance optimizations get a lot trickier, for example. The immutability that's foundational to Elixir and Erlang enable the incredible scaling capabilities of the Erlang VM.

pmarreck 5y ago
> The immutability that's foundational to Elixir and Erlang enable the incredible scaling capabilities of the Erlang VM This. If you want at least one order of magnitude of scaling to come "for free" (note: further orders of magnitude may still cost you), the BEAM VM will hook you up thanks to this fundamental design decision
chrisseaton 5y ago
> If you can add new methods or change their implementation at runtime, performance optimizations get a lot trickier This particular example is a non-issue though - it's completely solved through dynamic deoptimisation (as in the machine code with and without method redefinition is exactly the same.)