2 ms·
> To be fair, it is trivial to parallelize embarrassingly parallel problems in most languages. Including Python (with `multiprocessing`). Of course, but usuall
by danieldk 14y ago
> To be fair, it is trivial to parallelize embarrassingly parallel problems in most languages. Including Python (with `multiprocessing`).
Of course, but usually you are switching to C because the code that is being parallelized needs to be faster.
Go separates itself from C/C++ by making concurrent programming much easier.
Right. I was reacting to the grandparent, who mentioned parallel computation, not concurrency.
Also, you might be interested in my type parametric version of `ParMap` [1].
Nice :). Though my Haskell heart cries when people use interface{} plus reflection as a replacement for parametric polymorphism. Before we know it the library stack will effectively turn Go into a dynamically typed language.
- burntsushi 14y ago> Right. I was reacting to the grandparent, who mentioned parallel computation, not concurrency. Ah! I missed that. Mea culpa. > Nice :). Though my Haskell heart cries when people use interface{} plus reflection as a replacement for parametric polymorphism. As does mine :P But it was a fun exercise nonetheless. If you have a Haskell heart, you might be interested in my write up [1] on writing type parametric functions (using new Go 1.1 features). You will do some bleeding, but presumably you like types, so you might find it interesting. :-) > Before we know it the library stack will effectively turn Go into a dynamically typed language. Fortunately, the performance cost of reflection makes practical usage of it very limited. `ParMap` is in the minority here (where the overhead of concurrency shadows the overhead of reflection). [1] - http://blog.burntsushi.net/type-parametric-functions-golang http://blog.burntsushi.net/type-parametric-functions-golang