8 ms·

I usually wouldn't respond to mean comments, but, this one really throws me off (I'm the OP). There is a very strong difference between "cannot write" and the

I usually wouldn't respond to mean comments, but, this one really throws me off (I'm the OP). There is a very strong difference between "cannot write" and the need for something to be simple. I can definitely handle C/C++, and I don't think writing something in a higher-level language changes that. If something is doing processing with 4000 threads with around 10 years worth of by-the-minute data, it sure as hell will run too slow in Python. And, the arguments stated after are not crucial to "making you switch to Go", which was not the point of the article anyway. EDIT: Also, I did not abandon the app, and in fact open sourced the Bayesian filter stuff I wrote right here: https://github.com/Poincare/Bayesian.go https://github.com/Poincare/Bayesian.go

rocha 15y ago
Are you processing data using 4000 threads? Do you have access to a cluster? Otherwise it seems counter-productive. BTW, Python has great facilities (IPython.parallel) for doing parallel and distributed computing. It is also pretty good at number crunching using Numpy.
- genbattle 15y ago
  Goroutines are multiplexed onto a set of threads defined by the Go program. They're not each a full thread; it's more like Stackless Python's version of threads. http://www.stackless.com/ http://www.stackless.com/
  - rocha 15y ago
    Good point. Since the OP was talking about execution speed, I thought he was using the word thread to refer to OS threads.
    - sausagefeet 15y ago
      Even still, performing number crunching on 4000 Go thread seems like a bad idea.
tpsreport 15y ago
I simply summarized your article. There is nothing wrong with not being up to handling C++'s error messages. I don't feel up to that task myself most of the time. But your arguments for Go rang hollow. I'd urge you to go through the "pro-Go" arguments point by point and describe why, say, they apply to Go but not to Python 3.0. And I'm not a Python zealot by any means; I mention it as a comparison point mostly because it's very commonly used. There are undoubtedly lots of great reasons to use Go, but your article did not enunciate them in a way that would win people over.
- jvm 15y ago
  "why, say, they apply to Go but not to Python 3.0" That's sort of a terrible example since python is ill-suited to many (might I dare say a clear majority of?) production environments. The field of general-purpose production languages is actually pretty narrow. I somewhat agree with your point that the reasons were on the superficial side. Nevertheless, people are dissatisfied with the C/C++/JAVA trio and efforts to replace them have so far failed to stick (D comes to mind).
  - tpsreport 15y ago
    If you're unhappy with Python as a baseline comparison, pick anything else you're happy with that other people understand and compare to that. It's not like we're setting an impossibly high bar here. Just put forward a reasonable argument for why Go is cool. "Closures like salt shakers" will not win anyone over.
  - theorique 15y ago
    * python is ill-suited to many (might I dare say a clear majority of?) production environments * A bold statement, considering the broad range of production environments that have come to the opposite conclusion. Do you have anything in specific to back up this claim or is this just name-calling?
Peaker 15y ago
Did you try Haskell? Knowing Haskell makes reading about Go a very underwhelming experience.
- sausagefeet 15y ago
  Knowing any ML makes it pretty underwhelming.
  - Jach 15y ago
    Or even just any Lisp. http://briancarper.net/blog/497/im-turning-into-a-lisp-snob http://briancarper.net/blog/497/im-turning-into-a-lisp-snob
- jbarham 15y ago
  On the bright side, waiting for the Haskell compiler to grind away means you have plenty of time to read up on Go.
  - Peaker 15y ago
    I don't generally wait for GHC more than a few seconds at a time, except when I'm bootstrapping a new installation. Then I wait some minutes for "cabal install". Compilation times are not bad enough to be a problem.
Maro 15y ago
A tip: if you have say 4 cores, then using 4000 threads will most likely be slow due to lots of context switches. I say most likely because it depends on the details, but it's a safe guess.
- tomp 15y ago
  That is part of the problem; if you have 4 cores, your program should be using 4 OS-threads. Your programming language's runtime should take care of distributing your 4000 lightweight/green threads to the 4 actual threads. This is what e.g. Haskell does, and Go as well, I think.
  - masklinn 15y ago
    > This is what e.g. Haskell does, and Go as well, I think. This is what Erlang does by default, GHC >= 6.12 will do it when using `+RTS -N -RTS` and Go requires explicitly setting GOMAXPROCS, the runtime defaults to single-threaded (as far as I know, GOMAXPROCS still hasn't been retired) and there is no way to have it auto-detect the core count.
    - casualsuperman2 15y ago
      The current weekly release has (and Go v1 will have) runtime.NumCPU() so you can do runtime.GOMAXPROCS(runtime.NumCPU())
      - saucetenuto 15y ago
        Is that the default? If not, why not?

rocha 15y ago

Are you processing data using 4000 threads? Do you have access to a cluster? Otherwise it seems counter-productive. BTW, Python has great facilities (IPython.parallel) for doing parallel and distributed computing. It is also pretty good at number crunching using Numpy.

genbattle 15y ago
Goroutines are multiplexed onto a set of threads defined by the Go program. They're not each a full thread; it's more like Stackless Python's version of threads. http://www.stackless.com/ http://www.stackless.com/
- rocha 15y ago
  Good point. Since the OP was talking about execution speed, I thought he was using the word thread to refer to OS threads.
  - sausagefeet 15y ago
    Even still, performing number crunching on 4000 Go thread seems like a bad idea.

tpsreport 15y ago

I simply summarized your article. There is nothing wrong with not being up to handling C++'s error messages. I don't feel up to that task myself most of the time. But your arguments for Go rang hollow. I'd urge you to go through the "pro-Go" arguments point by point and describe why, say, they apply to Go but not to Python 3.0. And I'm not a Python zealot by any means; I mention it as a comparison point mostly because it's very commonly used. There are undoubtedly lots of great reasons to use Go, but your article did not enunciate them in a way that would win people over.

jvm 15y ago
"why, say, they apply to Go but not to Python 3.0" That's sort of a terrible example since python is ill-suited to many (might I dare say a clear majority of?) production environments. The field of general-purpose production languages is actually pretty narrow. I somewhat agree with your point that the reasons were on the superficial side. Nevertheless, people are dissatisfied with the C/C++/JAVA trio and efforts to replace them have so far failed to stick (D comes to mind).
- tpsreport 15y ago
  If you're unhappy with Python as a baseline comparison, pick anything else you're happy with that other people understand and compare to that. It's not like we're setting an impossibly high bar here. Just put forward a reasonable argument for why Go is cool. "Closures like salt shakers" will not win anyone over.
- theorique 15y ago
  * python is ill-suited to many (might I dare say a clear majority of?) production environments * A bold statement, considering the broad range of production environments that have come to the opposite conclusion. Do you have anything in specific to back up this claim or is this just name-calling?

Peaker 15y ago

Did you try Haskell? Knowing Haskell makes reading about Go a very underwhelming experience.

sausagefeet 15y ago
Knowing any ML makes it pretty underwhelming.
- Jach 15y ago
  Or even just any Lisp. http://briancarper.net/blog/497/im-turning-into-a-lisp-snob http://briancarper.net/blog/497/im-turning-into-a-lisp-snob
jbarham 15y ago
On the bright side, waiting for the Haskell compiler to grind away means you have plenty of time to read up on Go.
- Peaker 15y ago
  I don't generally wait for GHC more than a few seconds at a time, except when I'm bootstrapping a new installation. Then I wait some minutes for "cabal install". Compilation times are not bad enough to be a problem.

Maro 15y ago

A tip: if you have say 4 cores, then using 4000 threads will most likely be slow due to lots of context switches. I say most likely because it depends on the details, but it's a safe guess.

tomp 15y ago
That is part of the problem; if you have 4 cores, your program should be using 4 OS-threads. Your programming language's runtime should take care of distributing your 4000 lightweight/green threads to the 4 actual threads. This is what e.g. Haskell does, and Go as well, I think.
- masklinn 15y ago
  > This is what e.g. Haskell does, and Go as well, I think. This is what Erlang does by default, GHC >= 6.12 will do it when using `+RTS -N -RTS` and Go requires explicitly setting GOMAXPROCS, the runtime defaults to single-threaded (as far as I know, GOMAXPROCS still hasn't been retired) and there is no way to have it auto-detect the core count.
  - casualsuperman2 15y ago
    The current weekly release has (and Go v1 will have) runtime.NumCPU() so you can do runtime.GOMAXPROCS(runtime.NumCPU())
    - saucetenuto 15y ago
      Is that the default? If not, why not?