Erlang NOTP: a middle way | Hacker News Reader

Erlang NOTP: a middle way

blog.ikura.co

66 pointssetra11 comments

Still no explanation whatsoever of what this is doing.

Anyone knows what mystery "the final few pages in the Joe Armstrong 2nd edition Erlang book" hold?

The "final few pages" are entirely module reference for zlib so that probably isn't what is referenced. Prior to that are miscellaneous bits about debugging, tracing, code-reloading etc.

I have version P5.0 from 2011 though, so it could be wrong altogether.

"Appendix 3: A Simple Execution Environment"

https://www.safaribooksonline.com/library/view/programming-e...

http://erlang.org/pipermail/erlang-questions/2014-February/0...

In the book Joe explains that OTP loads 67 modules and starts 25 processes at startup, which makes it slow to boot. Then he demonstrates how to create a single module providing a very minimal subset of what these 67 modules do. This single module can then be used to create scripts that start and run very quickly, since they don't require the whole OTP machinery.

Some of the functionality the module provides are rpc, stdio, and very basic process registration.

This might make Erlang practical for FAAS. I also wonder if this will work with Elixir (since Elixir might have extra modules being loaded in too).

I'm not sure why one would do that as opposed to say, running things with JavaScript (ubiquity) or Ruby/Python (library support). I like Elixir, though I recognize that many of Erlang's advantages is in concurrency and control.

Why wouldn't you just use Mix tasks in Elixir? Once I discovered mix tasks, I have used them for all sorts of one off things.

I have not looked at mix tasks. It depends on its characteristics. FAAS isn't exactly a one-off thing and falls under a "serverless" paradigm. (I am a bit skeptical of FAAS myself). Mix tasks might have characteristics that makes it suitable for FAAS, or it might not.

Ah, for those sorts of things, they probably wouldn't work SUPER well, though I can see them made to work. Spinning up the BEAM is much cheaper than spinning up a JVM, though it is very much server-ey by design.

This seems much simpler than what one would normally have to do, but still not as simple as getting started in Ruby or Python or Node.js (or even Java).

erlang (OTP) has a learning curve without a doubt, but this author seems to gloss over using escript which is simple to use, although it has three lines of boilerplate

  #!/usr/bin/env escript
  %%!
  main(_) ->
    stuff.

In case you're like me and have no idea how to navigate bitbucket:

https://bitbucket.org/nato/notp/src/efe882a3ff3eb2e6a00d7013...

https://bitbucket.org/nato/notp/src no need to link to a specific revision.

Reply on news.ycombinator.com