4 ms·
What the go team fails to realize is that they haven't actually reduced complexity in their design of go; they've simply MOVED it. And it's been moved in unintu
by kstenerud 6y ago
What the go team fails to realize is that they haven't actually reduced complexity in their design of go; they've simply MOVED it. And it's been moved in unintuitive ways as they've painted themselves into corners that should have been avoidable with some careful planning.
We now have:
- magic file names
- magic directory names
- magic comments
- magic env vars
- API design requires gymnastics and juggling since recursive imports are disallowed
- A ton of useful code in the standard library remains unlayered and unexposed for no good reason (pprof, for example)
- Requiring full paths rather than relative imports complicates everything when you're fetching it from a different source location (replace directives and magic ENV vars).
- Slice implementation means that you need to do double pointer storage to keep track of the same slice from multiple places
- Creating arrays with a dynamically defined length is horribly overcomplicated
- Their policy on warnings and instead calling every little thing an error is terrible and wastes a ton of developer time.
- Lack of runtime const value support is just sloppy.
- Why do go source files even need a package declaration? It serves no useful purpose since the compiler already knows enough to spit out an error if you get it wrong.
- Refactoring across packages is nearly impossible to automate because there's no way to declare adherence to an interface.
- No importing of test code from other test code (which means that the import code in the compiler has increased complexity to enforce this silly rule).
- Stack overflows are STILL impossible to track down (after a DECADE!) because it only prints the top of the stack, which is useless in such a case.
- Linting is too opinionated and is all-or-nothing.
------------------
I could go on. I really wanted to like go, and many parts of it do actually feel nice. But even after a decade it's a huge mess. I've spent more time writing workarounds for go than for any other language in my 25 year career. Hell, I even modified the damn compiler out of frustration! [1]
[1] https://github.com/kstenerud/go#the-go-programming-language https://github.com/kstenerud/go#the-go-programming-language
- dan_hawkins 6y ago> - Why do go source files even need a package declaration? It serves no useful purpose since the compiler already knows enough to spit out an error if you get it wrong. I know about one use for it: package mypackage_test allows you to exclude test code from builds. I agree with the rest of your points though :)