4 ms·

I think you might have bad information. Go is not a systems programming language. You may be thinking of Rust? Go and C++ serve very different needs.

eloff 6y ago
You're being downvoted, but you're correct. Go and C++ have largely different non-overlapping use cases. Go is not a systems language. It's mostly a networked server language with a garbage collector. It's great for writing a wide variety of networked services like HTTP app servers. C++ is great for when you need full control and best possible performance and are willing to pay the hits in complexity, compile time, and other development expenses to achieve that. Drivers, games, trading software, database engines, etc.
- jrockway 6y ago
  I think I only agree with you on games and trading software. In games, you have 4ms (assuming an esports game at 240Hz) to read input, read game state from the network, do all your simulation, draw a frame to the screen, and write the results back to the network. There is absolutely no time budget for anything else; in fact, C++ games don't even manage to run at a 240Hz tickrate and just hack around the input / display handling while they wait for 60Hz networking and simulation run in another thread. (Going off topic, the end result of all of this is an incredible example of what "eventual consistency" means in the real world. Play a multiplayer FPS and you'll never use a database in any mode other than strict serializable again.) For drivers and database implementations, there is more time to do stuff. For example, I wrote a keyboard controller with Tinygo, and it mostly sits around waiting for the USB host's C++ driver to ask it for data. Go isn't adding any latency (and it's not really C++'s fault either; the standard sets a time interval to poll at). And if you wonder what an OS written in Go would look like, look at gVisor. It's not technically an OS, but it does a large number of OS-like things. Database engines that are focused on throughput rather than latency will also do fine with an occasional GC delay. CockroachDB and InfluxDB have plenty of users.
  - eloff 6y ago
    I think GC is not harmful than helpful in drivers and things like an OS. gVisor in particular jumps through hoops for performance and still has poor performance. It could be more successful in C++ or Rust probably. I like Go a lot, but if you needed the performance or manual control it is not the tool for the job. On the other hand most problems don't fit that description and Go is one of the best choices for them.
- seabrookmx 6y ago
  I think a lot of people just assume there's a ton of overlap because Go is AOT compiled into a single binary (like Rust and C/C++). As silly as that is.

eloff 6y ago

You're being downvoted, but you're correct. Go and C++ have largely different non-overlapping use cases. Go is not a systems language. It's mostly a networked server language with a garbage collector. It's great for writing a wide variety of networked services like HTTP app servers. C++ is great for when you need full control and best possible performance and are willing to pay the hits in complexity, compile time, and other development expenses to achieve that. Drivers, games, trading software, database engines, etc.

jrockway 6y ago
I think I only agree with you on games and trading software. In games, you have 4ms (assuming an esports game at 240Hz) to read input, read game state from the network, do all your simulation, draw a frame to the screen, and write the results back to the network. There is absolutely no time budget for anything else; in fact, C++ games don't even manage to run at a 240Hz tickrate and just hack around the input / display handling while they wait for 60Hz networking and simulation run in another thread. (Going off topic, the end result of all of this is an incredible example of what "eventual consistency" means in the real world. Play a multiplayer FPS and you'll never use a database in any mode other than strict serializable again.) For drivers and database implementations, there is more time to do stuff. For example, I wrote a keyboard controller with Tinygo, and it mostly sits around waiting for the USB host's C++ driver to ask it for data. Go isn't adding any latency (and it's not really C++'s fault either; the standard sets a time interval to poll at). And if you wonder what an OS written in Go would look like, look at gVisor. It's not technically an OS, but it does a large number of OS-like things. Database engines that are focused on throughput rather than latency will also do fine with an occasional GC delay. CockroachDB and InfluxDB have plenty of users.
- eloff 6y ago
  I think GC is not harmful than helpful in drivers and things like an OS. gVisor in particular jumps through hoops for performance and still has poor performance. It could be more successful in C++ or Rust probably. I like Go a lot, but if you needed the performance or manual control it is not the tool for the job. On the other hand most problems don't fit that description and Go is one of the best choices for them.
seabrookmx 6y ago
I think a lot of people just assume there's a ton of overlap because Go is AOT compiled into a single binary (like Rust and C/C++). As silly as that is.