I was glad to see Go get generics. Not because it was super-important but rather so we didn't have to hear about it anymore.
I think exceptions are a false economy so I have no real issue with Go's error handling. It could be cleaner. Rust's match expressions are better. Multiple returns are a bit awkward. Something like a result or error union type would be better and could fit in with the type system. Standard errors might allow more automatic (or at least less boilerplate on) propagating errors.
Go's dependency management is the real weak point. Putting domain names in import statements is a massive mistake. Java's Maven repos are simply better. Just ignore the XML for declaring dependencies). Thing slike being able to specify version is what you want. Having someone be able to verify dependencies is what you want. The latter may be necessary in a corporate environment where it may be too much of a security risk to allow open imports.
Maven configuration is a cottage industry in itself. I have not seen developers who know maven from first principles. Despite taking many courses, books, tutorials etc I just dare not touch pom.xml beyond adding/deleting/updating dependencies.
Even then every couple of months maven and IDE combination will run into obscure build issues that will not resolve until all the local maven repos are nuked from desktop.
1. Finding dependencies with tooling now requires parsing code. Luckily Go's syntax is relatively simple and doesn't have conditional includes like C++ does but it'd be better if you could simply inspect a depedency configuration;
2. You're directly importing potentially untrusted code that will often be of the form "github.io/someuser/reponame" so you now have a depedency on some random user's security practices or even just whims (eg making the repo private; IIRC this has happened in the node.js ecosystem);
3. These aren't versioned. You may want to stick to a particular version. A new version may break your code. You should be able to be explicit about that. Now you can "go get" particular versions but how do you specify that such that someone can just check out your code and build it?
4. Managing your own dependency repo (eg in an enterprise environment) is more limited.
seems to me like a worldview problem. are remote resources really persistent and associated with long lived commercial organizations like github? or are they more like urls that come and go.
it would suck to have to deal with another location service, although one could imagine using something like DNS were it sufficiently secure.
but on the other hand, I'm personally kind of offended that there is a rent-seeking intermediary in the middle of my development process
Go always had generics, map, slice, chan are all generic. Go just didn't let the user write any generics, so fuck you if you want any other data structure until 1.18.
If you really think you don't need generics, take your code code and replace every
Almost 40% of respondents either use generics or want to use generics, after having been released 6 months ago in 1.18. That's… a pretty incredible adoption rate for something that I've repeatedly heard wasn't necessary or was a mistake.
I think exceptions are a false economy so I have no real issue with Go's error handling. It could be cleaner. Rust's match expressions are better. Multiple returns are a bit awkward. Something like a result or error union type would be better and could fit in with the type system. Standard errors might allow more automatic (or at least less boilerplate on) propagating errors.
Go's dependency management is the real weak point. Putting domain names in import statements is a massive mistake. Java's Maven repos are simply better. Just ignore the XML for declaring dependencies). Thing slike being able to specify version is what you want. Having someone be able to verify dependencies is what you want. The latter may be necessary in a corporate environment where it may be too much of a security risk to allow open imports.