10 ms·

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

93 points by dcu 7y ago

JamesBarney 7y ago
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.
- lkramer 7y ago
  Why is it not a great replacement for Java? My experience have been opposite, C++ still have its place, but Go has taken over where previously maybe Java would be reached.
  - threeseed 7y ago
    1. Very limited libraries. 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.
    - geodel 7y ago
      Well of course everything you said is kinda true. Go is not going replace Java in one-to-one replacement type projects. It is going to be in a way like Cloud vendors have creamed traditional IT/outsourcing vendors or IPhones crushed blackberry. 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.
- SEJeff 7y ago
  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 7y ago
    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.
zepto 7y ago
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.
- vorpalhex 7y ago
  HackerNoon has been an editorial related to tech for quite some years. They don't have any secret conspiracy like interest, but like any editorial, they are made up of many different voices and opinions (which each have their own interests).
- tptacek 7y ago
  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 7y ago
    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.
turk73 7y ago
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 7y ago
  I'd argue that Java's killer feature is portability across platforms (embedded, mobile, server, etc..), not runtimes.
  - Gibbon1 7y ago
    > 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 7y ago
      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 7y ago
        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'.
Skunkleton 7y ago
This is a nice overview of Go, but I don't see why Go having enterprise features means that its poised to replace java.
datavirtue 7y ago
Not feeling it or seeing it.
wintorez 7y ago
As far as I can see, Java is pretty secure.
- nine_k 7y ago
  JVM is rock-solid and not going anywhere. 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.
- hathawsh 7y ago
  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-understanding-how-2019-java-licensing-changes-impact-you https://www.lakesidesoftware.com/blog/java-did-what-understa...
  - favorited 7y ago
    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 7y ago
      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.
  - threeseed 7y ago
    What is the issue here ? 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.
  - ben940830298432 7y ago
    That isn't going to change anything. Java is as open as ever you just use the openjdk now.
guessmyname 7y ago
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.
- sdinsn 7y ago
  They've already stated they will add generics
- nine_k 7y ago
  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.
  - smnplk 7y ago
    >> Python got to the top without a comparable corporate support from its creators.<< Yeah, but Google did a lot for python adoption.
  - hyeomans 7y ago
    Talking about coroutines, how do you do a synonym of async/await + Promise.all + cancellation token? In a microservice world, I habe to send a request to 6 microservices and I want to do them concurrently not sequentially
pard68 7y ago
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.
- nine_k 7y ago
  Rust will eventually replace C++: it's useful in areas where performance matters and things cannot be dumbed down without much consequence. For a CRUD app server, its an overkill, though.
  - w8rbt 7y ago
    It may replace C++, but it will take decades to do so. The C and C++ ecosystem is gigantic and has been around for 30 to 40 years and will will be around for the next 100 years or more years IMHO.
    - nine_k 7y ago
      Replace = new development is done in Rust, C++ development is for supporting (huge amounts of) existing C++ code. Even COBOL is not completely phased out by now, and runs in production, but it has been largely replaced by other languages.
- krapht 7y ago
  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 7y ago
    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.
throwaway55554 7y ago
Yeah, I don't think so. As Oracle proceeds to kill Java, C#/.Net Core will rise up even further.
echopom 7y ago
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 7y ago
  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 7y ago
    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.
ilovecaching 7y ago
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.
- networkimprov 7y ago
  "General application development" is not really a market segment. What classes of customers/situations are you referring to?
  - bitwize 7y ago
    Indeed. People haven't developed "general applications" since the 90s or 2000s. Mobile and cloud are the future, applications are distributed, and different app components have different requirements. The closest thing to an application language that meets developer needs across all environments is JavaScript. It's not the best in any domain except Web clients, but it's pretty good in all of them.
- krapht 7y ago
  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.
  - uwuhn 7y ago
    Lots in SF and LA.
  - misframer 7y ago
    What do you mean by area? Geographic location or technical?
networkimprov 7y ago
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 7y ago
  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.
  - networkimprov 7y ago
    If the third party is a major IT vendor, perhaps. But lack of specs slows adoption, generally speaking.
  - niftich 7y ago
    Spring is a collection of frameworks that impose their own structure and control flow so that one can focus on the parts of the design that are unique to one's situation. The Go language and standard library and the Go community have a very different mindset on delegation, structure, and control flow, so frameworks in the style of Spring or Rails aren't as widely used or popular. 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.
  - cabraca 7y ago
    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.
heartofgold 7y ago
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 7y ago
  > However, race conditions are still quite possible with goroutines Race detection in Go is pretty good, and idiomatic Go discourages writing such code.
tschellenbach 7y ago
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/
GiorgioG 7y ago
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.
- sixothree 7y ago
  The C# ecosystem is such a nice place to be. Libraries, frameworks, tooling, cross-platform support, development tooling, extensions, powerful robust languages - why would anyone want to give that up in favor of a Google property. No thanks.
  - dfrage 7y ago
    How good is all that off the Window ecosystem, and for how long has that been the case? 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.
    - GiorgioG 7y ago
      I write C#/.NET Core on my MacBook Pro all the time when I'm away from my desktop PC (Windows 10.) My apps run great on a DigitalOcean droplet under docker (alpine linux asp.net core image.) 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.)
- cameronbrown 7y ago
  I understand skepticism but sometimes it goes too far. Go has been out for ten years now, not six months.
draw_down 7y ago
My experience with Go is mostly limited to conducting interviews where the candidate uses it, but so much with it seems clumsy and inelegant. For example I was surprised how much is involved with a simple thing like sorting a list according to some custom comparison function. I guess once you learn the correct incantations for that you can just crank it out, as with any other language, but I wonder what it's like when you're trying to do something that's actually hard.
nullwasamistake 7y ago
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 7y ago
  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 7y ago
    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 7y ago
joelfolksy 7y ago
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.
faissaloo 7y ago
but it doesn't even have proper classes or exceptions

93 points by dcu 7y ago

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.

lkramer 7y ago
Why is it not a great replacement for Java? My experience have been opposite, C++ still have its place, but Go has taken over where previously maybe Java would be reached.
- threeseed 7y ago
  1. Very limited libraries. 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.
  - geodel 7y ago
    Well of course everything you said is kinda true. Go is not going replace Java in one-to-one replacement type projects. It is going to be in a way like Cloud vendors have creamed traditional IT/outsourcing vendors or IPhones crushed blackberry. 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.
SEJeff 7y ago
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 7y ago
  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.

zepto 7y ago

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.

vorpalhex 7y ago
HackerNoon has been an editorial related to tech for quite some years. They don't have any secret conspiracy like interest, but like any editorial, they are made up of many different voices and opinions (which each have their own interests).
tptacek 7y ago
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 7y ago
  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.

turk73 7y ago

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 7y ago
I'd argue that Java's killer feature is portability across platforms (embedded, mobile, server, etc..), not runtimes.
- Gibbon1 7y ago
  > 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 7y ago
    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 7y ago
      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'.

Skunkleton 7y ago

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

datavirtue 7y ago

Not feeling it or seeing it.

wintorez 7y ago

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

nine_k 7y ago
JVM is rock-solid and not going anywhere. 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.
hathawsh 7y ago
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-understanding-how-2019-java-licensing-changes-impact-you https://www.lakesidesoftware.com/blog/java-did-what-understa...
- favorited 7y ago
  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 7y ago
    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.
- threeseed 7y ago
  What is the issue here ? 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.
- ben940830298432 7y ago
  That isn't going to change anything. Java is as open as ever you just use the openjdk now.

guessmyname 7y ago

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.

sdinsn 7y ago
They've already stated they will add generics
nine_k 7y ago
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.
- smnplk 7y ago
  >> Python got to the top without a comparable corporate support from its creators.<< Yeah, but Google did a lot for python adoption.
- hyeomans 7y ago
  Talking about coroutines, how do you do a synonym of async/await + Promise.all + cancellation token? In a microservice world, I habe to send a request to 6 microservices and I want to do them concurrently not sequentially

pard68 7y ago

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.

nine_k 7y ago
Rust will eventually replace C++: it's useful in areas where performance matters and things cannot be dumbed down without much consequence. For a CRUD app server, its an overkill, though.
- w8rbt 7y ago
  It may replace C++, but it will take decades to do so. The C and C++ ecosystem is gigantic and has been around for 30 to 40 years and will will be around for the next 100 years or more years IMHO.
  - nine_k 7y ago
    Replace = new development is done in Rust, C++ development is for supporting (huge amounts of) existing C++ code. Even COBOL is not completely phased out by now, and runs in production, but it has been largely replaced by other languages.
krapht 7y ago
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 7y ago
  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.

throwaway55554 7y ago

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

echopom 7y ago

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 7y ago
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 7y ago
  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.

ilovecaching 7y ago

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.

networkimprov 7y ago
"General application development" is not really a market segment. What classes of customers/situations are you referring to?
- bitwize 7y ago
  Indeed. People haven't developed "general applications" since the 90s or 2000s. Mobile and cloud are the future, applications are distributed, and different app components have different requirements. The closest thing to an application language that meets developer needs across all environments is JavaScript. It's not the best in any domain except Web clients, but it's pretty good in all of them.
krapht 7y ago
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.
- uwuhn 7y ago
  Lots in SF and LA.
- misframer 7y ago
  What do you mean by area? Geographic location or technical?

networkimprov 7y ago

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 7y ago
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.
- networkimprov 7y ago
  If the third party is a major IT vendor, perhaps. But lack of specs slows adoption, generally speaking.
- niftich 7y ago
  Spring is a collection of frameworks that impose their own structure and control flow so that one can focus on the parts of the design that are unique to one's situation. The Go language and standard library and the Go community have a very different mindset on delegation, structure, and control flow, so frameworks in the style of Spring or Rails aren't as widely used or popular. 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.
- cabraca 7y ago
  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.

heartofgold 7y ago

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 7y ago
> However, race conditions are still quite possible with goroutines Race detection in Go is pretty good, and idiomatic Go discourages writing such code.

tschellenbach 7y ago

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/

GiorgioG 7y ago

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.

sixothree 7y ago
The C# ecosystem is such a nice place to be. Libraries, frameworks, tooling, cross-platform support, development tooling, extensions, powerful robust languages - why would anyone want to give that up in favor of a Google property. No thanks.
- dfrage 7y ago
  How good is all that off the Window ecosystem, and for how long has that been the case? 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.
  - GiorgioG 7y ago
    I write C#/.NET Core on my MacBook Pro all the time when I'm away from my desktop PC (Windows 10.) My apps run great on a DigitalOcean droplet under docker (alpine linux asp.net core image.) 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.)
cameronbrown 7y ago
I understand skepticism but sometimes it goes too far. Go has been out for ten years now, not six months.

draw_down 7y ago

My experience with Go is mostly limited to conducting interviews where the candidate uses it, but so much with it seems clumsy and inelegant. For example I was surprised how much is involved with a simple thing like sorting a list according to some custom comparison function. I guess once you learn the correct incantations for that you can just crank it out, as with any other language, but I wonder what it's like when you're trying to do something that's actually hard.

nullwasamistake 7y ago

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 7y ago
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 7y ago
  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 7y ago

joelfolksy 7y ago

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.

faissaloo 7y ago

but it doesn't even have proper classes or exceptions