Why I went from Python to Go (and not node.js)
1–10 of 202 posts
Re: Why I went from Python to Go (and not node.js)
#2Very cool post. The code samples really make me want to try out Go when I get some time to do so. Thanks.
Re: Why I went from Python to Go (and not node.js)
#3Very cool post. The code samples really make me want to try out Go when I get some time to do so. Thanks.
thanks for reading! I recommend starting with http://tour.golang.org/. It's a very useful learning tool.
Re: Why I went from Python to Go (and not node.js)
#4In 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.
Re: Why I went from Python to Go (and not node.js)
#5In 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.
Re: Why I went from Python to Go (and not node.js)
#6In 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.
Yes I get that. I just wanted to point out that a single threaded model is not necessarily a bad thing. It happens in GO too by default.
Re: Why I went from Python to Go (and not node.js)
#7Lots 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 holds huge potential).
For me, Go's major shortcoming is its community's lack of focus on readability as compared to Python.
Re: Why I went from Python to Go (and not node.js)
#8Lots 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…
+1 for dabeaz's coroutines presentation. It's really well done, and if you write Python daily / monthly / even yearly it's worth reading.
Re: Why I went from Python to Go (and not node.js)
#9Lots 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 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.
>Have a look at concurrent.futures
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.
Re: Why I went from Python to Go (and not node.js)
#10I'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 performance or contention worrying about it is premature.