[dhaivatpandya]

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

[tpsreport]

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]

"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]

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]

* 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?

[Maro]

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]

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]

> 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]

The current weekly release has (and Go v1 will have) runtime.NumCPU() so you can do runtime.GOMAXPROCS(runtime.NumCPU())

[saucetenuto]

Is that the default? If not, why not?

[rocha]

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]

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/

[rocha]

Good point. Since the OP was talking about execution speed, I thought he was using the word thread to refer to OS threads.

[sausagefeet]

Even still, performing number crunching on 4000 Go thread seems like a bad idea.

[Peaker]

Did you try Haskell?

Knowing Haskell makes reading about Go a very underwhelming experience.

[jbarham]

On the bright side, waiting for the Haskell compiler to grind away means you have plenty of time to read up on Go.

[Peaker]

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.

[sausagefeet]

Knowing any ML makes it pretty underwhelming.

[Jach]

Or even just any Lisp. http://briancarper.net/blog/497/im-turning-into-a-lisp-snob