3 ms·

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 deep

by siscia 6y ago

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.

busterarm 6y ago
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.
- tluyben2 6y ago
  This is a problem with 'theoretical' (books/uni 'experience') and 'IBM thinking' (people are more expensive than adding more machines, so always optimize for using less people time; just add machines... says the hardware (and per core software license) vendor. Amazon AWS agrees!) people is that they lack the real life experience where things do not fit in 'best practices' (as in design patterns) or green field architectures from books/tutorials if you don't want to scale up to 1000 nodes for 100.000 users. Optimizing this (so you can run those 100.000 on 1 node, but let's say 2 for failover) might not result in code which people might find 'understandable' from their point of view. A lot of people with even years of experience, work in a kind of 'process' way; stacking up code the way they have learned and handle every case as the same case with 'somewhat different logic'. They might not understand your code or they might understand it but think it's not adhering to proper best practices and standards. Their loss.
  - busterarm 6y ago
    I also think that while these engineers all went to schools where they got both high level and low level programming under their belts, not enough of them really made the connection to understand what their code actually makes the computer do, aside from in the theoretical sense (Big O). We're not really training enough truly full-stack engineers.
    - hinkley 6y ago
      I walked out of college having made a game of one-upmanship with a friend (easy CS homework days, we’d compete against each other over runtime or algorithms), onto a project whose UI was so slow you could watch the screen paint itself. It was so bad I was ashamed to be associated with the project, but I moved a long way so I stuck it out for a bit, until it was respectable. I think I learned as much about performance tuning in the next six months as most people do in their entire careers. A couple jobs later and I could write a few chapters of an advanced book on performance analysis (in particular perf logs tend to hide critical info in plain sight). We mostly just don’t care, and too many of us have honed or at least mislearned excuses for our behavior that business folks have no way to talk us out of. Most vexing for me is when customers threaten to leave over performance and the senior staff pull up some graphs that say we have done all we can. It’s fairly straightforward to climb the ranks on such a project by proving them wrong. These sorts often leave 2-3x (that I know how to find, who knows what he real number is) on the table, which is often enough to satisfy the customer. It’s often hard work but there’s nothing magic about it.
OkayPhysicist 6y ago
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.
dnautics 6y ago
> 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.

by siscia 6y ago

busterarm 6y ago

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.

tluyben2 6y ago
This is a problem with 'theoretical' (books/uni 'experience') and 'IBM thinking' (people are more expensive than adding more machines, so always optimize for using less people time; just add machines... says the hardware (and per core software license) vendor. Amazon AWS agrees!) people is that they lack the real life experience where things do not fit in 'best practices' (as in design patterns) or green field architectures from books/tutorials if you don't want to scale up to 1000 nodes for 100.000 users. Optimizing this (so you can run those 100.000 on 1 node, but let's say 2 for failover) might not result in code which people might find 'understandable' from their point of view. A lot of people with even years of experience, work in a kind of 'process' way; stacking up code the way they have learned and handle every case as the same case with 'somewhat different logic'. They might not understand your code or they might understand it but think it's not adhering to proper best practices and standards. Their loss.
- busterarm 6y ago
  I also think that while these engineers all went to schools where they got both high level and low level programming under their belts, not enough of them really made the connection to understand what their code actually makes the computer do, aside from in the theoretical sense (Big O). We're not really training enough truly full-stack engineers.
  - hinkley 6y ago
    I walked out of college having made a game of one-upmanship with a friend (easy CS homework days, we’d compete against each other over runtime or algorithms), onto a project whose UI was so slow you could watch the screen paint itself. It was so bad I was ashamed to be associated with the project, but I moved a long way so I stuck it out for a bit, until it was respectable. I think I learned as much about performance tuning in the next six months as most people do in their entire careers. A couple jobs later and I could write a few chapters of an advanced book on performance analysis (in particular perf logs tend to hide critical info in plain sight). We mostly just don’t care, and too many of us have honed or at least mislearned excuses for our behavior that business folks have no way to talk us out of. Most vexing for me is when customers threaten to leave over performance and the senior staff pull up some graphs that say we have done all we can. It’s fairly straightforward to climb the ranks on such a project by proving them wrong. These sorts often leave 2-3x (that I know how to find, who knows what he real number is) on the table, which is often enough to satisfy the customer. It’s often hard work but there’s nothing magic about it.

OkayPhysicist 6y ago

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.

dnautics 6y ago

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