2 ms·
I really like Go. My team has been working on a Go application at work for the last two months and I've had a great time of it. That said, like all good langua
by lbarrow 14y ago
I really like Go. My team has been working on a Go application at work for the last two months and I've had a great time of it.
That said, like all good languages, it's perfect until you run into the small list of warts that enrage you. In particular, as the author said, the fact that the make() types are different can get pretty annoying. What's really going on there are that make is really the only generic function in Go. That's why it's special -- unlike a lot of Go builtins, it's impossible to write make() in Go. I really do think this is the biggest single wart in the language (although there are others).
I don't really agree with the author's complaints about declaration syntax. I don't find it distracting: just figure out an idiomatic way to do things and move on.
Not having nil-able strings is annoying though. There are plenty of functions both in the standard library and in my own code that return ("", error) simply because the first return type is a string -- in a similar function with a different return type, I'd just return (nil, error) and be done. Not a big deal but it is a wart.
There are also some definite problems with the standard library, but I expect these will get fixed by OSS packages in time.
Before we all dump on Go though, it's worth pointing out some of the really cool innovations in the language that work great:
* Dependency management in the code is awesome. I love that importing a package and not using it is a compilation error. This seems to be so successful that they went and made declaring unused variables an error as well, which also does wonders for readability.
* Once you understand how you're supposed to use it, the GOPATH story is pretty great. Package management can get tricky and it's cool to see a language attacking it head on from the beginning -- you don't want to end up like Ruby.
* The notion of a Go "package" for namespacing -- and the exporting of CapitalizedVariables but not uncapitalizedVariables makes for very readable code. I really like it.
* The multiple return types for error handling definitely makes for more verbose code than the try-catch-finally pattern, but it also feels a bit cleaner. It takes a while to fully see the benefits of it, but it works great in the end.
I'm really excited for the future of this language. I think with a few more years, a few better frameworks, etc, we'll be able to do some really cool stuff very very easily in Go.
- frou_dh 14y agoBut is it that make is inherently confusing or that "creating" things in general is muddied by being conceptually too crowded? There are at least 6 concepts jostling around (make, new, zero values, special reference types, literals, pointers-to-literals). For starters, it seems like that could have have been reduced to 5 by eliminating new(T) completely and allowing the already-idiomatic &T{} to pick up the slack. I must agree with your overall praise for the language. The package/export system and the official tooling is masterfully done!