4 ms·

i just started going thru some elixir/phoenix tutorials and it looks esoteric and interesting. i hadn't really considered whether or not it was an 'alive' ecos

i just started going thru some elixir/phoenix tutorials and it looks esoteric and interesting. i hadn't really considered whether or not it was an 'alive' ecosystem because i was not considering building anything real with it/them. but i did have a thought -- let's say Erlang/Elixir -- it's super-duper great, in part or mostly, because it has some insane parallelism/comm/microservices/threading/etc. model. could we not just 'bolt on' a new language? so, typescript 'transpiles down' to javascript/ecmascript/something. scala runs on the java jvm. can java run on the erlang jvm? or python? maybe create a typescript-for-erlang? maybe it already exists and it's called go/rust/etc.

linkdd 6y ago
> it looks esoteric and interesting. Esoteric maybe, interesting definitely, mainly because: Elixir compiles to Erlang bytecode, executed by the BEAM (the Erlang VM). The BEAM provides an implementation of the Actor Model, and Erlang/Elixir embed that model in their syntax. Erlang's processes are actors, and they can send messages to each other, even if they are not on the same node, this is totally transparent. On top of that, the OTP framework provides abstractions like: - Supervisor: to handle failure of your processes (actors) - Application: what you would call today a "microservice" - GenServer: to provide RPC to the rest of your application - Mnesia: to provide a replicated database to your application - and many more An Erlang/Elixir node runs multiple applications, and they can talk to each other, making your applications aware of their distributed aspect (which enables complex logic that would not easily be done in another language). Also *hot code reloading*. Whenever you call a function from another module, the BEAM will try to load the most recent version of that module, so you don't need to restart your application (this is not a very common use case, but you don't want to shutdown your flying drone during an upgrade, do you?). Therefore, every function is "async", and every function call (to another module) have an implicit "await". > let's say Erlang/Elixir -- it's super-duper great At that point, it's not an hypothesis anymore to me :) And I did not talk about pattern matching... > could we not just 'bolt on' a new language? > maybe create a typescript-for-erlang? > maybe it already exists and it's called go/rust/etc. Typescript/Javascript async model (Promises and the NodeJS event loop) does not translate well to the actor model. Go & Rust are faaaaaaaaaar behind in term of distributed computing. Maybe because it's not their target? Erlang provides an interface to build nodes without the BEAM, that can still talk with BEAM nodes: - C/C++: https://erlang.org/doc/apps/erl_interface/ei_users_guide.html - Java: https://erlang.org/doc/apps/jinterface/jinterface_users_guide.html - Python: https://github.com/Pyrlang/Pyrlang But it's nowhere near perfect IMHO.

linkdd 6y ago

> it looks esoteric and interesting. Esoteric maybe, interesting definitely, mainly because: Elixir compiles to Erlang bytecode, executed by the BEAM (the Erlang VM). The BEAM provides an implementation of the Actor Model, and Erlang/Elixir embed that model in their syntax. Erlang's processes are actors, and they can send messages to each other, even if they are not on the same node, this is totally transparent. On top of that, the OTP framework provides abstractions like: - Supervisor: to handle failure of your processes (actors) - Application: what you would call today a "microservice" - GenServer: to provide RPC to the rest of your application - Mnesia: to provide a replicated database to your application - and many more An Erlang/Elixir node runs multiple applications, and they can talk to each other, making your applications aware of their distributed aspect (which enables complex logic that would not easily be done in another language). Also *hot code reloading*. Whenever you call a function from another module, the BEAM will try to load the most recent version of that module, so you don't need to restart your application (this is not a very common use case, but you don't want to shutdown your flying drone during an upgrade, do you?). Therefore, every function is "async", and every function call (to another module) have an implicit "await". > let's say Erlang/Elixir -- it's super-duper great At that point, it's not an hypothesis anymore to me :) And I did not talk about pattern matching... > could we not just 'bolt on' a new language? > maybe create a typescript-for-erlang? > maybe it already exists and it's called go/rust/etc. Typescript/Javascript async model (Promises and the NodeJS event loop) does not translate well to the actor model. Go & Rust are faaaaaaaaaar behind in term of distributed computing. Maybe because it's not their target? Erlang provides an interface to build nodes without the BEAM, that can still talk with BEAM nodes: - C/C++: https://erlang.org/doc/apps/erl_interface/ei_users_guide.html - Java: https://erlang.org/doc/apps/jinterface/jinterface_users_guide.html - Python: https://github.com/Pyrlang/Pyrlang But it's nowhere near perfect IMHO.