4 ms·

Does it really, though? Go really isn't meant for number crunching, or any CPU-bound code, really. I think it's just fine for a language to not strive to emit

by q3k 6y ago

Does it really, though? Go really isn't meant for number crunching, or any CPU-bound code, really. I think it's just fine for a language to not strive to emit the fastest possible code. I don't mind having an ecosystem where build times are fast in return for less optimized code. We already have plenty of languages that do the opposite (Rust, C++, Haskell, ...), and I would personally hate to see Go's compilation/link times creep up that level.

Thaxll 6y ago
Hmm I disagree, Go is a language that should have workload that is CPU bound, Go is not Python or Ruby it's more C++ in that case. It can do heavy computation, I think it's just a balance of compiler optimization vs compile time.
- cies 6y ago
  Go is a Google project. You may disagree all you like but it's their project and hence their priorities. I would have loved for Go not to copy in the "null mistake", to have generics available to all and to have proper sum types built in. But it does not and Google is not keen on fixing this. So I look elsewhere: Rust, Kotlin, Reason/OCaml, ...
- sanderjd 6y ago
  My take on this has long been that Go created a lot of confusion by initially selling itself as a better C++ when it is actually much closer to a better Python (outside of the data science use cases). Edit to add: Or a better / easier to deploy / less reviled / hipper Java. Go is a good and valuable language, but I think perhaps more than any language I know of, a lot of people go into it expecting it to be something that it is not.
Touche 6y ago
Why am I using a language with pointers if it doesn't care about being fast? Another problem with not having a smart compiler is the gigantic binaries it produces. For wasm, an officially supported target, this makes it a non-starter.
- q3k 6y ago
  > Why am I using a language with pointers if it doesn't care about being fast? Because, I assume, you want to differentiate between pass-by-value and pass-by-reference - and pointers are a familiar, simple (if not simplistic) way of expressing that.
- remus 6y ago
  > Why am I using a language with pointers if it doesn't care about being fast? I think there's a big difference between 'I dont care about speed' and 'fast enough'. Go sits pretty firmly in the 'fast enough' category for a lot of people, but of course if you lose sight of speed concerns entirely it'll quickly slow down and then won't be fast enough for a lot of people.
- kevindong 6y ago
  I think Go does care about being fast, but only to a degree. Having the compiled binary being as fast as possible isn't actually one of the listed pain points that Go was designed to solve [0]. [0]: https://talks.golang.org/2012/splash.article#TOC_4 https://talks.golang.org/2012/splash.article#TOC_4.
nirui 6y ago
I write Go and a bit Rust. I don't think compile time could be a huge problem, because: 1. There are ways to reduce it. For example incremental compiling, only recompile what's needed. 2. Many programmers already using CI when they're test/deploy/release their projects. And CI itself takes a long time to initialize and execute, basically throws away almost all the benefits of a fast compiler. 3. Let's don't forget the compiler could have different compile mode (Debug/Release mode), if Go wants to introduce it of course.

by q3k 6y ago

Thaxll 6y ago

Hmm I disagree, Go is a language that should have workload that is CPU bound, Go is not Python or Ruby it's more C++ in that case. It can do heavy computation, I think it's just a balance of compiler optimization vs compile time.

cies 6y ago
Go is a Google project. You may disagree all you like but it's their project and hence their priorities. I would have loved for Go not to copy in the "null mistake", to have generics available to all and to have proper sum types built in. But it does not and Google is not keen on fixing this. So I look elsewhere: Rust, Kotlin, Reason/OCaml, ...
sanderjd 6y ago
My take on this has long been that Go created a lot of confusion by initially selling itself as a better C++ when it is actually much closer to a better Python (outside of the data science use cases). Edit to add: Or a better / easier to deploy / less reviled / hipper Java. Go is a good and valuable language, but I think perhaps more than any language I know of, a lot of people go into it expecting it to be something that it is not.

Touche 6y ago

Why am I using a language with pointers if it doesn't care about being fast? Another problem with not having a smart compiler is the gigantic binaries it produces. For wasm, an officially supported target, this makes it a non-starter.

q3k 6y ago
> Why am I using a language with pointers if it doesn't care about being fast? Because, I assume, you want to differentiate between pass-by-value and pass-by-reference - and pointers are a familiar, simple (if not simplistic) way of expressing that.
remus 6y ago
> Why am I using a language with pointers if it doesn't care about being fast? I think there's a big difference between 'I dont care about speed' and 'fast enough'. Go sits pretty firmly in the 'fast enough' category for a lot of people, but of course if you lose sight of speed concerns entirely it'll quickly slow down and then won't be fast enough for a lot of people.
kevindong 6y ago
I think Go does care about being fast, but only to a degree. Having the compiled binary being as fast as possible isn't actually one of the listed pain points that Go was designed to solve [0]. [0]: https://talks.golang.org/2012/splash.article#TOC_4 https://talks.golang.org/2012/splash.article#TOC_4.

nirui 6y ago

I write Go and a bit Rust. I don't think compile time could be a huge problem, because: 1. There are ways to reduce it. For example incremental compiling, only recompile what's needed. 2. Many programmers already using CI when they're test/deploy/release their projects. And CI itself takes a long time to initialize and execute, basically throws away almost all the benefits of a fast compiler. 3. Let's don't forget the compiler could have different compile mode (Debug/Release mode), if Go wants to introduce it of course.