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

141–150 of 263 posts

Re: How I fell in love with Erlang

#141

Post by waynesonfire »

humamf wrote: post #125
sbuttgereit wrote: post #111

Earlier quoted context omitted.

I do a lot of Elixir programming, which is different and not at the same time :-) . What I find is that it takes me longer to write the initial code than I might in, say, JavaScript, but that the refactoring and ongoing maintenance of code is significantly faster. This is because I think the functional & actor paradigms force you to think harder upfront, but once those decisions are made are easier to manipulate. For…

Thats interesting. In my case, elixir does take a longer time. Probably because i dont get used to or just use it not as frequent as other languange. Would you mind telling me your elxir program about? Is it a webapps or something similar?

One of the features I really like about the BEAM is that it solves the problem of organizing the topology of the applications I build. It's unlikely you're even close to doing this in other languages / frameworks.

The supervisor tree is one of the killer-app features of BEAM. I hit the benefits of this ALL the time. I notice how it keeps getting solved over and over again in unique ways that are half-baked. In some ways, this quote is what I'm hinting at, except, things don't even have to be concurrent. That's just a cherry-on-top.

"Virding's First Rule of Programming: Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang."

I'd also argue that "sufficiently complicated" bar isn't very high.

Re: How I fell in love with Erlang

#142

Post by quaunaut »

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…

This reads as if it isn't trivial to have an HTTP API for your public API in Erlang/Elixir, which is weird. Sure there isn't an included HTTP API for Erlang processes, but why exactly would you want one? They're not for the public internet, as their an implementation detail of your system. The majority of what they're capable of just isn't relevant to the public internet.

Re: How I fell in love with Erlang

#143

Post by jrm4 »

munificent wrote: post #129
mock-possum wrote: post #97

Earlier quoted context omitted.

That’s funny, because to me, it was always immediately obvious that once that line runs, then it must be true - once that line runs, x is now equal to whatever it was before, + 1. It’s the price opposite of the lie, it’s the literal definition of truth, in the sense that what is true is set by that line. Programming is telling things to the computer, and in this case, you’re telling it what x is. Whatever you tell a…

> once that line runs This is the key point. Some people have a mental model that algebraic syntax is describing a set of immutable properties. You are defining things and giving them names, but not changing anything. There is no notion of time or sequence, because the universe is unchanging anyway. All you're doing is elucidating it. Then there is a model where you are molding the state of a computer one imperative…

It's hard for me to not suggest though that, essentially -- the math people are "right." Which is to say, "=" meant what it meant for 400 years, and then computers come along and redefine it to be an action verb and not an identity. And I think it's fair to consider that a mistake.

Re: How I fell in love with Erlang

#144

Post by toast0 »

zwnow wrote: post #54
marceldegraaf wrote: post #9

Earlier quoted context omitted.

It's funny that you mention this, and it made me take some time to appreciate I've been working with Elixir full-time for almost 10 years now, and the entire experience has been so... stable. There's been little drama, the language is relatively stable, the community has always been there when you need them but aren't too pushy and flashy. It all feels mature and – in the best possible way – boring, and that is aweso…

For me it took a tremendous amount of work to somewhat understand the OTP stuff though. Its one of those languages where I can never be confident about my implementations, and thankfully it has features to check whether you have stale processes or whatever. A language I am humbled by whenever I use it.

Here's a trick to confidence in a BEAM system. If you get good at hot loading, you significantly reduce the cost of deployment, and you don't need as much pre-push confidence. You can do things like "I think this works, and if it crashes, I'll revert or fix forward right away" that just aren't a good fit for a more common deployment pattern where you build the software, then build a container, then start new instances, then move traffic, etc.

Of course, there are some changes that you need confidence in before you push, but for lots of things, a bit crashy as an intermediate step is acceptable.

As for understanding the OTP stuff, I think you have to be willing to look at their code. Most of it fits into the 'as simple as possible' mold, although there's some places where the use case is complex and it shows in the code, or performance needs trumped simplicity.

There's also a lot of implicitness for interaction between processes. That takes a bit of getting used to, but I try to just mentally model each process in isolation: what does it do when it receives a message, does that make sense, does it need to change; and not worry about the sender at that time. Typically, when every process is individually correct, the whole system is correct; of course, if that always worked, distributed systems would be very boring and they're not.

Re: How I fell in love with Erlang

#146

Post by simoncion »

mrkeen wrote: post #38
bargainbin wrote: post #15

Earlier quoted context omitted.

> (mailbox = mailbox + message) is so simple! The author did not say this at all, they barely even touched on capabilities of erlang/OTP. Their focus was on the functional syntax of Erlang. > For instance, in head(sort(list)), will the whole list be sorted, or will the smallest element be returned? Your point isn’t clear. The functions have a clear nested call sequence, take a list, sort it, get the head. Also how is…

> 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 value of both 'ping/1' and 'pong/0' are irrelevant because they are ignored, and that the range of 'ping/1' is not only infinite, it can accept any type for which it's legal to '+ 1'. [0] They would have also mentioned why they call 'ping' and 'pong' at the end of the respective function, the reason for which is kinda strange if you're coming from a more-normal language.

One can add annotations to functions that indicate what their input and output types are, and if you do a little bit of work, you can also indicate valid ranges/values for those types. These annotations are not checked at runtime, but can be checked by tools such as dialyzer. But, because this blog post barely even touched on Erlang/OTP's capabilities, none of that was mentioned.

[0] I think the valid types are only integers and floats, but definitely don't bet your career on that information.

Re: How I fell in love with Erlang

#147

Post by nakamoto_damacy »

calvinmorrison wrote: post #113
nakamoto_damacy wrote: post #50

Will it ever run in WASM? EDIT: there is Lumen, but not sure if it's stalled or still going.

Usage It is not immediately clear what the intended usage pattern for Lumen and WebAssembly is. Pros and Cons Things we like: The idea of having both runtime and code compile is cool Things we’re not big fans of: We could not immediately figure out exactly how Lumen works, and builds appear to be failing The project might be stalled or unmaintained. It has not been updated in over a year.

WebAssembly’s goal is to be a “portable execution layer” — an OS abstraction. If WASM becomes the standard runtime across browsers, servers, and edge networks, something still has to orchestrate thousands of concurrent tasks, message queues, supervisors, restarts, etc.

Erlang/OTP already solves that — beautifully.

So, the motivation is:

“What if BEAM’s concurrency runtime could itself be compiled to WebAssembly — and become the actor system of the WebAssembly world?”

That’s why projects like Firefly and Lumen are interesting: they’re exploring whether Erlang’s runtime model can become part of the WASM ecosystem — just like how Go and Rust shaped the serverless world.

Re: How I fell in love with Erlang

#148

Post by isaacremuant »

jasperry wrote: post #105
donatj wrote: post #22

> X equals X plus one? That’s not math. That’s a lie. That's really interesting... My wife, who has no real mathematical background had the EXACT same reaction when I was trying to teach her some simple programming. I tried to explain that equals in that context was more of a storage operator than a statement that said line is true. She found it very frustrating and we gave up on the endeavor shortly thereafter. I've…

Am I wrong to be skeptical that this was a thought author had at 8 years old? I don't doubt that 8-year-olds can learn programming and advanced math, but even the brightest 8-year-old would still be in the "sponge" stage. It's hard to believe they would have a sufficiently fixed idea about algebra to be troubled that X = X + 1 is "wrong".

It's a common Tactic to pretend children are some sort of tabula rasa full of innocent wisdom that can be use to prove points.

It's ridiculous, usually fake and hide the biases of those who nurtured them to believe whatever they believe, even if it's by pure imitation.

So you're absolutely right to call BS.

Re: How I fell in love with Erlang

#149

Post by gf000 »

jacquesm wrote: post #91
dzonga wrote: post #90

Earlier quoted context omitted.

> want some immutable data structures and functions operating on them. Clojure has that for you. plus its jvm which means for your desktop use cases it works. hell with graalvm can be ported to native.

I used to think that Clojure was going to be the first FP language that was going to go mainstream but it seems to have fizzled. What went wrong?

> What went wrong?

Well, we have FP at home.

It just got ingrained into pretty much every mainstream language, and most [1] of the wins can be had even when it's applied to certain parts of the code base only. Like, Java has immutable data classes (records), ADTs with pattern matching, etc.

As much as I like Clojure, I just don't think Lisps can ever become too mainstream, their readability simply repels too many people (and even though I am okay with reading it, I do think it's less readable than an equivalent Java-style code would be).

[1]: I would even argue that a properly mixed pure and (locally) side-effecting code is the happy ground, as they strengthen each other

Re: How I fell in love with Erlang

#150

Post by dzonga »

skydhash wrote: post #96
jacquesm wrote: post #91

Earlier quoted context omitted.

I used to think that Clojure was going to be the first FP language that was going to go mainstream but it seems to have fizzled. What went wrong?

FP language is very hard on novice programmers. You can write thousands of lines of bad javascript/java/python code, but you won’t write ten in FP without the whole thing blowing up. And then there’s the whole evaluation instead of instructions. With FP, you’re always thinking recursively. With imperative, you can coast on a line by line understanding.

yeah - without an easy ramp up for beginners most languages / frameworks die.

I wish most language / framework designers knew that part.

again - another point why not hiring junior developers cz A.I or outsourcing those will cause catastrophic effects in the future.

Post reply on HN