Go Is on a Trajectory to Become the Next Enterprise Programming Language

Having used Go a bit and Java heavily, I doubt it. The minimalist approach is opposite of what enterprises want for their general purpose language.<p>Go is extremely verbose. I find myself writing a ton of &quot;one off&quot; single use code because the simple type system and lack of generics. The code may be easy to understand, but there&#x27;s a real lack of flexibility compared to Java.<p>Lack of run time code generation support makes a lot of what Java does impossible. Most common libraries like Jackson, Spring, Hibernate, use runtime code generation and object proxies to make their interfaces cleaner. A lot of what they do would not be possible in Go.<p>Another big shortcoming in Go is lack of runtime analysis. In Java I can instrument code at runtime with almost no cost. Tons of tools like NewRelic use this to implement monitoring. Again, not possible in Go since the binaries are precompiled.<p>Then there&#x27;s the nasty package system, but apparently that&#x27;s being fixed.<p>The only strong contender to realistically replace Java is C#

I didn&#x27;t a find a single argument about why the seniors engineers I used to work with in some of the largest European bank would move away from Java to Go.<p>Those engineers are already hostile to just changing naming conventions or &quot;trying&quot; Kotlin instead or Java and now you want them to use Go ?<p>Most seniors developers working in Fortune 500 learned one major framework like Spring , GWT or JSF and are generally sticking to it for everything.<p>They have absolutely no valid reason to move away from those frameworks because they are slowly approaching the late part of their career where they are eligible to become Manager. Managers in those institutions also have very little incentives to promote a new technology like Go because it would introduce major risk in their projects or dealing with developers hostile to change.<p>I can naturally draw a parallel to Airbnb React Native Fiasco where their mobile engineers wrote platform specific code on each platform because they didn&#x27;t like JavaScript.<p>Go is becoming Node.JS not the new Java , JavaScript is now the new Java , and Java is the new Cobol.<p>It&#x27;ll take half a decade for Go to truly penetrate all the institutions in the same way Node.JS did ( Enterprise , Schools , Bootcamps etc...) and be considered as a mainstream language like Python.<p>But even then , I doubt Go would replace Java. Java is here to stay the same way Cobol is staying.

Without generics (aka. Contracts) I don’t think so.<p>As much as I love how simple the language is in its current state <i>(except for Go Modules, which still feels half baked)</i>, I don’t think the language is strong enough to live in an enterprise environment, yet. The tooling is good, and the community keeps growing and maturing, but the road to full enterprise embracement is quite long. I hope the statement in this article becomes a reality though, because I really enjoy working with it.

I don&#x27;t trust Google, even with a product as popular as golang, to support it for the long haul.<p>I&#x27;ll stick with my C#&#x2F;.NET stack which has been going strong for almost 20 years and it&#x27;s still kicking. What developer tools has Google supported for that long? No thanks.

Why do we always let these Go evangelism pieces get away with insinuating that language simplicity is an unalloyed good?<p>If language simplicity (and the resulting &quot;low cognitive overhead&quot;) were the primary determinant of productivity, we would surely be using far simpler languages than Go (like Brainfuck).<p>What we should really care about is <i>code simplicity</i>, not <i>language simplicity</i>, and the two are definitely not equivalent. If we add features to Brainfuck, the language will get more complex (increasing cognitive overhead), but the code may well get simpler, and far easier to maintain.

The Go team has resisted (deferred?) defining APIs for many common protocols and formats (e.g. LDAP, Websockets).<p>These will be necessary for widespread enterprise adoption. Third parties libraries, offering arbitrary APIs, and maintained by volunteers, don&#x27;t pass muster.<p>Perhaps this work should be undertaken by committees outside the Go team, as it has limited resources.

Yeah, I don&#x27;t think so. As Oracle proceeds to kill Java, C#&#x2F;.Net Core will rise up even further.

It seems like go&#x27;s killer feature, initially, was it&#x27;s approach to concurrency with goroutines and CSP.<p>However, race conditions are still quite possible with goroutines, and many experienced go developers seem to eschew goroutines. It seems like for certain niches go works wonderfully, but I&#x27;m not convinced it will become THE next enterprise programming language.<p>In fact, we may not have another language dominate the enterprise landscape the way java did in the 2000s. It likely will end up being a mix of go, rust, python, java, .net, and node, among others.

I&#x27;ve seen a lot of projects use Go in the enterprise space. They all ran into the issue that Go is a great replacement for C++, a good replacement for real time systems, and a not a great replacement for C# and Java.

Rust and Go combined are on a trajectory to replace the high performance and general application development markets. Rust still has a battle ahead to secure its future, while Go is already most of the way there.

This is a nice overview of Go, but I don&#x27;t see why Go having enterprise features means that its poised to replace java.

As far as I can see, Java is pretty secure.

In case you want to try it out, here&#x27;s a tutorial I wrote a little while ago: <a href="https:&#x2F;&#x2F;getstream.io&#x2F;blog&#x2F;go-1-11-rocket-tutorial&#x2F;" rel="nofollow">https:&#x2F;&#x2F;getstream.io&#x2F;blog&#x2F;go-1-11-rocket-tutorial&#x2F;</a>

If Oracle goes through with the Java licensing threats, Go will have its day for sure.<p>Also, environments like Kubernetes and Openshift make Java kind of heavy--the portability comes via the container and thus there is no need for a portable runtime. A Go program running in a Kubernetes pod is plenty portable already.

but it doesn&#x27;t even have proper classes or exceptions

Why not Rust? I write both, Go feels incomplete, Rust is younger but is much more mature and filled in. I can write faster in Rust, its much like Python development.<p>The mix of functional and imperative styles is odd, but not bad.

What exactly is ‘hackernoon’?<p>A few days ago they posted a critique of Apple that bordered on libelous: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19853263" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19853263</a><p>Now they post a piece heavily promoting a Google language.<p>There are good points in both articles, but it’s interesting to wonder what “hackernoon”’s interest is.