5 ms·

I'm not sure Joe Armstrong would agree with your comment.

parthdesai 3y ago
After a certain scale, it actually does start to slow you down https://discord.com/blog/using-rust-to-scale-elixir-for-11-million-concurrent-users https://discord.com/blog/using-rust-to-scale-elixir-for-11-m...
- dpflan 3y ago
  This is a great engineering blogpost. Other good ones from Discord on scaling (elixir, rust, cassandraDB vs. scyllaDB: - https://discord.com/blog/how-discord-scaled-elixir-to-5-000-000-concurrent-users https://discord.com/blog/how-discord-scaled-elixir-to-5-000-... — continually improving elixir - https://discord.com/blog/how-discord-stores-trillions-of-messages https://discord.com/blog/how-discord-stores-trillions-of-mes... — moving to scyllaDB
- jimbokun 3y ago
  That was an excellent write up. And great case study in how to iteratively approach a performance problem. First address the algorithmic issues. Then once the algorithm is no longer the bottleneck, look into dropping into a higher performance, lower overhead language like Rust. Jumping directly to Rust with the original algorithm, would not have helped much. And in the general case, getting the algorithm right might make dropping down into Rust unnecessary. Very nice work.
wredue 3y ago
I don’t really care what people making claims say when they make claims without evidence. ”Who” makes a claim has no bearing on its truth. Immutability is a tool, not a rule, and I am free to reject any assertion otherwise when those assertions provide no evidence, or shitty anecdotes. Prove your claims. Certainly, immutability is a foundation for performance problems. Another provable rule in computing is that more lines of code = more bugs. Immutability uses more lines of code. Another demonstrable fact is that Haskell based programs have just as many bugs as any other programming language whether you have immutability or not. Therefore, immutability is not a bastion of robustness. You’re going to have significant difficulty proving to me that immutability = scalability and robustness when both are demonstrably not true just by taking measurements of thing you expect to improve out of those foundations. Immutability is not a silver bullet. It is a tool that is sometimes useful, but has significant drawbacks, including shitty performance, and significantly limiting how your data can be managed (without that limitation paying off in any significant way)
- dimitrios1 3y ago
  There isn't some universe where there exists a list of axiomatic, unfalisifable proofs for what or what doesn't constitute the foundations of scalability and robustness, rather, you have a tradition of development practices that have much more often lead you to scalability and robustness than than the alternatives, and Joe Armstrong was someone who trailblazed that tradition in blood sweat and tears so to speak, as well as a majority of developers here, many of which have had experience writing software that handles millions, sometimes hundreds of millions of requests per second who would very much likely agree with Joe on a lot of things. Not everything people say on a discussion board is some scientific claim, subject to scientific inquiry and in need of a thesis defense. But if you really off-the-cuff dismiss Joe Armstrong's opinion on a matter because it hasn't met your criteria of proof, despite you thinking you are somehow being the rational scientist here, you are actually revealing your own stupidity.
  - wredue 3y ago
    The author claimed that immutability is a foundation for scalability and robustness. I reject that claim. In this comment, you simultaneously agree and disagree with me. I don’t give a shit what Joe Armstrong says about immutability because the facts are the facts: 1) immutability cause performance problems 2) immutability significantly limits how you can manage data, which is counter to what computers are meant to do 3) immutability measurably does not reduce bugs in programs I am not dismissing <insert name> off the cuff. I am dismissing them because their claim does not align with metrics you expect to improve as a result of their claim. >it doesn’t have to be a scientific claim When you are telling people to “make immutability a foundation of their programming”, you 100% are opening yourself to scientific scrutiny. If you cannot back up this claim with actual metrics, and you’re just going to say “hurr durr, just let me make claims without calling me out to providing evidence please”, why should anyone believe you?
    - ch4s3 3y ago
      > 3) immutability measurably does not reduce bugs in programs I'd be curious to see how you back this claim up. Are you referring to something published that we can all go and read?
jerf 3y ago
Sadly, due to his untimely passing, I don't think Joe Armstrong ever really got a good chance to analyze Rust's borrow checker from his perspective. So I'd be reluctant to be too dogmatic about what he'd think about it. Personally I think that if you can stomach the additional complexity (which is a non-trivial "if", but a doable one), Rust's approach supercedes immutability. Full immutability was an interesting theory in the 1990s, and I mean that respectfully and not sarcastically, but in the end I think it was overkill and overcompensation. The correct thing to do is not to eliminate mutability, but to firmly, firmly control it. Rust has a sophisticated method for doing so, with compiler support. It may not be the only one, but it seems a very solid one. Immutability is another method of controlling it, but in my view, it's actually kind of a blunt instrument applied to a complex problem. In my considered opinion, in the end, immutability isn't even important to Erlang. What matters in Erlang is that you can't send references across messages, so there is no way to witness mutation done by another process. It was not necessary within a given process to be immutable, and I suspect that has been a non-trivial ball and chain around Erlang's legs in terms of adoption even to this day. There was never any need for a newbie Erlang developer to also have to learn how to program immutably within a process.
- toast0 3y ago
  > Sadly, due to his untimely passing, I don't think Joe Armstrong ever really got a good chance to analyze Rust's borrow checker from his perspective. So I'd be reluctant to be too dogmatic about what he'd think about it. I agree that Joe was a great explorer of ideas. I'm not sure if he expressed thoughts on Rust, but he would probably look at it again from time to time. > In my considered opinion, in the end, immutability isn't even important to Erlang. What matters in Erlang is that you can't send references across messages, so there is no way to witness mutation done by another process. In some ways, you may be right. But you can always mutate the process dictionary if immutable data really bothers you. But even with the process dictionary, it's not possible to construct a self refering datastructure as an Erlang term, which is important! That makes garbage collection simple. Also, functional programming makes Erlang processes effectively preemptive, when they're built from cooperative user space threads. Tokio tasks can loop and tie up the OS thread it's running on; but an Erlang process will always come to a function call in finite time and can be descheduled at that time, so all runable processes will get a share of cpu. Edit to add: It's also important to note that Immutability is a property of Erlang (and Elixir), not a property of BEAM. The BEAM vm has opcodes for mutation, and the Erlang compiler will emit them in certain sequences --- if you never use the old value again, it's ok to mutate it rather that create a new modified value; you're most likely to see that with Tuples, IIRC.

After a certain scale, it actually does start to slow you down https://discord.com/blog/using-rust-to-scale-elixir-for-11-million-concurrent-users https://discord.com/blog/using-rust-to-scale-elixir-for-11-m...

dpflan 3y ago
This is a great engineering blogpost. Other good ones from Discord on scaling (elixir, rust, cassandraDB vs. scyllaDB: - https://discord.com/blog/how-discord-scaled-elixir-to-5-000-000-concurrent-users https://discord.com/blog/how-discord-scaled-elixir-to-5-000-... — continually improving elixir - https://discord.com/blog/how-discord-stores-trillions-of-messages https://discord.com/blog/how-discord-stores-trillions-of-mes... — moving to scyllaDB
jimbokun 3y ago
That was an excellent write up. And great case study in how to iteratively approach a performance problem. First address the algorithmic issues. Then once the algorithm is no longer the bottleneck, look into dropping into a higher performance, lower overhead language like Rust. Jumping directly to Rust with the original algorithm, would not have helped much. And in the general case, getting the algorithm right might make dropping down into Rust unnecessary. Very nice work.

wredue 3y ago

I don’t really care what people making claims say when they make claims without evidence. ”Who” makes a claim has no bearing on its truth. Immutability is a tool, not a rule, and I am free to reject any assertion otherwise when those assertions provide no evidence, or shitty anecdotes. Prove your claims. Certainly, immutability is a foundation for performance problems. Another provable rule in computing is that more lines of code = more bugs. Immutability uses more lines of code. Another demonstrable fact is that Haskell based programs have just as many bugs as any other programming language whether you have immutability or not. Therefore, immutability is not a bastion of robustness. You’re going to have significant difficulty proving to me that immutability = scalability and robustness when both are demonstrably not true just by taking measurements of thing you expect to improve out of those foundations. Immutability is not a silver bullet. It is a tool that is sometimes useful, but has significant drawbacks, including shitty performance, and significantly limiting how your data can be managed (without that limitation paying off in any significant way)

dimitrios1 3y ago
There isn't some universe where there exists a list of axiomatic, unfalisifable proofs for what or what doesn't constitute the foundations of scalability and robustness, rather, you have a tradition of development practices that have much more often lead you to scalability and robustness than than the alternatives, and Joe Armstrong was someone who trailblazed that tradition in blood sweat and tears so to speak, as well as a majority of developers here, many of which have had experience writing software that handles millions, sometimes hundreds of millions of requests per second who would very much likely agree with Joe on a lot of things. Not everything people say on a discussion board is some scientific claim, subject to scientific inquiry and in need of a thesis defense. But if you really off-the-cuff dismiss Joe Armstrong's opinion on a matter because it hasn't met your criteria of proof, despite you thinking you are somehow being the rational scientist here, you are actually revealing your own stupidity.
- wredue 3y ago
  The author claimed that immutability is a foundation for scalability and robustness. I reject that claim. In this comment, you simultaneously agree and disagree with me. I don’t give a shit what Joe Armstrong says about immutability because the facts are the facts: 1) immutability cause performance problems 2) immutability significantly limits how you can manage data, which is counter to what computers are meant to do 3) immutability measurably does not reduce bugs in programs I am not dismissing <insert name> off the cuff. I am dismissing them because their claim does not align with metrics you expect to improve as a result of their claim. >it doesn’t have to be a scientific claim When you are telling people to “make immutability a foundation of their programming”, you 100% are opening yourself to scientific scrutiny. If you cannot back up this claim with actual metrics, and you’re just going to say “hurr durr, just let me make claims without calling me out to providing evidence please”, why should anyone believe you?
  - ch4s3 3y ago
    > 3) immutability measurably does not reduce bugs in programs I'd be curious to see how you back this claim up. Are you referring to something published that we can all go and read?

jerf 3y ago

Sadly, due to his untimely passing, I don't think Joe Armstrong ever really got a good chance to analyze Rust's borrow checker from his perspective. So I'd be reluctant to be too dogmatic about what he'd think about it. Personally I think that if you can stomach the additional complexity (which is a non-trivial "if", but a doable one), Rust's approach supercedes immutability. Full immutability was an interesting theory in the 1990s, and I mean that respectfully and not sarcastically, but in the end I think it was overkill and overcompensation. The correct thing to do is not to eliminate mutability, but to firmly, firmly control it. Rust has a sophisticated method for doing so, with compiler support. It may not be the only one, but it seems a very solid one. Immutability is another method of controlling it, but in my view, it's actually kind of a blunt instrument applied to a complex problem. In my considered opinion, in the end, immutability isn't even important to Erlang. What matters in Erlang is that you can't send references across messages, so there is no way to witness mutation done by another process. It was not necessary within a given process to be immutable, and I suspect that has been a non-trivial ball and chain around Erlang's legs in terms of adoption even to this day. There was never any need for a newbie Erlang developer to also have to learn how to program immutably within a process.

toast0 3y ago
> Sadly, due to his untimely passing, I don't think Joe Armstrong ever really got a good chance to analyze Rust's borrow checker from his perspective. So I'd be reluctant to be too dogmatic about what he'd think about it. I agree that Joe was a great explorer of ideas. I'm not sure if he expressed thoughts on Rust, but he would probably look at it again from time to time. > In my considered opinion, in the end, immutability isn't even important to Erlang. What matters in Erlang is that you can't send references across messages, so there is no way to witness mutation done by another process. In some ways, you may be right. But you can always mutate the process dictionary if immutable data really bothers you. But even with the process dictionary, it's not possible to construct a self refering datastructure as an Erlang term, which is important! That makes garbage collection simple. Also, functional programming makes Erlang processes effectively preemptive, when they're built from cooperative user space threads. Tokio tasks can loop and tie up the OS thread it's running on; but an Erlang process will always come to a function call in finite time and can be descheduled at that time, so all runable processes will get a share of cpu. Edit to add: It's also important to note that Immutability is a property of Erlang (and Elixir), not a property of BEAM. The BEAM vm has opcodes for mutation, and the Erlang compiler will emit them in certain sequences --- if you never use the old value again, it's ok to mutate it rather that create a new modified value; you're most likely to see that with Tuples, IIRC.