6 ms·

Go so far has always prioritized the things I care most about: - performance & high concurrency - a small language feature set so I can hire & train awesome pr

Go so far has always prioritized the things I care most about: - performance & high concurrency - a small language feature set so I can hire & train awesome programmers with a different background - practical solutions, with a focus on getting things done I feel confident that with Go 2 they will continue to go down this road. The `try` syntax looks kinda confusing with the implicit return. On the other hand, nothing too crazy.

stcredzero 7y ago
I have to say, as time goes on, the more I like contracts. Go concrete types can satisfy go Interfaces. Go concrete types and Interfaces can satisfy contracts. I would actually feel better if the proposed generics were a little less powerful. Composing generics can get ugly. This could be countered by community norms, however.
unscaled 7y ago
The "Go is performant" gospel seems to be coming from people who came from Python and JavaScript to Go. I don't think Go prioritizes performance more than most other popular statically-typed language Java[1], Haskell or Swift (or less popular ones like Ocaml). And Go obviously doesn't prioritize performance as much as C++ or Rust. Case in point is with very same error handling proposal discussed here. You're going to have to pay a performance price for using a handler since the Go compiler not only avoids inlining defer blocks (if I understand correctly), but even allocates dynamic memory for each block. Meanwhile, equivalent RAII in C++ has no overhead over manual code. Yes, the Go compiler team is now working on working on fixing this issue, but defer is not a new language construct and they should have started fixing that long ago, considered how often it's being used. What's worse, they still didn't make it a stated goal to eliminate the overhead of using defer completely, but only talk about reducing overhead in common cases. This approach makes me sad, because Go does have the engineering power and stated design goals to be more serious about performance. Yeah, I feel confident Go will keep improving, but just the same as Java does (without the same hype). [1] Although until recently they did have radically different choices about which kind of performance to optimize, e.g. Java went up with throughput (Throughput-optimized, JIT tricks for fastest execution after warmup), while Go went for low worst-case latency and faster startup time.
- throwaway34241 7y ago
  I'm not GP, but I like Go because it prioritizes performance in addition to compile times, ease of use, safety, etc. I don't think anyone is claiming that Go will outperform well-optimized C++, if you're willing to write your server software in it. Of the languages you mentioned Java would be the most typically considered alternative for server software. You mentioned Go's low latency but there's also some other strengths like more control of memory layout, slices make it easy to avoid copying in APIs, Goroutines can be lighter weight than Java threads, etc. But as long as Go is roughly comparable I think it's fair to consider Go performant, since Java itself is one of the most mature and optimized languages for server software.
  - jbergens 7y ago
    An interesting question is how the compile times in Go compares to those of Java and C#. If the language is somewhat easier, but not very easy, and compiles faster but not really that much faster, it might not be a good way forward for Java and C# developers. I've always assumed that the compile time comparisons were made against C++ since Google had a lot of large systems written in C++ that they said took a long, long time to compile. Today I think C# using .NET Core is a good general language. It is easy to learn, fast and compilles pretty fast. It also handles concurrency with async/await or threads. It still has longer start up time than Go, like Java, and might use a bit more memory but should work for most systems.
    - GoblinSlayer 7y ago
      JIT time disappears after a warm up, but cold start of a .net application is massive.
      - pjmlp 7y ago
        AOT has always been an option on .NET, even if until Windows 8 it lacked some love. Additionally it has been available in Mono and other runtimes as well.
    - 7y ago
tschellenbach 7y ago
Yes there are languages that are easier to work with, and yes there are languages that are faster. If you want to support hundreds of millions of users and have a relatively small dev team, Go is one of the best options out there since it's both performant and productive to work with.

stcredzero 7y ago

I have to say, as time goes on, the more I like contracts. Go concrete types can satisfy go Interfaces. Go concrete types and Interfaces can satisfy contracts. I would actually feel better if the proposed generics were a little less powerful. Composing generics can get ugly. This could be countered by community norms, however.

unscaled 7y ago

The "Go is performant" gospel seems to be coming from people who came from Python and JavaScript to Go. I don't think Go prioritizes performance more than most other popular statically-typed language Java[1], Haskell or Swift (or less popular ones like Ocaml). And Go obviously doesn't prioritize performance as much as C++ or Rust. Case in point is with very same error handling proposal discussed here. You're going to have to pay a performance price for using a handler since the Go compiler not only avoids inlining defer blocks (if I understand correctly), but even allocates dynamic memory for each block. Meanwhile, equivalent RAII in C++ has no overhead over manual code. Yes, the Go compiler team is now working on working on fixing this issue, but defer is not a new language construct and they should have started fixing that long ago, considered how often it's being used. What's worse, they still didn't make it a stated goal to eliminate the overhead of using defer completely, but only talk about reducing overhead in common cases. This approach makes me sad, because Go does have the engineering power and stated design goals to be more serious about performance. Yeah, I feel confident Go will keep improving, but just the same as Java does (without the same hype). [1] Although until recently they did have radically different choices about which kind of performance to optimize, e.g. Java went up with throughput (Throughput-optimized, JIT tricks for fastest execution after warmup), while Go went for low worst-case latency and faster startup time.

throwaway34241 7y ago
I'm not GP, but I like Go because it prioritizes performance in addition to compile times, ease of use, safety, etc. I don't think anyone is claiming that Go will outperform well-optimized C++, if you're willing to write your server software in it. Of the languages you mentioned Java would be the most typically considered alternative for server software. You mentioned Go's low latency but there's also some other strengths like more control of memory layout, slices make it easy to avoid copying in APIs, Goroutines can be lighter weight than Java threads, etc. But as long as Go is roughly comparable I think it's fair to consider Go performant, since Java itself is one of the most mature and optimized languages for server software.
- jbergens 7y ago
  An interesting question is how the compile times in Go compares to those of Java and C#. If the language is somewhat easier, but not very easy, and compiles faster but not really that much faster, it might not be a good way forward for Java and C# developers. I've always assumed that the compile time comparisons were made against C++ since Google had a lot of large systems written in C++ that they said took a long, long time to compile. Today I think C# using .NET Core is a good general language. It is easy to learn, fast and compilles pretty fast. It also handles concurrency with async/await or threads. It still has longer start up time than Go, like Java, and might use a bit more memory but should work for most systems.
  - GoblinSlayer 7y ago
    JIT time disappears after a warm up, but cold start of a .net application is massive.
    - pjmlp 7y ago
      AOT has always been an option on .NET, even if until Windows 8 it lacked some love. Additionally it has been available in Mono and other runtimes as well.
  - 7y ago

tschellenbach 7y ago

Yes there are languages that are easier to work with, and yes there are languages that are faster. If you want to support hundreds of millions of users and have a relatively small dev team, Go is one of the best options out there since it's both performant and productive to work with.