4 ms·

I'm not a Rust programmer, but: > light-weight threading with preemptive scheduling prioritizing latency over throughput Rust has Tokio for light-weight threa

I'm not a Rust programmer, but: > light-weight threading with preemptive scheduling prioritizing latency over throughput Rust has Tokio for light-weight threading which might well be sufficient for the majority of use-cases. > extremely robust fault tolerance with a supervision hierarchy One could argue that Rusts compile-time guarantees together with something like the Result-type make it so that such a supervision hierarchy isn't quite necessary and a few "manually implemented" error-boundaries are sufficient. This is also true for errors like network-hickups. > runtime introspection with code hotloading capabilities. Maybe you could add frictionless distributed system support as well Fair enough points. I don't think your attitude against the OP is justified though.

Fire-Dragon-DoL 4y ago
Tokio seems to be a valid replacement for lightweight threading in elixir. Fault tolerance and supervision hierarchy might be unnecessary as mentioned. Hotloading capabilities are unnecessary, most shops go with blue-green deployments, so the hotcode loading is usually unused (and for a good reason, so much complexity!). Distributed computing also goes unnecessary as most applications are deployed with containers with some form of autoscaling, so the industry went a different direction than elixir. That leaves us with runtime introspection, which is pretty cool indeed. But that has to compete with Rust performance. Pretty tough. I love elixir, but when Go got premptive scheduler for goroutine, the need for elixir dropped dramatically. Which is sad because i loved the language and phoenix. I'm hoping it makes a comeback, though!
- valenterry 4y ago
  > Fault tolerance and supervision hierarchy might be unnecessary as mentioned. It's not like there is suddenly no fault tolerance though. Erlang has a certain way of handling/dealing with errors/faults and so does Rust and other languages. I would not by default assume that Erlang's errorhandling is superior. > That leaves us with runtime introspection, which is pretty cool indeed. But that has to compete with Rust performance. I would much rather say that runtime introspection has to comete with a static type system. As I said many times, I really like the BEAM (saying that after having worked with Akka quite a bit) but Erlang/Elixir... those languages are really not great. There are many languages that way better. I also know that there is a new one for the BEAM (forgot the name) but so far we are mostly stuck with E&E.
  - Fire-Dragon-DoL 4y ago
    The reason why I haven't brought it up is because they are not the same thing, so they can't compare. Of course rust type system is great, but at the same time the memory management is not something necessary to most software. Elixir could teach some really good practices to people writing code, which is why I'm somewhat sad that other languages can supersede it (go, rust).
    - valenterry 4y ago
      > Elixir could teach some really good practices to people writing code, which is why I'm somewhat sad that other languages can supersede it (go, rust). My problem with this statement is, that it emphasizes the language (Elixir) but what you really mean is the paradigm of using the BEAM no? As in, using Erlang or Elixir doesn't really matter for those good practices, even if Elixir is nicer in some regards. In that case, it should be written like that, otherwise it will confuse people and prompt them to disagree, like I did.
      - Fire-Dragon-DoL 4y ago
        No, I don't think so. Sure the language is structured to work with beam, so the line is somewhat blurry, but in my mind I was referring to practices that the language itself promotes: - no state, unless when you really need it - avoid mocks unless you really need - pipeline-style approach where writes happen only at the end (io at the edge of the system) - prefer integration tests Just things you figure out as you write elixir code
kaba0 4y ago
Come on, Rust has a good type system, but it’s nothing special - Haskell has the same guarantees since decades and it’s not like Haskell programs are suddenly without fault. There is only so much static types can catch without dependent typing, as per Rice’s theorem, types are a ‘trivial property’. Most of the interesting stuff happens at runtime and those are much harder to reason about. Just because you have a Result type doesn’t mean you actually properly/meaningfully handle the error at all, it may just happen that “restart” is the correct solution. Also, Rust is not safe from dead/live locks and many other concurrency issues, only data race free. This is not against Rust, but against the very biased hype for it.
- valenterry 4y ago
  > it’s not like Haskell programs are suddenly without fault I never said that. But would you claim that Haskell programs are generally more faulty / less stable than Erlang programs? > Just because you have a Result type doesn’t mean you actually properly/meaningfully handle the error at all Okay, but the same is true for Erlang and the BEAM. > it may just happen that “restart” is the correct solution Yeah, but is very easy to do with Rust and Haskell or even just on the infrastructure level (i.e. restart the failed container/instance). > Also, Rust is not safe from dead/live locks and many other concurrency issues, only data race free. How is Erlang safe from those things in a way that cannot or only with a lot of effort be replicated when using Rust?
  - halostatue 4y ago
    > > Also, Rust is not safe from dead/live locks and many other concurrency issues, only data race free. > How is Erlang safe from those things in a way that cannot or only with a lot of effort be replicated when using Rust? Each BEAM process (other runtimes would call them preemptable green threads) has its own heap, communicates with other processes by messages, and only works on immutable data without the involvement of Native Interface Functions (NIFs). There’s no shared memory at all. It is natively massively concurrent without most of the risks involved. Sure, it’s possible to write code that results in mailbox deadlocks, but it also means stepping outside of normal program design for the BEAM, and it means stepping outside of OTP (which provides structured programming constructs like gen_server). Rust makes it harder to program without memory safety. Erlang (and other BEAM languages) make it harder to program without concurrency safety. Edited to add: Joe Armstrong’s thesis on Erlang is available for download and is written in very accessible language[1]. If you want more, you can also read Programming Erlang (2nd Edition)[2] also by Joe. (I would love to see a 3rd edition tackled by someone to address the newest stuff added in the 9 years since the last publication. I can understand why no one would want to approach this, since it was Joe’s.) [1] http://erlang.org/download/armstrong_thesis_2003.pdf http://erlang.org/download/armstrong_thesis_2003.pdf [2] https://pragprog.com/titles/jaerlang2/programming-erlang-2nd-edition/ https://pragprog.com/titles/jaerlang2/programming-erlang-2nd...

Fire-Dragon-DoL 4y ago

Tokio seems to be a valid replacement for lightweight threading in elixir. Fault tolerance and supervision hierarchy might be unnecessary as mentioned. Hotloading capabilities are unnecessary, most shops go with blue-green deployments, so the hotcode loading is usually unused (and for a good reason, so much complexity!). Distributed computing also goes unnecessary as most applications are deployed with containers with some form of autoscaling, so the industry went a different direction than elixir. That leaves us with runtime introspection, which is pretty cool indeed. But that has to compete with Rust performance. Pretty tough. I love elixir, but when Go got premptive scheduler for goroutine, the need for elixir dropped dramatically. Which is sad because i loved the language and phoenix. I'm hoping it makes a comeback, though!

valenterry 4y ago
> Fault tolerance and supervision hierarchy might be unnecessary as mentioned. It's not like there is suddenly no fault tolerance though. Erlang has a certain way of handling/dealing with errors/faults and so does Rust and other languages. I would not by default assume that Erlang's errorhandling is superior. > That leaves us with runtime introspection, which is pretty cool indeed. But that has to compete with Rust performance. I would much rather say that runtime introspection has to comete with a static type system. As I said many times, I really like the BEAM (saying that after having worked with Akka quite a bit) but Erlang/Elixir... those languages are really not great. There are many languages that way better. I also know that there is a new one for the BEAM (forgot the name) but so far we are mostly stuck with E&E.
- Fire-Dragon-DoL 4y ago
  The reason why I haven't brought it up is because they are not the same thing, so they can't compare. Of course rust type system is great, but at the same time the memory management is not something necessary to most software. Elixir could teach some really good practices to people writing code, which is why I'm somewhat sad that other languages can supersede it (go, rust).
  - valenterry 4y ago
    > Elixir could teach some really good practices to people writing code, which is why I'm somewhat sad that other languages can supersede it (go, rust). My problem with this statement is, that it emphasizes the language (Elixir) but what you really mean is the paradigm of using the BEAM no? As in, using Erlang or Elixir doesn't really matter for those good practices, even if Elixir is nicer in some regards. In that case, it should be written like that, otherwise it will confuse people and prompt them to disagree, like I did.
    - Fire-Dragon-DoL 4y ago
      No, I don't think so. Sure the language is structured to work with beam, so the line is somewhat blurry, but in my mind I was referring to practices that the language itself promotes: - no state, unless when you really need it - avoid mocks unless you really need - pipeline-style approach where writes happen only at the end (io at the edge of the system) - prefer integration tests Just things you figure out as you write elixir code

kaba0 4y ago

Come on, Rust has a good type system, but it’s nothing special - Haskell has the same guarantees since decades and it’s not like Haskell programs are suddenly without fault. There is only so much static types can catch without dependent typing, as per Rice’s theorem, types are a ‘trivial property’. Most of the interesting stuff happens at runtime and those are much harder to reason about. Just because you have a Result type doesn’t mean you actually properly/meaningfully handle the error at all, it may just happen that “restart” is the correct solution. Also, Rust is not safe from dead/live locks and many other concurrency issues, only data race free. This is not against Rust, but against the very biased hype for it.

valenterry 4y ago
> it’s not like Haskell programs are suddenly without fault I never said that. But would you claim that Haskell programs are generally more faulty / less stable than Erlang programs? > Just because you have a Result type doesn’t mean you actually properly/meaningfully handle the error at all Okay, but the same is true for Erlang and the BEAM. > it may just happen that “restart” is the correct solution Yeah, but is very easy to do with Rust and Haskell or even just on the infrastructure level (i.e. restart the failed container/instance). > Also, Rust is not safe from dead/live locks and many other concurrency issues, only data race free. How is Erlang safe from those things in a way that cannot or only with a lot of effort be replicated when using Rust?
- halostatue 4y ago
  > > Also, Rust is not safe from dead/live locks and many other concurrency issues, only data race free. > How is Erlang safe from those things in a way that cannot or only with a lot of effort be replicated when using Rust? Each BEAM process (other runtimes would call them preemptable green threads) has its own heap, communicates with other processes by messages, and only works on immutable data without the involvement of Native Interface Functions (NIFs). There’s no shared memory at all. It is natively massively concurrent without most of the risks involved. Sure, it’s possible to write code that results in mailbox deadlocks, but it also means stepping outside of normal program design for the BEAM, and it means stepping outside of OTP (which provides structured programming constructs like gen_server). Rust makes it harder to program without memory safety. Erlang (and other BEAM languages) make it harder to program without concurrency safety. Edited to add: Joe Armstrong’s thesis on Erlang is available for download and is written in very accessible language[1]. If you want more, you can also read Programming Erlang (2nd Edition)[2] also by Joe. (I would love to see a 3rd edition tackled by someone to address the newest stuff added in the 9 years since the last publication. I can understand why no one would want to approach this, since it was Joe’s.) [1] http://erlang.org/download/armstrong_thesis_2003.pdf http://erlang.org/download/armstrong_thesis_2003.pdf [2] https://pragprog.com/titles/jaerlang2/programming-erlang-2nd-edition/ https://pragprog.com/titles/jaerlang2/programming-erlang-2nd...