Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I fell in love with Erlang

boragonul.com

Post reply on HN
Print view View original

241–250 of 263 posts

Re: How I fell in love with Erlang

#241

Post by jacquesm »

shanemhansen wrote: post #103
jacquesm wrote: post #76

Earlier quoted context omitted.

> Why has no one put microkernels and Erlang into a blender? I know there's QNX, but it's still UNIX, not Erlang. That's a very good question. There are some even lesser known dialects out there that do this but you are going to find it hard to get to the same level of feature completeness that Erlang offers out of the box. QNX and Erlang embody quite a few of the same principles, but QNX really tried hard to do this…

You nerd sniped me a little and I'll admit I'm not 100% sure what a reduction is but I've understood it to be a measurement of work for scheduling purposes. A bit of googling indicates that actually you can use performance monitoring instur to generate an interrupt every n instructions. https://community.intel.com/t5/Software-Tuning-Performance/H... Which is part of the solution. Presumably the remainder of the solut…

Oh that's a really neat find. I'm not sure how 'instructions' map to 'reductions' in the sense that if you stop when a reduction is completed the system is in a fairly well defined state so you can switch context quickly, but when you stop in mid reduction you may have to save a lot more state. The neat thing about the BEAM is that it is effectively a perfect match for Erlang and any tricks like that will almost certainly come with some kind of price tag attached. An interrupt is super expensive compared to a BEAM context switch to another thread of execution, you don't see the kernel at all, it is the perfect balance between cooperative and preemptive multitasking. You can pretend it is the second but under the hood it is the first, the end result is lightning fast context switches.

But: great find, I wasn't aware of this at all and it is definitely an intriguing possibility.

Re: How I fell in love with Erlang

#242

Post by mrkeen »

simoncion wrote: post #146
mrkeen wrote: post #38

Earlier quoted context omitted.

> The author did not say this at all, they barely even touched on capabilities of erlang/OTP. Two separate Erlang nodes. On different machines, different networks, different continents if I wanted. And they could just… talk. No HTTP. No REST API. No serialization headaches. Just message passing. Just actors doing their thing. > Their focus was on the functional syntax of Erlang. They didn't write any Erlang until the…

Right. The author barely touched on the capabilities of Erlang/OTP. That section was pretty much a demo of the syntax and an advertisement of the fact that the language syntax and runtime system makes it trivial to have a distributed program that runs on separate machines. If the author actually talked about the capabilities of Erlang, they would -at minimum- answer the questions that you'd raised, that the return va…

My point is, for an article about functional programming and Erlang, there wasn't any functional programming in Erlang.

The author pivoted from rejecting "change state of X" to advertising "change state of mailbox".

> the return value of both 'ping/1' and 'pong/0' are irrelevant because they are ignored If they were functional, they'd be optimised away by the compiler (for being irrelevant). They only exist for their side effects. Ping and pong are procedures. This is 100% imperative.

Re: How I fell in love with Erlang

#243

Post by SeanDav »

jacquesm wrote: post #85
tommica wrote: post #18

Earlier quoted context omitted.

> Suddenly Erlang made it fun and programming became addictive. I'm saying this with complete sincerity: WHAT IS IT THAT YOU PEOPLE SEE!? What is the fun? What are you addicted to? Typing and seeing the output? Solving a problem? I feel like I am missing out on some amazing life altering experience when I see people state that. The same thing I have with the article - what does it mean to love a programming language?

It's a bit like cutting wood. Cutting wood can feel terrible. You do it every day because you have to. Along the grain, in wet wood, with a handsaw. And then, one day you discover the chainsaw, and the fact that you should cross cut. Suddenly cutting wood no longer feels terrible, it's smooth, stuff works the way you expect. Your chainsaw turns out to have features for all kinds of wood and for many different kinds o…

Until you hit a knot in the wood and get kickback, which leads to exciting times... j/k I get what you are trying to say.

Re: How I fell in love with Erlang

#244

Post by simoncion »

mrkeen wrote: post #242
simoncion wrote: post #146

Earlier quoted context omitted.

Right. The author barely touched on the capabilities of Erlang/OTP. That section was pretty much a demo of the syntax and an advertisement of the fact that the language syntax and runtime system makes it trivial to have a distributed program that runs on separate machines. If the author actually talked about the capabilities of Erlang, they would -at minimum- answer the questions that you'd raised, that the return va…

My point is, for an article about functional programming and Erlang, there wasn't any functional programming in Erlang. The author pivoted from rejecting "change state of X" to advertising "change state of mailbox". > the return value of both 'ping/1' and 'pong/0' are irrelevant because they are ignored If they were functional , they'd be optimised away by the compiler (for being irrelevant). They only exist for thei…

> [ping and pong] only exist for their side effects.

Yes, these are really obviously two functions that exist to mutate state by printing to a console somewhere then communicating with another process.

> If they were functional, they'd be optimised away by the compiler (for being irrelevant).

I'd expect -say- Haskell to not optimize away functions that exist just to print to a console.

So, is your complaint that Erlang is (like Prolog) not a purely functional language, and that the author has asserted that Erlang is a functional language (in the same way that Prolog is) [0] but provided example code that produces side effects?

[0] Be very careful when reading here. I'm fairly aware of just how much Prolog is a functional language.

Re: How I fell in love with Erlang

#245

Post by simoncion »

stevenjgarner wrote: post #131

Took me a long time to figure out what gets lost with Erlang is: a) Ubiquity — everything understands HTTP. Erlang nodes only talk to Erlang (or a compatible runtime) b) Because there are no middleware standards (REST, GraphQL, OAuth, etc.), you must build or integrate your own abstractions c) Giving up infrastructure (reverse proxies, load balancers, CDNs), You handle distribution yourself or through OTP design d) I…

> a) Ubiquity — everything understands HTTP. Erlang nodes only talk to Erlang (or a compatible runtime)

You're sort of confusing the purpose of Erlang distribution, so I would turn this on its head with the following questions:

Do the Python, Ruby, FORTRAN, Lua, etc, etc, runtimes provide built-in, standardized, network-transparent RPC, [0] or do you have to roll your own using some serialization library and network transport library that might not be The Thing that everyone else who decided to solve the problem uses? Do note that rolling your own thing that is the "obvious" thing to do is still rolling your own thing! Someone else might make a totally reasonable choice that makes their hand-rolled thing incompatible with yours!

I think this confusion influences the rest of your list. Erlang has several HTTP servers written for it [1], but it is not -itself- an HTTP server, nor does it use HTTP for its network-transparent RPC, service discovery, and monitoring protocol.

> The author's insight "No HTTP. No REST API", reframes the reality...

With respect, you're confused. The authors insight can be reworded as

> I can do RPC with no hassle. With just three symbols, I say 'Send this data over there.' and the runtime handles it entirely automatically, regardless of whether 'over there' is running in the same Erlang VM as the calling code or on a computer on the other side of the globe. With equivalent ease, I can say 'When someone sends me data, call this function with the transmitted data.' and -again- the runtime handles the messy details.

When I was first introduced to Erlang's distribution system, it also took me quite a while to detangle it from what I knew about the Web World. Reading through the 'Distribunomicon' chapter of Learn You Some Erlang [2] helped to knock those erroneous associations out of my head.

[0] ...let's not even talk about the service discovery and process/node monitoring features...

[1] Some of which totally do support middleware gunk.

[2] If you've not read LYSE, do note that it was first published in 2010 (and got an update in 2014 to cover the then-very-new Map datatype). Because the folks who work on Erlang tend to think that keeping old code working is a very virtuous thing, the information in it is still very useful and relevant. However, it's possible that improvements to Erlang have made some of the warnings contained within irrelevant in the intervening years.

Re: How I fell in love with Erlang

#246

Post by simoncion »

sodapopcan wrote: post #189
simoncion wrote: post #177

Earlier quoted context omitted.

To put it another way: anything you can express with iteration, you can express with recursion (just as long as you don't run out of call stack). Once you get it, it's obvious, but if you're not already familiar with the notion, the understanding can be pretty amazing.

> just as long as you don't run out of call stack And with tail-call you don't even need to worry about that :)

Of course, that assumes that you write your functions so that they can be converted into iteration!

Did you know that some C/C++ compilers will do tail-call -er- optimization? I learned this quite a while ago, so I'd expect every major C/C++ compiler to do it by now, but I was pretty impressed at the time.

Re: How I fell in love with Erlang

#247

Post by tome »

mrkeen wrote: post #242
simoncion wrote: post #146

Earlier quoted context omitted.

Right. The author barely touched on the capabilities of Erlang/OTP. That section was pretty much a demo of the syntax and an advertisement of the fact that the language syntax and runtime system makes it trivial to have a distributed program that runs on separate machines. If the author actually talked about the capabilities of Erlang, they would -at minimum- answer the questions that you'd raised, that the return va…

My point is, for an article about functional programming and Erlang, there wasn't any functional programming in Erlang. The author pivoted from rejecting "change state of X" to advertising "change state of mailbox". > the return value of both 'ping/1' and 'pong/0' are irrelevant because they are ignored If they were functional , they'd be optimised away by the compiler (for being irrelevant). They only exist for thei…

> there wasn't any functional programming ...This is 100% imperative

What distinction are you drawing between functional and imperative programming? This is not a trick question. Simon Peyton Jones has described Haskell as "the world's finest imperative programming language", and one way of interpreting my Haskell effect system Bluefin[1] is "purely functional imperative programming". I don't think functional and imperative are are mutually exclusive, in fact, I don't think they're even at odds. I think they're both at their best when combined.

[1] https://hackage.haskell.org/package/bluefin

Re: How I fell in love with Erlang

#248

Post by immibis »

__turbobrew__ wrote: post #230
immibis wrote: post #217

Earlier quoted context omitted.

There's probably not as much advantage to HTTP as you think. The simplest RPC protocol is where you connect to a TCP socket, send a newline-terminated string per request, and get a similar response back. You don't need HTTP for that - you might still want to use JSON. What does HTTP give you in addition? It's presumably still not something Erlang directly supports.

> What does HTTP give you in addition? HTTP2 offers lots of nice features like stream multiplexing and socket re-use. I guess also encoding standards? Less of an issue in this day and age where everything can work with utf-8. Presumably the fact that you can interoperate with other systems not part of BEAM is desirable too.

You also get this from newline-delimited-request-response. Multiplexing: send an ID with each request, and return the same ID in the response. Socket re-use: just keep reading until the client closes the socket. Encoding standards: you're the one designing it, so just say it's always UTF-8.

Lower layers of the protocol stack ossify faster in our minds than in reality.

Re: How I fell in love with Erlang

#249

Post by rramadass »

rramadass wrote: post #234
sph wrote: post #29

Earlier quoted context omitted.

I don't think it's cycles, more like newcomers rediscovering the future. I've learned Elixir in 2016 after a lull in my interest in programming languages, and 9 years later it's still my favourite environment by a country mile. It's not the language per se, but the BEAM, the actor model, the immutability — just makes sense, and doing things the C/Rust/Javascript/Python way is like building bridges out of cardboard. F…

> Why has no one put microkernels and Erlang into a blender? Peer Stritzinger ( https://stritzinger.com/ ) the guy behind the GRiSP project ( https://www.grisp.org/ ) has integrated Erlang + RTEMS ( https://www.rtems.org/ ) for the embedded GRiSP Nano HW ( https://www.grisp.org/hardware#grisp-nano-details-section and https://www.grisp.org/blog/posts/2025-06-11-grisp-nano-codeb... ) His HN account with some technical…

Addendum to above:

I just remembered Kry10 OS which runs Erlang/Elixir on seL4 microkernel - https://www.kry10.com/ Checkout the technical overview paper at https://www.kry10.com/get-started

Some excellent videos linked to from https://elixirforum.com/t/kry10-a-robust-and-secure-os-for-t...

Kry10 Secure Platform - https://www.youtube.com/watch?v=YG5BaoB24eA

The Kry10 Operating System: Security and the BEAM - https://www.youtube.com/watch?v=0ncI0I5uxJ4

seL4 and BEAM, a match made in Erlang - https://www.youtube.com/watch?v=owmvgUwBlJ0

Re: How I fell in love with Erlang

#250

Post by hasanhaja »

bora_g wrote: post #153

Author here, I'm really surprised to see the story reached top 3. All of them is true and thanks to Erlang still surprises me. My current stack is Elixir + Rustler on server and Rust + Wasm at frontend. Thanks for reading :)

Thank you so much for the write up! I've been avoiding processes for some reason while I've been learning Elixir and this post pushed me to play with it today. And I started in Erlang and then managed to translate it to Elixir successfully!

I ran into this issue and I'm not sure if it's just a me thing.

When sending the message from the Pong REPL, the following didn't work for me:

```erl {ping, 'ping@localhost'} ! {pong, self()}. ```

When I checked, the PID of `self()` is different to the PID of the registered `pong` process. I needed to change it to the following:

```erl {ping, 'ping@localhost'} ! {pong, whereis(pong)}. ```

This sends the correct PID to the Ping process and we have an infinite loop counting up.

Post reply on HN