undefined | Better HN

0 pointsMetaCosm13y ago0 comments

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).

0 comments

3 comments · 1 top-level

microtonal13y ago· 2 in thread

I'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.

MetaCosmOP13y ago

You 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.

microtonal13y ago

Stop 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.)

j / k navigate · click thread line to collapse