It's a pity the only thing he has to say about Erlang is

"insane Erlang programmers who are content writing sumerian cuneiform all day long"

Seems kind of equivalent to: "no, I never looked at Python - I heard it uses white space".

>Being a Python programmer

I yearn for the day when we'll stop calling ourselves X programmer, and writing articles about "switching languages" or "going from one to the other".

A language is a tool, not an identity.

So he went from one language to another language instead of a framework... Ok. I went from C++ to a C# instead of buying a kilo of bananas. Those are just different things.

I expected to see something like "I looked at my specific class of problems and it is not the kind of problems where Node.js gives a distinctive advantage to justify dealing with a flawed language, so I decided to pick a framework around a modern well-designed language, so that framework is..."

I was hoping to learn something, but I found this blog post to be lacking in actual content or substantial reasoned arguments. Phrases like "What? Come on.", "Seriously?" and "It was clear-ish." don't tell us anything about what the author does or doesn't like about a particular language or framework.

I thought Hacker School banned "feigned surprise" - (https://www.hackerschool.com/manual) - maybe the author attended before this rule was put in place.

I'd love to read a re-write with all of those types of phrases swapped for detailed explanations breaking down what and why the author thinks X is better or worse than Y.

Go is great! It's also a good choice for concurrency operations thanks to goroutines, which are not really threads nor other processes (this is what node.js does in the cluster module, it fires a new process every time you fork the main process - not very efficient by the way).

OP is describing a WSGI problem, he then abandoned Python.

I wonder how soon he will abandon Go because of other minor issues.

BTW background processing without any extra library in Django+WSGI is totally possible and deadly simple. The catch is that it's syncrhonous. But async with Django+Gevent/uWSGI/Tornado

I am just about to begin work at a new company that's looking to leverage node.js to develop a fairly robust REST API that should be able to support a lot on concurrent clients. I've been looking for an opportunity to learn Go.

Would it be worth investigating building it in Go rather than node?

"Why I Went From Tractor To Dirigible (and not Balloon)"

The post seems a bit undercooked for my liking. Isn't there a library from Guido called Tulip for doing Async tasks?

That said, reaching "true" concurrency in Python will always be impossible no matter how you twist the language or monkey patch it. But one has to also decide on the trade of. I've personally used Celery in almost all my tasks, and even though it is bit over-loaded with features, you can always trim it down to your use, and it works pretty damn smoothly. There is a talk by Instagram developer Rick Branson regarding the usage of Celery in Instagram. I would suggest people to check it out.

I'm also surprised that there wasn't a mention of Erlang, which is being predominantly used by Facebook chat, and Haskel or Clojure, which would allow us to achieve concurrent programming without breaking a sweat. Surely, one doesn't have to be a grey beard wizard to learn any one of these three languages?

Good luck to the him, though. Go seems like a very exciting language, whenever I've used to it. Sometimes, it doesn't even seem like a new programming language, just a weird concoction of Java, C++ and Python.

I was expecting an article like this to showcase some real advantages of Go over python, but the cornerstone of the argument is a reference to authority and a claim that it is faster. This is very disappointing, especially given the focus on concurrency and not performance.

The article never mentioned any of a number of interesting and relevant concepts like channels, goroutines or CSP. The specific problem of doing small amount of work in the background is easily solved using goroutines, but this isn't even mentioned and the Go code sample at the end is barely relevant to the rest of the discussion.

Also, I find the derision of Erlang to be out of place in an article on Go and concurrency since both Go and Erlang base their concurrency model on CSP (albeit with significant differences in interpretation).

I think that for concurrent programs, there aren't a lot of languages currently out there that can match Go. I quite like go, but for some things I really prefer a dynamic language.

The flexibility of Django's object abstraction would be a lot harder to create with Go. If I don't need to use a database I use Go, but if I do; python is my language of choice.

>Something in my gut said that using a plain-old, library-level function to spawn a new background process was unnatural.

Nothing unnatural about it. Besides, that's how Rust and Clojure also do it, iirc.

Oh, and in this case, it doesn't even spawn a "new background process".

Didn't see any problem with gevent example... Looks like the standard parallel code.

'hacker school' - I'm probably too old, this sounds so entirely lame.

Sounds lame. Background email sending? No problem. Just write management command and call it from cron...

Did you try to put "line-height: 1.5em;"? is a lot more readable (:

so fucking full of himself