(i hope this doesnāt sound spammy)
Because they are very different. Ruby is an OOP language, isnāt concurrent, isnāt immutable etc
The closest thing to getting anything like Ruby on the Erlang VM ā¦is Elixir
If you are a newbie I highly recommended any one of the brilliant Elixir books out there - they will help you understand a lot about Elixir and even the other technologies that are connected in some way or another
The sooner you realize that Elixir has nothing to do with Ruby the better. Mentally separate them entirely. The semantics of the languages are entirely different. Elixir is just Erlang with different skin on it.
I think it would be totally possible to do so, but it is not worth the effort.
Ruby as an OO language is all about mutabililty, which is strictly forbidden by the BEAM.
Also the dynamic dispatch of methods in classes or instances that had been altered during runtime might be a real hell and slow down the system massively.
you could build it but it will be complex and run slower than Ruby
I think it would be totally possible to do so
This does not seem like a substantiated claim to me, and I think it undersells how fundamentally different Ruby is from BEAM languages. Iām sure you could build a Ruby interpreter in Elixir but that really isnāt the same thing.
Ruby and Elixir (or Erlang) are conceptually completely different. Itās entirely possible to make Ruby compiled to BEAM, but this compiled ruby would be really slow and also very memory hungry due to the dynamic nature of ruby, which would lead to big abstraction layer. Abstracting memory sharing language on āimmutableā virtual machine is not a small task, and also in my opinion totally not needed.
I think that we would benefit much more with speed optimization in current Ruby VM.
This should be mandatory reading for everyone new to Elixir.
I second that!
Ruby is Turing Compilers as well as BEAM. So I do not see any reason why it werenāt possible.
Of course an interpreter might be much easier, but I canāt see anything that would disprove nigh claim in general.
It being Turing complete just means you could write an interpreter in elixir or erlang. That isnāt the same thing as saying it can compile to VM byte code.
You canāt compile ruby to ASM either but that doesnāt mean ASM isnāt Turing complete.
I think thatās a bit harsh tbh
Elixirās syntax was, in part, inspired by Ruby, and Phoenix itself inspired by Rails. Many (the majority?) of early adopters also came from Ruby and Rails. This is all well documented in talks that both JosĆ© and Chris have given on what prompted them to create these technologies. Ruby (and Rails) are definitely worthy tech to be inspired by imo
Having said that, yes, both Elixir and Phoenix are also very different to their Ruby counterparts.
Thatās much more agreeable
Can you proof the impossibility to compile ruby to ASM? I think it is
possible too, but totally in economically mostly because the dispatching of
methods.
To be honest thatās completely wrong. What you write in any programming language is in the end executed as machine language, a lower level then ASM. So thereās nothing stopping you to compile Ruby to BEAM compatible bytecode or ASMā¦ short of the sheer amount of the work you would need to invest in it. And by the way, I think writing transpiler from ruby to ASM would be easier than Ruby to BEAM bytecode compiler.
The operative word is ācompileā. Compiling something is not the same as running it.
I think Iām going to bow out of this discussion. It isnāt clear we mean the same thing by our terms, and the overall tone has gotten a bit dogmatic.
I think what @benwilson512 means it that you will have to have some runtime interpreter/environment for at least part of the code. So you can not compile all of it down to ASM.
Indeed, having come from Ruby, and hearing about how Elixir has āRuby-like syntaxā, I was hoping for it to be more like Ruby, at least syntactically. (Not that Iām disappointed or any such thing with Elixir! I like it, thereās just more of a learning curve than I had been led to believe, with lots of things that simply have no parallel in Ruby ā or much else that I already knew.) Perhaps some keywords are the same, and in some ways some of the large-scale structure. It seems to me more like the main thing it copies is the approach of valuing programmer-friendliness over things like absolute purity in its paradigm (Ruby in OO, Elixir in FP).
BTW, one little āahaā moment linking Elixir and Ruby (or other typical OO languages), was the realization that Elixirās |>
is very much like the other languagesā .
. Frex, in Ruby one might say "foobar".upcase.reverse
, while in Elixir, at least after import
ing String
, itās simply "foobar" |> upcase |> reverse
As others have mentioned you canāt directly compile Ruby down to the BEAM (erlang VM) as the underlying semantics are very different and quite incompatible, and the BEAM very specifically targets Erlang semantics. Itās Erlang all the way down.
What you could do however, is implement Ruby in Erlang. I have done it for Lua; itās called luerl, and is complete implementation of Lua 5.2. Seeing we have to implement Luaās global, shared, mutable data in Erlang it is slower than a native implementation but the interface between the languages is very fast. And you get all of Erlangās concurrency and system building for free. You could run millions of connections implemented in Ruby on one machine.
It depends on what you are after.
You can replace erlang with elixir in the discussion above as they have the same semantics. They just look different.
Hey Ben, if you feel anyone is holding incorrect assumptions please help us understand why you think they are wrong. Iām sure weād all rather be corrected than remain ignorant and continue to spread (perhaps inadvertently - even with the best of intentions) misinformation. Iām not sure about anyone else but Iād rather know (and promote) the facts.
However, no problem if you are truly done with this thread
Iāve marked Robertās post as the accepted answer/solution. Well, he is an authority on the topic given he is one of the languageās creators
I hope this is ok with everyone.
*runs