![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Second impressions of Go
Sep. 11th, 2015 09:57 pmGo is the new trendy programming language. In style it's kind of a backwards C, with an interesting amount of object-oriented features baked in. You can definitely get things done in Go, especially if you're not trying to interface to legacy systems.
As a modern language, though, the things it's missing seem odd. C++ has had parameterized template types as long as I've known it, and Java added them in eventually, but not Go, it's complicated. This means that basic functional-language primitives that are addictingly useful are essentially impossible to write. ( Remember 6.001? )
Most things in Go work by returning pairs of an actual result and a flag or error object. This does lead to making it more obvious to try to do some error handling, and it is "better" than both exception-based languages (where it's easy to ignore errors until they crash your program) or C's magic return value (where an int is an int, unless it's -1). But it also leads to more boilerplate. ( In which we briefly introduce monads )
There's one other oddity I've run into: ( When is nil not nil? )
Even so, the things that people find attractive about Go are still attractive. It's a compiled language, that isn't 30+ years old or owned by Oracle, that compiles reasonably obviously but can't obviously crash from pointer arithmetic errors. It's garbage-collected, which you may object to, but it beats the pants off of explicit memory management. The language includes maps and queues as base types, and if you secretly did like C memory management, you can relive the past with concrete arrays underneath slice views. I admit to having done almost nothing with goroutines, but the promise of the runtime having a select loop and thread management and synchronized channels in the core is much better than anything I've used that doesn't involve a big C library.
As a modern language, though, the things it's missing seem odd. C++ has had parameterized template types as long as I've known it, and Java added them in eventually, but not Go, it's complicated. This means that basic functional-language primitives that are addictingly useful are essentially impossible to write. ( Remember 6.001? )
Most things in Go work by returning pairs of an actual result and a flag or error object. This does lead to making it more obvious to try to do some error handling, and it is "better" than both exception-based languages (where it's easy to ignore errors until they crash your program) or C's magic return value (where an int is an int, unless it's -1). But it also leads to more boilerplate. ( In which we briefly introduce monads )
There's one other oddity I've run into: ( When is nil not nil? )
Even so, the things that people find attractive about Go are still attractive. It's a compiled language, that isn't 30+ years old or owned by Oracle, that compiles reasonably obviously but can't obviously crash from pointer arithmetic errors. It's garbage-collected, which you may object to, but it beats the pants off of explicit memory management. The language includes maps and queues as base types, and if you secretly did like C memory management, you can relive the past with concrete arrays underneath slice views. I admit to having done almost nothing with goroutines, but the promise of the runtime having a select loop and thread management and synchronized channels in the core is much better than anything I've used that doesn't involve a big C library.
