4 ms·

This sounds really interesting and compelling. As someone new to Go... What would be the advantages of using Go over Python (taking into account the emergence

by ak217 14y ago

This sounds really interesting and compelling. As someone new to Go... What would be the advantages of using Go over Python (taking into account the emergence and future ascendancy of pypy)?

dhconnelly 14y ago
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
micro_cam 14y ago
On the surface they feel similar in that they are both quite concise. Concurrency is a hugh difference. Python's approach to concurrency is the "global interpreter lock" which means only one thread can be running at once to prevent you from trying to access shared objects from multiple threads. Go has lite weight "go routines" that are multiplexed across os threads in parallel and channels that can be used for passing variables between them and the defer statement to help clean up. This sounds complicated at first but it is the simplest system for reasoning about concurrent code I have used. Go also has pointers, mutexes, fixed sized arrays (with easy to use dynamic slices over them) and other things that let you implement low level data structures when you need to. Go has interfaces and embedding but no inheritance which leads to iterative development of organization instead of needing to design from the start. The standard library makes extensive use of these and is extremely well organized...I much prefer go's http client code for example. It doesn't have as extensive a corpus of library implemented in optimized C/fortran and I really miss things like numpy...in many cases python code can be faster because the libraries do all the heavy lifting.
swdunlop 14y ago
Go has a smaller, narrower standard library that is more tightly maintained and governed than Python. Python's original slogan, "batteries included" could be amended after 20 years of use to "bitrot included." Some libraries have partially broken semantics that have been maintained because legacy applications rely on those broken semantics. Python modules don't even agree on tab width or casing. Part of that is youth, Go went 1.0 just this Spring, and had a serious housecleaning applied in the process. "Being boring" is a big part of Go's identity -- most changes have been pragmatic and thoroughly thought out, and when they come, "gofix" often knows how to apply them to legacy code. (Static linking doesn't hurt, either.) In theory, Go has more to gain in performance with the GC leaving a lot of room for improvement -- CPython has been subject to a lot of tuning over the years and has found a nice local maximum to settle on. In practice, this does not matter nearly as much as picking the right algorithm, profiling, and avoiding dumb mistakes. (A favorite gaffe: "string concatenation is faster than using a format string in Python".)
deleted 14y ago
[deleted]
deleted 14y ago
[deleted]

by ak217 14y ago

This sounds really interesting and compelling. As someone new to Go... What would be the advantages of using Go over Python (taking into account the emergence and future ascendancy of pypy)?

dhconnelly 14y ago

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

micro_cam 14y ago

On the surface they feel similar in that they are both quite concise. Concurrency is a hugh difference. Python's approach to concurrency is the "global interpreter lock" which means only one thread can be running at once to prevent you from trying to access shared objects from multiple threads. Go has lite weight "go routines" that are multiplexed across os threads in parallel and channels that can be used for passing variables between them and the defer statement to help clean up. This sounds complicated at first but it is the simplest system for reasoning about concurrent code I have used. Go also has pointers, mutexes, fixed sized arrays (with easy to use dynamic slices over them) and other things that let you implement low level data structures when you need to. Go has interfaces and embedding but no inheritance which leads to iterative development of organization instead of needing to design from the start. The standard library makes extensive use of these and is extremely well organized...I much prefer go's http client code for example. It doesn't have as extensive a corpus of library implemented in optimized C/fortran and I really miss things like numpy...in many cases python code can be faster because the libraries do all the heavy lifting.

swdunlop 14y ago

Go has a smaller, narrower standard library that is more tightly maintained and governed than Python. Python's original slogan, "batteries included" could be amended after 20 years of use to "bitrot included." Some libraries have partially broken semantics that have been maintained because legacy applications rely on those broken semantics. Python modules don't even agree on tab width or casing. Part of that is youth, Go went 1.0 just this Spring, and had a serious housecleaning applied in the process. "Being boring" is a big part of Go's identity -- most changes have been pragmatic and thoroughly thought out, and when they come, "gofix" often knows how to apply them to legacy code. (Static linking doesn't hurt, either.) In theory, Go has more to gain in performance with the GC leaving a lot of room for improvement -- CPython has been subject to a lot of tuning over the years and has found a nice local maximum to settle on. In practice, this does not matter nearly as much as picking the right algorithm, profiling, and avoiding dumb mistakes. (A favorite gaffe: "string concatenation is faster than using a format string in Python".)

deleted 14y ago

[deleted]

deleted 14y ago

[deleted]