Live data from Hacker News

How I fell in love with Erlang

boragonul.com

221–230 of 263 posts

Re: How I fell in love with Erlang

#221
post #100
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…

Lets count the number of comercial sucesful released games that don't use mutability or object orientation.... I can't find any.

Leisure Suit Larry

Re: How I fell in love with Erlang

#222
post #81

If you like Erlang, I recommend reading Making Reliable Distributed Systems in the Presence of Software Errors by Joe Armstrong: https://erlang.org/download/armstrong_thesis_2003.pdf His PhD thesis explains the thinking behind Erlang, especially how it handles failures, message passing, and concurrency. It was last updated in 2003, 22 years ago, time really flies!

Thank you for this, I'm unlikely to ever touch Erlang but looks like a fascinating read nonetheless.

It is a fantastic read. I find myself quoting section 5.3.1 on Well-Behaved Functions (WBFs) quite often, especially rule 2: "If the specification doesn’t say what to do raise an exception."

This really helps systems from muddling along into bizarre states, where things are going awry and nobody knows why.

Re: How I fell in love with Erlang

#224

It's funny, because I find Erlang to be one of the least accessible languages I've ever tried (and my entry into this world of digital wonders was thru disassembling cracktros on a M68k, before internet, in a then-foreign language). That said, the metaphors are so elegant, the key concepts so well chosen -- yes, the initial onramp may be a cognitive slog, but it's well worth it. It makes everything downstream so much…

[deleted]

Re: How I fell in love with Erlang

#225
post #18

I can totally relate to this. Programming in Erlang felt so natural compared to the knots I was twisting myself into writing C++. I was churning out C++ code, but wasn't having fun. Suddenly Erlang made it fun and programming became addictive.

> 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?

[deleted]

Re: How I fell in love with Erlang

#226

The only thing holding me back from Erlang is the lack of type checking. Convince me?

You might like https://gleam.run/ , another BEAM language but with type-checking. https://tour.gleam.run/basics/type-checking/

I have checked out Gleam and yes it does look delightful. Function captures are a really cool idea.

Re: How I fell in love with Erlang

#227
post #18

I can totally relate to this. Programming in Erlang felt so natural compared to the knots I was twisting myself into writing C++. I was churning out C++ code, but wasn't having fun. Suddenly Erlang made it fun and programming became addictive.

> 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?

The ability to load recompiled code on running processes makes it possible to change live services on the fly. I worked for a low budget mobile operator in SE-Asia where there were no test platforms, and every change was on the live servers. Erlang made changes fast, as small changes were trivial, while large changes were broken down into small changes, implemented individually, and tested. Rolling back was fast, as I kept the original code before modifying. No convoluted build structures, and praying the rollout to production doesn't throw unexpected errors.

Programming languages stress reusable code, where you get reusable processes (eg interface to the SMSC)in Erlang, which you would need messaging servers in other languages.

Re: How I fell in love with Erlang

#228

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…

This is such a conflicting comment for me because I agree with so much but also have so many quibbles. That said I think that the other comments cover most things, I'll just comment on b: I don't think this is a problem that a language should solve or needs to solve, since there is a new flavor of the week of network protocols every few years. off the top of my head

- REST (mentioned, but what kind of REST? Rails style REST? Just plain http resource endpoints? - GraphQL (mentioned) - gRPC - SOAP - JSON-RPC - Thrift - CGI (ok not really in the same category as the above) - Some weird adhoc thing someone created at 3am for "efficiency"

I'm actually fine with most languages deferring to their respective communities, maybe building on core libs like https://www.erlang.org/docs/17/apps/inets/http_client to handle the transport layer.

As an aside, funnily enough you can get JVM BEAM interop via https://www.erlang.org/doc/apps/jinterface/jinterface_users_... I don't necessarily recommend it but it's possible

Re: How I fell in love with Erlang

#229
post #178

Earlier quoted context omitted.

I learned to program in the 8 bit era, initially in BASIC on the TRS 80, then later assembly on the KIM-1 and then the 6809 based Dragon 32 (CoCo clone), which for the first time felt like a real computer. After that the BBC Micro and then the ARM, and eventually PCs. Those first years were a real slog. I wanted to understand this stuff so much but it just did not click. I actually remember when it did, it was like a…

Boy can I confirm that happening to find the right book back then was absolute key. And they were so expensive! Never really bought one. These days it's almost painful to come across great books that would have been so awesome to have in like 1984.

Another series that really helped me was Leventhal's assembly language series. The problems in the books were relatively simple but they gave you a hold on one CPU if you already knew something about another and they served as instruction set reference as well (which were ridiculously hard to get here in Europe, and I don't mean those little cards but the full data sheets).

Between that and a book on parsing I managed to cobble together an assembler and an editor together with a friend.

Oh, and in the list of machines I forgot the ST, the first machine that I had with a megabyte of RAM.

Re: How I fell in love with Erlang

#230

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…

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.

Post reply on HN