3 ms·

> * Dirty schedulers: This allows easy integration of blocking C-based libraries. So for example can wrap something like RocksDb and make it available to the re

> * Dirty schedulers: This allows easy integration of blocking C-based libraries. So for example can wrap something like RocksDb and make it available to the rest of the VM easier. Or libcurl and others. Amazing. I'm new to erlang, but within the last hour just read comments by a seasoned programmer on how erlang's shiny scheduler has an achilles heel when it comes to blocking C-based libraries. I suppose then that this truly is a significant advancement. Mention of the scheduler was in a comparison between erlang and node.js. Article here: https://notamonadtutorial.com/interview-with-jesper-louis-andersen-about-erlang-haskell-ocaml-go-idris-the-jvm-software-and-5628fe591295 https://notamonadtutorial.com/interview-with-jesper-louis-an...

rdtsc 9y ago
> how erlang's shiny scheduler has an achilles heel when it comes to blocking C-based libraries. It's an improvement but it was already possible to write C-based libraries. There are drivers, ports, NIFs were there before but for long running computation had to do your own thread and queue setup. This just avoids that bit because VM writers did it for the user so to speak (and probably did the right way). Also it is really something advanced and not what most Erlang programmers would end up doing anyway. Once you start writing C code and directly loading it into the VM, the same caveats as before apply - that is a some fault tolerance and safety guarantees go out of the window.
- brightball 9y ago
  Exactly. Half the point of the beam is not having that type of code impact the scheduler. Case in point, you can write a faster JSON parser in C and use it (jiffy)...but it's not desirable to pollute your BEAM for the minor performance gain.
- sausman 9y ago
  Yeah, the only thing I've used it for thus far is hashing passwords e.g. https://github.com/riverrun/argon2_elixir https://github.com/riverrun/argon2_elixir

rdtsc 9y ago

> how erlang's shiny scheduler has an achilles heel when it comes to blocking C-based libraries. It's an improvement but it was already possible to write C-based libraries. There are drivers, ports, NIFs were there before but for long running computation had to do your own thread and queue setup. This just avoids that bit because VM writers did it for the user so to speak (and probably did the right way). Also it is really something advanced and not what most Erlang programmers would end up doing anyway. Once you start writing C code and directly loading it into the VM, the same caveats as before apply - that is a some fault tolerance and safety guarantees go out of the window.

brightball 9y ago
Exactly. Half the point of the beam is not having that type of code impact the scheduler. Case in point, you can write a faster JSON parser in C and use it (jiffy)...but it's not desirable to pollute your BEAM for the minor performance gain.
sausman 9y ago
Yeah, the only thing I've used it for thus far is hashing passwords e.g. https://github.com/riverrun/argon2_elixir https://github.com/riverrun/argon2_elixir