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

The BEAM Has Spoiled Me

gvaughn.github.io

Post reply on HN
Print view View original

31–40 of 88 posts

Re: The BEAM Has Spoiled Me

#31

Post by OkayPhysicist »

hazz99 wrote: post #5
grantjpowell wrote: post #2

The BEAM is great, but the Elixir language itself is really what spoiled me. After having written ruby for years, I really enjoy what the Elixir language has to offer. Pattern matching[0] and the pipe operator[1] eliminate a ton of intermediate variables. Functional programming took a while to get used to, but I'm really starting to like thinking immutably. Now that I'm more advanced in the language, I'm starting to…

I love Erlang/Elixir and want to use it more, but I just don’t have any good use cases for it! I don’t often make big concurrent back ends - maybe REST APIs, but that didn’t seem easy last time I tried.

Phoenix takes a little bit of reading to figure out (though the documentation is brilliant, and really easy to read). Once you understand how it works, though, creating an API is extremely straightforward. It's amazing.

Re: The BEAM Has Spoiled Me

#32

Post by hazz99 »

OkayPhysicist wrote: post #31
hazz99 wrote: post #5

Earlier quoted context omitted.

I love Erlang/Elixir and want to use it more, but I just don’t have any good use cases for it! I don’t often make big concurrent back ends - maybe REST APIs, but that didn’t seem easy last time I tried.

Phoenix takes a little bit of reading to figure out (though the documentation is brilliant, and really easy to read). Once you understand how it works, though, creating an API is extremely straightforward. It's amazing.

I just couldn’t get past ecto! It never seemed to “click” for me. Maybe I need to go back and learn it more in-depth, it sounds like it’ll be fantastic once I get the hang of it.

Re: The BEAM Has Spoiled Me

#33

Post by cuddlecake »

amgreg wrote: post #15

> Some teams are happy to use Elixir to write web applications, to fit it into their pre-existing microservice deployment model. I urge developers to reach for those bigger thoughts that fault tolerant lighweight processes enable. You can consider each process a logical microservice, but you don’t need the friction of deploying it separately, and serializing to/from json, and containers, and orchestration, and distri…

I think the author's use of the microservices is unfortunate and confusing.

With the BEAM, it is easy to create fully independent process trees. The architecture enables it. In fact, you can pull in dependencies and add them as "OTP applications" (which is in essence a fully independent process tree, doing its thing.)

The BEAM lends itself very well to structuring parts of your application as independently supervised process trees.

This is similar to microservices, where each microservice represents a fully independent process tree, with which you can only communicate via well-defined interfaces.

As I said, the author's comparison to Microservices is very unfortunate.

Re: The BEAM Has Spoiled Me

#34

Post by OkayPhysicist »

siscia wrote: post #23

I use to make the same mistake of the author. It is not the BEAM, it is the architecture that the BEAM force upon you to spoils it (the author). There are deeper points in what the author says. Even if you let a process crash in the BEAM, but you don't leave the system in a consistent, recoverable state, the BEAM is not going to help you. Once you realize this, and have a way to apply back pressure, you can get a lot…

Sure you CAN, but Erlang/Elixir makes it really, really easy. The primary purpose of a programming language is establish pretty paths to solve problems. When you're fighting those pretty paths, your code gets bogged down with cruft and workarounds. When you're writing code with the pretty path, your code becomes clean, elegant, and painless.

To use a specific example, look at establishing independent processes that communicate through message passing. In Erlang/Elixir, it's trivial. 2 callback implementations and you've got yourself a GenServer running independently and expecting messages. A quick function to wrap the message call, and boom, you're off to the races. You want supervision? Bam, 2 short lines of code.

If you try to do that in, say, Python, you'll be bogged down by a language structure that is, by design, encouraging of serial code.

Re: The BEAM Has Spoiled Me

#35

Post by cuddlecake »

ridiculous_fish wrote: post #19

How does BEAM handle system calls? If I have a million BEAM processes and each one calls stat(), what happens?

What do you expect to happen in other languages, when your program makes a million calls to `stat()`? Is that something that happens often? What kind of application needs that? Is there a language that solves this neatly?

(I'm genuinely curious, independent of my newbie elixir evangelism)

Re: The BEAM Has Spoiled Me

#36

Post by jspash »

jefflombardjr wrote: post #3
grantjpowell wrote: post #2

The BEAM is great, but the Elixir language itself is really what spoiled me. After having written ruby for years, I really enjoy what the Elixir language has to offer. Pattern matching[0] and the pipe operator[1] eliminate a ton of intermediate variables. Functional programming took a while to get used to, but I'm really starting to like thinking immutably. Now that I'm more advanced in the language, I'm starting to…

Can you recommend any learning materials that were particularly useful to you?

Without a doubt, this was one of the best courses I've done in any language. https://www.udemy.com/course/the-complete-elixir-and-phoenix...

Re: The BEAM Has Spoiled Me

#37

Post by m12k »

busterarm wrote: post #25
siscia wrote: post #21

Earlier quoted context omitted.

The BEAM is not better. It is DIFFERENT. You can read as much as you want about the topic, but my suggestion would be to go and create something with it. You need to feel the difference yourself. If you got the time, I really suggest to try the BEAM, you will have fun and you will approach software differently (and this time also better) after you internalise the BEAM way.

There's one respect where I would say it is just _better_, in that if you want your processes to be message-passing actors, you don't have a lot of great options coming from other languages whereas in Erlang that's a fundamental design choice. "Better" is a matter of what types of systems you're trying to build.

Off the top of my head, Go and goroutines are built around message-passing as well. And Scala/Java with Akka seems pretty well-established at this point too - although it'll likely never have as broad support as something built into the language like Elixir and Go has.

Re: The BEAM Has Spoiled Me

#38

Post by dnautics »

hazz99 wrote: post #32
OkayPhysicist wrote: post #31

Earlier quoted context omitted.

Phoenix takes a little bit of reading to figure out (though the documentation is brilliant, and really easy to read). Once you understand how it works, though, creating an API is extremely straightforward. It's amazing.

I just couldn’t get past ecto! It never seemed to “click” for me. Maybe I need to go back and learn it more in-depth, it sounds like it’ll be fantastic once I get the hang of it.

It's definitely not an orm, as it was stolen from c# linq.

Imo this is actually much better than an orm because it really hits home that the data in memory are stale as soon as you receive them because database transactions are explicit, and not hidden behind getters and setters.

ORMs can get you into trouble because they try really hard to hide the problem of distributed state and sources of truth.

Re: The BEAM Has Spoiled Me

#39

Post by dnautics »

m12k wrote: post #37
busterarm wrote: post #25

Earlier quoted context omitted.

There's one respect where I would say it is just _better_, in that if you want your processes to be message-passing actors, you don't have a lot of great options coming from other languages whereas in Erlang that's a fundamental design choice. "Better" is a matter of what types of systems you're trying to build.

Off the top of my head, Go and goroutines are built around message-passing as well. And Scala/Java with Akka seems pretty well-established at this point too - although it'll likely never have as broad support as something built into the language like Elixir and Go has.

None of those other systems have solid failure-domain oriented programming baked in. Let's say there's a netsplit and you want your connection to bring down two other processes that depend on it, self-heal when the netsplit is resolved, and not have any other resources associated with the process leak (memory, file descriptors, resource pools, database connections, etc). This is like maybe two lines of elixir/erlang.

Re: The BEAM Has Spoiled Me

#40

Post by dnautics »

siscia wrote: post #23

I use to make the same mistake of the author. It is not the BEAM, it is the architecture that the BEAM force upon you to spoils it (the author). There are deeper points in what the author says. Even if you let a process crash in the BEAM, but you don't leave the system in a consistent, recoverable state, the BEAM is not going to help you. Once you realize this, and have a way to apply back pressure, you can get a lot…

> Even if you let a process crash in the BEAM, but you don't leave the system in a consistent, recoverable state, the BEAM is not going to help you.

The thing is, the default in the beam is that on crash you are in a recoverable state (file descriptors are closed, memory is freed). You have to work hard to not have that be the situation.

Other languages do not do this for you, and make you manage state back to recoverability with potentially confusing unwinding of stack state.

Post reply on HN