8 ms·

Rust is a community of very nice and helpful people, much like Elixir but with more money behind it. However, I certainly enjoy Elixir's unwillingness to break

Rust is a community of very nice and helpful people, much like Elixir but with more money behind it. However, I certainly enjoy Elixir's unwillingness to break working code with every release, or to force users to build against nightly releases just to use any features from the last year. Rust is improving in this regard, but isn't quite there yet.

qaq 8y ago
There is good interop story for Elixir/Rust. I would not be so sure about money bit either.
- gamache 8y ago
  There's a fine interop story, I've used Rustler before. The problem is when Rust nightly is sufficiently broken that even the auto-generated Rustler boilerplate won't compile. :)
- skrebbel 8y ago
  Just some random background for those reading about why Erlang/Elixir<->Rust interop is A Big Thing. The whole point of Erlang and Elixir is robustness in the face of high concurrency. All other design choices (eg functional programming, immutable data), follow from that goal. Core is that if one green thread ("process" in Erl/Ex lingo) crashes for whatever reason, the rest keep on running. Interop with native code is the sole exception here, which makes interop very scary. If a C function that's called into from Erl/Ex crashes, the entire program crashes. Boom, gone. Sure that holds for most other languages too, but Erlang/Elixir people get extra nervous because they're more accustomed to thinking about error scenarios and because they don't always have the same seven restart/recover layers outside the VM process that good devopsers wrap eg Node processes with because hey, no need, we have Erlang, we never crash. As a result, the idea of a technology that allows writing native code that has a tremendously small likelihood of crashing is very appealing. Until recently, no such technology was available but Rust changed that. Rust allows writing native functions that can be called from Erlang/Elixir with much fewer worries than C/C++ native extensions ever did, because of all the safety guarantees provided by the compiler. This is a big thing and I hope that as the interop story improves, it means that Erlang/Elixir will in practice become much faster because more libraries will be rewritten in native code.
  - davidw 8y ago
    Or you can just make a remote node out of your C/Java/Rust/whatever code and not worry too much about it crashing your Erlang system. It's not just crashing either, it's taking a long time to execute a given function in the native code - that can also cause problems for the Erlang system running it.
    - OvermindDL1 8y ago
      Remote nodes have overhead, however if you can handle that overhead then you definitely should use a remote node or Port over a NIF. However, NIF's taking a long time to run is not so much of an issue anymore now that the dirty NIF scheduler is enabled by default in the BEAM.
  - fabian2k 8y ago
    The danger of crashing the whole VM only applies to NIFs (native implemented functions), which is a very tight integration of the external code. There are also Ports, which don't carry the same risk of fatal crashes.
    - dozzie 8y ago
      > There are also Ports, which don't carry the same risk of fatal crashes. Oh, this is cute statement xD No, ports also carry the same risk as NIFs if you use port drivers, because it's still the same way of running the code, just with different API. You need ports backed by external process to be isolated from the crash, though there's still the problem of such ports eagerly reading all the available data without any backpressure whatsoever, so your BEAM can trigger OOM killer. This is much easier to avoid, fortunately.
  - dozzie 8y ago
    > [...] the idea of [...] writing native code that has a tremendously small likelihood of crashing is very appealing. Until recently, no such technology was available but Rust changed that. No such technology was available, barring maybe Ada or some other languages.
steveklabnik 8y ago
What stuff are you running into with this? The vast majority of the ecosystem is on stable, but there are some holdouts. Working on them! I always like to hear people’s pain points, it helps with prioritization.
- gamache 8y ago
  I'm just a dabbler and most of my experience is a few months old -- I have no specifics for you, I'm afraid.
  - vvanders 8y ago
    If you're talking about Rocket that seems to be the largest thing that requires nightly. That said I can count on my hands the number of times I've used nightly over the last 2-ish years. It's pretty rare that you need to do it. I'll also add that I've actually been really impressed with how much attention Rust takes to not break stable packages. Between crater[1] and how aggressively they've cut point releases to fix any issues that (rarely) happen to slip by. [1] https://github.com/rust-lang-nursery/crater https://github.com/rust-lang-nursery/crater
    - inferiorhuman 8y ago
      Bindgen also wants nightly so if you're doing any FFI stuff you may be tethered to nightly.
      - vvanders 8y ago
        You sure about that? I've been using bindgen for ages on stable and just grabbed the latest version on an empty project and it still works for me.
        steveklabnik 8y ago
        I'm sitting next to bindgen's author in meatspace right now and he says yes, it has been on stable for a long time.
kevinmgranger 8y ago
Has rust ever broken working code in a stable release?
- steveklabnik 8y ago
  Depends on how you define “working”. We have broken some code that used to compile due to soundness issues. We’ve also made some small changes that in theory can break code but weren’t observed in the wild. The tolerance for that has dropped over time, of course.

qaq 8y ago

There is good interop story for Elixir/Rust. I would not be so sure about money bit either.

gamache 8y ago
There's a fine interop story, I've used Rustler before. The problem is when Rust nightly is sufficiently broken that even the auto-generated Rustler boilerplate won't compile. :)
skrebbel 8y ago
Just some random background for those reading about why Erlang/Elixir<->Rust interop is A Big Thing. The whole point of Erlang and Elixir is robustness in the face of high concurrency. All other design choices (eg functional programming, immutable data), follow from that goal. Core is that if one green thread ("process" in Erl/Ex lingo) crashes for whatever reason, the rest keep on running. Interop with native code is the sole exception here, which makes interop very scary. If a C function that's called into from Erl/Ex crashes, the entire program crashes. Boom, gone. Sure that holds for most other languages too, but Erlang/Elixir people get extra nervous because they're more accustomed to thinking about error scenarios and because they don't always have the same seven restart/recover layers outside the VM process that good devopsers wrap eg Node processes with because hey, no need, we have Erlang, we never crash. As a result, the idea of a technology that allows writing native code that has a tremendously small likelihood of crashing is very appealing. Until recently, no such technology was available but Rust changed that. Rust allows writing native functions that can be called from Erlang/Elixir with much fewer worries than C/C++ native extensions ever did, because of all the safety guarantees provided by the compiler. This is a big thing and I hope that as the interop story improves, it means that Erlang/Elixir will in practice become much faster because more libraries will be rewritten in native code.
- davidw 8y ago
  Or you can just make a remote node out of your C/Java/Rust/whatever code and not worry too much about it crashing your Erlang system. It's not just crashing either, it's taking a long time to execute a given function in the native code - that can also cause problems for the Erlang system running it.
  - OvermindDL1 8y ago
    Remote nodes have overhead, however if you can handle that overhead then you definitely should use a remote node or Port over a NIF. However, NIF's taking a long time to run is not so much of an issue anymore now that the dirty NIF scheduler is enabled by default in the BEAM.
- fabian2k 8y ago
  The danger of crashing the whole VM only applies to NIFs (native implemented functions), which is a very tight integration of the external code. There are also Ports, which don't carry the same risk of fatal crashes.
  - dozzie 8y ago
    > There are also Ports, which don't carry the same risk of fatal crashes. Oh, this is cute statement xD No, ports also carry the same risk as NIFs if you use port drivers, because it's still the same way of running the code, just with different API. You need ports backed by external process to be isolated from the crash, though there's still the problem of such ports eagerly reading all the available data without any backpressure whatsoever, so your BEAM can trigger OOM killer. This is much easier to avoid, fortunately.
- dozzie 8y ago
  > [...] the idea of [...] writing native code that has a tremendously small likelihood of crashing is very appealing. Until recently, no such technology was available but Rust changed that. No such technology was available, barring maybe Ada or some other languages.

steveklabnik 8y ago

What stuff are you running into with this? The vast majority of the ecosystem is on stable, but there are some holdouts. Working on them! I always like to hear people’s pain points, it helps with prioritization.

gamache 8y ago
I'm just a dabbler and most of my experience is a few months old -- I have no specifics for you, I'm afraid.
- vvanders 8y ago
  If you're talking about Rocket that seems to be the largest thing that requires nightly. That said I can count on my hands the number of times I've used nightly over the last 2-ish years. It's pretty rare that you need to do it. I'll also add that I've actually been really impressed with how much attention Rust takes to not break stable packages. Between crater[1] and how aggressively they've cut point releases to fix any issues that (rarely) happen to slip by. [1] https://github.com/rust-lang-nursery/crater https://github.com/rust-lang-nursery/crater
  - inferiorhuman 8y ago
    Bindgen also wants nightly so if you're doing any FFI stuff you may be tethered to nightly.
    - vvanders 8y ago
      You sure about that? I've been using bindgen for ages on stable and just grabbed the latest version on an empty project and it still works for me.
      - steveklabnik 8y ago
        I'm sitting next to bindgen's author in meatspace right now and he says yes, it has been on stable for a long time.

kevinmgranger 8y ago

Has rust ever broken working code in a stable release?

steveklabnik 8y ago
Depends on how you define “working”. We have broken some code that used to compile due to soundness issues. We’ve also made some small changes that in theory can break code but weren’t observed in the wild. The tolerance for that has dropped over time, of course.