Comment by echopom | Hacker News Reader

Comment by echopom | Hacker News Reader

Parent Full thread

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.

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.

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.

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

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

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

Javascript is the new Java? LOL

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.

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.

Reply on news.ycombinator.com