6 ms·

> Using Rust afterwards was great, plus it was faster than the BEAM. I guess, why not use Rust entirely instead of as a FFI into Elixir or other backend languag

by dxhdr 3y ago

> Using Rust afterwards was great, plus it was faster than the BEAM. I guess, why not use Rust entirely instead of as a FFI into Elixir or other backend language? Sure, you just need to reimplement light-weight threading with preemptive scheduling prioritizing latency over throughput, extremely robust fault tolerance with a supervision hierarchy, and runtime introspection with code hotloading capabilities. Maybe you could add frictionless distributed system support as well. No big deal, why not right?

lucasyvas 3y ago
Is any of this needed though? For some use cases yes, but for many no. It's possible the parent has no practical use for these capabilities.
- deleted 3y ago
  [deleted]
- hexo 3y ago
  [flagged]
  - lucasyvas 3y ago
    The author gave static types and performance as examples of things that matter to them that they clearly don't feel Elixir does as well. It's probable they weren't the target demographic for Elixir, like many aren't the target demographic for Rust. The initial response made an assumption that all these capabilities matter either way, and that's not true.
  - tines 3y ago
    You may not realize this, but your comment comes off as being very snide and annoying, which I'm sure you didn't intend. Try rewording things in a way that assumes good faith, and besides making better relationships you'll persuade people more effectively as well.
  - tessierashpool 3y ago
    This is not helpful. Please consider what if might be like if you were to edit your comment to improve it.
- pdpi 3y ago
  If you're building a project that actually benefits from Elixir/Erlang's features, you can have a constructive discussion about whether those features justify sacrificing static typing. If you don't actually benefit from those features, "I tried to use a language that's unfit for my purposes and found it unfit for my purposes" is a comment of very limited value.
Dowwie 3y ago
This list isn't long enough. OTP and Elixir are wonderfully unique. Rust is, however, as well. I don't think that anyone who truly understands the two could comment about using one as a default.
dist1ll 3y ago
> light-weight threading with preemptive scheduling prioritizing latency over throughput Tasks for backend systems are usually pretty homogeneous. I'm not sure how in such cases the overhead of preemption is in any way better than cooperative multitasking.
- calo_star 3y ago
  Erlang processes indeed do cooperative multitasking under the hood, something like yielding control to the scheduler roughly every 1000 function calls.
giancarlostoro 3y ago
Implementing all of that, without using a significant amount of memory for every step of the way to boot. It's impressive how little memory an Erlang process needs.
valenterry 3y ago
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 3y 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 3y 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.

by dxhdr 3y ago

lucasyvas 3y ago

Is any of this needed though? For some use cases yes, but for many no. It's possible the parent has no practical use for these capabilities.

deleted 3y ago
[deleted]
hexo 3y ago
[flagged]
- lucasyvas 3y ago
  The author gave static types and performance as examples of things that matter to them that they clearly don't feel Elixir does as well. It's probable they weren't the target demographic for Elixir, like many aren't the target demographic for Rust. The initial response made an assumption that all these capabilities matter either way, and that's not true.
- tines 3y ago
  You may not realize this, but your comment comes off as being very snide and annoying, which I'm sure you didn't intend. Try rewording things in a way that assumes good faith, and besides making better relationships you'll persuade people more effectively as well.
- tessierashpool 3y ago
  This is not helpful. Please consider what if might be like if you were to edit your comment to improve it.
pdpi 3y ago
If you're building a project that actually benefits from Elixir/Erlang's features, you can have a constructive discussion about whether those features justify sacrificing static typing. If you don't actually benefit from those features, "I tried to use a language that's unfit for my purposes and found it unfit for my purposes" is a comment of very limited value.

Dowwie 3y ago

This list isn't long enough. OTP and Elixir are wonderfully unique. Rust is, however, as well. I don't think that anyone who truly understands the two could comment about using one as a default.

dist1ll 3y ago

> light-weight threading with preemptive scheduling prioritizing latency over throughput Tasks for backend systems are usually pretty homogeneous. I'm not sure how in such cases the overhead of preemption is in any way better than cooperative multitasking.

calo_star 3y ago
Erlang processes indeed do cooperative multitasking under the hood, something like yielding control to the scheduler roughly every 1000 function calls.

giancarlostoro 3y ago

Implementing all of that, without using a significant amount of memory for every step of the way to boot. It's impressive how little memory an Erlang process needs.

valenterry 3y ago

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 3y 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 3y 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.