4 ms·

A few: - Go has language-level support, in the form of goroutines, for multithreaded concurrency. Python is single-OS-thread-only, and PyPy doesn't change tha

A few: - Go has language-level support, in the form of goroutines, for multithreaded concurrency. Python is single-OS-thread-only, and PyPy doesn't change that. - Go has enough static typing to help you write safer code, without the verbosity of "bigger" languages like C++ or Java. If you write a lot of tests for your Python app, you might not have variable typos or function argument type mismatches, but in Go the compiler catches these things. - Go is compiled to machine code. This means that, barring a miracle in JIT/VM research, Go will probably always be faster than PyPy for most tasks. These, together with the fact that many of the niceties of Python are available in Go (lightweight syntax, first-class functions, iterators and list slicing, etc), make it, in my opinion, a compelling alternative to Python.

ak217 14y ago
> Python is single-OS-thread-only, and PyPy doesn't change that. Neither statement is really the whole truth, and Python does have some nice ways to do coroutines and futures now, but I see how Go is better here (those 2 features do need to be in the core of the language) and with your other points, thanks.
batista 14y ago
>- Go is compiled to machine code. This means that, barring a miracle in JIT/VM research, Go will probably always be faster than PyPy for most tasks. Actually it's slower or comparable that simple Python in most cases. And slower than Java, which also uses a JIT. It being "Machine code" doesn't mean much. The implementation also counts, as do the libs. In Python lots of stuff is delegated to plain old C libs.
irahul 14y ago
> Python is single-OS-thread-only, and PyPy doesn't change that. Python uses native multi-threads, but the GIL restriction means only one thread can run at a time regardless of number of cores or processors you have. > If you write a lot of tests for your Python app, you might not have variable typos or function argument type mismatches, but in Go the compiler catches these things. Use pylint and/or syntastic(for vim). > Go is compiled to machine code. This means that, barring a miracle in JIT/VM research, Go will probably always be faster than PyPy for most tasks. Go is slower than Java. http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=go&lang2=java http://shootout.alioth.debian.org/u32/benchmark.php?test=all... They removed lua-jit from the benchmarks. lua-jit will smoke go in most scenarios. Here is a comparison between lua-jit and lua. http://luajit.org/performance_x86.html http://luajit.org/performance_x86.html Native code doesn't mean "always faster than JIT/VM". A good JIT can do optimizations which a static compiler can't. For a long running process with hotspots(same code hit multiple times), a JIT can be as good as(or better) than native code.
- deleted 14y ago
  [deleted]
- masklinn 14y ago
  > Python uses native multi-threads, but the GIL restriction means only one thread can run Can run Python code, if you're multithreading for e.g. IO the IO code will generally release the GIL.
- irahul 14y ago
  For some reason, masklinn's comment is dead. Posting it here: <quote> > Python uses native multi-threads, but the GIL restriction means only one thread can run >> Can run Python code, if you're multithreading for e.g. IO the IO code will generally release the GIL. </quote> Yes, native code can release the GIL and run in parallel. As far as it's pure python, only one thread runs at a time. The options are multiprocessing, gevent style concurrency(which I prefer to node's) and native extensions. It isn't as bleak as people make it out to be.
  - masklinn 14y ago
    > For some reason, masklinn's comment is dead. Posting it here: Sorry, that's probably because I got error messages while posting ending up with 2 or 3 comments, and I removed the extraneous ones. You probably tried to reply to one of those I deleted.

ak217 14y ago

> Python is single-OS-thread-only, and PyPy doesn't change that. Neither statement is really the whole truth, and Python does have some nice ways to do coroutines and futures now, but I see how Go is better here (those 2 features do need to be in the core of the language) and with your other points, thanks.

batista 14y ago

>- Go is compiled to machine code. This means that, barring a miracle in JIT/VM research, Go will probably always be faster than PyPy for most tasks. Actually it's slower or comparable that simple Python in most cases. And slower than Java, which also uses a JIT. It being "Machine code" doesn't mean much. The implementation also counts, as do the libs. In Python lots of stuff is delegated to plain old C libs.

irahul 14y ago

> Python is single-OS-thread-only, and PyPy doesn't change that. Python uses native multi-threads, but the GIL restriction means only one thread can run at a time regardless of number of cores or processors you have. > If you write a lot of tests for your Python app, you might not have variable typos or function argument type mismatches, but in Go the compiler catches these things. Use pylint and/or syntastic(for vim). > Go is compiled to machine code. This means that, barring a miracle in JIT/VM research, Go will probably always be faster than PyPy for most tasks. Go is slower than Java. http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=go&lang2=java http://shootout.alioth.debian.org/u32/benchmark.php?test=all... They removed lua-jit from the benchmarks. lua-jit will smoke go in most scenarios. Here is a comparison between lua-jit and lua. http://luajit.org/performance_x86.html http://luajit.org/performance_x86.html Native code doesn't mean "always faster than JIT/VM". A good JIT can do optimizations which a static compiler can't. For a long running process with hotspots(same code hit multiple times), a JIT can be as good as(or better) than native code.

deleted 14y ago
[deleted]
masklinn 14y ago
> Python uses native multi-threads, but the GIL restriction means only one thread can run Can run Python code, if you're multithreading for e.g. IO the IO code will generally release the GIL.
irahul 14y ago
For some reason, masklinn's comment is dead. Posting it here: <quote> > Python uses native multi-threads, but the GIL restriction means only one thread can run >> Can run Python code, if you're multithreading for e.g. IO the IO code will generally release the GIL. </quote> Yes, native code can release the GIL and run in parallel. As far as it's pure python, only one thread runs at a time. The options are multiprocessing, gevent style concurrency(which I prefer to node's) and native extensions. It isn't as bleak as people make it out to be.
- masklinn 14y ago
  > For some reason, masklinn's comment is dead. Posting it here: Sorry, that's probably because I got error messages while posting ending up with 2 or 3 comments, and I removed the extraneous ones. You probably tried to reply to one of those I deleted.