6 ms·

> webassembly [is] eating JVM's cake It's hard for me to take all the "Java is dying" threads seriously when they don't even seem to understand where Java play

> webassembly [is] eating JVM's cake It's hard for me to take all the "Java is dying" threads seriously when they don't even seem to understand where Java plays. Webassembly? Really? That's a client-side tech, and 99.999% of Java devs ceded the browser battleground pre-9/11. Java's bread and butter is EAI, ETL, and server-side business application development. Particularly with pieces requiring heavily distributed design. Node might pick away at some of the lowest-hanging fruit (e.g. JavaScript webdevs writing their own REST endpoints to fetch user settings from the database). But most of that crowd doesn't understand what the terms "EAI" or "ETL" even mean. Hell, most of that crowd has never had the experience of working for a company that turns a profit. The next major downturn will be interesting to watch... And JavaScript is the only JVM-alternative to take seriously at all. Hype trains come and go for Rust, .NET Core, Go, etc. But they never really gain serious traction beyond a non-Java niche area, and/or devolve into endless arguments about generics or whatever. I've seen zero actual encroachment into anything that earns me money for the past 10 years now, and at this point I'll probably be retired before I have to worry about it.

aphexairlines 7y ago
You're right that Java is entrenched in a lot of the enterprise space, but I think you're being quick to dismiss entrants that have gained steam in the last few years. For example, Go is becoming the default in Kubernetes applications. It's eating tech companies that became large in the last few years like Lyft and Uber. It'll spread to other large tech companies like Amazon or IBM with ease. It will possibly get picked up by a significant number of universities for undergrad courses within a few years as well.
- StevePerkins 7y ago
  Seriously, people. K8s is a container orchestration system. Yes, it's written in Go, like Docker itself. DevOps tooling is a niche area where Go has been very successful. But k8s runs whatever you put into your Docker containers. I've seen no indication of it changing which languages people choose to containerize (Node containers probably being way more common than Go ones). If anything, easy containerization negates one of Go's strongest selling points (i.e. standalone executables with no need for a runtime environment).
  - stephenhuey 7y ago
    Exactly! In the enterprise world, there is a lot of Java and .NET code that isn’t going away for a while especially since K8s makes it easier to port to the cloud. In my enterprise, the only other language that comes close in usage numbers is Python, so I think a lot of enterprise folks will opt for that over Go.
    - smarterclayton 7y ago
      As someone who works on Kubernetes in the enterprise I would agree - there’s lots of go, but it’s newer and organized around the teams who were early adopters. And even the early adopters have massive Java, .NET, and increasingly Node footprints. However I think the rule of enterprise software is that it’s increasingly fragmented and diverse - that’s partially why Kubernetes and containers were so attractive because it allows operations to unify footprint on prem and have a path to cloud. Nobody in an enterprise ever stopped using a piece of technology. It lives on forever (and public cloud just gives it new places to live).
  - yebyen 7y ago
    > If anything, easy containerization negates one of Go's strongest selling points (i.e. standalone executables with no need for a runtime environment). I don't know about that, I think that is still a strong selling point for Go, even in a containerized environment. Somewhere I saw a statistic that says over 90% of container images in the wild contain unpatched CVE vulnerabilities and (searching...) [1] here's an article that shows just how bad the problem is, according to this article in just the top 10 docker images, there are over 8000 known vulnerable paths. The reason is probably not because those 10 products are simply nightmarish from a security perspective and expose the lions share of the vulnerabilities in their own code paths, it's because of unchecked dependencies. If someone took a tree shaker to those images and removed all of the unnecessary packages that aren't real dependencies, you see that number going down by probably about 30% if not more. Even then, you're still seeing lots of potential issues caused by far-away dependencies that we do actually need, but don't really care about. There's something to be said for a development stack that is geared toward automatically pruning out packages you've included when the compiler can prove you're not even using them, and helping you reduce the scope and size of your external, far-away dependencies. From an InfoSec perspective that's the biggest problem I see in containerized environments, (and true that just not using containers won't really make it much better) so correct me if I'm wrong, but I think that Go does all of that for us. [1]: https://snyk.io/blog/top-ten-docker-images-contain-over-8000-vulnerable-paths/ https://snyk.io/blog/top-ten-docker-images-contain-over-8000...
- bastardoperator 7y ago
  I'm working with customers now that are running Kubernetes to host Java applications and microservices. I'm not a huge fan of Java or the ecosystem, or the fact you can build a Kubernetes cluster using maven, but to claim its dying is outright absurd. As a consultant, I see Java widespread. Every organization is either writing Java or running an application dependent on Java that is also mission/business critical. Most of my work happens on the backend, but we see lots of Java upstream with mobile apps, big data, ETL, etc...
- diegoliber 7y ago
  Go is a good language for developing middleware and automation tools, but it's not, at any rate, a replacement for Object-Oriented languages. Java, C#, Python, Ruby etc are much more suited to business-oriented apps, data science and so on. There are many uggly things on Go language that can be considered nice features for system programming. Even though, if you go too much on the low-level (such as for operating system, drivers or embedded devices) it's still a issue to use go instead of a more hardcore systems language such as C++ or C. It is, at most, a niche language today. And probably will stay this way unless it goes into a major redesign. Better to talk about Rust or Kotlin, which are languages that have much more potential and can be a real threat to the dominant languages/platforms today. But right now, they are too unknown to be taken in consideration just as many other good languages that never came to be.
dtech 7y ago
I said LLVM and webassembly. LLVM has replaced JVM as a programming language target bytecode in the last 10 years (except Kotlin no new JVM language). JVM has lost web to JS 20-15 years ago, and Webassembly is now taking shape as proper web bytecode. I do not know what will be the most dominant language + bytecode in 25 years, but I would bet $10000 that it isn't Java and JVM.
- StevePerkins 7y ago
  > except Kotlin no new JVM language Java's never going to be on the bleeding-edge of trendiness (thank goodness). But there have been fewer JVM-targeting alternative languages over the past decade, because Java itself started leaning in a functional direction. It became "good enough" to negate the purpose for most of them. At any rate, counting compile targets for hobbyist toy languages is barely one step beyond measuring GitHub stars. > I do not know what will be the most dominant language + bytecode in 25 years In 25 years, I'll be long gone and you can have it. By then, the industry will be pushing to automate most programming jobs out of existence altogether, and you can be the old guard arguing against that.
  - victor106 7y ago
    > except Kotlin no new JVM language. What about Clojure? I 100% agree with you on Java. Some of these people who compare Java to Cobol have no idea. It’s hard for anyone to predict the future in tech but at this point Java is so widely used in the enterprise that it’s foolhardy to think that Java will disappear anytime soon. To the credit of the Java community they keep the language relevant and refreshed. I agree it’s always about 1-2 years behind other languages in terms of features but most enterprises don’t give a damn. Most enterprises just want to get work done. They don’t care about functional or OO. In the last 3 years I have seen maybe 40% of developers use the latest features from java 8. So while java might be slow to catch up that’s what it’s customers want. Spring and Vert.x and similar Java frameworks will always keep Java relevant that it will be hard to ignore
    - rpeden 7y ago
marcus_holmes 7y ago
I've heard that attitude before. C++ developers working in finance around 2000. They were damn sure that no-one was going to switch to any other language because reasons. I'm sure there's still a bunch of C++ devs working in finance, and making decent money, but I think the industry has moved on now. The industry always moves on
- DaiPlusPlus 7y ago
  HFT gigs I’ve looked at were all C++, some even Rust now - because they don’t want the risk of a long GC pause messing up a trade (which means Java, .NET, and Go are right-out).
  - dilyevsky 7y ago
    Go uses tri-color mark-and-sweep gc that runs concurrently and its latency is extremely short compared to .net and java (probably still not short enough to be put in the critical path of hft order processor tho). Edit: I'm also confident you can ensure Go’s gc doesn’t run when you don’t want it to so there’s that.
    - dgoldstein0 7y ago
      This may be true but conventional wisdom against using anything GC'ed for real-time applications (like HFT or aerospace stuff) is going to mean even if go's gc is good enough, using any gc'ed language for these apps is going to be extremely rare for years if not decades. Seems far more likely that rust will chisel away at that market than golang or any other gc'ed language.
      - nvarsj 7y ago
        Many HFT firms have used Java for ages. If you know what you’re doing you can avoid GC. Also, not everything needs to be realtime.
        haglin 7y ago
sqldba 7y ago
I didn't know Java had so much mindshare for ETL. Can you explain further?
- stingraycharles 7y ago
  The JVM, Java and Scala have a huge ecosystem with Hadoop, Spark, many databases, etcetera. Go to any company that does a lot of data-intensive processing, and chances are very likely it's powered by the JVM in at least some of the components.
int_19h 7y ago
There are active ongoing efforts to push wasm beyond the web client. Which makes perfect sense, since it could, in theory, deliver JVM's "compile once, run everywhere", but with a lot more flexibility for the languages on top. As far as Node.js being the only JVM alternatively to take seriously, I don't even know what to say. There are lots of enterprises with mature .NET (not Core) business apps, doing all that very stuff that you list - EAI, ETL etc.
TheRealDunkirk 7y ago
And then there's the evil implication of this aging, entrenched ecosystem. Companies who wrote their Java development process documentation did so in the 90's, with guidance from IBM or a "big 3," and now treat EVERY project in the business as though it was the same scale and complexity as the mainframe projects they were trying to supplement. Which is why it takes 6 months for me (on the FAST TRACK!) to even get a development environment for a simple CRUD web app designed to replace a terrible Excel spreadsheet with 5 users -- so that I can submit my feature list and test plan to review boards -- so that I can START writing my application. No wonder it takes the IT group 2 years to write an application I can have in production in 3 months! I don't need a reverse proxy! I don't need redundancy! I don't need an encrypted file store! It's a shared, specialized to-do list application! I don't need the overhead of a global financial application running on Sun E10K's! Nothing personal, but there are a lot of us out here who can't WAIT for people who have based their careers on "enterprise" Java to get out of the way already, and retire. When computers were as powerful as smart watches, we NEEDED all that distributed processing and faffing about with off-line data. Now? Not so much. "Hype trains" Rust, .NET, Go, etc.? Maybe you, too, think that Rails is too "new" and "unproven" to use for anything.
- carrja99 7y ago
  LOL... someone woke up in the wrong side of the bed this morning.
  - dang 7y ago
    Please don't do this here.
lucidone 7y ago
I'm one of those Node devs who've mostly worked for companies who have never made a profit, and I've recently been exploring Go, Java and C# (.NET Core) given I'm starting to work on more "serious" (or difficult) backends (distributed systems) and am hitting the limits of the language and ecosystem I know. Genuinely curious - why do you think I should give Java my attention over C# or Go?
Shorel 7y ago
ETL is the bread and butter of the company where I work and you can be sure Java is not even allowed near our systems. We have thousands if not dozens of thousands of different data providers and it is mostly financial data. Everything important is PHP and Python. It was Perl 10 years ago. There is some Java, but not in the ETL subsystems.

aphexairlines 7y ago

You're right that Java is entrenched in a lot of the enterprise space, but I think you're being quick to dismiss entrants that have gained steam in the last few years. For example, Go is becoming the default in Kubernetes applications. It's eating tech companies that became large in the last few years like Lyft and Uber. It'll spread to other large tech companies like Amazon or IBM with ease. It will possibly get picked up by a significant number of universities for undergrad courses within a few years as well.

StevePerkins 7y ago
Seriously, people. K8s is a container orchestration system. Yes, it's written in Go, like Docker itself. DevOps tooling is a niche area where Go has been very successful. But k8s runs whatever you put into your Docker containers. I've seen no indication of it changing which languages people choose to containerize (Node containers probably being way more common than Go ones). If anything, easy containerization negates one of Go's strongest selling points (i.e. standalone executables with no need for a runtime environment).
- stephenhuey 7y ago
  Exactly! In the enterprise world, there is a lot of Java and .NET code that isn’t going away for a while especially since K8s makes it easier to port to the cloud. In my enterprise, the only other language that comes close in usage numbers is Python, so I think a lot of enterprise folks will opt for that over Go.
  - smarterclayton 7y ago
    As someone who works on Kubernetes in the enterprise I would agree - there’s lots of go, but it’s newer and organized around the teams who were early adopters. And even the early adopters have massive Java, .NET, and increasingly Node footprints. However I think the rule of enterprise software is that it’s increasingly fragmented and diverse - that’s partially why Kubernetes and containers were so attractive because it allows operations to unify footprint on prem and have a path to cloud. Nobody in an enterprise ever stopped using a piece of technology. It lives on forever (and public cloud just gives it new places to live).
- yebyen 7y ago
  > If anything, easy containerization negates one of Go's strongest selling points (i.e. standalone executables with no need for a runtime environment). I don't know about that, I think that is still a strong selling point for Go, even in a containerized environment. Somewhere I saw a statistic that says over 90% of container images in the wild contain unpatched CVE vulnerabilities and (searching...) [1] here's an article that shows just how bad the problem is, according to this article in just the top 10 docker images, there are over 8000 known vulnerable paths. The reason is probably not because those 10 products are simply nightmarish from a security perspective and expose the lions share of the vulnerabilities in their own code paths, it's because of unchecked dependencies. If someone took a tree shaker to those images and removed all of the unnecessary packages that aren't real dependencies, you see that number going down by probably about 30% if not more. Even then, you're still seeing lots of potential issues caused by far-away dependencies that we do actually need, but don't really care about. There's something to be said for a development stack that is geared toward automatically pruning out packages you've included when the compiler can prove you're not even using them, and helping you reduce the scope and size of your external, far-away dependencies. From an InfoSec perspective that's the biggest problem I see in containerized environments, (and true that just not using containers won't really make it much better) so correct me if I'm wrong, but I think that Go does all of that for us. [1]: https://snyk.io/blog/top-ten-docker-images-contain-over-8000-vulnerable-paths/ https://snyk.io/blog/top-ten-docker-images-contain-over-8000...
bastardoperator 7y ago
I'm working with customers now that are running Kubernetes to host Java applications and microservices. I'm not a huge fan of Java or the ecosystem, or the fact you can build a Kubernetes cluster using maven, but to claim its dying is outright absurd. As a consultant, I see Java widespread. Every organization is either writing Java or running an application dependent on Java that is also mission/business critical. Most of my work happens on the backend, but we see lots of Java upstream with mobile apps, big data, ETL, etc...
diegoliber 7y ago
Go is a good language for developing middleware and automation tools, but it's not, at any rate, a replacement for Object-Oriented languages. Java, C#, Python, Ruby etc are much more suited to business-oriented apps, data science and so on. There are many uggly things on Go language that can be considered nice features for system programming. Even though, if you go too much on the low-level (such as for operating system, drivers or embedded devices) it's still a issue to use go instead of a more hardcore systems language such as C++ or C. It is, at most, a niche language today. And probably will stay this way unless it goes into a major redesign. Better to talk about Rust or Kotlin, which are languages that have much more potential and can be a real threat to the dominant languages/platforms today. But right now, they are too unknown to be taken in consideration just as many other good languages that never came to be.

dtech 7y ago

I said LLVM and webassembly. LLVM has replaced JVM as a programming language target bytecode in the last 10 years (except Kotlin no new JVM language). JVM has lost web to JS 20-15 years ago, and Webassembly is now taking shape as proper web bytecode. I do not know what will be the most dominant language + bytecode in 25 years, but I would bet $10000 that it isn't Java and JVM.

StevePerkins 7y ago
> except Kotlin no new JVM language Java's never going to be on the bleeding-edge of trendiness (thank goodness). But there have been fewer JVM-targeting alternative languages over the past decade, because Java itself started leaning in a functional direction. It became "good enough" to negate the purpose for most of them. At any rate, counting compile targets for hobbyist toy languages is barely one step beyond measuring GitHub stars. > I do not know what will be the most dominant language + bytecode in 25 years In 25 years, I'll be long gone and you can have it. By then, the industry will be pushing to automate most programming jobs out of existence altogether, and you can be the old guard arguing against that.
- victor106 7y ago
  > except Kotlin no new JVM language. What about Clojure? I 100% agree with you on Java. Some of these people who compare Java to Cobol have no idea. It’s hard for anyone to predict the future in tech but at this point Java is so widely used in the enterprise that it’s foolhardy to think that Java will disappear anytime soon. To the credit of the Java community they keep the language relevant and refreshed. I agree it’s always about 1-2 years behind other languages in terms of features but most enterprises don’t give a damn. Most enterprises just want to get work done. They don’t care about functional or OO. In the last 3 years I have seen maybe 40% of developers use the latest features from java 8. So while java might be slow to catch up that’s what it’s customers want. Spring and Vert.x and similar Java frameworks will always keep Java relevant that it will be hard to ignore
  - rpeden 7y ago

marcus_holmes 7y ago

I've heard that attitude before. C++ developers working in finance around 2000. They were damn sure that no-one was going to switch to any other language because reasons. I'm sure there's still a bunch of C++ devs working in finance, and making decent money, but I think the industry has moved on now. The industry always moves on

DaiPlusPlus 7y ago
HFT gigs I’ve looked at were all C++, some even Rust now - because they don’t want the risk of a long GC pause messing up a trade (which means Java, .NET, and Go are right-out).
- dilyevsky 7y ago
  Go uses tri-color mark-and-sweep gc that runs concurrently and its latency is extremely short compared to .net and java (probably still not short enough to be put in the critical path of hft order processor tho). Edit: I'm also confident you can ensure Go’s gc doesn’t run when you don’t want it to so there’s that.
  - dgoldstein0 7y ago
    This may be true but conventional wisdom against using anything GC'ed for real-time applications (like HFT or aerospace stuff) is going to mean even if go's gc is good enough, using any gc'ed language for these apps is going to be extremely rare for years if not decades. Seems far more likely that rust will chisel away at that market than golang or any other gc'ed language.
    - nvarsj 7y ago
      Many HFT firms have used Java for ages. If you know what you’re doing you can avoid GC. Also, not everything needs to be realtime.
      - haglin 7y ago

sqldba 7y ago

I didn't know Java had so much mindshare for ETL. Can you explain further?

stingraycharles 7y ago
The JVM, Java and Scala have a huge ecosystem with Hadoop, Spark, many databases, etcetera. Go to any company that does a lot of data-intensive processing, and chances are very likely it's powered by the JVM in at least some of the components.

int_19h 7y ago

There are active ongoing efforts to push wasm beyond the web client. Which makes perfect sense, since it could, in theory, deliver JVM's "compile once, run everywhere", but with a lot more flexibility for the languages on top. As far as Node.js being the only JVM alternatively to take seriously, I don't even know what to say. There are lots of enterprises with mature .NET (not Core) business apps, doing all that very stuff that you list - EAI, ETL etc.

TheRealDunkirk 7y ago

And then there's the evil implication of this aging, entrenched ecosystem. Companies who wrote their Java development process documentation did so in the 90's, with guidance from IBM or a "big 3," and now treat EVERY project in the business as though it was the same scale and complexity as the mainframe projects they were trying to supplement. Which is why it takes 6 months for me (on the FAST TRACK!) to even get a development environment for a simple CRUD web app designed to replace a terrible Excel spreadsheet with 5 users -- so that I can submit my feature list and test plan to review boards -- so that I can START writing my application. No wonder it takes the IT group 2 years to write an application I can have in production in 3 months! I don't need a reverse proxy! I don't need redundancy! I don't need an encrypted file store! It's a shared, specialized to-do list application! I don't need the overhead of a global financial application running on Sun E10K's! Nothing personal, but there are a lot of us out here who can't WAIT for people who have based their careers on "enterprise" Java to get out of the way already, and retire. When computers were as powerful as smart watches, we NEEDED all that distributed processing and faffing about with off-line data. Now? Not so much. "Hype trains" Rust, .NET, Go, etc.? Maybe you, too, think that Rails is too "new" and "unproven" to use for anything.

carrja99 7y ago
LOL... someone woke up in the wrong side of the bed this morning.
- dang 7y ago
  Please don't do this here.

lucidone 7y ago

I'm one of those Node devs who've mostly worked for companies who have never made a profit, and I've recently been exploring Go, Java and C# (.NET Core) given I'm starting to work on more "serious" (or difficult) backends (distributed systems) and am hitting the limits of the language and ecosystem I know. Genuinely curious - why do you think I should give Java my attention over C# or Go?

Shorel 7y ago

ETL is the bread and butter of the company where I work and you can be sure Java is not even allowed near our systems. We have thousands if not dozens of thousands of different data providers and it is mostly financial data. Everything important is PHP and Python. It was Perl 10 years ago. There is some Java, but not in the ETL subsystems.