6 ms·

So, just to speak about the BEAM, which is the part of Elixir I am familiar with, I don't think any BEAM language will ever be a good goto language. The BEAM is

So, just to speak about the BEAM, which is the part of Elixir I am familiar with, I don't think any BEAM language will ever be a good goto language. The BEAM isn't good at general purpose computing. It's not particularly efficient at performing calculations or using memory. It's good at reliably performing as you increase memory pressure on your system (via message passing). You can scale a business to a decent size on a smaller number of fatter nodes (high RAM machines). Connections will keep pouring in and you'll get a consistent ms. That said, you'll run into issues once you hit a certain level of scale. I've had to make patches to the BEAM just to keep us scaling, and I've never seen someone get away with stock dist. You pretty much have to rewrite pieces of OTP. Now is Elixir ok for a CRUD app serving 10G of traffic? Of course... but this is also the age in which every language has a solution to the C10K(, C100K, and more in many cases) problem, and there are compelling reasons to write your CRUD app in Go and get better library support, static types up front (trust me, you want a static type system), and lower latency. Personally, I'm bullish about Rust. With async/await landing, it stands a good chance of providing the same focus on safety and reliability while being infinity more flexible at what it can effectively. It's a better general purpose language. Also, the actor model (and CSP as well) aren't the end all be all of concurrency patterns. Rust only provides the building block (futures) so it's much easier to choose the concurrent pattern that fits best for your problem. You can sting a future using the actor model, so it's still an option, but you aren't limited to it.

emerongi 8y ago
Ok... yet 99% of development is trying to write bug-free and readable code and do it pragmatically. Elixir gives you that plus a lot of goodies that are really hard to get in other languages. The creators of Erlang were really clever and in my opinion, so are the creators of Elixir. If I ever were "bullish" on a language, Elixir would be it. Elixir is a very pragmatic language. It doesn't get in your way, but still forces decent habits and design on your application.
- ilovecaching 8y ago
  > bug-free and readable code and do it pragmatically Erlang has historically been a bad choice for this, and there's been a lot of effort (dialyzer, records, maps etc) to make it better. Dynamically typed languages are, in my experience, not worth the cost of maintenance and readability. In Elixir and Erlang it's possible to create function signatures that tell you almost nothing about the shape of the data you expect to pass in. This makes it really hard to collaborate at scale. Various attempts to enforce dialyzer use are usually met with 'we need to move faster' or 'we'll add them later'. So if you want to write bug-free readable code, I think Rust is a much better choice. It's statically typed, and the addition of traits and lifetimes tell you so much about how a function or type will behave, and there's no need to sync specs or docs. The code doesn't lie.
  - StreamBright 8y ago
    Exactly, this is why the most reliable piece of mission critical system was written in Erlang.
  - SZJX 8y ago
    I've hardly run into any bugs in Elixir. It feels almost like Haskell to me. Pure magic. On the contrary I struggle to get even the most basic Rust program to compile, wasting hours before anything is done.
- dnautics 8y ago
  just a nitpick, elixir does not let you write bug free code, it lets you write buggy code and actually get away with it.
gfodor 8y ago
Until someone re-implements the process isolation and other battle-hardened distributed systems characteristics of BEAM/OTP in a rust stack, it certainly seems like embedding Rust as NIFs into erlang/elixir seems like a nice option to make up for the perf deficiencies you mention (though doesn't cover the memory concerns.) I have not tried doing it, but I'd imagine the safety guarantees of Rust are a nice thing to have to reduce the risks involved around NIF callouts. I believe Discord recently posted that they are doing this, and I'm interested in hearing about their results. edit: Google is my friend. https://github.com/hansihe/rustler https://github.com/hansihe/rustler
- ilovecaching 8y ago
  I think they're being reimplemented in Kubernetes. Kubernetes provides scale-ability, fault tolerance, and the pieces you need to build robust distributed systems. There's no need for this from the language itself. It's actually disadvantageous to mix Erlang and Kubernetes, because Erlang really wants a stable set of node names. It's not a good fit for the way in which we're doing fault tolerance in the cloud. Erlang focuses on not crashing the BEAM, by letting processes crash while allowing graceful degradation of service. Supervisors are akin to Kubernetes deployments. Processes are pods. The pods themselves should be designed to crash gracefully.
  - arianvanp 8y ago
    BEAM on Kubernetes is certainly possible: https://github.com/bitwalker/libcluster https://github.com/bitwalker/libcluster just not by default
- qohen 8y ago
  In case it's of interest, Sonny Scroggin gave a talk last March at Code BEAM SF (i.e. the rebranded Erlang Factory) on writing NIFs in Rust, if you're interested: https://www.youtube.com/watch?v=F86JXaCPowo https://www.youtube.com/watch?v=F86JXaCPowo (Sonny is a core team-member of the Phoenix framework).
StreamBright 8y ago
actually no you do need a static type system (i dont trust you on that one, i trust the extensive studies instead) and Go would be the worst example of static type systems anyways.
- dnautics 8y ago
  not having a static type system in elixir is great. I have my deploy code which takes a certain type of map, but i can paralellize my integration tests by adding a test_id field to the map which is passed a UUID in my HTTP call, which then goes stores in the API harness an RPC'd link (erlang RPC is nice enough to message-pass correct proc id's) to a dynamically created mock of the component which cannot be parallelized. At any given time during integration testing 5-10 of these mocks are in flight on the backend. You could probably do this with a static type system. I wouldn't want to. I'm not an "expert" elixir programmer, and I got this up and running in 2 hours.
dymk 8y ago
Oh I remember you - you were in the other Erlang thread peddling Rust exactly the same way. You'd make general claims of authority about Elixir/Erlang and how there were all sort of vague issues with them, and then gave out blanket advice for how Rust would be a better option. It was pretty annoying to read.
lpgauth 8y ago
What did you have to patch in OTP? Usually it's pretty easy to get your changes merged upstream... And there's plenty of companies running large Erlang projects without any custom patches.
camgunz 8y ago
> The BEAM isn't good at general purpose computing. It's not particularly efficient at performing calculations or using memory. BEAM languages are fine, easily faster than Python, Ruby, PHP, and competitive with v8 in many cases. Furthermore anyone doing serious data processing in a web service uses a work queue, which can be serviced (if you so choose) by workers written in any language you like.
- jashmatthews 8y ago
  Ruby has had a VM competitive with BEAM since Ruby 1.9. BEAM has a slight edge but Ruby also has JRuby with a real JIT and all the GC goodness of the JVM. Modern Python, Ruby, PHP7 are all much faster than generally expected outside of microbenchmarks.

emerongi 8y ago

Ok... yet 99% of development is trying to write bug-free and readable code and do it pragmatically. Elixir gives you that plus a lot of goodies that are really hard to get in other languages. The creators of Erlang were really clever and in my opinion, so are the creators of Elixir. If I ever were "bullish" on a language, Elixir would be it. Elixir is a very pragmatic language. It doesn't get in your way, but still forces decent habits and design on your application.

ilovecaching 8y ago
> bug-free and readable code and do it pragmatically Erlang has historically been a bad choice for this, and there's been a lot of effort (dialyzer, records, maps etc) to make it better. Dynamically typed languages are, in my experience, not worth the cost of maintenance and readability. In Elixir and Erlang it's possible to create function signatures that tell you almost nothing about the shape of the data you expect to pass in. This makes it really hard to collaborate at scale. Various attempts to enforce dialyzer use are usually met with 'we need to move faster' or 'we'll add them later'. So if you want to write bug-free readable code, I think Rust is a much better choice. It's statically typed, and the addition of traits and lifetimes tell you so much about how a function or type will behave, and there's no need to sync specs or docs. The code doesn't lie.
- StreamBright 8y ago
  Exactly, this is why the most reliable piece of mission critical system was written in Erlang.
- SZJX 8y ago
  I've hardly run into any bugs in Elixir. It feels almost like Haskell to me. Pure magic. On the contrary I struggle to get even the most basic Rust program to compile, wasting hours before anything is done.
dnautics 8y ago
just a nitpick, elixir does not let you write bug free code, it lets you write buggy code and actually get away with it.

gfodor 8y ago

Until someone re-implements the process isolation and other battle-hardened distributed systems characteristics of BEAM/OTP in a rust stack, it certainly seems like embedding Rust as NIFs into erlang/elixir seems like a nice option to make up for the perf deficiencies you mention (though doesn't cover the memory concerns.) I have not tried doing it, but I'd imagine the safety guarantees of Rust are a nice thing to have to reduce the risks involved around NIF callouts. I believe Discord recently posted that they are doing this, and I'm interested in hearing about their results. edit: Google is my friend. https://github.com/hansihe/rustler https://github.com/hansihe/rustler

ilovecaching 8y ago
I think they're being reimplemented in Kubernetes. Kubernetes provides scale-ability, fault tolerance, and the pieces you need to build robust distributed systems. There's no need for this from the language itself. It's actually disadvantageous to mix Erlang and Kubernetes, because Erlang really wants a stable set of node names. It's not a good fit for the way in which we're doing fault tolerance in the cloud. Erlang focuses on not crashing the BEAM, by letting processes crash while allowing graceful degradation of service. Supervisors are akin to Kubernetes deployments. Processes are pods. The pods themselves should be designed to crash gracefully.
- arianvanp 8y ago
  BEAM on Kubernetes is certainly possible: https://github.com/bitwalker/libcluster https://github.com/bitwalker/libcluster just not by default
qohen 8y ago
In case it's of interest, Sonny Scroggin gave a talk last March at Code BEAM SF (i.e. the rebranded Erlang Factory) on writing NIFs in Rust, if you're interested: https://www.youtube.com/watch?v=F86JXaCPowo https://www.youtube.com/watch?v=F86JXaCPowo (Sonny is a core team-member of the Phoenix framework).

StreamBright 8y ago

actually no you do need a static type system (i dont trust you on that one, i trust the extensive studies instead) and Go would be the worst example of static type systems anyways.

dnautics 8y ago
not having a static type system in elixir is great. I have my deploy code which takes a certain type of map, but i can paralellize my integration tests by adding a test_id field to the map which is passed a UUID in my HTTP call, which then goes stores in the API harness an RPC'd link (erlang RPC is nice enough to message-pass correct proc id's) to a dynamically created mock of the component which cannot be parallelized. At any given time during integration testing 5-10 of these mocks are in flight on the backend. You could probably do this with a static type system. I wouldn't want to. I'm not an "expert" elixir programmer, and I got this up and running in 2 hours.

dymk 8y ago

Oh I remember you - you were in the other Erlang thread peddling Rust exactly the same way. You'd make general claims of authority about Elixir/Erlang and how there were all sort of vague issues with them, and then gave out blanket advice for how Rust would be a better option. It was pretty annoying to read.

lpgauth 8y ago

What did you have to patch in OTP? Usually it's pretty easy to get your changes merged upstream... And there's plenty of companies running large Erlang projects without any custom patches.

camgunz 8y ago

> The BEAM isn't good at general purpose computing. It's not particularly efficient at performing calculations or using memory. BEAM languages are fine, easily faster than Python, Ruby, PHP, and competitive with v8 in many cases. Furthermore anyone doing serious data processing in a web service uses a work queue, which can be serviced (if you so choose) by workers written in any language you like.

jashmatthews 8y ago
Ruby has had a VM competitive with BEAM since Ruby 1.9. BEAM has a slight edge but Ruby also has JRuby with a real JIT and all the GC goodness of the JVM. Modern Python, Ruby, PHP7 are all much faster than generally expected outside of microbenchmarks.