6 ms·

> How do programmers fix these problems? They don’t. They pray. Ah! No, Joe, that's what you do. Most of developers have figured out how to do concurrency and

> How do programmers fix these problems? They don’t. They pray. Ah! No, Joe, that's what you do. Most of developers have figured out how to do concurrency and parallelism with mutable state and locks. It's not as hard as you make it sound and it's supported in a lot of languages which, as opposed to Erlang, are statically typed, hence much more suitable to the kind of large scale software you describe. And yes, that was already true in 2007.

douche 10y ago
You have a more optimistic view of the average level of skill and knowledge of developers than I would. Basic concurrency bugs strike all the time, and a lot of people don't know what they don't know, until they've been burned a few times.
zaphar 10y ago
If I am totally honest. Most of the code where I was pretty sure I had figured out the whole mutable states and locks thing has another developer looking at it right now and cursing me under his breath.
- patates 10y ago
  I'm investigating an issue with a deployment where a process keeps crashing with the log.fatal("not reachable"). I already fixed 3 potential race conditions and still not sure if and when I'll get my next email basically telling me "haha it's still reachable". Yesterday my neighbor came to my door to ask if everything is okay because I cried "aber warum?" (but why?) out loud. tl;dr: Don't be that programmer :)
gamache 10y ago
Do you realize how silly this sounds? You are disregarding not only Erlang, but decades of research and development on concurrent programming best practices. Immutability has been promoted for parallel programming since the 1970s. For the past fifteen years, even languages like C++ have moved to promote this style of programming. (Also, Erlang has a compile-time static type checker, if type safety is something you're after.)
- nilved 10y ago
  Are you referring to Dialyzer? I've always wanted to learn Erlang but can't give up on types.
  - gamache 10y ago
    Yup, Dialyzer. Works with Elixir too (there's even a Dialyxir mix task) and gives me all the type checking I want -- which admittedly isn't much.
    - yellowapple 10y ago
      Personally, even when I do want something resembling type checking, I've found pattern matching / destructuring to be more than sufficient. With Elixir's structs, this is trivial: def some_function(SomeStruct{} = some_struct) do some_struct.foo + some_struct.bar end Or better yet, if I only want certain fields: def some_function(SomeStruct{foo: foo, bar: bar}) do foo + bar end This way, if the "type check" fails (that is, someone tries to use "some_function/1" on something that isn't a SomeStruct), there'll be a clear error to that effect. Between this and protocols, I very rarely feel the need to reach for something like Dialyzer. YMMV, of course.
      - boardwaalk 10y ago
        Pattern matching is fantastic. Also, there are guards: def handle_info(msg, state) when is_tuple(msg) do # ... end I haven't written anything big with Elixir/Erlang yet, but I definitely feel more confident my Elixir code will work than Python, say. Not as much as Go, though. As an aside, comparing: {:ok, port} = Port.open(...) to something similar in Go: port, err := port.open(...) if err != nil { panic(err) } That's very convenient. Also, you can bind multiple times to a single argument (sort of like what you showed): def handle_info([], state = {ppid, _port}) do Supervisor.stop(ppid) {:noreply, state} end That's not a default argument, that's binding the second argument to state and the pid inside the state tuple.
- Const-me 10y ago
lliamander 10y ago
>> How do programmers fix these problems? They don’t. They pray. >Ah! No, Joe, that's what you do. I don't know if Joe is a religious man, but I don't believe beseeching the Almighty was one of the reasons listed for why an Ericsson switch was able to achieve nine 9's of availability. > Most of developers have figured out how to do concurrency and parallelism with mutable state and locks. It appears to me that the industry has moved to a combination of promises, message passing, thread-safe data structures, transactions, etc., instead of code that directly manipulates locks. >...as opposed to Erlang, are statically typed, hence much more suitable to the kind of large scale software you describe. Depends on what you mean for scale. If you mean "suitable for gargantuan code bases and development teams" then it might not be the best. If you mean "suitable for processing large volumes of requests/events with low latency" then Erlang should be fine. Types are nice, and I try to heavily leverage the type analysis tools that are available for Erlang (e.g. dialyzer). Java & C# (the two main static languages) are OK, but presence of null pointer exceptions and absence of sum types, intersection types, tuples, etc. really makes righting terse, type-safe code a chore.
- daddykotex 10y ago
  I think that's where Scala shines. I don't know if you have tried it, but it solves a bunch of the problem you enumerate with Java & C. Sure, it can be hard to read because you can write the same thing in tens of different ways and some people abuse it, but if you don't and your team does not, you end up with a beautiful code base.
  - lliamander 10y ago
    I believe it does. The only issue I take is that I believe null objects are still possible. Kotlin and Ceylon both correctly addressed this (but lack some of the sophisticated type features found in Scala).
rdtsc 10y ago
> how to do concurrency and parallelism with mutable state and locks. It's not as hard as you make it sound This has to be sarcasm, right?
Jtsummers 10y ago
> Most of developers have figured out how to do concurrency and parallelism with mutable state and locks. Based on my experience of almost a decade in the embedded/safety space, this isn't true. Based on my experience as an end user of software on computers, phones, and tablets, I'm also not inspired by the crashes and performance snags I see. Even when it's safe, it's often slower than necessary thanks to unneeded locks by being too conservative (or due to refactorings which made the locks unnecessary but still present). I agree it's not too hard. But it requires more thought and deliberation to make concurrent code in C/C++/Java than in Erlang than most developers seem willing to commit to the task. Paired with the built-in features of OTP to the Erlang platform, it beats the stock distribution of many other languages for reliability/safety of concurrent code. Those depending on external libraries can never seem to agree on just which one to use. It's too faddish to be reliable for maintenance over the next decade or five.

douche 10y ago

You have a more optimistic view of the average level of skill and knowledge of developers than I would. Basic concurrency bugs strike all the time, and a lot of people don't know what they don't know, until they've been burned a few times.

zaphar 10y ago

If I am totally honest. Most of the code where I was pretty sure I had figured out the whole mutable states and locks thing has another developer looking at it right now and cursing me under his breath.

patates 10y ago
I'm investigating an issue with a deployment where a process keeps crashing with the log.fatal("not reachable"). I already fixed 3 potential race conditions and still not sure if and when I'll get my next email basically telling me "haha it's still reachable". Yesterday my neighbor came to my door to ask if everything is okay because I cried "aber warum?" (but why?) out loud. tl;dr: Don't be that programmer :)

gamache 10y ago

Do you realize how silly this sounds? You are disregarding not only Erlang, but decades of research and development on concurrent programming best practices. Immutability has been promoted for parallel programming since the 1970s. For the past fifteen years, even languages like C++ have moved to promote this style of programming. (Also, Erlang has a compile-time static type checker, if type safety is something you're after.)

nilved 10y ago
Are you referring to Dialyzer? I've always wanted to learn Erlang but can't give up on types.
- gamache 10y ago
  Yup, Dialyzer. Works with Elixir too (there's even a Dialyxir mix task) and gives me all the type checking I want -- which admittedly isn't much.
  - yellowapple 10y ago
    Personally, even when I do want something resembling type checking, I've found pattern matching / destructuring to be more than sufficient. With Elixir's structs, this is trivial: def some_function(SomeStruct{} = some_struct) do some_struct.foo + some_struct.bar end Or better yet, if I only want certain fields: def some_function(SomeStruct{foo: foo, bar: bar}) do foo + bar end This way, if the "type check" fails (that is, someone tries to use "some_function/1" on something that isn't a SomeStruct), there'll be a clear error to that effect. Between this and protocols, I very rarely feel the need to reach for something like Dialyzer. YMMV, of course.
    - boardwaalk 10y ago
      Pattern matching is fantastic. Also, there are guards: def handle_info(msg, state) when is_tuple(msg) do # ... end I haven't written anything big with Elixir/Erlang yet, but I definitely feel more confident my Elixir code will work than Python, say. Not as much as Go, though. As an aside, comparing: {:ok, port} = Port.open(...) to something similar in Go: port, err := port.open(...) if err != nil { panic(err) } That's very convenient. Also, you can bind multiple times to a single argument (sort of like what you showed): def handle_info([], state = {ppid, _port}) do Supervisor.stop(ppid) {:noreply, state} end That's not a default argument, that's binding the second argument to state and the pid inside the state tuple.
Const-me 10y ago

lliamander 10y ago

>> How do programmers fix these problems? They don’t. They pray. >Ah! No, Joe, that's what you do. I don't know if Joe is a religious man, but I don't believe beseeching the Almighty was one of the reasons listed for why an Ericsson switch was able to achieve nine 9's of availability. > Most of developers have figured out how to do concurrency and parallelism with mutable state and locks. It appears to me that the industry has moved to a combination of promises, message passing, thread-safe data structures, transactions, etc., instead of code that directly manipulates locks. >...as opposed to Erlang, are statically typed, hence much more suitable to the kind of large scale software you describe. Depends on what you mean for scale. If you mean "suitable for gargantuan code bases and development teams" then it might not be the best. If you mean "suitable for processing large volumes of requests/events with low latency" then Erlang should be fine. Types are nice, and I try to heavily leverage the type analysis tools that are available for Erlang (e.g. dialyzer). Java & C# (the two main static languages) are OK, but presence of null pointer exceptions and absence of sum types, intersection types, tuples, etc. really makes righting terse, type-safe code a chore.

daddykotex 10y ago
I think that's where Scala shines. I don't know if you have tried it, but it solves a bunch of the problem you enumerate with Java & C. Sure, it can be hard to read because you can write the same thing in tens of different ways and some people abuse it, but if you don't and your team does not, you end up with a beautiful code base.
- lliamander 10y ago
  I believe it does. The only issue I take is that I believe null objects are still possible. Kotlin and Ceylon both correctly addressed this (but lack some of the sophisticated type features found in Scala).

rdtsc 10y ago

> how to do concurrency and parallelism with mutable state and locks. It's not as hard as you make it sound This has to be sarcasm, right?

Jtsummers 10y ago

> Most of developers have figured out how to do concurrency and parallelism with mutable state and locks. Based on my experience of almost a decade in the embedded/safety space, this isn't true. Based on my experience as an end user of software on computers, phones, and tablets, I'm also not inspired by the crashes and performance snags I see. Even when it's safe, it's often slower than necessary thanks to unneeded locks by being too conservative (or due to refactorings which made the locks unnecessary but still present). I agree it's not too hard. But it requires more thought and deliberation to make concurrent code in C/C++/Java than in Erlang than most developers seem willing to commit to the task. Paired with the built-in features of OTP to the Erlang platform, it beats the stock distribution of many other languages for reliability/safety of concurrent code. Those depending on external libraries can never seem to agree on just which one to use. It's too faddish to be reliable for maintenance over the next decade or five.