5 ms·
The Zen of Erlang (2016)
- mumrah 8y agoIf you like this, I recommend checking out Learn You Some Erlang (for great good) http://learnyousomeerlang.com/content http://learnyousomeerlang.com/content
- matt-snider 8y agoThe blog author is the author of Learn You Some Erlang btw (just for others reading this, since it wasn't clear from your comment)
- _asummers 8y agoHis other writings are good too. I recommend Erlang in Anger.
- mononcqc 8y agoI've also written http://propertesting.com/ http://propertesting.com/, which I'm currently working to turn into a full book with Pragmatic Programmers (with Elixir translations included as well, so that everyone on the BEAM can benefit :) )
- autocorr 8y agoDoes anyone know of erlang being used for scientfic computing? The ideas and "let it crash" scheme outlined in the article are really cool, and it made me think how it would actually be very useful for making robust data pipelines in scientific contexts. For example, in astronomy you would have a telescope spitting out raw data, and a pipeline processing the data to create more inspectable intermediate products. Typically these are brittle C/C++ programs, with lots of state and branching logic, and further they become extremely hard to refactor because their function is so integral to running the facility. Erlang seems like it would be very useful for a control and pipeline system like this that needs to stay alive and not crash, but it's hard to tell (for me) if it's well suited to numeric/scientific computing tasks. Do people know of libraries or resources that would be useful for that? I did find this neat lsci[1] package that aims to call python modules like numpy/matplotlib (which would be perfect) but is sadly in a nascent state. [1] https://github.com/lfex/lsci https://github.com/lfex/lsci
- pg_bot 8y agoErlang's main weakness is computationally intensive mathematics. You could always write a NIF in C if you needed pure speed for a specific function. If you're not interested in writing safe c code it looks like there is a bridge from rust to erlang. https://github.com/hansihe/rustler https://github.com/hansihe/rustler
- digitalzombie 8y agoEven if you write NIF C or in Rust. They can take down Erlang's BEAM VM. > http://erlang.org/doc/tutorial/nif.html http://erlang.org/doc/tutorial/nif.html Erlang itself shield you from actually doing stupid thing and follow the assumptions that BEAM have while running programs. You're better off choosing a different language. Have Erlang deal with concurrency but don't have it do number crunching.
- xtagon 8y agoRustler in particular boasts safety and an inability to crash the Erlang VM. Whether that holds true in practice, I don't know, but it's the first thing they mention in their README.
- tov_objorkin 8y agoIf you need fast small function use NIF, for large logic blocks better use C node its safe and isolated.
- deleted 8y ago[deleted]
- Ceezy 8y agoYou should probably use erlang to start/monitor/kill process but not for doing the actual computing
- andy_ppp 8y agoI have thought about this too, even doing things like modelling climate change through distributed message passing (each process could act like a cube of the earth) but sadly I think the performance is going to be too far from C to be useful. HiPE has seen some very large performance increases in maths performance but still C is going to alway be a substantial amount faster.
- deleted 8y ago[deleted]
- Ceezy 8y agoThat s a MUST READ
- snarfy 8y ago"We all know the saying it’s better to ask for forgiveness than permission. And everyone knows that, but I think there is a corollary: If everyone is trying to prevent error, it screws things up. It’s better to fix problems than to prevent them. " [1] [1] - https://signalvnoise.com/posts/2440-we-all-know-the-saying-its-better-to-ask-f https://signalvnoise.com/posts/2440-we-all-know-the-saying-i...
- kuon 8y agoI really like the "let it crash" philosophy. I have been working with elixir for a year now and it makes software much more reliable and easier to write.