8 ms·

i'm so sick of this DevOps bullshit i wonder if there is an alternative language that you can hot swap code and do all the black magic stuff while keeping the r

i'm so sick of this DevOps bullshit i wonder if there is an alternative language that you can hot swap code and do all the black magic stuff while keeping the reliability and performance like Rust.

saurik 2y ago
I am shocked at the idea of anyone implying that Erlang is "unreliable"... it's entire reason for existence was to step up the game on reliability.
- Me001 2y ago
  [flagged]
  - sgarland 2y ago
    Can’t wait to hear your take on NodeJS.
- zanderwohl 2y ago
  I agree. I don't know much about Erlang but what I've heard seems to indicate it's used for high-uptime systems that handle errors well.
  - Muromec 2y ago
    I suspect the causality is reversed. When you have a good designed telecom system, then spmething shaped as erlang happens to be a good tool to create to implement it. The tool than keeps you committed to the design choices you made by being restrictive enough.
- Muromec 2y ago
  I heard the quote that some 50% of the mobile traffic is handled by erlang. Somehow the other 50% seems to be doing just fine (except the usual shitshow on the inside that sofware is everywhere all the time).
  - simoncion 2y ago
    > I heard the quote that some 50% of the mobile traffic is handled by erlang. Given that you can implement OTP in any language (albeit with varying degrees of difficulty), that's not surprising. The thing to remember is that Erlang was first used in production in like 1986. nearly forty years is more than enough time for the biggest good ideas in Erlang to percolate out into non-BEAM systems.
- LAC-Tech 2y ago
  As someone who is now in the rust world and very very sympathetic to the Erlang world... you both probably mean completely different things when you say "reliable". The contexts are just world apart.
- dcsommer 2y ago
  GP seems to be implying hot swapping, not Erlang, is unreliable. To which, from my experience using it in Erlang, I heartily agree is fraught. Inconsistent state across nodes is much harder to reason about. When you _must_ ensure consistency, hot swapping is reckless, especially as org size and product complexity increases. Leave hot loading to local/development environments, not production deploys. Loading configs on the fly can also have some of this risk, but it is much easier to reason about typically.
sergiotapia 2y ago
we had this wonderful thing in PHP where you would just save a .php file and bada bing it was LIVE. what happened? :D
- thanksgiving 2y ago
  They took away our access after one too many outages :yay:
  - Muromec 2y ago
    Sounds like what happened with hot upgrade privileges in some erlang shops too.
    - thanksgiving 2y ago
      I've worked at a smaller project where it worked just fine. The key I think is to have the project be small enough to be able to fit in my head. That and have an identical test server. I used to make changes locally, test it locally, then make the same change on test, have someone else look at it, get a lgtm, and do the same thing on the production machine. It sounds like a lot of steps but it is pretty straightforward. Sadly, it probably doesn't work with bigger teams or more complicated projects.
      - Muromec 2y ago
        A lot of things work on a small project where everybody knows what they are doing and can keep all the dependencies and data structure in their heads. Logging to the production server and editing PHP file right where apache is looking at it and fixing stuff with sql commands in the production database to address customer complaints. The big question is what everyone else should be doing that survives the touch with unevenly distributed amounts of technical expertise and amount fucks given about result.
- cardanome 2y ago
  We still have that and it is awesome. PHP is better than ever. In serious emergencies I even sometimes end up quickly SSH-en to a prod server and changing the file directly. Which is kind of horrifying but hey customer is happy it got fixed immediately and I get to relax and take my time to write a proper fix. Beats sweating and watching the pipeline build and asking around for people to approve my merge request.
Muromec 2y ago
The black magic comes at the cost of not having one streamlined procedure to release stuff. And to make the black magic work you have to engage with it. Most of the time people don't even bother write to a proper import.meta.hot.accept thingy in javascript. Developers simply hate chores, which is evident by not willing to write proper unit tests (despite knowing that tests work) or writing just enough to let the coverage cop pass ship the build. A dedicated small team running something like whatsup? Sure, look into the arcane and let it look back at you (although high insight makes one more susceptible to madness you know). But most of the time you will do better job with PHP in a stupid restartable box behind seven load balancing proxies.
- yetihehe 2y ago
  > The black magic comes at the cost of not having one streamlined procedure to release stuff. You can also have a streamlined procedure to release stuff. Most changes in my erlang based system consist of "push to staging branch, click to deploy and test, pull to master, click deploy button". Can't be simpler than that. Most changes in such systems are also pretty simple. When you need to add something big, typically not many things are dependent on that, so deploy is also pretty simple. > But most of the time you will do better job with PHP in a stupid restartable box behind seven load balancing proxies. Yeah, we talk here about more complicated things here. If you have something simple, you don't need to use erlang, `python -m http.server` will be even simpler than your php in stupid restartable box, because you don't need a special box, just one small command.
  - Muromec 2y ago
    Do you do 100% of deployments using hot reload? If yes, maybe you should share the recipy with everybody else, since consensus seems to recommend the opposite. At the very least you will have a different procedure to upgrade the erlang itself, right? >If you have something simple, you don't need to use erlang I think on a spectrum of difficult things there is an area between hosting static file on rpi at home and running massivele distributed system full of long running stateful processes.
lamuswawir 2y ago
Erlang is built for reliability. They're chasing nine nines. Everything about the BEAM is built to emphasize that, the design choices, the documentation, the recommended practices. Erlang is not very fast, but that's not what it was built for.
- Muromec 2y ago
  Is it really beam or just otp? Sure, beam gives you processes, network-transparent send, immutable structures and linking-monitoring thingy on top, but is what makes it good to shoot for nines? I suspect the aura of mistycism around yet another jit vm is not that warranted
  - jerf 2y ago
    It is reasonable to conceive of Erlang as encompassing OTP. Perhaps somewhere in the world there is some developer out there hot on Erlang but just hates OTP and doesn't use it, but they must be fairly frustrated at how hard it is to keep OTP out of their code base if they ever need any libraries. Restarting is arguably the definitive thing that makes Erlang stack the 9s out past what most languages and runtimes can achieve... the thing is, it's more complicated to use in practice than a web page like this makes it look, and it's beyond what most products need. Few applications need the fifth or sixth or seventh nine, and it gets to the point that you can't have it anyhow because your Erlang cluster, no matter how well distributed, itself probably doesn't have 99.99999 availability, and your users probably don't have 99.99999 availability on their own network connection. It's not impossibly complicated, but it is the sort of thing where you if you want to use the feature you need to have it sort of constantly in mind as you write the rest of your system, and it's a lot easier even in Erlang to just design the system to take entire nodes down and bring them back up, if not the entire cluster down, rather than fuss with hot reloads. I wish Erlang advocates would be more upfront about pitching this as an interesting niche feature, but not really a reason to consider Erlang. Unless you absolutely need it, in which case it can indeed be the thing that puts it on the short list of choices... but as evidenced by the vast, vast majority of software and systems not being on Erlang and managing to get along, there aren't really that many things that need it.
gf000 2y ago
It's not well known, but the JVM has very good hot reload support, and is a very reliable and performant platform.

i'm so sick of this DevOps bullshit i wonder if there is an alternative language that you can hot swap code and do all the black magic stuff while keeping the reliability and performance like Rust.

saurik 2y ago

I am shocked at the idea of anyone implying that Erlang is "unreliable"... it's entire reason for existence was to step up the game on reliability.

Me001 2y ago
[flagged]
- sgarland 2y ago
  Can’t wait to hear your take on NodeJS.
zanderwohl 2y ago
I agree. I don't know much about Erlang but what I've heard seems to indicate it's used for high-uptime systems that handle errors well.
- Muromec 2y ago
  I suspect the causality is reversed. When you have a good designed telecom system, then spmething shaped as erlang happens to be a good tool to create to implement it. The tool than keeps you committed to the design choices you made by being restrictive enough.
Muromec 2y ago
I heard the quote that some 50% of the mobile traffic is handled by erlang. Somehow the other 50% seems to be doing just fine (except the usual shitshow on the inside that sofware is everywhere all the time).
- simoncion 2y ago
  > I heard the quote that some 50% of the mobile traffic is handled by erlang. Given that you can implement OTP in any language (albeit with varying degrees of difficulty), that's not surprising. The thing to remember is that Erlang was first used in production in like 1986. nearly forty years is more than enough time for the biggest good ideas in Erlang to percolate out into non-BEAM systems.
LAC-Tech 2y ago
As someone who is now in the rust world and very very sympathetic to the Erlang world... you both probably mean completely different things when you say "reliable". The contexts are just world apart.
dcsommer 2y ago
GP seems to be implying hot swapping, not Erlang, is unreliable. To which, from my experience using it in Erlang, I heartily agree is fraught. Inconsistent state across nodes is much harder to reason about. When you _must_ ensure consistency, hot swapping is reckless, especially as org size and product complexity increases. Leave hot loading to local/development environments, not production deploys. Loading configs on the fly can also have some of this risk, but it is much easier to reason about typically.

sergiotapia 2y ago

we had this wonderful thing in PHP where you would just save a .php file and bada bing it was LIVE. what happened? :D

thanksgiving 2y ago
They took away our access after one too many outages :yay:
- Muromec 2y ago
  Sounds like what happened with hot upgrade privileges in some erlang shops too.
  - thanksgiving 2y ago
    I've worked at a smaller project where it worked just fine. The key I think is to have the project be small enough to be able to fit in my head. That and have an identical test server. I used to make changes locally, test it locally, then make the same change on test, have someone else look at it, get a lgtm, and do the same thing on the production machine. It sounds like a lot of steps but it is pretty straightforward. Sadly, it probably doesn't work with bigger teams or more complicated projects.
    - Muromec 2y ago
      A lot of things work on a small project where everybody knows what they are doing and can keep all the dependencies and data structure in their heads. Logging to the production server and editing PHP file right where apache is looking at it and fixing stuff with sql commands in the production database to address customer complaints. The big question is what everyone else should be doing that survives the touch with unevenly distributed amounts of technical expertise and amount fucks given about result.
cardanome 2y ago
We still have that and it is awesome. PHP is better than ever. In serious emergencies I even sometimes end up quickly SSH-en to a prod server and changing the file directly. Which is kind of horrifying but hey customer is happy it got fixed immediately and I get to relax and take my time to write a proper fix. Beats sweating and watching the pipeline build and asking around for people to approve my merge request.

Muromec 2y ago

The black magic comes at the cost of not having one streamlined procedure to release stuff. And to make the black magic work you have to engage with it. Most of the time people don't even bother write to a proper import.meta.hot.accept thingy in javascript. Developers simply hate chores, which is evident by not willing to write proper unit tests (despite knowing that tests work) or writing just enough to let the coverage cop pass ship the build. A dedicated small team running something like whatsup? Sure, look into the arcane and let it look back at you (although high insight makes one more susceptible to madness you know). But most of the time you will do better job with PHP in a stupid restartable box behind seven load balancing proxies.

yetihehe 2y ago
> The black magic comes at the cost of not having one streamlined procedure to release stuff. You can also have a streamlined procedure to release stuff. Most changes in my erlang based system consist of "push to staging branch, click to deploy and test, pull to master, click deploy button". Can't be simpler than that. Most changes in such systems are also pretty simple. When you need to add something big, typically not many things are dependent on that, so deploy is also pretty simple. > But most of the time you will do better job with PHP in a stupid restartable box behind seven load balancing proxies. Yeah, we talk here about more complicated things here. If you have something simple, you don't need to use erlang, `python -m http.server` will be even simpler than your php in stupid restartable box, because you don't need a special box, just one small command.
- Muromec 2y ago
  Do you do 100% of deployments using hot reload? If yes, maybe you should share the recipy with everybody else, since consensus seems to recommend the opposite. At the very least you will have a different procedure to upgrade the erlang itself, right? >If you have something simple, you don't need to use erlang I think on a spectrum of difficult things there is an area between hosting static file on rpi at home and running massivele distributed system full of long running stateful processes.

lamuswawir 2y ago

Erlang is built for reliability. They're chasing nine nines. Everything about the BEAM is built to emphasize that, the design choices, the documentation, the recommended practices. Erlang is not very fast, but that's not what it was built for.

Muromec 2y ago
Is it really beam or just otp? Sure, beam gives you processes, network-transparent send, immutable structures and linking-monitoring thingy on top, but is what makes it good to shoot for nines? I suspect the aura of mistycism around yet another jit vm is not that warranted
- jerf 2y ago
  It is reasonable to conceive of Erlang as encompassing OTP. Perhaps somewhere in the world there is some developer out there hot on Erlang but just hates OTP and doesn't use it, but they must be fairly frustrated at how hard it is to keep OTP out of their code base if they ever need any libraries. Restarting is arguably the definitive thing that makes Erlang stack the 9s out past what most languages and runtimes can achieve... the thing is, it's more complicated to use in practice than a web page like this makes it look, and it's beyond what most products need. Few applications need the fifth or sixth or seventh nine, and it gets to the point that you can't have it anyhow because your Erlang cluster, no matter how well distributed, itself probably doesn't have 99.99999 availability, and your users probably don't have 99.99999 availability on their own network connection. It's not impossibly complicated, but it is the sort of thing where you if you want to use the feature you need to have it sort of constantly in mind as you write the rest of your system, and it's a lot easier even in Erlang to just design the system to take entire nodes down and bring them back up, if not the entire cluster down, rather than fuss with hot reloads. I wish Erlang advocates would be more upfront about pitching this as an interesting niche feature, but not really a reason to consider Erlang. Unless you absolutely need it, in which case it can indeed be the thing that puts it on the short list of choices... but as evidenced by the vast, vast majority of software and systems not being on Erlang and managing to get along, there aren't really that many things that need it.

gf000 2y ago

It's not well known, but the JVM has very good hot reload support, and is a very reliable and performant platform.