HN Theater @HNTheaterMonth

Erlang: The Movie shows how it's done (RIP Joe Armstrong): https://www.youtube.com/watch?v=xrIjfIjssLE

⬐ xrayarx

Very old but very entertaining movie (11min) about erlang by showcasing then new landline phone features

Lol, this reminds me of Erlang: The Movie

https://www.youtube.com/watch?v=xrIjfIjssLE

⬐ macintux

Thanks for posting that; the output clearly makes more sense if you’re familiar with the movie.

⬐ lelf

And just in case you missed it, — Erlang The Movie II: The Sequel https://www.youtube.com/watch?v=rRbY3TMUcgQ

It is one of the core features of Erlang (a language developed by Ericsson), being able to rewrite code in production, with errors/crashes that break one thread not affecting another.

Obligatory link to Erlang: The Movie (10min)- https://www.youtube.com/watch?v=xrIjfIjssLE

Note that they start crashing things in Erlang around minute 7, and fix them shortly thereafter. Meanwhile, their setup keeps calls that weren't directly involved in the crash alive and running unaffected.

⬐ Matrixik

Well, great for Erlang.

But this hardware is not running on Erlang but on C++. Erlang is used for testing.

⬐ StudentStuff

Source? Ericsson themselves state that Erlang is a backbone of LTE, with "Many smartphones are connected for data transfer using Erlang software.".

Seeing as Ericsson doesn't make cell phones, this would directly imply that critical portions of their base station software are written in Erlang.

https://www.ericsson.com/en/news/2014/12/inside-erlang--crea...

⬐ Matrixik

I was working on the code for mobile nodes, 3G and 4G. C++ with RSARTE (IBM plugin for Eclipse for Real-Time Applications) [1]. I left but my friends started working on 5G where looks like they want to get rid of RSARTE and use clean C++. At some point of time some people in Sweden started looking into rewriting it in Erlang but after around 1 year it was dropped, don't remember why.

[1] https://www.ibm.com/developerworks/community/wikis/home?lang...

⬐ StudentStuff

Speed of running the code was likely why C++ was retained, Erlang is a higher level language that uses more resources, and depending on your platform target there may not be enough CPU resources in your average base station to support a software stack in Erlang doing packet forwarding, QoS or especially DPI.

That being said, for communications platforms it has some very useful properties when code starts to break, hence WhatsApp and 2600hz using it for their respective projects.

I discovered Erlang in the late 2000s via its kinda weird and iconic video "Erlang the Movie" https://www.youtube.com/watch?v=xrIjfIjssLE that prompted me to dig further. I was at the time an average developer. Erlang, and Joe Armstrong books and videos, made me understand things that other web-oriented languages ( Ruby, PHP... ) never really dug into at the time. Because the Erlang ecosystem is more than distribution. Distribution is a consequence of its design around concurrency and message passing and let-it-crash/auto-healing philosophy. Erlang, and after that Elixir, made me think differently about code and made me a better programmer.

⬐ paulsutter

The sequel is shorter and more fun, “all erlang needs is an image upgrade.. we need something fresh, something edgy”

https://youtu.be/rRbY3TMUcgQ

⬐ cuddlybacon

I love it!

When will OTP be updated to support Blockchain?

⬐ kirillseva

Haha, this reminds me of red-lang's approach to get funded via ICO https://ico.red-lang.org/

> Clojure

Alex Miller and Stuart Halloway immediately jump to mind as lieutenants that could jump in and take over without too much disruption.

> Erlang

Well, there's also Roberts and Mike (reference, for those not familiar: https://youtu.be/xrIjfIjssLE?t=213).

The author doesn't talk a lot about preemptive scheduling, which is probably the best thing about the Erlang virtual machine. This video explains what preemptive scheduling is and why it is extremely useful: https://www.youtube.com/watch?v=5SbWapbXhKo

First, the speaker creates an application endpoint that runs into an infinite loop on invalid input. Then, he shows how that doesn't block the rest of the requests. Using native BEAM (EDIT: BEAM = EVM = Erlang Virtual Machine) tools, he looks for the misbehaving process (the one running the infinite loop), prints some debug information and kills it. It's pretty impressive.

Another great (and lighter) resource, is "Erlang the Movie" (https://www.youtube.com/watch?v=xrIjfIjssLE). It shows the power of concurrency through independent processes, the default debug tools, and the power of hot code reloading. Don't miss the twist at the end.

⬐ wmonk

I have just started reading Elixir in Action[1] by the same person in the video. I've been enjoying it so far, I think things like the stuff demonstrated will be in the book.

[1] - https://www.manning.com/books/elixir-in-action

⬐ KallDrexx

Preemptive scheduling is great, but there are some times when it is bad. For example, I was having problems in my Elixir code for live streaming that it was taking too many reductions to fully deserialize and process the incoming message (nothing major was in this code path, just a parsing the TCP packet and unwrapping the different layers). This ended up causing the process to get (what seems to be) overbalanced and I ended up at having delays transferring 5+mbps video through it.

I broke the deserialization up into 3 separate processes (1 for handling the I/O, 1 for packet deserialization, 1 for message deserialization) and while this fixed all the issues (presumably because it can balance the processes more effectively since no single process went over the reduction limit) it turned the effectively synchronous parsing process into a split async process and caused a lot of extra complexity around that.

I'm sure there's more to what caused the issue than just reduction limits but it also made me wary about the magic happening under the hood.

⬐ bitwalker

You may have been able to bump the process priority to give that process more scheduler time if it's a critical process in a hot path. Perhaps you tried that though. Definitely have to be careful with it, but always an option to keep in mind!

⬐ KallDrexx

I haven't tried that, but I'd have to make sure that every inbound and outbound RTMP connection had high enough priority to correctly execute, and that seemed like a lot of tweaking that had to be done in order to maintain the constant flow of video throughout the app with low latency.

At least for my operation it looked very much like I would really need to become a BEAM vm expert to make sure things ran smoothly (not just with that but other potential issues I had in the back of my mind as well).

⬐ randomstudent

> At least for my operation it looked very much like I would really need to become a BEAM vm expert to make sure things ran smoothly

From someone with zero experience in building concurrent systems: isn't this true for every sufficiently complex system? If your system is complex enough, then no general framework will help much, right?

⬐ KallDrexx

At some point sure, but I can get concurrent systems up and running pretty easily in Go, C# and Rust without going too deep into the underlying details of the asynchronous framework. Erlang's VM does a lot more than any of those frameworks or runtimes do though because of how it handles per process garbage collection yet globally shared binaries, the preemptive scheduler and how it balances process load, the hot-reload capabilities etc... It does a lot of things really well but there's a lot of magic behind it, and I seemed to brush against that much faster than I have in other languages.

⬐ dguaraglia

Do you mind me asking what kind of throughput you are seeing for a process like that where you unpack video across some processes? I'm working on something similar using Go and it'd be great to know if Elixir is a good alternative or not.

⬐ KallDrexx

I know of some Erlang based platforms that achieve 10gbps throughput. I hadn't done exhaustive testing on my prototype as I've changed gears away from my home-grown solution to modifying some open source C++ media servers that are a bit more proven than my own stuff.

⬐ lobster_johnson

Not just scheduling — the ability to forcibly terminate processes itself is a key part of why Erlang can be resilient to failures.

It's a key area where I think Go went wrong. Without the ability to kill a goroutine, you can't implement caller-enforced timeouts and canceling — anything that should be able to be canceled has to explicitly check for some signal sent by the controlling party. This is why Go ended up with Context, which infects everything it touched.

And you also can't create Erlang-style supervisor trees; you can't create self-repairing hiearchies of control. And you can't do things like use a debugger to attach to a process and terminate runaway goroutines.

⬐ zaptheimpaler

Isn't pre-emptive multitasking the same strategy used by OS threads etc. where some global scheduler decides which tasks are running? I suppose the VM is managing the threads here rather than OS, so "green threads" like Go. Regardless, it would be pre-emptive multitasking in any multi-threaded Java program or Go program. Just trying to understand what the "secret sauce" of the Erlang VM is.

Is it just that context switches are a lot cheaper within green threads rather than the OS thread?

⬐ noir_lord

Pre-emptive scheduling is indeed the approach used by most operating systems (those of us who are bit older will remember when the most common version of Windows was co-operative scheduling - that was fun, any single application misbehaving could hold all the resources on the machine and that happened quite a lot!).

The genius of Erlang is that instead of a per machine it was designed to be distributed from the start so you have a lot less inter dependencies when you want to scale across machines (or cores since that's where Erlang/Elixir shines at the moment), that was one of the design goals since it was designed for the kinds of software where that was a desirable quality (back when hardware was way slower than now), dropping a single call/circuit wasn't the end of the world if the rest stayed alive.

Lifted from the wikipedia article :-

    Everything is a process.
    Processes are strongly isolated.
    Process creation and destruction is a lightweight operation.
    Message passing is the only way for processes to interact.
    Processes have unique names.
    If you know the name of a process you can send it a message.
    Processes share no resources.
    Error handling is non-local.
    Processes do what they are supposed to do or fail.

I think when you get down to it there isn't really anything you can do in Erlang you couldn't do in another language, at one time Erlang went through C as a build step, it's that it was a fairly radical departure as a solution to a problem at the time (telephony) that also happens to fit a fair few problems we run into on the internet.

I'm not an Erlang/Elixir programmer (so I've no dog in the fight) but I've been fascinated by the language since I read about it in the early 90's in a programming journal, it seemed alien then and it seems alien now (much like APL).

Amongst my programmer friends Elixir seems to be really popular with Ruby programmers (I'm sure there is a reason but I'm not a Ruby programmer either so I couldn't tell you).

⬐ dgllghr

I completely agree. I used to be a big believer in monad based concurrency using Promise/Future/Async/etc. But the simplicity of using preemptive, user-space scheduling has changed my mind. It makes concurrency, especially IO concurrency, cleaner. There are fewer moving parts in your code because the VM is doing a lot of the heavy lifting for you.

⬐ randomstudent

What do Promises/Futures/Async/etc. have to do with monads? Are monads a good abstraction to model those things?

⬐ dmix

They are just a way to wrap up the code/data somewhat similar to how callbacks are used in Javascript async code. And from using Haskell I believe they are an excellent abstraction when doing any async programming, once you wrap your head around them.

Although in terms of concurrency I've found Elixir/Erlang actor-esque process based system with messaging much more intuitive when building complex programs and much simpler to reason about than the various solutions Haskell offered. But I'm also not an expert at Haskell so take that comparison with a grain of salt.

⬐ dgllghr

Many of the actual implementations of these types are not actually monads by the monad laws, but they are monad-like in that they are containers for execution that can be composed with each other.

⬐ arianvanp

Continuations / Promises / Futures form a Monad (https://www.stackage.org/haddock/lts-9.1/transformers-0.5.2....)

A Monad is any data structure with the follwing two methods:

    (>>=) :: m a -> ( a -> m b) -> m b
    pure :: a -> m a

the monadic bind is exactly `andThen` in javascript:

    (>>=) :: m a -> (a -> m b) -> m b
    (>>=) :: Future a -> (a -> Future b) -> Future b
    Future.andThen :: Future a -> (a -> Future b) -> Future b

and the monadic `pure` is exactly the `Future` constructor:

    pure :: a -> m a
    pure :: a -> Future a
    Future.always :: a -> Future a

Every Monad is a Functor, so you also get this one for free:

    map :: (a  -> b ) -> m a -> m b
    -- if I know how to convert a's to b's I can convert a future a to a future b
    Future.map :: (a -> b) -> Future a -> Future b

So basically, saying "futures are a monad" gives you all the useful functions that you would expect from a future based API, which is nice. It means you can use all kinds of higher level functions not specific to futures to abstract behaviour:

Like, given a list of element,s and a way to create a future for each element, create a future that returns a list of elements:

    forM :: (Monad m) => Array a -> (a -> m b) -> m (Array b
    Future.forEvery :: Array a -> (a -> Future b) -> Future (Array b)

⬐ devjungle

How do you begin to even read that notation stuff? Do you know of any resources for learning it?

⬐ gamache

That's the Haskell language. There are a lot of "big" concepts in the language itself, compared to just about any other language from the last 50 years that people get paid to write, but the notation isn't hard to straighten out after a few tries. There's a really good intro here: http://learnyouahaskell.com/

⬐ None

None

⬐ jordwest

The notation in the GP is Haskell-ish type notation, which is certainly different to the majority of languages out there today, but it's actually fairly simple (difficult to learn, but simple).

Quick glossary:

    ::      Defines a new function signature. The left hand side is the function name, and the right hand side is the signature.
    a -> b  A function which converts something of type a to type b
    m a     A generic m of type a. In Java/C# this might be written as m<a>. eg, `Array String` means an array of string elements, and might be written in C# as Array<String>.

Types starting with a lowercase letter (m, a, b) generally mean the type is generic - as in the function will take any type.

It might be helpful to define a function you already know:

    string_to_int :: String -> Int

Or, for changing an Array of something to an Array of something else:

   map :: (a -> b) -> Array a -> Array b

Here, we're defining a function that:

   1. Takes a function that converts an 'a' to a 'b' (a -> b)
   2. Takes an array of 'a'
   3. Returns an array of 'b'

Notice that 'a' and 'b' can be anything! Since the first parameter* is a function that handles the conversion from a to b, the map function actually doesn't need to know what type a and b are.

Let's say we pass in the `string_to_int` as the first parameter, now the type checker will actually infer the following function type:

    map :: (String -> Int) -> Array String -> Array Int

* Haskell functions actually only ever have one parameter, it uses Currying to accept multiple arguments: https://en.wikipedia.org/wiki/Currying

⬐ qualitytime

Noted down, thanks for that. Will be handy for future whiteboard interview questions.

⬐ dboreham

Um...you know this is basically threads right?

(not disagreeing, but having watched the past few years as "threads bad, don't know why though..." it is amusing to see thread-style concurrency rediscovered with a new name).

⬐ dgllghr

Great point! However, I've found that the implementations of user space, preemptive threads (UPT) have friendlier APIs than the implementations of kernel space, preemptive threads (KPT). Also, UPT APIs generally come with really nice synchronization primitives (like STM in Haskell) or designs that remove the need for them (like message passing on BEAM). Also, I really like not worrying about creating too many threads and having to use a thread pool because the overhead of UPT is generally so much lower.

⬐ tim333

While it can be a little unclear what people mean, the Wikipedia take on threads is:

"Multiple threads can exist within one process, executing concurrently and sharing resources such as memory"

Whereas Erlang/Elixir processes don't share memory and have their own independent heaps and garbage collection.

Shared memory can lead to complicated effects if two threads try to change the same bit. You don't have that with Erlang processes.

⬐ anko

That is like saying queues are basically the same as lists!

size, scheduling and the lack of shared state add up to vast differences. Also the message parsing primitives are way more lightweight than the thread based equivalents.

⬐ brightball

This quote from Joe Armstrong explains the difference better than I can. There are other factors than just this in play of course.

> [Erlang] is a concurrent language – by that I mean that threads are part of the programming language, they do not belong to the operating system. That's really what's wrong with programming languages like Java and C++. It's threads aren't in the programming language, threads are something in the operating system – and they inherit all the problems that they have in the operating system. One of the problems is granularity of the memory management system. The memory management in the operating system protects whole pages of memory, so the smallest size that a thread can be is the smallest size of a page. That's actually too big.

> If you add more memory to your machine – you have the same number of bits that protects the memory so the granularity of the page tables goes up – you end up using say 64kB for a process you know running in a few hundred bytes.

There’s also “Erlang the Movie”; the designers of Erlang demo some of the qualities of the Erlang system in a delightful way: https://youtu.be/xrIjfIjssLE

"Hello Joe" - Awesome interview opening joke [0] :)

[0] - https://youtu.be/xrIjfIjssLE

⬐ ust

I've just seen the movie after your comments, it was interesting to see that they use emacs (without syntax highlighting, it appears..). OT, but how's vim for coding in erlang, anyone?

⬐ draven

I had to check and according to https://en.wikipedia.org/wiki/GNU_Emacs , font-lock was added in version 19.28 released November 1, 1994. The movie certainly looks like it was recorded in the 80s.

Some people also still use Acme which AFAIK does not have syntax highlighting.

⬐ di4na

Every editors have all that is needed. The community use everything and do not care that much about editor of choice.

⬐ josteink

> it was interesting to see that they use emacs

How so? It's a solid piece of software which has been around since forever (since before Ctrl-C and Ctrl-V conventions ever existed). We're all programmers, and Emacs is all about being a programmer's editor.

If you want to see an Emacs-user out-hipster every single web-developer who thought he was cool when he used HTML for his presentations instead of Powerpoint/Keynote... Then watch this: https://www.youtube.com/watch?v=TMoPuv-xXMM

It's incredibly contrived, and incredibly nerdy, yet this, to me, encapsulates so much about what Emacs is. And I love it :)

⬐ copperx

Wasting time in such contrived approaches that ultimately gain you nothing is part of what Alan Kay talks about.

Programmers have the devious hobby of tackling complexity of their own doing. It isn't praiseworthy, or something to be proud about.

Might be worth watching this first, though:

https://www.youtube.com/watch?v=xrIjfIjssLE

If anyone hasn't seen the original, it's worth a watch.

https://www.youtube.com/watch?v=xrIjfIjssLE

⬐ kazagistar

Dang, they just casually leave a phone call going (through their demo telephony system), then do some apparently unrelated demo where they fix a bug that is causing another part of the system to crash, and then as a big reveal, the phone call they left up is still going untouched.

⬐ rvirding

The best thing that we weren't faking this. We did actually run though the whole sequence as was shown in the movie with having a call going while another part of the crashed and was fixed.

The original “Erlang: The Movie” https://www.youtube.com/watch?v=xrIjfIjssLE (with a good demonstration of what a reliability means)

you might enjoy a comparison between c++ and erlang: http://youtu.be/xrIjfIjssLE?t=1m21s

And if you haven't seen it, here is some classic. “Erlang: the Movie”:

— http://www.youtube.com/watch?v=xrIjfIjssLE

And sequel “Erlang: the Movie II”:

— http://www.youtube.com/watch?v=rRbY3TMUcgQ

Don't think wtf. Just watch.

⬐ silentbicycle

I have a mug etched with a picture from that movie (by way of Learn You Some Erlang For Great Good): https://twitter.com/silentbicycle/status/299278899886579712 :)

"Hello, Joe?"

http://www.youtube.com/watch?v=xrIjfIjssLE

⬐ laumars

Joe Armstrong did help create Erlang with Bjarne Dacker:

Erlang was created at the CSLab by an initial team of Joe Armstrong, Mike Williams and Robert Virding.

http://www.erlang-factory.com/conference/SFBay2010/speakers/...

⬐ peteretep

Unless I'm mistaken, you can see him in the link posted, too, making phone calls to the other developers...

⬐ laumars

Ahhh that's what you meant by your post.

Your original comment was a little cryptic (either that, or I've not had enough coffee today hehe)

⬐ cpt1138

Hard not to equate this with a Monty Python skit. "And now for something completely different...."