4 ms·

As others have pointed out, the Blub analogy fails miserably because there's not one universal scale on which to grade programming languages. Wanna do concurre

As others have pointed out, the Blub analogy fails miserably because there's not one universal scale on which to grade programming languages. Wanna do concurrent and parallel programming in a mostly seamless manner, not thinking about deadlocks and being isolated from most dumb mistakes that we all make? Go use Erlang/Elixir, Rust, Golang, OCaml 5.0 and a few others. You can't convince me -- or most practical programmers out there for that matter -- that you can use "most" programming languages "easily" for concurrent and parallel programming. That's bullshit coming from people who are either too idealistic or are stuck deep into their sunk cost fallacy aftermath. Wanna do scientific number-crunching? I hate Python but I know its attached ecosystem excels at this. (Maybe Polars and a few other alternatives as well.) Examples abound. So as far as we can even accept the proposition that "Blub programmers" exist then yes I'd say most of us are kinda sorta "Blub programmers" indeed. It's inevitable; we have limited time and energy and on top of that our brain can burn out. I learned 8 languages and I haven't learned and used a new one ever since I learned Elixir and Rust 5-6 years ago. I am pretty sure I'll learn one or two more and that's going to be it. It's normal. But it still doesn't justify the people who are like "Python everything!". Feels like they didn't even try to find the right tools for the separate jobs. Those people I can't respect.

kaba0 4y ago
> not thinking about deadlocks and being isolated from most dumb mistakes that we all make? Go use Erlang/Elixir, Rust, Golang, OCaml 5.0 and a few others None of them can prevent you from dumb mistakes regarding concurrency (maybe Erlang can do so by runtime checking). At most Rust and Erlang prevents data races (by the borrow checker and by not having shared memory, respectively). I don’t know much about Ocaml, didn’t it have quite a poor concurrency story? But I agree with you in that you can’t do concurrency easily (but I also exclude these languages)
- pdimitar 4y ago
  Why do you exclude them though? Golang and Rust do quite amazing and are constantly growing. Even Elixir that many deem niche is used by quite a lot of companies, VERY successfully at that.
  - kaba0 4y ago
    Here is your sentence I replied to (emphasis mine): > Wanna do concurrent and parallel programming in a mostly seamless manner, not thinking about deadlocks and being isolated from most dumb mistakes that we all make? Neither of these languages allow for that, as deadlocks (and livelocks and all kinds of other race conditions) are not avoidable in any of them. Rust and Elixir does prevent some race conditions (data races), Go does nothing (other than recommending the usage of channels, but that is still prone to race conditions), and I don’t know about OCaml enough to comment.
    - pdimitar 4y ago
      General point was that there exist a number of languages that don't make you use classic multi-threading and all the horrors you can inflict with it. And that clumping all languages together and proclaiming "all are equally good/bad with concurrency and parallelism" is obviously not true. But if you are here to nitpick then congratulations, you have succeeded. :D I don't like Golang but IMO it's still an improvement even though it doesn't save you from certain scenarios as you pointed out.

kaba0 4y ago

> not thinking about deadlocks and being isolated from most dumb mistakes that we all make? Go use Erlang/Elixir, Rust, Golang, OCaml 5.0 and a few others None of them can prevent you from dumb mistakes regarding concurrency (maybe Erlang can do so by runtime checking). At most Rust and Erlang prevents data races (by the borrow checker and by not having shared memory, respectively). I don’t know much about Ocaml, didn’t it have quite a poor concurrency story? But I agree with you in that you can’t do concurrency easily (but I also exclude these languages)

pdimitar 4y ago
Why do you exclude them though? Golang and Rust do quite amazing and are constantly growing. Even Elixir that many deem niche is used by quite a lot of companies, VERY successfully at that.
- kaba0 4y ago
  Here is your sentence I replied to (emphasis mine): > Wanna do concurrent and parallel programming in a mostly seamless manner, not thinking about deadlocks and being isolated from most dumb mistakes that we all make? Neither of these languages allow for that, as deadlocks (and livelocks and all kinds of other race conditions) are not avoidable in any of them. Rust and Elixir does prevent some race conditions (data races), Go does nothing (other than recommending the usage of channels, but that is still prone to race conditions), and I don’t know about OCaml enough to comment.
  - pdimitar 4y ago
    General point was that there exist a number of languages that don't make you use classic multi-threading and all the horrors you can inflict with it. And that clumping all languages together and proclaiming "all are equally good/bad with concurrency and parallelism" is obviously not true. But if you are here to nitpick then congratulations, you have succeeded. :D I don't like Golang but IMO it's still an improvement even though it doesn't save you from certain scenarios as you pointed out.