Go Is on a Trajectory to Become the Next Enterprise Programming Language(hackernoon.com)
hackernoon.com
Go Is on a Trajectory to Become the Next Enterprise Programming Language
https://hackernoon.com/go-is-on-a-trajectory-to-become-the-next-enterprise-programming-language-3b75d70544e
113 comments
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
- 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.
- 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.
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.
And we use Go for a relatively big EHR program.
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.
Yes. I have indeed tried leaving JFR on in production. For many years. We even used to take chunks from the repo continuously (even though not supported). We solved 95% of our production problems with only the JFR data (with some contextual data recorded), rarely having to ask for other pieces of data or run special builds with additional one-off instrumentation. JFR is not only a production time profiler; but it is pretty awesome at that too...
NewRelic installs itself as a Java agent, doesn't need any code integration it's just a command line param on app startup. That's one advantage of java, you can redefine classes at runtime. NewRelic uses Java Agent API to instrument code at runtime, no SDK or special build needed
I'm not sure if we talk about the same thing, custom tracing: https://docs.newrelic.com/docs/agents/java-agent/api-guides/...
Yes, so you can annotate methods for additional tracing but the default agent alone provides a lot of metrics and it attaches using diagnostics API.
> The only strong contender to realistically replace Java is C#
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.
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.
Go aligns well with Google's frequent rewrite policy.
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
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
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.
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.
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.
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.
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.
I suppose he/she meant Go discourages it relatively compared to Java, not that Java encourages it.
Why would they actively disdain developers in creating novel tools that push the limit of their language in creative ways? Sure, there _is_ going to be a group of developers that are ignorant, arrogant and curious at the same time, but it is not the job of the programming language to reel-in those engineers versus the ones who create new frameworks and shape the development process.
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.
Many languages give engineers a way to write code without thinking of the more complex shenanigans going on behind the scenes, while at the same time exposing just enough of the core of the language to allow breakers to break past it's constraints, i.e. Javascript or C#. Not every language desires to be like C++ or C or Lisp.
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.
Many languages give engineers a way to write code without thinking of the more complex shenanigans going on behind the scenes, while at the same time exposing just enough of the core of the language to allow breakers to break past it's constraints, i.e. Javascript or C#. Not every language desires to be like C++ or C or Lisp.
> JavaScript is now the new Java
No it absolutely is not.
The benefit of Java is all of the enterprise libraries and support. After all of these years I still don't see any of that in Javascript.
No it absolutely is not.
The benefit of Java is all of the enterprise libraries and support. After all of these years I still don't see any of that in Javascript.
> JavaScript is now the new Java
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.
Just a few years ago, JavaScript became that cool language with a new paradigm: run the same code in the server and the browser. In a few years, it became ubiquitous.
I suppose the OP intended the comparison in this way, not in a feature comparison or a judgement on the maturity of the ecosystem.
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.
Just a few years ago, JavaScript became that cool language with a new paradigm: run the same code in the server and the browser. In a few years, it became ubiquitous.
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 also don't expect that a lot of the existing Java code will be rewritten in Go. But there exists a whole array of startups/unicorns today who use Go extensively. Many of them will grow into enterprises. I predict that Go will generally hold up well for them as they scale. They will feel a lot less of an urge to switch to something more mature and scalable like Java, as many companies who started out with Ruby, Scala, or PHP did.
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.
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.
I see that some readers are mocking your analogy about NodeJs being the new Java but that has been case in my company. A few years ago we moved some backend projects from in house operated JavaEE application servers (Weblogic mostly) to cloud based micro services written in NodeJs and SpringBoot.
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).
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).
Javascript is the new Java? LOL
Otherwise, you're quite right that enterprise IT culture is deeply conservative.
Otherwise, you're quite right that enterprise IT culture is deeply conservative.
Well, it does run on the client and the server, which was the promise of Java in ye olde days.
Java, Kotlin and Scala can all compile to Javascript and hence can run on the client and server as well. For example this is written in Scala.JS: https://scalafiddle.io
But that is irrelevant since enterprises don't care about SPAs and so are fine using standard web frameworks like Play, Dropwizard or Tomcat.
But that is irrelevant since enterprises don't care about SPAs and so are fine using standard web frameworks like Play, Dropwizard or Tomcat.
There's also something to be said for real type safety and high performance numerics for which Javascript has to be twisted to achieve part way.
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.
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.
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.
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.
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.
Yeah but now that we have generics the bar has been raised right?
I’m not giving generics up, that’s for sure.
Well of course you don't need to. Individual/independent developers would use what they deem fit. It is corporate developers who will receive mandate to use a particular language or technology. For example a large company where I work, it is mostly Java shop. However the new telemetry/tooling group has now mandated to use Go. So about 40+ devs are working in Go. Nobody asked their opinion about Go vs Java or Generics , Sum types, exception vs errors and so on. Same devs would have used Weblogic/Websphere or whatever if asked.
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.
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.
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
In a microservice world, I habe to send a request to 6 microservices and I want to do them concurrently not sequentially
Spin several goroutines, do a `select` on them. It's right in the Tour of Go.
Cancellation tokens are harder, though.
Cancellation tokens are harder, though.
It’s been a while since I’ve been writing Go, but wasn’t that nominally what the Context objects were supposed to be for? I think they were introduced a bit late in the game, but APIs that supported them handled cancellation well (if I’m remembering right)
Context would be passed to each go-routines for cancellation but the pattern would be the same as OP's suggestion. I'd say a set of go-routines and a sync.WaitGroup would probably be a better pattern for this use case. Routines + select is more useful for listening on incoming data than concurrently sending out bytes.
use zeromq
>> Python got to the top without a comparable corporate support from its creators.<<
Yeah, but Google did a lot for python adoption.
Yeah, but Google did a lot for python adoption.
Totally agree. A lot of people address the lack of generics as merely a lack of a convenience feature. Sure, one aspect of generics are that they allow for more flexible types that help get around rewriting trivial variants, but that is hardly their primary function. Generics allow for the use of generalized functions while preserving arbitrarily complex typings to be preserved.
> generics (aka. Contracts)
What? Generics ≡ parametric polymorphism.
What? Generics ≡ parametric polymorphism.
OP referring to Go2's draft proposal for generics where the feature is called Contracts. https://go.googlesource.com/proposal/+/master/design/go2draf...
They've already stated they will add generics
Enterprises don't choose a language for academic reasons ( generics ect ... ). They choose a language for stability, ecosystem, hiring difficulty, support ...
As a Go developer, I rarely ever miss generics. If you design up front with interfaces and the lack of generics in mind, you can almost always avoid needing them.
And when you finally get them, you'll wonder how you ever lived without :-)
Yet having moved from (primarily) Java to (primarily) Go I find I don't miss them.
I had them (Java and C#) and I am happy Go does not have them. I feel like most people just miss them for collections and abuse them in other instances.
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.
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.
When you need to switch from native maps to sync.Map, you not only have to give up type safety but rewrite all your calling code. Codegen doesn't help because you are not one of the people allowed to overload those operators.
It is more that you code around the lack of generics.
Interfaces: same API, different source code. Generics: different APIs, same source code.
This is why Go needs to have generics.
Interfaces: same API, different source code. Generics: different APIs, same source code.
This is why Go needs to have generics.
A bit like saying if you know you won’t have a hammer, you’ll instead bring a drill, a screwdriver, and screws. But sometimes it’s nice to be able to nail things together.
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.
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.
I understand skepticism but sometimes it goes too far.
Go has been out for ten years now, not six months.
Go has been out for ten years now, not six months.
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
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
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.
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.
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.
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.
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.)
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.)
Python used to have Google as its sugar daddy supporting the BDFL. It's doing fine even though it's no longer the new hotness and Google is only sponsoring < $100K/yr.
Google abandons a lot of stuff lately, but they can't pull a plug and make "go build" start failing.
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.
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.
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.
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.
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.
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.
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.
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.
Enterprise does not care if there is A solution.
Enterprise cares if there is a SUPPORTED solution.
Java has javax.persistence as a standard interface for ORMs, almost in standard library, and third-party ORMs use it.
If the third party is a major IT vendor, perhaps.
But lack of specs slows adoption, generally speaking.
But lack of specs slows adoption, generally speaking.
Yeah, I don't think so. As Oracle proceeds to kill Java, C#/.Net Core will rise up even further.
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.
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.
> However, race conditions are still quite possible with goroutines
Race detection in Go is pretty good, and idiomatic Go discourages writing such code.
Race detection in Go is pretty good, and idiomatic Go discourages writing such code.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
"General application development" is not really a market segment.
What classes of customers/situations are you referring to?
What classes of customers/situations are you referring to?
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.
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.
This is a nice overview of Go, but I don't see why Go having enterprise features means that its poised to replace java.
As far as I can see, Java is pretty secure.
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-understa...
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.
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.
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?
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.
That isn't going to change anything. Java is as open as ever you just use the openjdk now.
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.
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.
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/
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.
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 Oracle goes through with the Java licensing threats
If they do that they'll be a mighty big bar tab run up in Redmond.
If they do that they'll be a mighty big bar tab run up in Redmond.
I'd argue that Java's killer feature is portability across platforms (embedded, mobile, server, etc..), not runtimes.
> 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.
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.
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.
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.
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'.
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'.
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...
> Java is essentially never used for serious embedded work.
I don't know whether it counts as "serious" to you, but literally billions of SIM cards and credit cards are running JavaCard:
https://software.ac.uk/blog/2018-07-13-javacard-execution-en...
https://www.youtube.com/watch?v=31D94QOo2gY
I don't know whether it counts as "serious" to you, but literally billions of SIM cards and credit cards are running JavaCard:
https://software.ac.uk/blog/2018-07-13-javacard-execution-en...
https://www.youtube.com/watch?v=31D94QOo2gY
but it doesn'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.
The mix of functional and imperative styles is odd, but not bad.
The mix of functional and imperative styles is odd, but not bad.
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.
For a CRUD app server, its an overkill, though.
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.
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.
Even COBOL is not completely phased out by now, and runs in production, but it has been largely replaced by other languages.
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.
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.
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.
If there's one single reason why Java killed C++ in the enterprise space, it's memory safety. (Concurrency-readiness and WORA were also important features of course.) GC was not important, other than as a means to an end of course.
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.)
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.)
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
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.
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.
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).
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.
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.
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.
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.
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#