5 ms·

Hence why Rustler is of so much interest since it provides more protections against this happening. Discord is a big Erlang + Rustler user.

drawnwren 2y ago
Is any of this code open source? As an outsider, I'm kind of at a loss for why anyone wants this or what you kids are doing over there and how offended I should be by it.
- jhgg 2y ago
  https://github.com/discord/sorted_set_nif https://github.com/discord/sorted_set_nif
  - drawnwren 2y ago
    Awesome! Thank you! My sarcasm got downvoted heavily (poe's law), but I was genuinely interested.
- alberth 2y ago
  Do you mean Rustler? Yes, it's Apache 2.0 https://github.com/rusterlium/rustler https://github.com/rusterlium/rustler
- sodapopcan 2y ago
  TL;DR: Erlang/Elixir/etc are high level languages and the virtual machine they run on, the BEAM, is optimized for speedy IO but is not so great when it comes to intensive CPU tasks. You'll want to write the latter in a good systems language which is what libraries like this provide (you get C bindings out of the box, I believe).
depr 2y ago
Are they really? Their projects don't look so active
- sodapopcan 2y ago
  It’s pretty common in the Elixir ecosystem for these types of libraries to not change very much. Elixir itself doesn’t change too much so these libraries stay solid without needing frequent updates. It doesn’t mean people aren’t using them. Some libraries even put disclaimers that they are actively maintained even if they haven’t seen an update in a long time. It’s something that takes some getting used to for some people (including myself at one point).
  - andy_ppp 2y ago
    Yeah I was trying to explain this to another developer that packages end up being “finished” eventually and seem to continue to work exceptionally well without updates for a really long time. Something about immutability and the structure of Elixir leads to surprisingly few bugs.
  - sbuttgereit 2y ago
    Yep. This is one reason I choose Elixir for a project. For a variety of use cases, long term stability is a big plus.
  - photonthug 2y ago
    > It’s pretty common in the Elixir ecosystem for these types of libraries to not change very much. This is kind of fascinating and seems worthy of more detailed study. I'm sure almost anything looks stable compared to javascript/python ecosystems, but would be interesting to see how other ecosystems with venerable old web-frameworks or solid old compression libraries compare. But on further reflection.. language metrics like "popularity" are also in danger of just quantifying the churn that it takes to keep working stuff working. You can't even measure strictly new projects and hope that helps, because new projects may be a reaction to perceived need to replace other stuff that's annoyingly unstable over periods of 5-10 years, etc. Some churn is introduced by trying to keep up with a changing language, standard lib, or other dependencies, but some is just adding features forever or endlessly refactoring aesthetics under different management. Makes me wish for a project badge to indicate a commitment like finished-except-for-bugfixes.
deleted 2y ago
[deleted]
johnisgood 2y ago
What kind of protections as opposed to Zigler?
- alberth 2y ago
  Rust comes with memory safety. It's one less potential cause that might bring down the entire Erlang VM.
  - hinkley 2y ago
    SIGSEGV is a pretty common failure mode alright.
- el_oni 2y ago
  Rustler catches panics before they crash the VM and raises them on the elixir side as an exception. So your process might crash but the vm wont
  - kristoff_it 2y ago
    That's a neat way to get corrupted state in your application, especially when users of said language don't realize that their language has exceptions. I wrote this recently about Go, but it equally applies to any Rust application that tries to recover from a panic. https://kristoff.it/blog/go-exceptions-unconvinced/ https://kristoff.it/blog/go-exceptions-unconvinced/
    - ellroy 2y ago
      I don't think this is right. The process will crash, and the Supervision strategy you are using will determine what happens from there. This is what the BEAM is all about. The thing with NIFs is that they can crash the entire VM if they error.
    - MarcusE1W 2y ago
      Erlang's (Elixirs) error management approach is actually "Let it crash" This is based on the acknowledgment that if you have a large number of longer running processes at some point something will crash anyway, so you may quite as well be good at managing crashes ;-) https://dev.to/adolfont/the-let-it-crash-error-handling-strategy-of-erlang-by-joe-armstrong-25hf https://dev.to/adolfont/the-let-it-crash-error-handling-stra...

drawnwren 2y ago

Is any of this code open source? As an outsider, I'm kind of at a loss for why anyone wants this or what you kids are doing over there and how offended I should be by it.

jhgg 2y ago
https://github.com/discord/sorted_set_nif https://github.com/discord/sorted_set_nif
- drawnwren 2y ago
  Awesome! Thank you! My sarcasm got downvoted heavily (poe's law), but I was genuinely interested.
alberth 2y ago
Do you mean Rustler? Yes, it's Apache 2.0 https://github.com/rusterlium/rustler https://github.com/rusterlium/rustler
sodapopcan 2y ago
TL;DR: Erlang/Elixir/etc are high level languages and the virtual machine they run on, the BEAM, is optimized for speedy IO but is not so great when it comes to intensive CPU tasks. You'll want to write the latter in a good systems language which is what libraries like this provide (you get C bindings out of the box, I believe).

depr 2y ago

Are they really? Their projects don't look so active

sodapopcan 2y ago
It’s pretty common in the Elixir ecosystem for these types of libraries to not change very much. Elixir itself doesn’t change too much so these libraries stay solid without needing frequent updates. It doesn’t mean people aren’t using them. Some libraries even put disclaimers that they are actively maintained even if they haven’t seen an update in a long time. It’s something that takes some getting used to for some people (including myself at one point).
- andy_ppp 2y ago
  Yeah I was trying to explain this to another developer that packages end up being “finished” eventually and seem to continue to work exceptionally well without updates for a really long time. Something about immutability and the structure of Elixir leads to surprisingly few bugs.
- sbuttgereit 2y ago
  Yep. This is one reason I choose Elixir for a project. For a variety of use cases, long term stability is a big plus.
- photonthug 2y ago
  > It’s pretty common in the Elixir ecosystem for these types of libraries to not change very much. This is kind of fascinating and seems worthy of more detailed study. I'm sure almost anything looks stable compared to javascript/python ecosystems, but would be interesting to see how other ecosystems with venerable old web-frameworks or solid old compression libraries compare. But on further reflection.. language metrics like "popularity" are also in danger of just quantifying the churn that it takes to keep working stuff working. You can't even measure strictly new projects and hope that helps, because new projects may be a reaction to perceived need to replace other stuff that's annoyingly unstable over periods of 5-10 years, etc. Some churn is introduced by trying to keep up with a changing language, standard lib, or other dependencies, but some is just adding features forever or endlessly refactoring aesthetics under different management. Makes me wish for a project badge to indicate a commitment like finished-except-for-bugfixes.

deleted 2y ago

[deleted]

johnisgood 2y ago

What kind of protections as opposed to Zigler?

alberth 2y ago
Rust comes with memory safety. It's one less potential cause that might bring down the entire Erlang VM.
- hinkley 2y ago
  SIGSEGV is a pretty common failure mode alright.
el_oni 2y ago
Rustler catches panics before they crash the VM and raises them on the elixir side as an exception. So your process might crash but the vm wont
- kristoff_it 2y ago
  That's a neat way to get corrupted state in your application, especially when users of said language don't realize that their language has exceptions. I wrote this recently about Go, but it equally applies to any Rust application that tries to recover from a panic. https://kristoff.it/blog/go-exceptions-unconvinced/ https://kristoff.it/blog/go-exceptions-unconvinced/
  - ellroy 2y ago
    I don't think this is right. The process will crash, and the Supervision strategy you are using will determine what happens from there. This is what the BEAM is all about. The thing with NIFs is that they can crash the entire VM if they error.
  - MarcusE1W 2y ago
    Erlang's (Elixirs) error management approach is actually "Let it crash" This is based on the acknowledgment that if you have a large number of longer running processes at some point something will crash anyway, so you may quite as well be good at managing crashes ;-) https://dev.to/adolfont/the-let-it-crash-error-handling-strategy-of-erlang-by-joe-armstrong-25hf https://dev.to/adolfont/the-let-it-crash-error-handling-stra...