Live data from Hacker News

Why I went from Python to Go (and not node.js)

orel.li

11–20 of 202 posts

Re: Why I went from Python to Go (and not node.js)

#11
post #9
post #7

Lots of sentiment, not much substance. Concurrency support is possible in Python, without gevent-style monkey patching (or callback madness). Have a look at concurrent.futures and http://www.dabeaz.com/coroutines/index.html . It really needs a lot more work before it's part of the language's DNA, though. Also, pypy needs much wider adoption as quickly as possible, to address the speed problems (and its STM branch hol…

>Lots of fluff, not much substance. that was deliberate. There has been a glut of "introduction to Go" blog posts, and the documentation for introductory Go from the Go Team is quite good, so I didn't feel the need to author another introductory post. Most of the stories about why people use Go are bigger, established companies, so I wanted to show how it was perceived by a different audience. I don't remember where…

> but this is part of the problem: it's a library. Concurrency deserves language-level support. Adding concurrency at the library level is like adding an object system at the library level.

Which is not a problem at all. Lisp and Scheme have been doing that since forever.

Re: Why I went from Python to Go (and not node.js)

#12
post #9
post #7

Lots of sentiment, not much substance. Concurrency support is possible in Python, without gevent-style monkey patching (or callback madness). Have a look at concurrent.futures and http://www.dabeaz.com/coroutines/index.html . It really needs a lot more work before it's part of the language's DNA, though. Also, pypy needs much wider adoption as quickly as possible, to address the speed problems (and its STM branch hol…

>Lots of fluff, not much substance. that was deliberate. There has been a glut of "introduction to Go" blog posts, and the documentation for introductory Go from the Go Team is quite good, so I didn't feel the need to author another introductory post. Most of the stories about why people use Go are bigger, established companies, so I wanted to show how it was perceived by a different audience. I don't remember where…

> Concurrency deserves language-level support.

I absolutely agree, which is why I said it needs more work.

Re: Why I went from Python to Go (and not node.js)

#13
post #7

Lots of sentiment, not much substance. Concurrency support is possible in Python, without gevent-style monkey patching (or callback madness). Have a look at concurrent.futures and http://www.dabeaz.com/coroutines/index.html . It really needs a lot more work before it's part of the language's DNA, though. Also, pypy needs much wider adoption as quickly as possible, to address the speed problems (and its STM branch hol…

"For me, Go's major shortcoming is its community's lack of focus on readability as compared to Python."

Can you be a bit more concrete here? Because whether you like the code styles enforced by gofmt and the compiler itself or not, Go is the most consistently readable language I've ever used (once you adapt yourself to the language). IMO, this seems like an especially odd problem for someone to have with Go.

Re: Why I went from Python to Go (and not node.js)

#14
post #10

I'd like to see more detail about the real problem he was facing in python. It sounds like he mostly wants a non-blocking background job "I don’t want to set up another daemon, I just want to send some email in the background!" Why not just use Queue (thread-safe, waitable, built-in) and a background thread(pool)? There's an awful global lock on the actual execution of python code, but unless the problem is performan…

Not only that, but there's a multiprocess Queue class as well that is a drop in replacement for the threaded one. So if you are having problems with GIL contention (unlikely, but possible), you can still just as easily use multiple processes.

Re: Why I went from Python to Go (and not node.js)

#15
"As a Django developer, there wasn’t a straightforward and obvious way to just do things in the background on a page request. People suggested I try Celery, but I didn’t like that option at all. A distributed task queue? What? I just want to do something in the background without making the user wait; I don’t need some super comprehensive ultimate computing machine. The whole notion that I would need to set up and configure one of these supported brokers made my spidey sense tingle"

It's not really that hard. I just latch on to a broker that I'm already using elsewhere in my stack (Redis). Celery makes it super simple to run a command in the background.

Re: Why I went from Python to Go (and not node.js)

#16
post #5

In Go, the coroutines are in the same thread. There is a single thread here too(just like node.js). Coroutines are just multiplexed to the one main thread. Multi-Core Processing is handled by coroutine internals too i.e. there may or may not be more than one threads and even if there are more than one threads, they too will be multiplexed with the one main thread.

Goroutines running Go code are multiplexed onto a variable number of system threads (GOMAXPROCS, in the gc implementation), Goroutines running C code, for example via cgo, or when they call a blocking system call, have their own thread.

I believe the number of threads can be higher than GOMAXPROCS, but only GOMAXPROCS can be running at once.

https://groups.google.com/d/topic/golang-nuts/bP6_KD51ed4/di...

Re: Why I went from Python to Go (and not node.js)

#17
post #7

Lots of sentiment, not much substance. Concurrency support is possible in Python, without gevent-style monkey patching (or callback madness). Have a look at concurrent.futures and http://www.dabeaz.com/coroutines/index.html . It really needs a lot more work before it's part of the language's DNA, though. Also, pypy needs much wider adoption as quickly as possible, to address the speed problems (and its STM branch hol…

"For me, Go's major shortcoming is its community's lack of focus on readability as compared to Python." Can you be a bit more concrete here? Because whether you like the code styles enforced by gofmt and the compiler itself or not, Go is the most consistently readable language I've ever used (once you adapt yourself to the language). IMO, this seems like an especially odd problem for someone to have with Go.

Idiomatic Go: http://golang.org/doc/effective_go.html

Idiomatic Python: http://python.net/~goodger/projects/pycon/2007/idiomatic/han... (doesn't cover a number of important things)

When comparing the two, I'm not impressed with Go.

Re: Why I went from Python to Go (and not node.js)

#18
post #9
post #7

Lots of sentiment, not much substance. Concurrency support is possible in Python, without gevent-style monkey patching (or callback madness). Have a look at concurrent.futures and http://www.dabeaz.com/coroutines/index.html . It really needs a lot more work before it's part of the language's DNA, though. Also, pypy needs much wider adoption as quickly as possible, to address the speed problems (and its STM branch hol…

>Lots of fluff, not much substance. that was deliberate. There has been a glut of "introduction to Go" blog posts, and the documentation for introductory Go from the Go Team is quite good, so I didn't feel the need to author another introductory post. Most of the stories about why people use Go are bigger, established companies, so I wanted to show how it was perceived by a different audience. I don't remember where…

> I don't remember where I saw it, but someone talked about using Go in contrast with Java, and the overwhelming reaction was "that's cool but I'm a Python programmer, I'm curious what Python programmers think", so I was just trying to give it that angle.

I have seen more Python/Ruby programmers interested in Go than Java or C++ programmers. Rob Pike seems to have observed it as well.

I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.

http://commandcenter.blogspot.in/2012/06/less-is-exponential...

Re: Why I went from Python to Go (and not node.js)

#20
Another gonatic? I'm immediately reminded of the days when everyone who liked D proclaimed it would overtake C++ and rule the world with terrible, contrived examples: "let me show you why my language is better than yours by completely misunderstanding how to solve a problem, then implementing that broken/overengineered solution in your language, then compare it to something my language's API can do for me, just so we can see how much simpler that bad solution is in my language!"

The insight to async I/O is that this server, for this I/O bound task, will perform as well as your GOMAXPROCS example:

    require('http').createServer(function(req, res) {
        res.writeHead(200);
        res.end("hello world\n");
    }).listen(8000);
But it's a lot simpler. You don't need to bolt on parallelism when you don't actually need parallelism. There are valid reasons to use Go, and there are valid complaints against Node. I don't see any of either here.
Post reply on HN