[tpsreport]

Here's a summary of the article:

* author cannot write portable C sockets code

* author cannot handle C/C++

* author believes his app would be too slow in Python, later abandons App, but retains his bias against Python

* Go has no parens for if/for

* Go has unicode support

* Go has closures "like salt shakers"

* Go is cohesively designed

* Go has nice libraries

Go may or may not be a good language, but this kind of argument is not going to win me over.

[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

[stiff]

It's hard to expect a really detailed analysis from someone still in high school. On the other hand, it is good to see how the various languages look like from a fresh perspective of someone with relatively little preconceptions from years of using C/C++/Python/whatever. After all, if he has lots of problems with writing something in C++, but much less when writing it in Go, it probably means lots of us had at some point to internalize lots of knowledge that's not directly relevant to the problem being solved, but to the intricacies of C++ or whatever. If the next generation of programmers can avoid this, that's a huge step ahead in what problems we will be able to solve.

[lclarkmichalek]

Please, ignore people's age, it makes people in high school much happier. From someone in highschool (or the UK equivalent), the age anonymity of the internet is one of it's greatest strengths.

I think he'll still have to learn a fair few tricks to get around some features of Go. Things like type assertions, float32 vs float64, get ready for it lack of generics, and no distinction between stack and heap aren't common in other similar languages, and just getting to know the standard library is a huge part of being productive in a language. C could be seen as better in that respect; the core language is _very_ simple, which can't really be said for Go, though the advantages of Go probably out weigh the advantages of C for many people.

[tpsreport]

Wow, I had no idea that the OP was in high school. Kudos to him! His blog entry is close enough to other software dev blogs in quality that I think we can leave his age, identity and personality aside, and talk about what it takes to win people over to a new language.

[gukjoon]

Wow. 1. Have you written or debugged C sockets code? Because if you have, I doubt you would be dinging him on not wanting to do that. 2. He doesn't want to handle C/C++. I would say that most people who write application code are with him. 3. Yeah... I'm pretty sure Python, an interpreted language, is slower than Go, a compiled language. Even with the progress PyPy is making, I doubt it's going to beat Go.

The author needs no age defense. He makes a ton of valid points for why you should try out Go.

[ootachi]

PyPy is an optimizing JIT compiler; 6g/8g is not an optimizing compiler. I'm pretty sure one could construct examples in which PyPy beats Go for this reason (try something that relies on loop-invariant code motion, for example).

Additionally, PyPy has many garbage collection algorithms, while Go has a stop-the-world mark-and-sweep collector.

[enneff]

PyPy is an amazing project, but it is my understanding that the Python language makes certain guarantees (particularly around thread safety) that will hamper the speed of any implementation for a long time.

Go is still really young, yet it's plenty fast. There's plenty of room for it to get much faster.

[ootachi]

You don't say exactly what you're referring to, but I assume it's the GIL. The GIL exists because Python threads share a single global namespace, and synchronizing atomically on hash tables for module lookup would be way too slow. If you create isolated contexts (like goroutines, but without shared state), the GIL won't bite you (edit: the degenerate cases that folks like David Beazley has described notwithstanding, but those aren't part of the language semantics and have more to do with unfortunate edge cases arising from the way Python's runtime interacts with the OS scheduler).

The problems with making Python fast mostly have to do with its complicated semantics, particularly around things like name lookup; the GIL doesn't have much to do with it.

Interestingly, I predict Go will have a much tougher time here, unless a form of goroutine is created that can't share any state at all. PyPy has been able to do a lot of garbage collection work precisely because it doesn't have to do concurrent GC. Unfortunately, Go crossed that bridge and can't really go back at this point.

[drivebyacct2]

Not to downplay these criticisms or to imply that Python isn't a great choice for many of these requirements, but the things you've mentioned of Go's compiler and garbage collectors are (as I understand the intent of the language designers) simply the current stating of being and I believe are both known (and planned) targets for future improvement.

[pjmlp]

Not to mention that his remark regarding Unicode support in Go reveals a total lack of knowledge in programming languages.

[drivebyacct2]

So, a developer likes that list of things and it fits their project. Your comment offers nothing as a counter to choosing Go in such a situation. Your comment literally brings nothing to the discussion except a tl;dr for anyone who chose to not read it (if you didn't, go read it)

I mean, if I want to write a cross platform websocket server signaling server for PeerConnection, what would you recommend that will let me write a statically typed server in 80 lines of code that's all standard libraries? (edit: Websockets was moved to a `go install`able package recently)

[noveltyaccount]

* Author is 14 years old

[dhaivatpandya]

Even if I was 59, I still think that the comment above is quite misinformed.