6 ms·

I mean, Go is closer to C than Python is. But Go is still a garbage collected language with a runtime. It's not going to come close to the limits of performance

I mean, Go is closer to C than Python is. But Go is still a garbage collected language with a runtime. It's not going to come close to the limits of performance that C offers

morelisp 4y ago
Having played with this a previous time it was posted and looking at the profiler results, the main difference between the Go and C isn't due to any memory allocations but rather the lack of in-place update and slightly higher cost from being general-purpose in Go's hash table. (This is also probably why Rust, without the GC overhead, clusters with Go rather than C.)
- sidlls 4y ago
  I'm fairly certain that if one wrote C (or C++) programs with the same safety targets that Rust has out-of-the-box the performance is close, if not (for practical purposes) identical. Of course, to do much useful (and performant) in Rust one often has to break out `unsafe`, which eliminates some of the out-of-the-box guarantees for safety--and in some cases makes one wonder if it's worth all the overhead instead of just using C or C++.
  - morelisp 4y ago
    > the same safety targets Rust's selling point is that the safety targets' costs are dev/compile-time ones. There should not be a difference unless the C/C++ code requires some IB or extremely manual memory management trickery, which it doesn't; and Go offers basically the same memory safety guarantees as Rust in this regard and is (slightly) faster. In this case it's really almost entirely about the speed of the hash table.
    - sidlls 4y ago
      I was referring to the overhead of development time. Rust is more complex than C, at least, and even after having gained proficiency coding in Rust still takes more time than writing an equivalent C program. And "zero-cost" is misleading. There are definitely performance impacts from the implicit (and unadvertised explicit) bounds checking some of Rust's features come with. Writing a C program to an equivalent level of safety would have similar performance impacts. Hence, for as close to the same safety as possible, Rust and C should be almost identical in terms of performance.
k__ 4y ago
That's probably the reason why Go got many people switching from their scripting languages and didn't end up as the C killer it was sold in the beginning.
- pdimitar 4y ago
  That's exactly my reason to use it: fast prototyping and ability to replace bash scripts (as they become too unwieldy to maintain and expand from one point and on). I've also successfully made an MVP with Golang which I then proceeded to rewrite in Rust in almost only one go and almost without blockers along the way. Golang is pretty good but it still lacks important things like algebraic data types, and they're hugely important for fearless refactoring and correctness.
- taf2 4y ago
  I never remember it being sold as a C killer maybe as a Java killer?
  - habibur 4y ago
    It was sold as C killer in the beginning. And then a few years later there was an article that said, the Go engineers were surprised when they saw C/C++ coders weren't switching to Go rather Python/Ruby coders were "upgrading" to Go.
  - capableweb 4y ago
    golang.org circa 2010: > go is ... fast > Go compilers produce fast code fast. Typical builds take a fraction of a second yet the resulting programs run nearly as quickly as comparable C or C++ code. https://web.archive.org/web/20100217123645/http://golang.org/ https://web.archive.org/web/20100217123645/http://golang.org... That seems to me like they were trying to say "If you want C/C++ performance but nicer/easier syntax, you can use Go", which turned out to be not that true in the end. Edit: the old "Language Design FAQ" also goes further in detail on how the envision (the first version of the) language: https://web.archive.org/web/20100211104313/http://golang.org/doc/go_lang_faq.html https://web.archive.org/web/20100211104313/http://golang.org...
  - deleted 4y ago
eloff 4y ago
For a script like this your be surprised. If you don't do too much allocation, the garbage collector need not run. In fact it's common to disable it at the start. Now you can allocate much faster than C because you never clean up after yourself! A real world example is esbuild, the author implemented it both Rust and Go initially. The Go version was faster and the code simpler. Which is why it's implemented in Go.
- leethaxor 4y ago
  > A real world example is esbuild, the author implemented it both Rust and Go initially. The Go version was faster and the code simpler. Which is why it's implemented in Go. But why is swc faster than esbuild then? The code isn't even considerably more complex.
  - eloff 4y ago
    Because different programs, implemented differently, run at different speeds... I'm saying the performance of Go can sometimes be surprisingly fast. Not that it's magic.
    - leethaxor 4y ago
      So you're saying they wrote exactly the same program in Go and Rust for the comparison, changing the syntax only? Well then it's no surprise the Go version was faster. Don't write Rust as if it was Go. That doesn't say anything meaningful about either Go or Rust.
      - eloff 4y ago
        Actually he wrote the Rust version first, so you're wrong jumping to conclusions. I'm not trying to say Go is faster than Rust, it's usually slower. But there are always exceptions to the rule. The Go code, on the other hand, is usually simpler and quicker to write. For that reason I'd prefer Go if the problem lends itself to a garbage collected language.

I mean, Go is closer to C than Python is. But Go is still a garbage collected language with a runtime. It's not going to come close to the limits of performance that C offers

morelisp 4y ago

Having played with this a previous time it was posted and looking at the profiler results, the main difference between the Go and C isn't due to any memory allocations but rather the lack of in-place update and slightly higher cost from being general-purpose in Go's hash table. (This is also probably why Rust, without the GC overhead, clusters with Go rather than C.)

sidlls 4y ago
I'm fairly certain that if one wrote C (or C++) programs with the same safety targets that Rust has out-of-the-box the performance is close, if not (for practical purposes) identical. Of course, to do much useful (and performant) in Rust one often has to break out `unsafe`, which eliminates some of the out-of-the-box guarantees for safety--and in some cases makes one wonder if it's worth all the overhead instead of just using C or C++.
- morelisp 4y ago
  > the same safety targets Rust's selling point is that the safety targets' costs are dev/compile-time ones. There should not be a difference unless the C/C++ code requires some IB or extremely manual memory management trickery, which it doesn't; and Go offers basically the same memory safety guarantees as Rust in this regard and is (slightly) faster. In this case it's really almost entirely about the speed of the hash table.
  - sidlls 4y ago
    I was referring to the overhead of development time. Rust is more complex than C, at least, and even after having gained proficiency coding in Rust still takes more time than writing an equivalent C program. And "zero-cost" is misleading. There are definitely performance impacts from the implicit (and unadvertised explicit) bounds checking some of Rust's features come with. Writing a C program to an equivalent level of safety would have similar performance impacts. Hence, for as close to the same safety as possible, Rust and C should be almost identical in terms of performance.

k__ 4y ago

That's probably the reason why Go got many people switching from their scripting languages and didn't end up as the C killer it was sold in the beginning.

pdimitar 4y ago
That's exactly my reason to use it: fast prototyping and ability to replace bash scripts (as they become too unwieldy to maintain and expand from one point and on). I've also successfully made an MVP with Golang which I then proceeded to rewrite in Rust in almost only one go and almost without blockers along the way. Golang is pretty good but it still lacks important things like algebraic data types, and they're hugely important for fearless refactoring and correctness.
taf2 4y ago
I never remember it being sold as a C killer maybe as a Java killer?
- habibur 4y ago
  It was sold as C killer in the beginning. And then a few years later there was an article that said, the Go engineers were surprised when they saw C/C++ coders weren't switching to Go rather Python/Ruby coders were "upgrading" to Go.
- capableweb 4y ago
  golang.org circa 2010: > go is ... fast > Go compilers produce fast code fast. Typical builds take a fraction of a second yet the resulting programs run nearly as quickly as comparable C or C++ code. https://web.archive.org/web/20100217123645/http://golang.org/ https://web.archive.org/web/20100217123645/http://golang.org... That seems to me like they were trying to say "If you want C/C++ performance but nicer/easier syntax, you can use Go", which turned out to be not that true in the end. Edit: the old "Language Design FAQ" also goes further in detail on how the envision (the first version of the) language: https://web.archive.org/web/20100211104313/http://golang.org/doc/go_lang_faq.html https://web.archive.org/web/20100211104313/http://golang.org...
- deleted 4y ago

eloff 4y ago

For a script like this your be surprised. If you don't do too much allocation, the garbage collector need not run. In fact it's common to disable it at the start. Now you can allocate much faster than C because you never clean up after yourself! A real world example is esbuild, the author implemented it both Rust and Go initially. The Go version was faster and the code simpler. Which is why it's implemented in Go.

leethaxor 4y ago
> A real world example is esbuild, the author implemented it both Rust and Go initially. The Go version was faster and the code simpler. Which is why it's implemented in Go. But why is swc faster than esbuild then? The code isn't even considerably more complex.
- eloff 4y ago
  Because different programs, implemented differently, run at different speeds... I'm saying the performance of Go can sometimes be surprisingly fast. Not that it's magic.
  - leethaxor 4y ago
    So you're saying they wrote exactly the same program in Go and Rust for the comparison, changing the syntax only? Well then it's no surprise the Go version was faster. Don't write Rust as if it was Go. That doesn't say anything meaningful about either Go or Rust.
    - eloff 4y ago
      Actually he wrote the Rust version first, so you're wrong jumping to conclusions. I'm not trying to say Go is faster than Rust, it's usually slower. But there are always exceptions to the rule. The Go code, on the other hand, is usually simpler and quicker to write. For that reason I'd prefer Go if the problem lends itself to a garbage collected language.