1. 8
  1.  

  2. 2

    Joe Armstrong’s reaction on Twitter to this is roughly how I feel about it:

    Whatever next - shared mutable state and concurrency + errors is a mess - read my thesis - all is explained

    A little glib and/or arrogant, but that’s Twitter reactions, I suppose.

    1. 2

      Can someone explain this? I’m somewhat familiar with erlang but I don’t get what he’s trying to say. Is he saying that nobody should ever use shared mutable state and he figured it out 20 years ago?

      If so that seems both disrespectful and untrue. I have no doubt erlang is amazing for certain applications. But programming is very diverse and one size doesn’t fit all. The domain of erlang is almost the opposite of the domain of Swift.

      1. 2

        I can agree with this a little. I was surprised by the explicit mention of Rust, which is very fuzzy and doesn’t feel necessary. I also disagree with it somewhat. To replicate my comment from r/rust:

        On the downside, their ownership model has a higher learning curve than the design described here, their abstractions are typically very low level (great for systems programmers, but not as helpful for higher levels), and they don’t provide much guidance for programmers about which abstractions to choose, how to structure an application, etc. Rust also doesn’t provide an obvious model to scale into distributed applications.

        I find this a little… too much in one paragraph. I disagree with the level of abstractions: Rust can be very high level, but still give a glimpse of their structure.

        I hate the characterisation of Ownership as a cliff. It is gradually learnable. It’s just a hill that you have to climb on the journey. Ownership/Borrowing situations in Rust are very much possible to be refactored, which enables gradual learning.

        The middle parts I agree with. Rust is pretty un-opinionated on the solution. Although this is the case in many other languages (such as Java) and has lead to an ecosystem of layered abstractions.

        The last part leaves me confused: aside from Erlang/Elixir, I wouldn’t know any language where the model of building distributed applications comes out of the language.

        1. 1

          The last part leaves me confused: aside from Erlang/Elixir, I wouldn’t know any language where the model of building distributed applications comes out of the language.

          For some historical perspective, examples of other languages with distribution built in are Mozart/Oz, AliceML (built on top of Mozart) and E.

          I think Mozart/Oz is especially cool as data ownership would move around the nodes as necessary. Network partition were also not reflected in the value of the variable itself but rather in a stream that one could subscribe to about the variable. I think the attempted rewrite in Scala was really misdirected, Mozart/Oz was a really cool and fascinating language and it’s unfortunate it couldn’t develope a bigger following to become more of a production language.

          1. 1

            It’s unfortunate Mozart/Oz development has slowed. I agree that it’s a fascinating language - I used it in production once and it was nice to write in. There’s still some signs of life. There’s a mozart implementation on graal/truffle in progress as part of some academic work. One of the things I think Mozart/Oz has struggled with is a lot of the development was directed by academic studies and grants and they would stall when the people involved left university. I still use it and try and keep the Mozart 1.3.x and 1.4.x branches building.

            I wonder why E hasn’t received interest in a production implementation. From what I can see it’s a good language with some nice ideas.