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

21–30 of 88 posts

Re: The BEAM Has Spoiled Me

#21

Post by siscia »

QuadrupleA wrote: post #8

Article piqued my interest, but also left me scratching my head a bit - everything mentioned is kinda vague / abstract. Elixir/BEAM are "better" but better than what? Curious the author's prior language experience. What's he developing with it exactly? Native apps? Web stuff? Or just learning / experimenting? Didn't really understand how the Elixir / BEAM approach is different from typical threads, OS processes, or a…

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.

Re: The BEAM Has Spoiled Me

#22

Post by [deleted] »

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…

[deleted]

Re: The BEAM Has Spoiled Me

#23

Post by siscia »

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 of the benefits of the BEAM in any language. (Not all, being a VM carefully tuned and design for this pattern still means something, but still.)

When you realise that it is so much simpler to leave the system in a consistent state and program very very aggressively, following only the happy path without worrying about errors, you can apply the same pattern every where. Of course within reason that perform can be impacted.

My takeaway is that the BEAM (and the community around it) force upon you a very particular style of programming, and most of the benefits comes from this style, not from the BEAM itself. You can apply the same style in any programming language.

Re: The BEAM Has Spoiled Me

#24

Post by busterarm »

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…

The problem there is that your coworkers working in those languages who don't have Erlang/Elixir experience have not internalized those lessons yet and they're not going to understand why you're doing what you're doing when they review your code.

Edit: I remember an interview that I had once with a team that was trying to bring on a senior to improve their PHP code and they were really unused to the code style I used to solve their problem. Their main issue was the way wrote their code duplicated most of the (very large) request data unnecessarily many times and forced PHP to add more chunks of RAM several times as it handled the request. My code cut all of that fat, but because they didn't understand that's what their problem was they wrote it off as "this guy doesn't know how to code". They didn't even ask and I was glad to not move forward, ultimately.

Re: The BEAM Has Spoiled Me

#25

Post by busterarm »

siscia wrote: post #21
QuadrupleA wrote: post #8

Article piqued my interest, but also left me scratching my head a bit - everything mentioned is kinda vague / abstract. Elixir/BEAM are "better" but better than what? Curious the author's prior language experience. What's he developing with it exactly? Native apps? Web stuff? Or just learning / experimenting? Didn't really understand how the Elixir / BEAM approach is different from typical threads, OS processes, or a…

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.

Re: The BEAM Has Spoiled Me

#26

Post by sergiotapia »

Been programming in Elixir for years now, I'd say 19 out of 20 engineers I've spoken to don't really leverage BEAM.

There's a significant gap between "I write Elixir" and "I leverage BEAM". I'm in the former camp _still_. I just can't find the time/opportunity to dive in and use it to my advantage.

Testament to how performant and easy it is to get things up and running in Phoenix I guess. I believe once this secret sauce is spread far and wide, we'll see uptake in Elixir the likes of which the world has never seen the likes of which.

Re: The BEAM Has Spoiled Me

#28

Post by conradfr »

QuadrupleA wrote: post #8

Article piqued my interest, but also left me scratching my head a bit - everything mentioned is kinda vague / abstract. Elixir/BEAM are "better" but better than what? Curious the author's prior language experience. What's he developing with it exactly? Native apps? Web stuff? Or just learning / experimenting? Didn't really understand how the Elixir / BEAM approach is different from typical threads, OS processes, or a…

I agree with you. Something like https://ferd.ca/the-zen-of-erlang.html may be a more complete picture.

Re: The BEAM Has Spoiled Me

#29

Post by ekimekim »

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?

I can't speak directly for BEAM but in most languages with built-in green threads (like BEAM's processes), one of two things happens:

1. If the call is a short, syncronous operation (like stat() (well, mostly), open(), getpid()), it just calls it directly in your green thread. It occupies the entire OS-level thread while it runs.

2. For long, blocking operations (eg. nanosleep(), recv(), maybe read() depending on the nature of the fd), the runtime will translate your blocking call into a callback in the main event loop, informing your green thread when data is available to read, or your timer has expired, etc. Only once the runtime knows your operation will return immediately will it actually do the call. In the meantime this frees the OS thread to run a different green thread.

Re: The BEAM Has Spoiled Me

#30

Post by OkayPhysicist »

Kaze404 wrote: post #4
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…

The killer feature for me was the documentation. I got thrown into an Elixir application that uses Ecto and Phoenix and literally everything I ever had to do was documented and explained in Hexdocs.

Seriously, the Elixir documentation should be considered the gold standard. Almost everything is documented with exactly what kind of situations the library/module/function should be used for, combined with illustrative examples showing how it should be used.
Post reply on HN