4 ms·
Just because Go doesn't fit your use case doesn't mean it should be something else. In most cases Go IS a better choice than C/C++ in a server side case. For in
by jaegerpicker 13y ago
Just because Go doesn't fit your use case doesn't mean it should be something else. In most cases Go IS a better choice than C/C++ in a server side case. For instance let's say you are writing a server for a multiplayer game. Most of the server's activity is spent on waiting for IO and managing concurrent socket based connections. There are drawbacks and risks to managing memory in this type of system and Go's concurrency makes writing this code much easier. Another great go use case is a rest based web service, a lot of these are typically written in Java, Ruby, or Python. I love python but go has serious advantages over all three of those languages in this use case. This is where go was designed to be used and it's best spot. The glue servers that are most commonly used for web applications. Go is designed to be simpler, safer, and easier to write than C/C++, Java, or C# but faster, more modern, and more fault tolerant than python or ruby. It's not a perfect language by any means but it does fill a nice sweet spot.
- stcredzero 13y agoI'm writing a multiplayer game in Go. The reason I chose it is that it allows me to control memory layout at a low level. This can be very important for achieving multicore parallelism. (Also known as optimizing for fewer cache misses.)
- jeffdavis 13y agoThat's a good point. There aren't a lot of GC languages that let you control structure layout. Not a problem I face, but interesting.
- stcredzero 13y agoNot a problem I face, but interesting. Only a problem you face if you are trying to keep multiple cores busy with low latency.
- jeffdavis 13y agoI think I'm missing your point. Why do you need a GC language for that?
- stcredzero 13y agoI was more talking about being able to control memory layout.
- jeffdavis 13y ago"Most of the server's activity is spent on waiting for IO and managing concurrent socket based connections." That sounds like a story I've heard a hundred times before. For the cases where it's true, good engineers have already been using one of the many other languages that fills that niche. For cases where that's not the primary problem, Go doesn't help. That doesn't mean Go isn't a better option for some use cases. Great. I just don't understand why it's worth reinventing the universe to get something a little better for some use cases. Fine with me -- I'm not the one doing the work. I am just saying that I don't get it. Especially for Google, a company which could have really made a difference in the way we write software.