
Go Is on a Trajectory to Become the Next Enterprise Programming Language - dcu
https://hackernoon.com/go-is-on-a-trajectory-to-become-the-next-enterprise-programming-language-3b75d70544e
======
nullwasamistake
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.

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#

~~~
Thaxll
I don't think you used Go that much:

\- 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](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.

~~~
Insanity
I hope go 2 does not introduce generics. Having used Java for about a decade
(and C# 4 years) I can't say I miss it.

And we use Go for a relatively big EHR program.

~~~
owaislone
I hope they introduce it only if it keeps the language as simple as it is
today even if it means generics will not be as powerful as other languages. I
mean we have a ton of languages and Go is a unique one. If a project or team
really needs generics, they can always use Java, Rust or something dynamic
like Python or JS. I don't see much point in turning Go into another Rust or
Java. Not that Rust or Java are wrong but with Go being so simple, we have all
sorts of options. If it turns into another beast of a language just to solve
what other language already have then we lose the simple and fast Go we all
like.

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

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.

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't like JavaScript.

Go is becoming Node.JS not the new Java , JavaScript is now the new Java , and
Java is the new Cobol.

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.

~~~
tomohawk
I've got a lot of experience with enterprise java and go. Java is here to
stay, but a large chunk of what people use Java for in enterprises would be
much better done with Go. I've seen way too many applications done in Java
that required high priced talent to achieve a feature set that was not
proportional to the cost. The high cost makes this skill set a target.

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.

~~~
dkarl
Wait, Java is now a language that encourages cleverness and requires high-
priced talent? My head is spinning trying to imagine what your situation would
be to have that perspective on Java.

~~~
owaislone
I suppose he/she meant Go discourages it relatively compared to Java, not that
Java encourages it.

------
guessmyname
Without generics (aka. Contracts) I don’t think so.

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.

~~~
nine_k
Java had become the industry's workhorse also without generics, that were
included only in Java 5, 8 years after Java 1.0. C++ had it for ages by that
time, but it did not help its adoption too much (if not the other way around).

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.

~~~
booleandilemma
_Java had become the industry 's workhorse also without generics..._

Yeah but now that we have generics the bar has been raised right?

I’m not giving generics up, that’s for sure.

~~~
copperx
Java had the Object superclass, and that's how generic methods and classes
were written before version 5.

Is there a Go equivalent of Object?

~~~
adamlett
Yes. The empty interface.

------
GiorgioG
I don't trust Google, even with a product as popular as golang, to support it
for the long haul.

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.

~~~
dfrage
An entirely valid concern, but languages and their ecosystems can get big
enough that a or the major supporter can drop out without killing or
necessarily even significantly harming them in the medium term. I currently
_guess_ that Go is there, while Rust is not quite yet vis-à-vis Mozilla.

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](https://adoptopenjdk.net/quality.html)

~~~
steveklabnik
Rust will certainly survive without Mozilla; they pay the CI bill, and that’s
wonderful, but most contributors, by a pretty large margin, are volunteer.

------
joelfolksy
Why do we always let these Go evangelism pieces get away with insinuating that
language simplicity is an unalloyed good?

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.

------
networkimprov
The Go team has resisted (deferred?) defining APIs for many common protocols
and formats (e.g. LDAP, Websockets).

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.

~~~
nine_k
Why can't this be served by established third-party libraries? Java did not
have a good ORM, or a good dependency injection framework in the standard
library for ages; everybody just used Spring.

~~~
cabraca
Because John Doe the Maintainer is not offering Support for his third-party
library. SpringSource/Pivotal was/is offering that for Spring. Redhat is
offering Support for hibernate.

Enterprise does not care if there is A solution.

Enterprise cares if there is a SUPPORTED solution.

~~~
nine_k
An established library usually has a bunch of maintainers from big companies
that are investend in that library. You know, most open-source code by now
gets written for money as a day job.

~~~
cabraca
and the enterprise doesn't care as long as they don't offer them a support
contract.

------
throwaway55554
Yeah, I don't think so. As Oracle proceeds to kill Java, C#/.Net Core will
rise up even further.

------
heartofgold
It seems like go's killer feature, initially, was it's approach to concurrency
with goroutines and CSP.

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.

~~~
pstuart
> However, race conditions are still quite possible with goroutines

Race detection in Go is pretty good, and idiomatic Go discourages writing such
code.

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

~~~
SEJeff
Go is a terrible replacement for real time systems. While newer go has a much
better garbage collector, it still isn't 100% deterministic. Most real time
systems are written in C / C++ / Systems Verilog (FPGAs) / etc. I've once seen
it written in a special java where the internal core sys (garbage collection)
jars were overridden to disable gc entirely. Once the JIT was primed and ready
to go this was exceptionally good and was fast as heck.

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.

~~~
JamesBarney
Sorry by real time systems I just meant systems that do lots of data
processing that is generated in real time but don't have super strict latency
issues. Not the control system that's running on the oil rig for instance but
all of the data processing that is happening downstream on the data the
sensors generate.

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.

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

~~~
krapht
That seems optimistic. I have zero reason to believe anything will replace
Java or C# anytime soon. Anecdotally, but in my area I have seen almost zero
job postings for Go.

~~~
misframer
What do you mean by area? Geographic location or technical?

------
Skunkleton
This is a nice overview of Go, but I don't see why Go having enterprise
features means that its poised to replace java.

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

~~~
hathawsh
Oracle's recent Java licensing changes are likely to reduce the use of Java
for new projects.

[https://www.lakesidesoftware.com/blog/java-did-what-
understa...](https://www.lakesidesoftware.com/blog/java-did-what-
understanding-how-2019-java-licensing-changes-impact-you)

~~~
favorited
In enterprise? No way. Enterprise and IT orgs are already perfectly willing to
shell out cash for Oracle databases, why would Java licenses be any different?

~~~
dfrage
All depends on how desperate Oracle gets; already we hear of a lot of high
priority migrations to PostgreSQL starting after a visit from the Oracle
Police.

------
tschellenbach
In case you want to try it out, here's a tutorial I wrote a little while ago:
[https://getstream.io/blog/go-1-11-rocket-
tutorial/](https://getstream.io/blog/go-1-11-rocket-tutorial/)

------
turk73
If Oracle goes through with the Java licensing threats, Go will have its day
for sure.

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.

~~~
cameronbrown
I'd argue that Java's killer feature is portability across platforms
(embedded, mobile, server, etc..), not runtimes.

~~~
Gibbon1
> embedded

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.

~~~
tonyarkles
Heh, yeah... I saw my first “embedded Java” project 2 years ago and it was
pretty horrifying. To add insult to injury, it was on a legacy ARM processor
and Oracle had stopped providing new JREs for it. Pretty rough spot to be in;
the product was 10 years old, and probably had another 10 years of life in it,
but development was stuck at a bit of a dead end. It was also based on GWT...

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.

~~~
Gibbon1
A constant consideration with Java and Embedded Linux is the ratio of external
code vs yours that you are pulling in. With the caveat that the maintainers
don't care at all about your particular product.

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

~~~
tonyarkles
Heh, funny you mention that. Building the binaries for the rest of the system
wouldn't work on anything newer than Ubuntu 9.04 because of some Perl
incompatibility that the build system depended on...

------
faissaloo
but it doesn't even have proper classes or exceptions

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

The mix of functional and imperative styles is odd, but not bad.

~~~
krapht
Garbage collection is a big productivity boost. That's why Java killed C++ to
begin with in the enterprise space. You can't go backwards in that sense.

~~~
kermitismyhero
It's also easier on the learning curve. I've just gotten back into coding as a
hobby after a two-decade-long gap. In that time every few years I've tried to
pick up C, and always ended up bewildered and frustrated by garbage collection
matters. Maybe with formal instruction I could have figured it out, but the
learning curve as a weekend/evening hobbyist was like a vertical cliff.

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.

------
zepto
What exactly is ‘hackernoon’?

A few days ago they posted a critique of Apple that bordered on libelous:
[https://news.ycombinator.com/item?id=19853263](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.

~~~
tptacek
This kind of argument is unhelpful and, per the guidelines, unwelcome on HN. I
don't much like Hackernoon (it's a low quality source) but you can make that
argument without suggesting a shadowy conspiracy.

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.

~~~
zepto
I’m not arguing that Google is unfairly promoting Go, nor that it Hackernoon
has anything to do with Google or is a conspiracy.

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.

