4 ms·

As much as I don't like javascript, there is a whole swathe of concurrency bugs that exists in golang and not in nodejs.

Thaxll 8y ago
Makes sense since Nodejs has no parallelism features.
- beatgammit 8y ago
  And that's a large reason why I use Go: scaling to multiple cores works out of the box if you build it with goroutines.
- pcwalton 8y ago
  Go doesn't really have parallelism features either. A language designed for parallelism needs to have data-parallel features like parallel iterators, good support for SIMD, and concurrent data structures, neither of which Go has. (In fact, due to lack of generics, you can't even build your own generic concurrent data structures!)
  - Thaxll 8y ago
    Your comment makes no sense, goroutines are multiplexed on each cores thus it has parallelism. https://en.wikipedia.org/wiki/Parallel_computing https://en.wikipedia.org/wiki/Parallel_computing "Parallel computing is a type of computation in which many calculations or the execution of processes are carried out simultaneously." Do you enjoy trolling and dismissing Go in general? Reading your comments sounds like some envy toward Go popularity. When you're not complaining about concurrency features it's about Go GC.
    - pcwalton 8y ago
      And Node has workers and can thus achieve parallelism as well. What matters isn't whether the language can achieve parallelism: it's whether the language is designed for it. Go is designed for concurrency, not parallelism. It's Rob Pike's view [1] that concurrency enables parallelism "for free". I think that's oversimplified and at odds with the way people who write CPU-bound code actually use parallelism features, but that's how Go was designed: it omits traditional parallelism features in favor of concurrency features. [1]: https://blog.golang.org/concurrency-is-not-parallelism https://blog.golang.org/concurrency-is-not-parallelism
  - tedunangst 8y ago
    Yikes. It's impossible to do parallel processing on my old pentium pro because it lacks MMX?
    - pcwalton 8y ago
      I didn't say it was impossible to do parallel work in Go. You can get parallelism in Node, too, by using workers, or by just forking processes and having them communicate with pipes. Rather, what I was trying to emphasize is that Go—and Node—aren't designed for parallelism. Go has good support for concurrency, not parallelism. Parallel languages have feature sets more like CUDA, C++ with OpenMP, OpenCL, etc.
    - nickpsecurity 8y ago
      The traditional definition was doing multiple operations at the same time. SIMD, SMP, multicore, and clustering would qualify. So, yeah, you could do parallel processing in dual- or quad-CPU configuration. Beowulf clusters started with 486 using MPI and PVM. So, scale the Pentium Pro's up and out. EDIT: Glanced at Wikipedia out of curiosity. Forgot it was used in ASCI Red. So, definitely can use them for parallel computing. To pass a teraflop, you just need 1,600 sq. ft. of them running at 850 kW. ;) https://en.wikipedia.org/wiki/ASCI_Red https://en.wikipedia.org/wiki/ASCI_Red
    - coldtea 8y ago
      Well, also because it only features a single processor. You could mimic parallel processing effects with multitasking tho. Note however how parent didn't say that Go "can't do" parallelism, but that Go is not "a language designed for parallelism".
- merb 8y ago
  doesn't node have workers ?
  - gjs278 8y ago
    when i worked with it there were special npm modules to manage a cluster to use all the cpus. why wouldn’t express just use workers?
    - merb 8y ago
      well they are relativly new: https://nodejs.org/api/worker_threads.html https://nodejs.org/api/worker_threads.html probably experimental, too
- crimsonalucard 8y ago
  Python threads don't either due to the GIL, yet they hit the same concurrency bugs. It's the granularity of the concurrency.
- crimsonalucard 8y ago
  Actually the event loop in nodejs uses several threads. There is parallelism. It's the granularity of the atomic operations that causes certain types of data race bugs. In node, var x = 5; is atomic. In golang var x: Int = 5 is not atomic.

Thaxll 8y ago

Makes sense since Nodejs has no parallelism features.

beatgammit 8y ago
And that's a large reason why I use Go: scaling to multiple cores works out of the box if you build it with goroutines.
pcwalton 8y ago
Go doesn't really have parallelism features either. A language designed for parallelism needs to have data-parallel features like parallel iterators, good support for SIMD, and concurrent data structures, neither of which Go has. (In fact, due to lack of generics, you can't even build your own generic concurrent data structures!)
- Thaxll 8y ago
  Your comment makes no sense, goroutines are multiplexed on each cores thus it has parallelism. https://en.wikipedia.org/wiki/Parallel_computing https://en.wikipedia.org/wiki/Parallel_computing "Parallel computing is a type of computation in which many calculations or the execution of processes are carried out simultaneously." Do you enjoy trolling and dismissing Go in general? Reading your comments sounds like some envy toward Go popularity. When you're not complaining about concurrency features it's about Go GC.
  - pcwalton 8y ago
    And Node has workers and can thus achieve parallelism as well. What matters isn't whether the language can achieve parallelism: it's whether the language is designed for it. Go is designed for concurrency, not parallelism. It's Rob Pike's view [1] that concurrency enables parallelism "for free". I think that's oversimplified and at odds with the way people who write CPU-bound code actually use parallelism features, but that's how Go was designed: it omits traditional parallelism features in favor of concurrency features. [1]: https://blog.golang.org/concurrency-is-not-parallelism https://blog.golang.org/concurrency-is-not-parallelism
- tedunangst 8y ago
  Yikes. It's impossible to do parallel processing on my old pentium pro because it lacks MMX?
  - pcwalton 8y ago
    I didn't say it was impossible to do parallel work in Go. You can get parallelism in Node, too, by using workers, or by just forking processes and having them communicate with pipes. Rather, what I was trying to emphasize is that Go—and Node—aren't designed for parallelism. Go has good support for concurrency, not parallelism. Parallel languages have feature sets more like CUDA, C++ with OpenMP, OpenCL, etc.
  - nickpsecurity 8y ago
    The traditional definition was doing multiple operations at the same time. SIMD, SMP, multicore, and clustering would qualify. So, yeah, you could do parallel processing in dual- or quad-CPU configuration. Beowulf clusters started with 486 using MPI and PVM. So, scale the Pentium Pro's up and out. EDIT: Glanced at Wikipedia out of curiosity. Forgot it was used in ASCI Red. So, definitely can use them for parallel computing. To pass a teraflop, you just need 1,600 sq. ft. of them running at 850 kW. ;) https://en.wikipedia.org/wiki/ASCI_Red https://en.wikipedia.org/wiki/ASCI_Red
  - coldtea 8y ago
    Well, also because it only features a single processor. You could mimic parallel processing effects with multitasking tho. Note however how parent didn't say that Go "can't do" parallelism, but that Go is not "a language designed for parallelism".
merb 8y ago
doesn't node have workers ?
- gjs278 8y ago
  when i worked with it there were special npm modules to manage a cluster to use all the cpus. why wouldn’t express just use workers?
  - merb 8y ago
    well they are relativly new: https://nodejs.org/api/worker_threads.html https://nodejs.org/api/worker_threads.html probably experimental, too
crimsonalucard 8y ago
Python threads don't either due to the GIL, yet they hit the same concurrency bugs. It's the granularity of the concurrency.
crimsonalucard 8y ago
Actually the event loop in nodejs uses several threads. There is parallelism. It's the granularity of the atomic operations that causes certain types of data race bugs. In node, var x = 5; is atomic. In golang var x: Int = 5 is not atomic.