5 ms·

Is Go really that efficient? I heard similar claims from somewhere else, and this has been a motivation for me to learn and then build something in Go. And wha

by ameen 13y ago

Is Go really that efficient? I heard similar claims from somewhere else, and this has been a motivation for me to learn and then build something in Go. And what might be the reason for that? Speed? Parallel processing?

blinkingled 13y ago
While I don't have any first hand experience with Go's performance - it is not that hard to believe it will be fast enough - it is a compiled language, so no interpreter / JIT overhead like Ruby / NodeJS. Plus they try to be closer to C where it makes sense (it has pointers but no pointer math for e.g.). The synthetic language benchmarks also put it very close to gcc -O2 C performance. About the only things that need to be improved further (so I've heard) in Go are the GC, coroutine/thread scheduler and crypto performance. They are already better in 1.1 release but Crypto is still not close to OpenSSL performance.
- diakritikal 13y ago
  Crypto performance improvements, briefly benched and blogged by jgc: http://blog.jgc.org/2013/04/update-on-go-11-crypto-performance.html http://blog.jgc.org/2013/04/update-on-go-11-crypto-performan...
- pjmlp 13y ago
  > it is a compiled language, Correction: It is a programming language with two compilers available as the main implementation, but there are also interpreters being developed.
_ak 13y ago
As someone who writes Go code professionally, I find Go code to be really easy and quick to write, with fewer bugs/LOC than any other language I've used. Both compilation and execution speed are really fast, so you have both quick edit-compile-test turnarounds similar to a scripting language while having the execution speed of native code. Not quite as fast as C and C++, but getting there. Writing concurrent code is incredibly easy with the primitives Go provides: goroutines (think of them like green threads multiplexed to 1 to very few OS threads) and channels (similar to pipes). No more faffing around with details of thread creation and teardown or an unreadable mess of callbacks (like you would have in system with event loops). So, if you've written concurrent software (like network servers) before, check it out, you will enjoy it.
- pjmlp 13y ago
  > Both compilation and execution speed are really fast, so you have both quick edit-compile-test turnarounds similar to a scripting language while having the execution speed of native code. It always makes me smile when C and C++ young developers re-discover the compilation times we old timers already enjoyed with Modula-2 and Extended Pascal compilers in the mid-80's.
  - _ak 13y ago
    I learned programming with Turbo Pascal, so I knew before that compilers could be fast and produce efficient code. ;-) If only innovation in Pascal hadn't stopped, we might be using it more than we currently do.
    - pjmlp 13y ago
      It did not stop. Ada, Modula-2, Modula-3, Delphi, Oberon, Oberon-2, Component Pascal, Active Oberon, Zonnon, ... The industry just decided to look into another direction and now with buffer exploits everywhere, it is rediscovering that you can have strong typing with compilers that produce native code.
      - _ak 13y ago
        Now were we talking about Pascal or everything that vaguely looks like a Wirth language? Delphi, alright, Ada, okay, but the others? Meh. None of them had anything fundamentally innovative or were just too obscure from the beginning.
        mseepgood 13y ago
        Modula and Oberon do not vaguely look like Wirth lanugages, they are Wirth languages. And unlike Pascal, which was designed mainly for educational purposes, Modula and Oberon were designed for real world usage.
        13y ago

by ameen 13y ago

blinkingled 13y ago

While I don't have any first hand experience with Go's performance - it is not that hard to believe it will be fast enough - it is a compiled language, so no interpreter / JIT overhead like Ruby / NodeJS. Plus they try to be closer to C where it makes sense (it has pointers but no pointer math for e.g.). The synthetic language benchmarks also put it very close to gcc -O2 C performance. About the only things that need to be improved further (so I've heard) in Go are the GC, coroutine/thread scheduler and crypto performance. They are already better in 1.1 release but Crypto is still not close to OpenSSL performance.

diakritikal 13y ago
Crypto performance improvements, briefly benched and blogged by jgc: http://blog.jgc.org/2013/04/update-on-go-11-crypto-performance.html http://blog.jgc.org/2013/04/update-on-go-11-crypto-performan...
pjmlp 13y ago
> it is a compiled language, Correction: It is a programming language with two compilers available as the main implementation, but there are also interpreters being developed.

_ak 13y ago

As someone who writes Go code professionally, I find Go code to be really easy and quick to write, with fewer bugs/LOC than any other language I've used. Both compilation and execution speed are really fast, so you have both quick edit-compile-test turnarounds similar to a scripting language while having the execution speed of native code. Not quite as fast as C and C++, but getting there. Writing concurrent code is incredibly easy with the primitives Go provides: goroutines (think of them like green threads multiplexed to 1 to very few OS threads) and channels (similar to pipes). No more faffing around with details of thread creation and teardown or an unreadable mess of callbacks (like you would have in system with event loops). So, if you've written concurrent software (like network servers) before, check it out, you will enjoy it.

pjmlp 13y ago
> Both compilation and execution speed are really fast, so you have both quick edit-compile-test turnarounds similar to a scripting language while having the execution speed of native code. It always makes me smile when C and C++ young developers re-discover the compilation times we old timers already enjoyed with Modula-2 and Extended Pascal compilers in the mid-80's.
- _ak 13y ago
  I learned programming with Turbo Pascal, so I knew before that compilers could be fast and produce efficient code. ;-) If only innovation in Pascal hadn't stopped, we might be using it more than we currently do.
  - pjmlp 13y ago
    It did not stop. Ada, Modula-2, Modula-3, Delphi, Oberon, Oberon-2, Component Pascal, Active Oberon, Zonnon, ... The industry just decided to look into another direction and now with buffer exploits everywhere, it is rediscovering that you can have strong typing with compilers that produce native code.
    - _ak 13y ago
      Now were we talking about Pascal or everything that vaguely looks like a Wirth language? Delphi, alright, Ada, okay, but the others? Meh. None of them had anything fundamentally innovative or were just too obscure from the beginning.
      - mseepgood 13y ago
        Modula and Oberon do not vaguely look like Wirth lanugages, they are Wirth languages. And unlike Pascal, which was designed mainly for educational purposes, Modula and Oberon were designed for real world usage.
        13y ago