Go is extremely verbose. I find myself writing a ton of "one off" single use code because the simple type system and lack of generics. The code may be easy to understand, but there's a real lack of flexibility compared to Java.
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.
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.
Then there's the nasty package system, but apparently that's being fixed.
The only strong contender to realistically replace Java is C#
- Go runtime analysis is as good a Java but 10x easier to use, and it uses way less resources than your Java equivalent ( JavaMissionControl, JMX, JVisualStudio, thread dump, Java Flight Recorder ect ... ) Have you tried to leave JFR on when running in production? I can run pprof / tracing with 0 problems, no corruptions of dump or hit on performance.
- NewRelic instruments code using an SDK you have to integrate into your code, there is nothing magic, NR has also the same SDK for Go: https://newrelic.com/golang
- For the generics / package it's on the way to be fixed.
For C# I agree. I think people don't realize how many companies are actually using Go on large project even outside of k8s / cloud world.
And we use Go for a relatively big EHR program.
I haven't used C# for a few years, being stuck deep in my firmware hole. But it sure seems like Microsoft is angling C# that direction. 'Open sourcing it' and making the language more and more cross platform.
A consideration with enterprise software vs web scale infotainment spyware is the former; each transaction has a vastly higher value associated with it then the latter. And the life span of the software is much much longer.
Go needs to be efficient because of the low revenue stream per transaction. And goggle doesn't care about maintence over the long haul because they rewrite and throw away code constantly. Vs enterprise where code is used for decades.
C# is truly superior to Java in tons of ways, but adoption really hurts it's utility. The main driver for Java the last decade or so has been that it's good enough and has a library for anything.
Need a DB driver for an esoteric datastore that died 12 years ago? Java has it. That's the selling point. It will take a decade or more of C# on it's current trajectory to catch up
Those engineers are already hostile to just changing naming conventions or "trying" Kotlin instead or Java and now you want them to use Go ?
Most seniors developers working in Fortune 500 learned one major framework like Spring , GWT or JSF and are generally sticking to it for everything.
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.
It'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.
But even then , I doubt Go would replace Java. Java is here to stay the same way Cobol is staying.
Go is designed to scale with people, in that it discourages clever approaches (in coding, in deploying, and in tooling). The result is that you generally end up with a code base that everyone on the team can deal with and which costs less.
Additionally, our experience is that you need less hardware to run Go applications than Java ones. Another cost savings.
Some tooling is not meant to be touched upon by engineers who aren't as experienced as the more senior developers who create those tools, and that's fine, eventually they will learn not only the limitations of the language but also how and when to push past those limitations by digging deeper into the langauge via compiler, reflection, unsafe code or more.
No it absolutely is not.
Toward the end of the 90s, Java was a cool language with a new paradigm: write once, run everywhere. I remember people advocating it passionately. A few years later, Java was everywhere: servers, web browsers, programming courses… It was de facto the standard language in many domains.
I suppose the OP intended the comparison in this way, not in a feature comparison or a judgement on the maturity of the ecosystem.
I often see enterprises using a mix of languages and technologies (depending on how independent the different org units within it are) and some amount of Java fatigue in developers who are not retiring in less than a decade. Go is often amongst the top choices they are exploring.
NodeJs has been used for rapidly evolving projects with moving API and Springboot for slower paced projects with legacy SOAP API and lot of crypto.
NodeJs apps are still very capable of communicating with message brokers, SQL/NoSQL databases, exposing REST, even SOAP API, doing some authentication, acting as message orchestrators, etc. Even though dealing with CPU bound tasks is not NodeJs forte.
That being said I don't believe that replacing Java with NodeJs is a general trend in the enterprise world (but more than Golang).
Otherwise, you're quite right that enterprise IT culture is deeply conservative.
But that is irrelevant since enterprises don't care about SPAs and so are fine using standard web frameworks like Play, Dropwizard or Tomcat.
As much as I love how simple the language is in its current state (except for Go Modules, which still feels half baked), 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.
Go's very lack of expressive power is what helps make it an enterprise language. It's simple enough and limiting enough so that a non-brilliant developer has little trouble picking it up, and is unlikely to run into a complicated corner case. As statistics inevitably have it, half the developers are below median level, by definition.
The really smart stuff in Go, like goroutines scheduling or lightning-fast GC, is all under the hood, and you don't get to touch it, and don't have to.
You can see the same pattern in other wildly successful languages of the past, such as Fortran, Cobol, Visual Basic, or PHP.
Having one of the largest IT corporations backing the language and actively using it does help, too. But I would not exaggerate this factor: Python got to the top without a comparable corporate support from its creators.
Yeah but now that we have generics the bar has been raised right?
I’m not giving generics up, that’s for sure.
Developers in this categories are not going to say "LOL J2EE" or "LOL Go". They will do whatever being asked and collect paycheck in return. If they chose to be independent voice, they are going to be asked to leave and make way for devs who comply.
Is there a Go equivalent of Object?
In a microservice world, I habe to send a request to 6 microservices and I want to do them concurrently not sequentially
Cancellation tokens are harder, though.
Yeah, but Google did a lot for python adoption.
What? Generics ≡ parametric polymorphism.
And for collections Go has other tools (like generator if you really want to). Overall in the 2ish years of writing Go, I only missed them when I was learning the language coming from years of Java.
Interfaces: same API, different source code.
Generics: different APIs, same source code.
This is why Go needs to have generics.
I'll stick with my C#/.NET stack which has been going strong for almost 20 years and it's still kicking. What developer tools has Google supported for that long? No thanks.
Go has been out for ten years now, not six months.
Microsoft's focus on developers from its founding gives us a great deal of confidence about a respectable level of support for C#/.Net, although their movement from closed source is too new to depend on quite yet.
Whereas Oracle's acquisition of "Java" has prompted a lot of people including myself to step smartly back from its ecosystem due to the demonstrated risks of that malevolent company. See only the latest thing I've learned about it withholding a TCK (test suite) license to AdoptOpenJDK: https://adoptopenjdk.net/quality.html
Microsoft institutionally had a "does not play well with others" attitude to the point of stark figurative murderousness as we saw in SCO v. The World during the Ballmer years ... and as for "robustness", the one signal failing of Nadella is quality.... I could make a case it's as risky an option in the medium and long term as these other ones, and confidently state it will take at least a decades before a lot of us maybe trust Microsoft's good will outside its Windows ecosystem, hindering wider adaptation.
It's a first class citizen in terms of cross-platform compatibility. And if you don't like Visual Studio on Windows or Mac, there's VS Code (which obviously runs on Linux as well), you can always pay for Rider (which is great btw.)
These will be necessary for widespread enterprise adoption. Third parties libraries, offering arbitrary APIs, and maintained by volunteers, don't pass muster.
Perhaps this work should be undertaken by committees outside the Go team, as it has limited resources.
Go has also long based their packaging around the idea that locations of source code and the identity of a package are strongly bound. This meant that random github-hosted libraries were easy to pull in, but it also meant that people did pull in all sorts of random github-hosted libraries. In Java programming, it's more common to use a modest number of high-quality libraries and frameworks (which may, in fairness, have a lot of transitive dependencies), but not as common as it is in Go or Node to use a large number of direct dependencies sourced from all over the web.
Enterprise does not care if there is A solution.
Enterprise cares if there is a SUPPORTED solution.
But lack of specs slows adoption, generally speaking.
If language simplicity (and the resulting "low cognitive overhead") were the primary determinant of productivity, we would surely be using far simpler languages than Go (like Brainfuck).
What we should really care about is code simplicity, not language simplicity, 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.
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'm not convinced it will become THE next enterprise programming language.
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.
Race detection in Go is pretty good, and idiomatic Go discourages writing such code.
If go is killing anything, it is killing Ruby and it is seriously cutting into the server side stuff written in node. In my experience, Go is a nice fit right in the middle between C and Python. The best part of it is probably that the language spec is so short any developer can read it all and memorize it. As more and more stuff uses Go due to its overall simplicity and sensibility, some java stuff will suffer for sure.
I can see how that wasn't clear at all. I should have used maybe the term data stream processing applications.
> Go is a nice fit right in the middle between C and Python
Totally agree. I just see it used as a Python replacement more often then a C replacement. And the teams that did seemed to be getting a lot less done than the ones using a Python equivalent language.
2. Very limited support from enterprise vendors.
3. Poor at scaling to hundreds of developers. Java's verbosity and over use of design patterns has actually been beneficial.
4. Network effects. Almost every enterprise developer, outsourced dev shop and operations team knows at least a little Java.
At some point existing Java systems will stop delivering value compared to their maintenance cost in lot of situations. This is where Go as replacement will come in handy.
What classes of customers/situations are you referring to?
OpenJDK is still free, open source, is built in to almost every OS and has distributions by multiple vendors e.g. Amazon. Oracle is simply charging for enterprise support which seems pretty normal to me.
Java the language has such reams of already written code that it's not going anywhere either for a decade or so.
But take a look at Kotlin.
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.
If they do that they'll be a mighty big bar tab run up in Redmond.
Java is essentially never used for serious embedded work.
I've seen it done, you end up with a embedded arm or 0x86 processor that runs 'hot' doing stuff that embedded python can do on a small single core processor drawing 100th the power.
Edit: if I’m remembering right, that was the worst part of it. They couldn’t upgrade GWT because they couldn’t upgrade the JRE.
One of my experiences was trying to get Uboot and an old version of Linux to compile. The old compiler wouldn't work on my machine(s). The old code wouldn't compile with a newer compiler because of 'UB'.
I don't know whether it counts as "serious" to you, but literally billions of SIM cards and credit cards are running JavaCard:
The mix of functional and imperative styles is odd, but not bad.
For a CRUD app server, its an overkill, though.
Even COBOL is not completely phased out by now, and runs in production, but it has been largely replaced by other languages.
But in one month with Go, I've gone from "barely remembers his teenage QBasic days and dabbles in VBA at work" to "writing genuinely useful utilities with minimal time investment". I'm sure the language has limitations, but I've yet to run into any that are personal showstoppers.
What GC does in practice is open up new domains. There are object-management patterns that simply can't be written feasibly without something like a GC runtime under the hood. (Hence Greenspun's tenth rule of programming, of course.)
A few days ago they posted a critique of Apple that bordered on libelous: https://news.ycombinator.com/item?id=19853263
Now they post a piece heavily promoting a Google language.
There are good points in both articles, but it’s interesting to wonder what “hackernoon”’s interest is.
I have never seen a "Google is unfairly promoting Go" argument that wasn't fundamentally silly. Would that it were otherwise, but I don't think Go is a super important company priority inside Google, rather, I think it's mostly a labor of love for a small faction of Googlers.
It’s more a question about what Hackernoon actually is given that there appear to be these editorializing pieces arguing strongly in favor of or against one thing or another.