The Dulin Report

Try as I might I can't bring myself to like JavaScript. In a debate with a colleague, I was asked, "If not JavaScript, what language would you use if you had to start over?"

If someone asked me that question 3-4 years ago, I would have likely said Java. At that point in my career, I spent some solid fifteen years building enterprise applications in Java, and I was perfectly happy with it.

The rise of Node as an enterprise platform forced me to adopt JavaScript for a good chunk of my work. My verdict on JavaScript is simple: I believe that the corporations who have chosen to use it as an enterprise application platform will pay for their mistake dearly in the years to come. I no longer feel it is a platform suitable for large complex applications.

There are situations where there is no choice of a programming language platform. For example, making native applications for iOS is best done in Swift. JavaScript is the only viable platform for interactive web applications.

In the past three years, I have been doing more and more of my work in Golang. If I had to pick a language for backend microservice development (which is where 99% of my career has been), I would now gladly choose Go.

Cross-platform nature of Java has not been relevant for at least a decade now

Java's biggest selling point used to be platform independence: "Write once, run anywhere." The reality is that in my career, I don't think I ever needed to run my software on anything other than a Linux x86 server.

The problem of portability has long been solved by containers, like Docker. Therefore, it is no longer relevant for compilers to produce cross-platform bytecode and require a complex virtual machine to run it.

It turns out that JavaScript is not that simple

I feel that JavaScript was forced upon me by management types who perpetuated myths about its simplicity.

In JavaScript, there is an infinite number of ways to do the same task. The resulting code is borderline unreadable. Developers may not even find bugs long after the system is in production.

Pointers aren't that complicated

Developers have been building applications in Objective-C for iOS, and pointers have never been an issue. In Java, just about everything is referenced via pointers. The real problem with pointers is knowing when to deallocate memory.

Java solves it with a complex and resource-intensive garbage collection mechanism. Go also relies on garbage collection, but optimizes it for low latency.

Concurrency in Java has become too bloated with too many ways to shoot oneself in the foot

Go concurrency is vastly simpler than Java yet more flexible than the Node.js model.

Back in the 1990s, Java supported the concept of "green threads," but they were ridiculously inefficient. The community was ecstatic when Java began to support native operating system threads.

Go does green threads far more efficiently, resulting in much better utilization of multi-core servers.

Object orientation isn't that critical

Go is not object-oriented. In practice, there is rarely a reason to use more than three layers of inheritance.

Despite not being object-oriented, Go supports inheritance by composition, which is good enough for most projects.

Deployment package size matters

Both Java and JavaScript are dynamically linked and require the final deployment package to have all of the dependencies. If your code is using one function out of hundreds offered by a module, you need to include the entire module in your deployable package. A complex application can reach hundreds of megabytes in size, not gigabytes.

Large deployable packages are costly when used with modern-day containers and serverless functions. Large containers take longer to bootstrap, longer to build, longer to deploy. Large functions have long wake up times and may not work at all as they exceed the maximum footprint enforced by the cloud provider.

Go, on the other hand, is statically linked and produces a single executable binary all dependencies in it. A complex application can be no more than a few megabytes in size. It is quick to start, ready to run, and exerts little pressure on computing resources.

Final thoughts

There is little reason not to use Go for a brand new application, or brand new services for an existing application. It's a platform ideal for cloud-native applications due to its compactness and efficiency.