5 ms·
Some things I like from the new release: * Dirty schedulers: This allows easy integration of blocking C-based libraries. So for example can wrap something like
by rdtsc 9y ago
Some things I like from the new release:
* 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.
* DTLS : This lets it talk to WebRTC clients
* Erlang literals are no longer copied when sending messages : This is kinda of a sneaky one. By default (with exception of large binaries) Erlang VM usually copies data when it sends messages. However, in this case module literals (constants, strings, etc) will be another thing that's not copied. There is a hack to dynamically compile configuration values or other tables of constants as a module at runtime. So if you use that hack, you'd get a nice performance boost.
* code_change, terminate and handle_info callbacks optional in the OTP behaviors. This is very nice. I always wondered why I had to write all that boiler plate code.
Also here is a detailed list of changes:
http://erlang.org/download/otp_src_20.0-rc2.readme http://erlang.org/download/otp_src_20.0-rc2.readme
- fredliu 9y ago* DTLS : This lets it talk to WebRTC clients Could you elaborate more on this? I don't know much about erlang/OTP's support for WebRTC. Does adding DTLS makes erlang/OTP possible to talk to WebRTC clients because WebRTC requires DTLS? or this means erlang/OTP now has a complete stack and API for WebRTC communication out of the box?
- rdtsc 9y agoDTLS is TLS (SSL) but for datagrams (UDP) instead of the traditional streams (TCP). WebRTC uses DTLS as one of its base protocols. The other one is SRTP but even its setup requires DTLS. I am not sure how complete the rest of the support it but having DTLS is a major step ahead.
- fredliu 9y agoThanks for the clarification. I was aware of the DTLS requirement for WebRTC, but not sure the whole WebRTC stack support on erlang/OTP. Now thinking about it, maybe an erlang/elixir/whatever-on-BEAM implementation of STUN/TURN server would make sense...
- scandox 9y agoI thought that the STUN/TURN stuff was just for discovery and used fairly conventional protocols...Isn't the DTLS for actual media transmission - i.e. directly between clients (or via some kind of Gateway?)
- fredliu 9y agoSTUN is for signaling, but the hole-punching business is not 100% guaranteed to work, so you need TURN as the back up relay server. DTLS is needed for both p2p traffic and the replaying traffic through TURN, so your TURN server does need DTLS for its job.
- zurn 9y agoSTUN/TURN are just NAT traversal, they are building blocks in WebRTC signaling.
- mtanski 9y ago> * 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. Silly question, but shouldn't elang have some good & highly concurrent http libraries?
- tomjakubowski 9y agolibcurl supports some other protocols, too. Maybe Erlang lacks good and highly concurrent Gopher libraries. :-)
- micmus 9y agoDirty schedules are about functions implemented in C - called NIFs (Native Implemented Functions) - a sort of FFI you'd find in most languages. Because of preemptive nature of Erlang, doing lengthy work in those functions can destabilise the system (the "magic value" is said to be around 1ms). That is because C functions can't be preempted in the middle of execution like Erlang ones can. Using dirty schedulers lifts this time limitation, but gives a higher constant overhead when calling a function on a dirty scheduler, since it means switching OS thread. This tradeoff, however, is perfectly acceptable for a lot of cases. And yes, Erlang has good & highly concurrent HTTP libraries implemented in Erlang.
- eugene_pirogov 9y agoA question regarding dirty schedulers: does it still mean that when called C code crashes during execution, entire Erlang VM will crash as well?
- micmus 9y agoYes. That's not changed. All NIFs (regular or dirty ones) are executed directly in the context of the VM. A safe option would be a port - a regular program where you communicate through stdin/stdout. Ports allow representing such program (running in a separate OS process) as something equivalent to a native Erlang process. There's also work on supporting writing NIFs in Rust, which gives some degree of additional safety. The relevant project would be: https://github.com/hansihe/rustler https://github.com/hansihe/rustler
- equalunique 9y ago> * 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 agoExactly. 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 agoYeah, 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
- wcummings 9y agoI thought dirty NIFs were available since like 17 or 18. I know I wrote some code that used them a couple of years ago.
- marianoguerra 9y agoThey were marked as experimental. Now they are marked as stable
- deleted 9y ago[deleted]
- _asummers 9y agoETS CAS is a huge one, too!
- bostonvaulter2 9y agoCan you explain what that is for the uninitiated?
- greenleafjacob 9y agoETS is a fast [1] in-memory K/V store including a set type with constant time put/get in the standard library of Erlang. New in OTP 20 is an atomic CAS (compare-and-swap) operation. [1] http://www.erlang-factory.com/static/upload/media/1459269312665211markallenwhenetsistooslow.pdf http://www.erlang-factory.com/static/upload/media/1459269312...