-
I too was playing around with Go generics. I wrote some naive concurrent filter and fold (reduce) functions for slices and maps here https://github.com/unix1/gostdx if anyone is curious how those would feel.
-
CodeRabbit
CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
-
I'd be really happy with that! Building the functionality of errcheck[1] and ineffassign[2] into the compiler — or at the very least, into govet — would go a long way to allay my worries with Go.
I think the reason they don't do this is that it's a slight (albeit a very tiny one) against Go's philosophy of errors being values, just like any other. While the `error` type is standard and used throughout Go source code, it still just has a simple three-line definition[3] and is not treated as a special case anywhere else; there is nothing stopping you from returning your own error type if you wish. A third-party linter could simply check for the `error` type specifically, but the first-party tools should not, and there's nothing like Rust's `#[must_use]` attribute that could be used instead. I respect Go's philosophy, but I feel like pragmatism must win in this case.
[1]: https://github.com/kisielk/errcheck
-
-
I feel the similar way, though I wouldn't be so brave to say I didn't ever use interface{}. I think we all work around slices and maps being the only generic containers and don't know we do. I think everyone will find that while they didn't need generics, they will help them when using utility libraries. Java 1.4 people thought the same.
I expect a well-curated libraries to come about that will really simplify some otherwise difficult problems for people (e.g. task/object pooling). I'm even toying with a futures impl at https://github.com/cretz/fut, but I wouldn't use it in place of channels in most cases.
-
There's a proposal for the Go 2 draft that addresses this:
https://github.com/golang/go/issues/20803
https://go.googlesource.com/proposal/+/master/design/go2draf...
-
-
I found this closed-mindedness hard to understand -- I don't spend very much conscious thought on the syntax when programming at all -- but for people like you facebook made Reason ML https://reasonml.github.io/
Someone should port OCaml to the Go runtime with a good high-level FFI. It could really give the community a boost.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives