[yagodragon]

Java might be the most successful programming language. It is a solid choice among many different fields. It is used on huge infrastructure projects (Apache Foundation), governments, big tech companies such as amazon, ibm, google, apple for many large scale services. It can do web, ml, GUIs, it's still strong among academics. On top of that it offers a great programming experience with excellent IDE support and it's ecosystem is huge. Even if you don't like the language itself , you can choose between Kotlin,Scala,Clojure that run on the JVM.

I think that Java is seriously being downplayed by HN crowd.

[hn_throwaway_99]

Ironically, while Java was the original "write once, run anywhere" language, it never succeeded in that regard (e.g. browser applets were never popular). Ironically, I believe Javascript has.

I was pretty much exclusively a Java programmer for the first decade and a half of my career, before moving to Node and TypeScript. I don't think I could ever go back at the point. Most importantly, this is my first time where the entire code base (front end and back end) is in the same language and toolchain, and I think it is the single most important thing I've seen in years for improved team productivity. The ease with which engineers can go between front end and backend is an incredible boon that shouldn't be underestimated.

[throwaway189262]

I use typescript a lot. It's way better than JS but the type erasure problem is far worse than Java. Essentially all types are erased, so bugs where typings don't match what you expect and everything blows up are common. This isn't possible in Java because it's statically typed at runtime.

JS also uses several times more memory, is slower, and has a terrible (non existing) threading model. Yes you can run multiple instance of node or whatever, but sharing objects between them requires message passing which is orders of magnitude slower.

Until JS has a good threading model I'm never using it for backend. It's too expensive to use a bunch of single core machines to make up for it.

All of our devs use Typescript and Java daily for front and backend, the only overhead is making sure objects were passing around match on both ends. The only advantage to using the same language for everything is hiring inexperienced devs that don't know both IMO

[ht85]

> bugs where typings don't match what you expect and everything blows up are common

> the only overhead is making sure objects were passing around match on both ends

Seem like is it a big deal based on the first sentence.

I've never been convinced of the single language argument. Sharing code between frontend and backend sounds good but as in practice there's little overlap... models have subtle differences, there's extra logic server side... All in all it's not very practical.

To me the most awesome part of a fully TS project is that you can use the same interfaces everywhere. If you take the time to define them for any input / output, everything is pretty much guaranteed to be sound.

> the type erasure problem is far worse than Java

Check out RunTypes [1], amazing to guard any incoming data.

1. https://github.com/pelotom/runtypes

[salamanderman]

It's more about the ability to share programmers than the literally code, in my opinion.

[throwaway189262]

This library looks great! For cross language comms you can also use gRPC to avoid writing objects for both sides. We're not using it company wide but so far it works as advertised, minus the annoyance of having to use gRPC proxy to web endpoints

[watwut]

> Seem like is it a big deal based on the first sentence.

There is big difference between "this API can blow" and "it can blow everywhere".

[manquer]

Sharing same stack is more important when team / project is small.

[0xae4f5b]

> has a terrible (non existing) threading model. Yes you can run multiple instance of node or whatever, but sharing objects between them requires message passing

Don’t Node.js worker threads solve exactly this?

[hota_mazi]

If erasure is bothering you so much, it means you are heavily relying on reflection / runtime type information retrieving.

Which means you are second guessing the compiler, which provided you with such great guarantees.

You should do your best to minimize this kind of code.

[hota_mazi]

> Ironically, while Java was the original "write once, run anywhere" language, it never succeeded in that regard (e.g. browser applets were never popular). Ironically, I believe Javascript has.

It completely succeeded in that!

Java (well JVM) developers today can

- Write code on any of Windows/Linux/macOS

- Deploy that code on any of Windows/Linux/macOS

Not a lot of language/platforms can claim to this amount of success, let alone with such an amazing set of tools and ecosystem.

[tasogare]

C# (largely inspired by Java) run on even more platforms, because there is compiler/runtimes for mobile platform. It’s also the second biggest "entreprise" language, which fix a lot of Java pain points.

[pjmlp]

Actually C# runs on less platforms than Java, because it doesn't run on embedded devices, M2M, bluray players, military deployments, mainframes, Xerox and Ricoh copiers, SIM and chip based credit cards, and plenty of others devices, like even having a mobile OS based on an Java dialect.

[hota_mazi]

Technically, maybe.

In practice, how many developers write C# on a non Windows platform? I'd say a very, very tiny minority.

On the other hand, Java is being written on all platforms and being deployed on many as well.

[nfg]

> In practice, how many developers write C# on a non Windows platform? I'd say a very, very tiny minority.

Plenty do - think of deploying c# web services on Linux servers / containers.

[throwaway8941]

GP said "write", not "deploy".

I write C# on Linux and I am basically the only person I know who does that.

[jussij]

Microsoft is pushing hard with it's .Net Core offerings and that effort is designed to make C# a more universal language.

Whether that effort pays off, only time will tell.

[thu2111]

There are for Java too. You can - obviously - run Java on Android, using either the native runtime or, less obviously, OpenJDK with JavaFX.

You can also compile JavaFX apps AOT for iOS! It's called Gluon Substrate, check it out.

Java really does run on a lot of stuff, even if OpenJDK itself may not.

[coldtea]

>Ironically, while Java was the original "write once, run anywhere" language, it never succeeded in that regard

That's what people say, but I don't see that.

The same Java code is extremely portable, from Windows, MacOS, Linux, etc, on both the server, cli, and GUI app side.

It's just that its UI libs have historically been over-engineered shit like Swing.

[hn_throwaway_99]

I'm not saying Java code isn't very portable, and there are some notable exceptions (the IntelliJ/JetBrains products always are first to come to mind) of successful cross platform Java client apps.

But much of the original late 90s hype about Java was its cross platform nature, especially in the browser, but Java applets and other in-browser Java technologies were never popular (consider GMail and other GWT apps were written in Java but compiled down to Javascript).

Java owes 90%+ of its ubiquity and longevity to its success on the server.

[thu2111]

They were pretty popular actually. The problem was that browser makers started trying to kill applets off very early. Netscape supported them, but Microsoft / Sun had a huge falling out and they ended up pushing ActiveX very hard as a replacement. The dominance of IE assured that ActiveX replaced Java applets for a while, and then MS fell out of love with ActiveX too, so HTML+JS was all that was left.

Applets were very much a victim of various power struggles within the browser industry, combined with Sun's general lack of competence on the desktop - for instance, their online upgrade engines have always sucked. Though in fairness, nobody got that right until Chrome.

[spullara]

Ironically if Java developers had used the built in DOM APIs instead of the Applet canvas crap, we probably would have had great SPAs a lot earlier.

[chii]

> DOM APIs instead of the Applet canvas crap

i wonder if it was because at the time, the different DOM api in each browser was so immature, that to unify it into a single api is too big a task. The applet+blackbox region for rendering is the easiest MVP. Of course, with hindsight, that turned out to be a piece of crap.

[zaphirplane]

Isn’t that jquery? Seems surmounted by a few very talented people

[therealx]

True, and if gui libraries stuck with common widgets that were cross platform, we would already have a long term native cross platform GUI toolkit.

[therealx]

The successful cross platform apps usually are in a space where having a non-native GUI is accepted.

[WalterBright]

> Java was the original "write once, run anywhere" language

That crown properly belongs to the UCSD P-System, which was the Java of the 1980's. It was the same idea as Java - compilation to a bytecode which an interpreter ran. It failed because the interpreter performance penalty was too high.

Java also started out as an interpreter, which made it too slow. Steve Russell of Symantec invented a JIT for it, and like the lumbering Allison-engined P-51 getting a supercharged Merlin, it brought Java to life.

[nsxwolf]

I also wonder how much the difficulty of sharing files between different systems due to different disk formats played a role in its failure.

You could run p-system on a lot of machines - Apple II, IBM PC, TI-99/4A, PDP11... but how would you (and why would you) distribute your code across machines with such different storage media?

[WalterBright]

Oh, people found ways to transfer files. BBSs were one way, the Kermit program another, NNTP newsgroups, etc.

I transferred files from my PDP-11 (8" floppies) to my PC (5.25" floppies) using Kermit.

[nsxwolf]

Maybe it was more of a problem of not being able to think of a use case for running a pCode program meant for a 512K PDP11 on a 48K Apple II+. A bit ahead of its time.

[WalterBright]

It was definitely ahead of its time, but I and others tried to use it. It was just too slow, and you couldn't make competitive products with it.

[hota_mazi]

I don't know about that.

I coded in UCSD-P quite a bit (and played a few games written in it, Wizardry on the Apple 2 anyone?).

But UCSD-Pascal never reached a tiny fraction of the audience that Turbo Pascal did.

[WalterBright]

Turbo Pascal certainly had more users, but it was never "run anywhere".

[hota_mazi]

Not sure what you mean by that.

Are you talking about the host OS and the fact that Turbo Pascal was Windows only, as opposed to Pascal UCSD which was a VM?

[WalterBright]

I meant that the UCSD system ran on many diverse platforms, and TP did not.

[manyxcxi]

Though it’s technically _not_ Java, Kotlin has been a breath of fresh air for us in the last year. We tried it on a few smaller projects and it took off like wildfire throughout our team.

I write a lot of JavaScript (typescript included) and I have found it to be a very nice combination of things I like from both Java/JavaScript.

Admittedly I have been primarily writing Java for the last 15 years and consider JavaScript a second language for me, you may find Kotlin gives you a good reason to come back to the JVM (where it makes sense to of course).

[ralphc]

It succeeded. Early 2000's I converted my company's "document server" from _heavily_ ifdef'd C to Java. It ran on Windows, Linux, AIX, Solaris, HP-UX, and Linux on IBM mainframes. Having EBCDIC as the default encoding for strings really made you pay attention to encoding in and out of Unicode.

[pjmlp]

How come?

I do it daily during most of those 25 years, developing on Windows, deploying across multiple flavours of UNIX.

[mavelikara]

"Write Once,Run Anywhere" (WORA) is not the same thing as using the same language on the frontend and backend. Java has quite good success with WORA as explained by hota_mazi in the sibling comment. Aplets failing to catch on does not take anything from WORA success story of Java.

[bassman9000]

Is there any major player or project doing backends in JS?

[deepsun]

As far as I know, all major players care about performance and scalability, which JS cannot afford on a single-threaded runtimes.

[bryik]

Uber: https://eng.uber.com/uber-tech-stack-part-two/

[bassman9000]

There's a lot of Java in that article: Hive, Hadoop, Spark, Elasticsearch, Kafka, Cassandra...

[shock]

> The ease with which engineers can go between front end and backend is an incredible boon that shouldn't be underestimated.

In my experience, the engineers that can do that and still produce solid code are very, very rare.

[bird_monster]

Yeah it's a losing battle to suggest Java is mostly fine on HN. In this bubble we only use FP and/or Go/Rust and/or C++.

[ed25519FUUU]

Those are the languages we love at least. I’m willing to bet that most of us are java developers to pay the bills.

[madmax108]

This is practically a trope at this point. Sure, most of us who started off with Java 1.5-1.6 felt the same and Java was pretty much taken seriously only in the enterprise world, but in the last decade so much has happened in the JVM world.

In retrospect, as an early adopter of languages like Scala/Groovy, I really like how Java just waited and watched for a few years to see what was good in those languages and let them make mistakes on the way to building something stable and then adopted a lot of things that made those languages fun.

Java since 11.x onwards had been a great mix of developer productivity, stable core (other than people writing trivial projects, most people want something that lasts for years without random bugs), portability, and great tooling (specially from the IntelliJ side, as well as from the debugging side).

I'd much more openly recommend Java as a loved language now than back in 2010 (though Elixir is the new and shiny project I'm playing around with right now ;)).

[josephg]

It’s really hard to make intuitive guesses like that because we’re all so siloed by the kinds of programming work we do. I did technical screening for about a year (interviewed ~400 people in that time). I thought javascript would be the most popular language (because most of the programmers I interact with write JS more than anything else).

But I was wrong - the most popular language by far for the programming test was Python.

[FpUser]

This depends. End of 90s beginning of 2000s I did an awful lot of Java as I was doing work for Telcos and they have wanted nothing else. Then I changed type clients and suddenly Java had disappeared from my horizon completely (well I did one more single nice contract somewhere around 2005 I think).

For my own products I've never used anything but native (well except browser programming which was Javascript).

[The_rationalist]

Then it's only a matter of time before they learn to love the well being gift that is Kotlin

[StreamBright]

I think your assumption is based on a noisy minority.

[IceWreck]

FP ?

[chishaku]

functional programming

[neuronic]

I hope that most programming is functional to someone.

[chrisseaton]

That's not what they mean.

https://en.wikipedia.org/wiki/Functional_programming

[balloneij]

Sounded like a joke to me

[mrjoelkemp]

In my opinion, Java as a web language is good when you don't need to really understand what's happening (like in low-traffic situations). If concurrency isn't an issue, then the massive amount of libraries can help you a lot.

In high-traffic environments, that ignorance punishes you. I've always felt Java and the JVM are of the mindset that you need a Ph.D. to even understand how it works or how to configure it, and if you can't get it, then you're just a bad programmer.

You need to know if you're blocking threads, if there's memory contention, and if libraries you pull in are using the forkjoin common pool (which you're likely using as a default threadpool). And when something blows up, finding the reason (even for any of the above issues) is really tough. You can use flight recorder, heap dumps and gc logs all day, but good luck navigating it all unless you're a genius. I've seen too many devs end up shrugging and hoping the issues are transient.

Even figuring out proper threadpool usage isn't straightforward. Look at the number of concurrency abstractions just to model concurrency in your system: https://www.youtube.com/watch?v=yhguOt863nw. It's ridiculous.

Lots of large tech companies "seem" to "make it work." But if my experience is at all similar, they're just relying on a handful of Ph.D.'s to hold the hands of the rest of the company when it comes to troubleshooting.

Part of the reason I fell in love with Elixir/Erlang and the BEAM is that it provides a simple (actor) concurrency model (with a single concurrency primitive, a process) and guardrails (time-slice scheduling) to prevent libraries from shooting you in the foot. OTP's observer makes finding bottlenecks a breeze.

For the web, taming concurrency feels way more important than any cpu-crunching perf gains the JVM can give you. I'm too stupid for the JVM; I'll stick to tools that take away numerous categories of complexity and get me closer to mastering my system.

[coldtea]

>In my opinion, Java as a web language is good when you don't need to really understand what's happening (like in low-traffic situations)

Huh? Java is used in huge traffic backends, including HFT with minimal latencies acceptable all the way to Google and Twitter scale.

If anything, Java is much more fast and low level than the typical languages used for huge high-traffic services -- Rails, Python, etc - never mind about what's used in "low-traffic situations".

[lostcolony]

OP isn't comparing it to Rails, Python, etc. He's comparing it to Erlang.

ANd, to that, I'd agree. I've built high traffic stuff in Java. We built it, load tested it, it was terrible. After multiple rounds of profiling, tweaking GC settings, tweaking threadpool sizes, rewriting things to be async, finding out that a client library wasn't reusing connections properly, etc, we finally had acceptable performance...that still was less than I'd gotten out of the box in similar, IO bound services, written as unoptimized Erlang.

[jacques_chester]

> You need to know if you're blocking threads, if there's memory contention, and if libraries you pull in are using the forkjoin common pool (which you're likely using as a default threadpool). And when something blows up, finding the reason (even for any of the above issues) is really tough. You can use flight recorder, heap dumps and gc logs all day, but good luck navigating it all unless you're a genius.

I've seen the same troubles with alternatives, just without the amazing tools, featuresome standard library or widely-accepted conventions.

Erlang is amazing and is places concurrency in a more central position. I'm hopeful Project Loom will greatly diminish the gap while carrying legacy code forward unchanged.

[The_rationalist]

There's tooling such as Blockhound

[MaxBarraclough]

In defence of Java, I read somewhere it's 25 years old ;-)

Part of the reason for its success has been its strong commitment to backward compatibility, so it's to be expected that it might accumulate many ways of doing things. Python wisdom tells us this is often a Bad Thing. [0]

I imagine Java's approach to concurrency and parallelism might be quite different if it were designed today.

[0] https://wiki.python.org/moin/TOOWTDI

[thu2111]

I imagine Java's approach to concurrency and parallelism might be quite different if it were designed today.

Probably not, actually. Project Loom's initial goal was to rethink concurrency on the JVM from scratch. What they came up with was:

* Make threads really, really cheap

* Make thread locals work better (as scoped locals)

* Add a few Executor utilities to help you control sub-tasks better (structured concurrency)

It turns out that Java concurrency is pretty damn good already. It provides all the different paradigms you might want to explore, is efficient and well specified. Meanwhile they realised that many of the alternative approaches to concurrency are in reality trying to work around the high cost of kernel threads. When you make threads really cheap, a lot of the motivation for other approaches falls away and the existing set of tools in the JDK come to the fore.

[smarks]

Your characterization of Loom is, I think, pretty accurate.

There are, however, a few things in Java's early concurrency support that make various things harder, including Loom, and we're having to put some extra effort into grappling with them.

Probably the most obvious is the fact that the language and VM requires every object to have a monitor lock that can be synchronized and waited/notified. In 1996 this was viewed as "Ooooh, sophisticated, building locking and concurrency support into the platform!" In recent years this has started to get in the way. Really only a very few objects are used as locks, but the _potential_ for every object to be locked is paid by the JVM.

It also intrudes on Project Valhalla, which is trying to define "identity-less" inline types (formerly, "value types"). Ideally, we'd want all conventional objects and inline objects to be descendants of java.lang.Object. But Object has the locking APIs defined on it, and locking is intertwined with object identity. So, does Object have identity or not? There are some solutions, but they're kind of weird and special-cased.

Another issue is that the locks defined by the language/VM ("synchronized") are implemented differently from locks implemented by the library (in java.util.concurrent.locks). Loom supports virtual threads taking library-based locks, in that when a virtual thread blocks on a lock it will be dismounted from the real thread. This can't be done with language/VM locks, so there's an effort underway to migrate the those locks to delegate to library code for their implementation. This isn't an insurmountable problem, but it's yet more work to be done, and it's a consequence of some of the original designs of Java 1.0's concurrency model.

[thu2111]

That's true but if Java had been designed with a "synchronizable" keyword applied to classes, I wouldn't consider that a radically different language. The prevalence of unnecessarily lockable things is unfortunate from a JVM implementors perspective, slightly convenient from a user's perspective, but ultimately not a defining feature of the language or platform even if it may have seemed important in 1995.

When I think about Java concurrency today I tend to think of java.util.concurrent or the JMM. Perhaps that's odd.

[bandris]

Actually BEAM and Erlang pre-dates Java. ;-)

As for compatibility: why is Java 8 market share so high in 2020?

[pjmlp]

Shitty Android.

[cesarb]

Isn't Android mostly based on Java 7 (for instance, the Guava artifact you need for Android is the Java 7 one)? It can't be the reason why Java 8 is popular.

I believe that the reason why Java 8 is so popular is because there were a lot of backward compatibility problems with Java 9, compounded by the fact that Java 11 (the next LTS after Java 8; both Java 9 and Java 10 had very a very short life) removed many APIs deprecated by Java 9.

[pjmlp]

Nope, Java 8 nowadays.

https://developer.android.com/studio/write/java8-support

All libraries that matter on the Java eco-system are already on Java 11.

[hota_mazi]

Android moved past the Java restriction ten years ago.

First by adding their own features to the JDK, and today simply by making Kotlin the main language to program in on Android.

Android is completely unshackled from Java today. Android is compeltely

[pjmlp]

On the contrary, without access to Maven Central ecosystem of Java libraries, it quickly loses interest as development platform.

[binaryjay]

More like shitty Java. I'm glad Java is being relegated to a second class language that is not recommended for Android development. Kotlin is the now the recommended language for Android development. I give Google 2-3 years before they deprecate Java from Android.

[MaxBarraclough]

> BEAM and Erlang pre-dates Java

That's not really fair. The point of the Erlang language was its novel and opinionated approach to concurrency. Java wasn't trying to be like Erlang, it was trying to lure programmers by having significant similarities to C/C++.

[deepakarora3]

There are a lot of points which I simply cannot agree with. 1) concurrency as an issue - you make it sound as if doing concurrent programming in Java is hard. Its not if you read through the documentation. In todays world of spinning up small servers, when done right, it scales to massive levels. 2) Blocking threads, memory contention etc. - i think you may be comparing against the likes of single thread programming models like Vert.x or Node.js etc. The flip side which in my opinion is more severe is that if you get even a small thing wrong on the other side, it blows up even more which is more difficult to isolate and debug. Plus the need to learn a whole new programming paradigm which is not easy to wrap your head around. 3) Lot of tech companies seem to make it work - while I agree that corporates will pretty much make everything seem to work, it requires a few engineers who understand software design principles to create design and abstractions that work well. You imply that only PhDs understand that kind of stuff whereas I am sayin that there are many other who understand and who are genuinely making things work in the Java world. I can tell you, when concurrency done right in Java, it is so performance that many will simply not believe. Just my thoughts and happy to differ.

[dnautics]

Just try playing around with the other vm for a bit. It's just crazy easy.

[miskin]

I believe there are few runtimes out there that have such a good monitoring and profiling tools for free and out of the box as Java. Java Flight Recorder, remote debugging and monitoring can be really useful for rare production performance issues.

[lostcolony]

It's funny you should mention that in response to a post talking about Erlang. :P Because, yes, there are few. The BEAM happens to be one that definitely beats the JVM on that front.

[The_rationalist]

In which précise aspect does it outperform jvm tooling?

[lostcolony]

So monitoring and profiling are pretty similar in what sort of things they tell you, but the meaningfulness tends to feel higher due to the programming model. Here's a fairly recent blog post giving an example from someone trying the BEAM for the first time, coming from the JVM - https://medium.com/@mrjoelkemp/jvm-struggles-and-the-beam-4d...

But when it comes to remote debugging, and more specifically, a general "I want to understand what is happening in production", the ability to attach a REPL, alongside your tools, is amazing. I can insert a breakpoint, sure (if I for some reason built my production instance with debug info), but just as easily (without any debug info compiled in!), and more usefully, I can query actor state, mailboxes, etc, fire a message to a process to see what happens, etc...all the things you'd get with a REPL running locally in your dev environment, basically. Do stuff like query for internal state for a process, then call a function with it to see what happens to the data, all in isolation from the normal execution flow (since immutable data gives you a degree of safety to actually run that live code, with copies of the live data, and see what happens). I can even remotely load new code, if I want, effectively allowing me to deploy a hotfix without taking the node down. And I can do all of this in prod. All of this is, of course, super dangerous, but with great power etc etc.

[matsemann]

I hardly know anything about those things, and write java backends powering one of the most used services in my country. So I disagree with it being that complicated.

If you write the service stateless it's incredible what you can achieve with a couple small instances of a default spring boot container.

[kbrisso]

I work on a lot of legacy systems in financial services, the biggest issues related to threads is variable scope regarding servlet design patterns. I just migrated a 18 year old app off Weblogic to TomEE and we had issues with struts tags. The main app I work on has around 350 concurrent users. I have JMX on all the time and monitor it for long running threads and tune it when needed. The problem I have with Java is the massive amount of libraries that can be used and developers who copy and paste code and don't think about what the code does. The verbosity kills me too, it's so over done. I've decided to learn Go just because I'm tired of reading Java code, especially legacy code. But yes you are correct there is a lot of settings in the JVM and a lot to read to understand it. It's a powerful language with a lot of features.

[The_rationalist]

Regarding the verbosity you would be better off with Kotlin

[apta]

> If concurrency isn't an issue, then the massive amount of libraries can help you a lot.

Can you point to another language that has anything remotely comparable to `java.util.concurrent`? Also, Java is getting green threads by means of Project Loom.

[jjav]

> In my opinion, Java as a web language is good when you don't need to really understand what's happening (like in low-traffic situations). If concurrency isn't an issue, then the massive amount of libraries can help you a lot.

Not sure how to interpret this comment.. If high concurrency and high performance matter, that is precisely where Java shines. The only other reasonable option would be C++ but it brings so much pain with it that Java is the way to go.

If traffic is low and performance doesn't matter (which is most sites), then sure, use whatever favorite scripting language.

[haolez]

Java is a language that protects your investment. If you write code for it today, it will probably run and be easily deployable in the future by default.

The same cannot be said for Python and JavaScript, for example. At least not by default.

[cuddlecake]

Not sure if being "deployable" is an issue, considering docker exists. So, anything is deployable in the future by default, given a machine running the correct docker image.

Or am I misinterpreting the argument?

[spullara]

Java code will run on the new ARM machines Apple will ship. Running your Docker code in the same environment is not going to be pleasant.

[saagarjha]

Java already runs on the new ARM machines ;) Someone has OpenJDK building for the server variant, and it works quite well already: https://github.com/gonzalolarralde/jdk/tree/gonzalolarralde/.... Apple had the C0 interpreter up on the day of the announcement because they needed it for various Xcode tools.

[cuddlecake]

I must admit I am completely ignorant to how much of an issue this is in real life, but I'm also in the privileged position of having the backend code compiled and run on remote servers, rarely on my own machine. On the other hand, I'm a junior developer, so I might yet stumble on this problem's relevancy at some point.

To be fair, docker is already a pain on my machine (using Fedora 32). I gave up on using docker at some point.

[thu2111]

Apple Silicon dev machines do not currently run Docker at all, or any CPU-level virtualisation.

[CamouflagedKiwi]

It's very widely used, that's for sure. But it's increasingly not a good choice - in the examples you give - web, ML, GUIs, it is not first class in any of those (and not near to it in the latter two).

What's next for Java should be relatively little change; let a language like Kotlin without all the baggage be the way ahead on the JVM. There's a remarkably good compatibility story there; way better than basically any other language ecosystem out there, that's the real legacy of Java.

[lostcolony]

I like to think of Java as 'a reasonable choice for almost any problem'. Almost never the best one. If you're looking for a single language to standardize on for all the things corporate-wide, it makes sense. But don't lie to yourself thinking you've picked the best tool for any job.

[pkulak]

I think it's the JVM that's the real win for Java. At my work we have a mix of Java, Kotlin and Scala and they all Just Work in our deployment pipeline that was built with just Java in mind.

[AnimalMuppet]

I think it's the libraries. They're like Barbie - they have everything. You need, say, to store affine transforms in your SQL database? Java can bridge those very different worlds. (It literally has affine transforms in the library.)

[cesarb]

> I think it's the libraries. [...] they have everything.

On the other hand, they need to have everything. In many other languages, it's common to just use a library written in a different language. For some reason, the foreign function interface of Java seems to have been designed to be hard to use, so instead of using an already existing library, Java developers tend to go through the route of "Rewrite It In Java".

[marvy]

With Project Panama, they are finally trying to make calling non-Java code easy.

[neeleshs]

Also because libraries in other languages often have platform specific dependencies.

[pjmlp]

That was indeed done on purpose, Mark Reinhold has had a talk about it once, but as noted on the sibling comment that is being fixed.

[imtringued]

It wouldn't be portable if it wasn't written in Java.

[socialdemocrat]

This is the nature of technology and economics though. Widely used and mature technology will almost by definition be behind the state of the art. Progress is always happening and by definition a new language cannot achieve mass adoption over night.

Java is big because it has been around a long time and was decent when it came out. Java was the Go of its generation. Nothing radically new but wrapped up in a way people liked and was familiar with in large part due to the success of C/C++ prior.

Whatever achieves mass adoption after Java will also be behind the times by the time that happens, and as geeks we will have moved on to whatever is newer and cooler.

I am pretty neutral towards Java as a language. My biggest issue is with the software culture of over-engineering and complicating things. Java guys seems very dogmatic about how to design software.

[codeulike]

And it gave us Minecraft of course

[chrisdalke]

Not only that, but Java's reflection features opened the door for a huge, vibrant modding community that is arguably one of the largest among any PC game.

Very early in Minecraft's development, people were already decompiling/modifying/injecting their own mods, and a lot of frameworks (Bukkit, Spigot, etc.) emerged to provide a common API for modding.

The large modding community arguably had a very positive impact on Minecraft's early success -- Although I don't have any quantitative metrics to reinforce that point, I fondly remember early Minecraft as having a relatively technical community that tinkered with the game as a sandbox for countless custom experiences.

[StreamBright]

Java is still my default language after so many years (even though through Clojure). I think Java's biggest advantage is the JVM though, if it had an ML programming language on the top without null and proper interfacing to Java packages I would never look at anything else. Just like .NET has F#.

[wk_end]

What's your opinion of Scala?

[StreamBright]

Great question, I think it is a good alternative to Java even though it is trying to do too much. Not sure it is happening because it is trying to build on the top of Java or some other reasons. Scala is still good and productive language though!

https://www.youtube.com/watch?v=v1wrWQcqLpo&ab_channel=Java

[non-entity]

No the commenter you're replying to, but I've actually looked into Scala a few times and while it has some big criticisms I don't necessarily disagree with, there we're many things I actually liked about the language. I briefly considered picking up for a side project, but ultimately went with something else that provided more relevant features and abstractions.

Sadly, in the real world, it seems that Scala is mostly relegated to the Spark world.

[bishalb]

HN downplays it because Java isn't hipster enough.

[billman]

Java is pretty solid, but not percieved as cutting edge anymore, even though they are still improving it. I think Oracle has done a better job then I originally expected. I think the ecosystem is by far it's biggest advantage. It's a integration target for many projects just because it has such wide adoption.

[blackbeard334]

this thread does a good job in summarizing java https://twitter.com/cpurdy/status/1261139068672507905

excerpt Nothing competes with Java. Nothing. Because Java wasn't about destroying the competition; Java was about creating a reality that otherwise did not and could not exist. It was about imaging the "what could have been", and then creating that.

[coliveira]

The main problem with Java is its concurrency model, which gives incentive to the creation of threads that fight for resources and introduce bugs. This seemed a wise choice in the 90s, but as concurrency has increased several-fold in the last 25 years, the model cannot scale to real software needs. It is the Java equivalent to pointers in C.

[kasperni]

> the model cannot scale to real software needs.

And somehow it is still widely used within Google, Facebook, Amazon, Twitter...

[brown9-2]

Most of those companies are not writing one-thread-per-request servers, they write non-blocking / async IO Java.

[Matthias247]

Some will do for sure - but it might not even be "most". There is a suprising amount of thread-per-request code out there. And actually it's doing fairly well - even at the scale of the companies you listed if you are using it in the right place. Right place here means don't use it for a frontend proxy which needs to manage 100k keepalive connections.

But for a service which needs to handle 500 concurrent requests at maximum and doesn't have to deal with TLS anymore it will be fine. And there's enough of those services out there.

A lot of the Java code in bigger companies is also written based on older frameworks like earlier versions of Servlet and J2EE. Those programs will also not make any use of async mechnanisms and prefer a simple programming model instead.

[conjectures]

This isn't actually a rebuttal of the point.

[coliveira]

C/C++ are also used at Google, FB, Amazon, etc. It doesn't mean that it's not a problem.

[tomc1985]

I'd bet you're alienating well over half the entire field of software engineering with calling Java, C, and C++ "problems".

[coliveira]

You're misinterpreting what I said. I talked about the "main problem with Java", and with C/C++. Saying that a tool has a problem doesn't mean it is useless, far from it.

[spullara]

Amusingly, Loom, which will likely appear in the Java 17 time-frame will allow you to use all that blocking code and it automatically transforms it into non-blocking code. Going to make coding high-concurrency applications a lot easier. Check out the few lines of code needed to convert Jetty from blocking to non-blocking:

https://github.com/rodrigovedovato/jetty-loom/blob/master/sr...

[hilbertseries]

I'm very skeptical of this conversion into loom. Jetty bounds the number of concurrent requests it serves based on the size of its thread pool (of course Jetty also uses a few of the threads to run its acceptors and selectors). The implementation provided here, replaces Jetty's fixed sized thread pool with an unbounded thread pool. This is going to lead to some terrible failure states when the service slows down.

[kasperni]

The computational resources of a machine is finite no matter what language you use. You got to put limits somewhere.

[plmpsu]

Can't wait for project Loom:

https://openjdk.java.net/projects/loom

[apta]

What alternative model would you suggest? Green threads still introduce bugs (race conditions), and fight over resources (DB connections, filesystem, etc.)

[Reelin]

This is just silly. What concurrency model doesn't "fight for resources and introduce bugs"?

Threads (and pointers, which you compared them to) are the abstraction at the hardware level - everything else has to be built on top of them in one way or another. Just because you have access to threads (or pointers) doesn't mean you have to make poor architectural decisions. I'd like to draw your attention to Doom Eternal which takes the thread pool model through to its logical conclusion. (https://twitter.com/axelgneiting/status/1241487918046347264) I hope you'll agree that's an example of meeting the needs of real software. (I'm sure it's not the first or only example of that approach, it was just on my mind because it came up recently.)

[jjav]

> the model cannot scale to real software needs

Most of the highest performance server code across many industries in written in Java. So...

I wonder what do you consider could possibly compete with Java in this space?

[neeleshs]

Akka streams and actor model make it better

[agumonkey]

I tried. I honestly tried. Java is my #1 most hated programming language (maybe unless you forget everything before 8 .. and even then.. import java.util.function.BiFunction makes me want to run to a mountain)