16 ms·

Erlang/OTP by Example

218 points by jxub 8y ago

xq3000 8y ago
Cool site! PS: Content looks cropped on an iPhone 7 nonmatter how you resize it
- phyrex 8y ago
  Yep, completely unusable on mobile
- Waterluvian 8y ago
  Can't read the left half of any code examples on Android chrome.
jlouis 8y ago
If you get to the part about monitors, consider erlang:demonitor(Ref, [flush]) in your own code. This also removes the monitor message from your mailbox if it arrived in between, which is a real problem in an async setting. Though in some situations, it is better to just ignore the spurious message when it arrives by tracking what monitors you have enabled in the process state. Unkonwn monitors are just gracefully ignored. The same pattern is useful with timeouts as well. Cancel the timeout, but if it arrives in your mailbox while the cancel is happening, you can just detect an old timeout and ignore it.
- jhgg 8y ago
  demonitor flush can be harmful in some instances as it invokes a selective receive to yank the down message from your process's mailbox. In the event that you are demonitor+flushing on a process that has a growing message queue, every flush gets more and more costly - especially if the monitor has already delivered a DOWN message for it to yank. it's almost always better to ignore down messages that you don't care about.
davidw 8y ago
This is also a fantastic Erlang learning resource: https://learnyousomeerlang.com/ https://learnyousomeerlang.com/
ilovecaching 8y ago
As someone who has worked two jobs now writing, deploying, and operating Erlang clusters, I recommend switching to Rust. Erlang requires a lot of TLC to get right, it's super slow, and it's hard to burst. Like, super hard to burst. Erlang nodes are meant to cluster as a k graph and never go down. Modern ops, especially container ops, does availability through ephemerality of services. The BEAM just doesn't like to be treated like cattle. Also Erlang has notoriously bad error messages, very little abstraction, and converting between binary strings and lists is a pain. Gaining Erlang operational knowledge also takes a while. We eventually had to rewrite things like gen_server, ditch mnesia etc. as we scaled. So why Rust? Like Erlang, it's damn good at concurrency and enables functional programming. It also enables event driven programming through tokio, which is a better fit for web servers than green threads (you're mostly waiting on the network). Unlike Erlang, it's super fast (even at math), has a great type system, amazing error messages, low memory usage, and the community is already quite a bit bigger.
- dev_dull 8y ago
  The world of ephemeral containers really has changed the dynamic. Erlang solves a lot of problems with good solutions, but writing good software is only part of the battle. Lifecycle management, monitoring, etc make up a huge operational burden and should always be thought of as first-class problems in language design. Rust makes that better in many ways but not uniquely better than alternative languages.
  - ilovecaching 8y ago
    In my experience any compiled language is easier to manage. There is no disconnect between your runtime and the system. You're investing in systems knowledge rather than knowledge of a particular VM's bytecode/abstractions as well. Erlang does provide good solutions to lifecycle management. The problem is that whenever someone picks a solution for you, you're now locked it and it can be difficult to migrate to a new paradigm like containers.
    - dev_dull 8y ago
plainOldText 8y ago
In addition, two other highly informative resources: * http://spawnedshelter.com/ http://spawnedshelter.com/ * http://beam-wisdoms.clau.se/en/latest/ http://beam-wisdoms.clau.se/en/latest/
the_clarence 8y ago
I'm kind of sad that Elixir is getting all the love and the cool resources since I much prefer Erlang's syntax. Thanks for this page!
- innocentoldguy 8y ago
  I love Erlang too, but I don't think Elixir's popularity is stealing love away from Erlang. If anything, I think Elixir compliments Erlang and provides a path for people to enter the world of Erlang, BEAM, and OTP that they didn't have before. Elixir helped to lower the bar of entry. My understanding is that the Elixir team has also helped drive some improvements in Erlang, which is nice. Personally, I love both Erlang and Elixir and hope to ride out the rest of my career on these platforms.
  - richjdsmith 8y ago
    I agree wholeheartedly. Elixir gave me an opportunity to start to play around with Erlang and OTP. While I prefer using Elixir, its ability to mix and match with Erlang has made it a great gateway.

218 points by jxub 8y ago

xq3000 8y ago

Cool site! PS: Content looks cropped on an iPhone 7 nonmatter how you resize it

phyrex 8y ago
Yep, completely unusable on mobile
Waterluvian 8y ago
Can't read the left half of any code examples on Android chrome.

jlouis 8y ago

If you get to the part about monitors, consider erlang:demonitor(Ref, [flush]) in your own code. This also removes the monitor message from your mailbox if it arrived in between, which is a real problem in an async setting. Though in some situations, it is better to just ignore the spurious message when it arrives by tracking what monitors you have enabled in the process state. Unkonwn monitors are just gracefully ignored. The same pattern is useful with timeouts as well. Cancel the timeout, but if it arrives in your mailbox while the cancel is happening, you can just detect an old timeout and ignore it.

jhgg 8y ago
demonitor flush can be harmful in some instances as it invokes a selective receive to yank the down message from your process's mailbox. In the event that you are demonitor+flushing on a process that has a growing message queue, every flush gets more and more costly - especially if the monitor has already delivered a DOWN message for it to yank. it's almost always better to ignore down messages that you don't care about.

davidw 8y ago

This is also a fantastic Erlang learning resource: https://learnyousomeerlang.com/ https://learnyousomeerlang.com/

ilovecaching 8y ago

As someone who has worked two jobs now writing, deploying, and operating Erlang clusters, I recommend switching to Rust. Erlang requires a lot of TLC to get right, it's super slow, and it's hard to burst. Like, super hard to burst. Erlang nodes are meant to cluster as a k graph and never go down. Modern ops, especially container ops, does availability through ephemerality of services. The BEAM just doesn't like to be treated like cattle. Also Erlang has notoriously bad error messages, very little abstraction, and converting between binary strings and lists is a pain. Gaining Erlang operational knowledge also takes a while. We eventually had to rewrite things like gen_server, ditch mnesia etc. as we scaled. So why Rust? Like Erlang, it's damn good at concurrency and enables functional programming. It also enables event driven programming through tokio, which is a better fit for web servers than green threads (you're mostly waiting on the network). Unlike Erlang, it's super fast (even at math), has a great type system, amazing error messages, low memory usage, and the community is already quite a bit bigger.

dev_dull 8y ago
The world of ephemeral containers really has changed the dynamic. Erlang solves a lot of problems with good solutions, but writing good software is only part of the battle. Lifecycle management, monitoring, etc make up a huge operational burden and should always be thought of as first-class problems in language design. Rust makes that better in many ways but not uniquely better than alternative languages.
- ilovecaching 8y ago
  In my experience any compiled language is easier to manage. There is no disconnect between your runtime and the system. You're investing in systems knowledge rather than knowledge of a particular VM's bytecode/abstractions as well. Erlang does provide good solutions to lifecycle management. The problem is that whenever someone picks a solution for you, you're now locked it and it can be difficult to migrate to a new paradigm like containers.
  - dev_dull 8y ago

plainOldText 8y ago

In addition, two other highly informative resources: * http://spawnedshelter.com/ http://spawnedshelter.com/ * http://beam-wisdoms.clau.se/en/latest/ http://beam-wisdoms.clau.se/en/latest/

the_clarence 8y ago

I'm kind of sad that Elixir is getting all the love and the cool resources since I much prefer Erlang's syntax. Thanks for this page!

innocentoldguy 8y ago
I love Erlang too, but I don't think Elixir's popularity is stealing love away from Erlang. If anything, I think Elixir compliments Erlang and provides a path for people to enter the world of Erlang, BEAM, and OTP that they didn't have before. Elixir helped to lower the bar of entry. My understanding is that the Elixir team has also helped drive some improvements in Erlang, which is nice. Personally, I love both Erlang and Elixir and hope to ride out the rest of my career on these platforms.
- richjdsmith 8y ago
  I agree wholeheartedly. Elixir gave me an opportunity to start to play around with Erlang and OTP. While I prefer using Elixir, its ability to mix and match with Erlang has made it a great gateway.