3 ms·

So you've basically experienced the benefits of actors (message-passing style, no shared state). But you can use message-passing paradigm in imperative language

by zvrba 13y ago

So you've basically experienced the benefits of actors (message-passing style, no shared state). But you can use message-passing paradigm in imperative languages too, though it's rather cumbersome in non-extensible languages like C or Java.

jerf 13y ago
I think (s)he strongly implied that. I'd simply flat-out say it, the best way to learn how to program in an imperative multi-threaded environment is to clock enough time in Erlang, Haskell, or perhaps Clojure (with as much immutability as possible) that you can get real work done (not merely finish a couple of tutorials) that you are forced to learn how to program in a minimal-sharing style, then if you go back to something like Go or something, it's really not that hard. I think you can learn how to program multithreaded code well without that, but you'll learn a great deal faster if you use a language that kicks you in the face every time you do something stupid (or simply doesn't let you do it). As in, potentially an order of magnitude faster. Fast feedback is non-linearly better than slow feedback. Though this does assume you get to greenfield the multithreaded code. Woe betide ye who have to retrofit existing poor multithreaded code. I don't even know what to tell you, except you have my pity.
- timje1 13y ago
  That's correct, I love the actor system in Erlang, and I wish I had access to it in every other language I've used. Building multi-threaded applications with functional programming forced me to write pure functions - or close enough, Erlang does have some side-effects but this is just to make it more useable than the mostly academic Haskell. I've carried this approach into C# and Java, and typically end up with methods that fit a multi-threaded paradigm by default because of their lack of state. As a freebie, they can be effortlessly unit tested by mocking their direct parameters and testing the return values (no need to mock or test state).

by zvrba 13y ago

jerf 13y ago

I think (s)he strongly implied that. I'd simply flat-out say it, the best way to learn how to program in an imperative multi-threaded environment is to clock enough time in Erlang, Haskell, or perhaps Clojure (with as much immutability as possible) that you can get real work done (not merely finish a couple of tutorials) that you are forced to learn how to program in a minimal-sharing style, then if you go back to something like Go or something, it's really not that hard. I think you can learn how to program multithreaded code well without that, but you'll learn a great deal faster if you use a language that kicks you in the face every time you do something stupid (or simply doesn't let you do it). As in, potentially an order of magnitude faster. Fast feedback is non-linearly better than slow feedback. Though this does assume you get to greenfield the multithreaded code. Woe betide ye who have to retrofit existing poor multithreaded code. I don't even know what to tell you, except you have my pity.

timje1 13y ago
That's correct, I love the actor system in Erlang, and I wish I had access to it in every other language I've used. Building multi-threaded applications with functional programming forced me to write pure functions - or close enough, Erlang does have some side-effects but this is just to make it more useable than the mostly academic Haskell. I've carried this approach into C# and Java, and typically end up with methods that fit a multi-threaded paradigm by default because of their lack of state. As a freebie, they can be effortlessly unit tested by mocking their direct parameters and testing the return values (no need to mock or test state).