3 ms·
Go's aha moment IMHO is at the edges. If you have built a complex application (250k+ lines) in C++, Python or Java you know about the quiet undignified pains t
by MetaCosm 13y ago
Go's aha moment IMHO is at the edges. If you have built a complex application (250k+ lines) in C++, Python or Java you know about the quiet undignified pains those projects often suffer.
- Horrible build systems (and horrible build times)
--- Go compiles fast, and the compile and dependency system is baked in
- Impossible to untangle dependencies (don't ever remove an include, who knows where it is used)
--- Go forces you to either use a dependency or remove it, stopping dependency cruft from ever building up
- Nightmare deploys (system wide assumptions)
--- Go deploys with a single platform dependent binary, it is absolutely awesome
- Inconsistent formatting, self-directed standards on formatting.
--- Gofmt is the one true format, heck, even some bad formatting won't compile (try to uncuddle your else to see)
- Inconsistent build systems and build system quality, made worse by using libraries and systems that have their OWN build systems.
--- Go get combined with its include system (use it or lose it) really let you tie together systems in a sane way without any custom build routes.
- Dealing with modern concurrency
--- Go having built in channel communication makes many problems trivial, and allows new methods of abstraction (goes to Go's model of composition).
- danieldk 13y agoI'll take Java as an example, since I only use Python for short scripts. - Horrible build systems (and horrible build times) Maven is a great build system, Java has good compile times, and most modern Java IDEs have incremental compilation. And you can specify versions of dependencies, rather than having to maintain a list of SHA1 hashes of versions considered to be stable. (don't ever remove an include, who knows where it is used) This is primarily a problem in C/C++, where one can indirectly get the correct dependencies by accident. Most modern compiled languages don't have this problem. Go forces you to either use a dependency or remove it, stopping dependency cruft from ever building up Which can be annoying for debugging. I'd rather have my IDE or linter give warnings. - Nightmare deploys (system wide assumptions) 'mvn package', it's also easy to configure maven to build an archive with dependencies, configuration files, or whatever you'd like to be in a deploy. In fact, deployments are even easier than in Go, since my package built on OS X will also deploy on a Linux server. My colleagues use different platforms (a mixture of Linux, Windows, and OS X) and it's never a problem. - Inconsistent formatting, self-directed standards on formatting. It's good that the Go team made a standard formatting. That said, my employer has a default layout. It's a matter of importing an XML file in Eclipse or IntelliJ and everything is in company layout (yay). - Inconsistent build systems and build system quality Nearly every Java library is available via Central Maven Repository. Including versioning :), meaning that if upstream changes their API, it's not your problem. In contrast to Go repository/packages. Dealing with modern concurrency Ever heard of Actor models and Akka? Composable concurrency, across more than one machine. With supervision, routing, etc.
- MetaCosm 13y agoYou are right, it is just as simple as using Java, Akka, Maven, working at a company with a good standard formatting and structure and being forced to use an IDE with conditional compilation and only using packages that support Maven and put themselves in the Maven Ultra-Centralized Repo. Or you could use Go and the text editor of your choice.
- danieldk 13y agoStop being so silly. brew install maven And use the text editor of your choice. (Or you could just install IntelliJ and get a stellar development environment with nearly everything you'd ever need.)