6 ms·

Nothing in these results should really surprise anyone. Go is a good tool for writing networking services, but it is not (and does not intend to be) a systems l

by cmyr 8y ago

Nothing in these results should really surprise anyone. Go is a good tool for writing networking services, but it is not (and does not intend to be) a systems language. For another perspective, look at Go versus Python: https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-python3.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

logicallee 8y ago
to be fair, it was explicitly designed to be a systems language, and its specification says "Go is a general-purpose language designed with systems programming in mind." This should be removed, and I would say that it gave up on its design goal of being a systems language.
- sagichmal 8y ago
  "Systems programming language" has multiple, equally-valid definitions. This no-true-Scotsman rules lawyering about language classification is the least interesting possible discussion about a programming language.
  - logicallee 8y ago
    you're right it's not an interesting semantic distinction, but it's weird to have people going around saying "but it is not (and does not intend to be) a systems language" when it's an explicit design goal for Go and explicitly mentioned in line 1 of its specifications. OK, not a very interesting discussion.
    - sagichmal 8y ago
      It's not intended to be a [Rust-style] systems language [in which one might implement a resource-constrained operating system]. It's absolutely intended to be a [Google-style] systems language [in which one might implement a large distributed data system].
- yahyaheee 8y ago
  There’s that kubernetes thing of course ;)
- pjmlp 8y ago
  The TPC/IP, WLAN, disk management, system update stacks in Fuchsia sound very like systems programming to me.
rqs 8y ago
Go makes writing networking services like a dream for sure, and Rust also seems have it's own plan[0] on network service field. It could be awesome to see they compete with each other and come up something good. [0] https://internals.rust-lang.org/t/announcing-the-network-services-working-group-wg-net/7354 https://internals.rust-lang.org/t/announcing-the-network-ser...
- PopsiclePete 8y ago
  Rust is still figuring out its "async" story. Go figured it out, and went full steam ahead before the language was even made public - day 0, basically. I'm not holding my breath for Rust dethroning non-perf-critical Go projects anytime soon.
  - rqs 8y ago
    That's true. I'm also use Go primarily to write any application that may needs parallel (Not just network service). For me, Rust is a exciting new language that I could love to use if they can finally put all the async/await things together.
_ph_ 8y ago
I think Go is an excellent systems language, but these benchmarks are not a good measure, for the reasons mentioned by others in this discussion.
lmm 8y ago
Go is a compiled managed language; unsurprisingly performance is similar to Java or C# (or, say, Haskell or OCaml). There was a lot of frankly dishonest promotion of it as a C-like systems language for performance, but reality wins out in the end.
- pjmlp 8y ago
  Given the way it is being used in Fuchsia for writing critical system components like TPC/IP, WLAN, disk management, update infrastructure, it wasn't really dishonest. C code in the 80's was about 80% inline Assembly on 16 bit machines, so surely there is plenty of room to improve Go's optimizer if they so wish. Of course Go will never fit into those PIC micro-controllers with 16 KB of RAM.
- littlestymaar 8y ago
  Being “compiled” (which in reality means “statically-compiled”) doesn't give you magical gains you know. It can even be the opposite, since you can't benefit from JIT optimizations. What makes C, C++ or Rust efficient is not just that they are statically compiled, it's that they have massively-tuned optimizing compiler spending a lot of time in compile-time optimizations. Go's compiler is way less aggressive with optimization because they wants to keep the compile-time low (which is probably a good idea in their niche) and because it has been much less of a focus than for LLVM or Gcc. Also, the lack of generics and the pervasive use of dynamic dispatch (with interfaces) also prevent many optimization but it keeps compilation fast, which is what Go developers want. (Please note that this is not an argument in favor of Go developers not adding generics to the language, they could totally add generics but keep the dynamic dispatch to keep the compile-time as it is right now).

by cmyr 8y ago

logicallee 8y ago

to be fair, it was explicitly designed to be a systems language, and its specification says "Go is a general-purpose language designed with systems programming in mind." This should be removed, and I would say that it gave up on its design goal of being a systems language.

sagichmal 8y ago
"Systems programming language" has multiple, equally-valid definitions. This no-true-Scotsman rules lawyering about language classification is the least interesting possible discussion about a programming language.
- logicallee 8y ago
  you're right it's not an interesting semantic distinction, but it's weird to have people going around saying "but it is not (and does not intend to be) a systems language" when it's an explicit design goal for Go and explicitly mentioned in line 1 of its specifications. OK, not a very interesting discussion.
  - sagichmal 8y ago
    It's not intended to be a [Rust-style] systems language [in which one might implement a resource-constrained operating system]. It's absolutely intended to be a [Google-style] systems language [in which one might implement a large distributed data system].
yahyaheee 8y ago
There’s that kubernetes thing of course ;)
pjmlp 8y ago
The TPC/IP, WLAN, disk management, system update stacks in Fuchsia sound very like systems programming to me.

rqs 8y ago

Go makes writing networking services like a dream for sure, and Rust also seems have it's own plan[0] on network service field. It could be awesome to see they compete with each other and come up something good. [0] https://internals.rust-lang.org/t/announcing-the-network-services-working-group-wg-net/7354 https://internals.rust-lang.org/t/announcing-the-network-ser...

PopsiclePete 8y ago
Rust is still figuring out its "async" story. Go figured it out, and went full steam ahead before the language was even made public - day 0, basically. I'm not holding my breath for Rust dethroning non-perf-critical Go projects anytime soon.
- rqs 8y ago
  That's true. I'm also use Go primarily to write any application that may needs parallel (Not just network service). For me, Rust is a exciting new language that I could love to use if they can finally put all the async/await things together.

_ph_ 8y ago

I think Go is an excellent systems language, but these benchmarks are not a good measure, for the reasons mentioned by others in this discussion.

lmm 8y ago

Go is a compiled managed language; unsurprisingly performance is similar to Java or C# (or, say, Haskell or OCaml). There was a lot of frankly dishonest promotion of it as a C-like systems language for performance, but reality wins out in the end.

pjmlp 8y ago
Given the way it is being used in Fuchsia for writing critical system components like TPC/IP, WLAN, disk management, update infrastructure, it wasn't really dishonest. C code in the 80's was about 80% inline Assembly on 16 bit machines, so surely there is plenty of room to improve Go's optimizer if they so wish. Of course Go will never fit into those PIC micro-controllers with 16 KB of RAM.
littlestymaar 8y ago
Being “compiled” (which in reality means “statically-compiled”) doesn't give you magical gains you know. It can even be the opposite, since you can't benefit from JIT optimizations. What makes C, C++ or Rust efficient is not just that they are statically compiled, it's that they have massively-tuned optimizing compiler spending a lot of time in compile-time optimizations. Go's compiler is way less aggressive with optimization because they wants to keep the compile-time low (which is probably a good idea in their niche) and because it has been much less of a focus than for LLVM or Gcc. Also, the lack of generics and the pervasive use of dynamic dispatch (with interfaces) also prevent many optimization but it keeps compilation fast, which is what Go developers want. (Please note that this is not an argument in favor of Go developers not adding generics to the language, they could totally add generics but keep the dynamic dispatch to keep the compile-time as it is right now).