Java at 30: Interview with James Gosling
134 comments
·May 16, 2025nelup20
deepsun
My opinion on that is the projects scale. Typically people came from a 10+ year Java project of 100+ engineers, to a greenfield advanced hello-world -- of course it's going to feel better and more productive.
Also, as open-source folks say, "rewrite is always better". It also serves as a good security review. But companies typically don't have resources to do complete rewrites every so often, I saw it only in Google.
bsaul
Funny. I've been trying rust for the past 2 months fulltime, and i'm really wondering how you can call it a "joy to work with" when compared to java, at least for server development.
Rust feels like walking on a minefield, praying to never meet any lifetime problem that's going to ruin your afternoon productivity ( recently lost an afternoon on something that could very well be a known compiler bug, but on a method with such a horrible signature that i never can be sure. in the end i recoded the thing with macros instead).
The feeling of typesafety is satisfying , i agree. But calling the overall experience a "joy" ?
asa400
I'm not discounting your experience, or saying you're wrong or anything like that. I've been writing Rust for a while, and for me, that feeling went away. Lifetime/ownership problems used to run me over but it almost never happens anymore. I think Rust has a rather severe "hump" that a lot of people run headlong into, but it does get better, I promise you. You start thinking in ownership/borrowing terms and it just fades into the background at some point. Rust is easily my most productive language now. Again, not discounting your experience at all, it can be rough starting out.
mynameisash
> I've been trying rust for the past 2 months fulltime,
> recently lost an afternoon on something that could very well be a known compiler bug
With respect, at two months, you're still in the throes of the learning curve, and it seems highly unlikely you've found a compiler bug. Most folks (myself included) struggled for a few months before we hit the 'joyful' part of Rust.
worik
> I've been trying rust for the past 2 months fulltime
Rust has a horrid learning curve
I've programmed for decades in many languages, and I felt the same as you
Persevere.
Surrender! to compile
Weather the ferocious storm
You will find, true bliss
keybored
Funny. On the other hand my Java code just compiles, it UnsupportedOperationException (5000 identical lines)
bdangubic
same! mid-way through my almost 3 decade career I got bored and thought lets try some non-JVM projects, for 2 years I took projects using other languages etc… worse two years of my career :)
sapiogram
My feelings exactly. Go was particularly disappointing, it promised everything but only felt like a sidegrade from Java. Screw it, a downgrade, until go errors get stack traces.
overfeed
The reason I prefer the Go ecosystem to Java is cultural, rather than technical. Sure, the JVM is very impressive and the language has been evolving, but the culture around Java seems to encourage needless complexity.
Of all the languages I've had to work with trying to get to know unfamiliar code-bases, it's the Go codebases I've been quickest to grok, and yielded the fewest surprises since as the code I'm looking for is almost always where I expect it to be.
null
exabrial
Java performance isn't the fastest, that's ok, a close 3rd place behind C/CPP ain't bad. And you're still ahead of Go, and 10x or more ahead of Python and Ruby.
Java syntax isn't perfect, but it is consistent, and predictable. And hey, if you're using an Idea or Eclipse (and not notepad, atom, etc), it's just pressing control-space all day and you're fine.
Java memory management seems weird from a Unix Philosophy POV, till you understand whats happening. Again, not perfect, but a good tradeoff.
What do you get for all of these tradeoffs? Speed, memory safety. But with that you still still have dynamic invocation capabilities (making things like interception possible) and hotswap/live redefinition (things that C/CPP cannot do).
Perfect? No, but very practical for the real world use case.
hintymad
> And hey, if you're using an Idea or Eclipse (and not notepad, atom, etc),
Java's tools are really top notch. Using IntelliJ for Java feels a whole new different world from using IDEs for other languages.
Speaking of Go, does anyone know why Go community is not hot on developing containers for concurrent data structures? I see Mutex this and lock that scattering in Go code, while in Java community the #1 advice on writing concurrency code is to use Java's amazing containers. Sometimes, I do miss the java.util.concurrent and JCTools.
eikenberry
It's a core principle.
Don't communicate by sharing memory; share memory by communicating.
fidotron
My experience is a shocking amount of the golang community believe channels are a performance problem for whatever they're doing, and they use mutexes in some misguided effort at optimization.
But then I have also encountered Rust people that will look down on Java but had no idea buffered I/O had higher throughput than unbuffered.
hintymad
Thanks! What about data structure shared by multiple goroutines? Say, an in-memory cache object? Or do we always have multiple goroutines talk to a dedicated goroutine for the shared value? Would the performance be okay for all use cases? A reason that people use JCTools is that it can easily support hundreds of millions of concurrent reads/writes to its data structures on a 10-year old laptop.
zwnow
Just implement concurrency with actors and u save up on some locks and mutexes...
The patterns are available, its up to the community to apply proper concurrency patterns.
PaulDavisThe1st
The only replacement for locks/mutexes is a lock free data structure. Locks are not what make concurrency possible, they are what makes it data-safe.
You can use platform threads, user-space threads, language-provided "green" threads, goroutines, continuations or whatever you wish for concurrency management, but that's almost orthogonal to data safety.
paulddraper
The x86 instruction set is available as well.
brightball
When I got out of college and was still firmly in the "Java is the solution to everything" mentality I didn't realize that my admiration was really for the JVM and the Java App Server tooling that was so much more advanced than anything else at the time. It was basically Docker + K8s for anything running on the JVM more than 2 decades earlier.
Java the language eventually drove me away because the productivity was so poor until it started improving around 2006-2007.
Now I keep an eye on it for other languages that run on the JVM: JRuby, Clojure, Scala, Groovy, Kotlin, etc.
IMO JRuby is the most interesting since you gain access to 2 very mature ecosystems by using it. When Java introduced Project Loom and made it possible to use Ruby's Fibers on the JVM via Virtual Threads it was a win for both.
Charles Nutter really doesn't get anywhere close to enough credit for his work there.
cogman10
Let me extol the virtues of Java the language.
You can take pretty much any code written for Java 1.0 and you can still build and run it on Java 24. There are exceptions (sun.misc.Unsafe usage, for example) but they are few and far between. Moreso than nearly any other language backwards compatibility has been key to java. Heck, there's a pretty good chance you can take a jar compiled for 1.0 and still use it to this day without recompiling it.
Both Ruby and Python, with pedigrees nearly as old as Java's, have made changes to their languages which make things look better, but ultimately break things. Heck, C++ tends to have so many undefined quirks and common compiler extensions that it's not uncommon to see code that only compiles with specific C++ compilers.
fpoling
I have C++ code from 1997 that I occasionally compile. So far it runs. 10 yeas ago compiling with -Wall exposed an inconsequential bug and that was it. I suspect when it stops to compile it will be from an absence of a particular X11 library that I used to parse a config in otherwise command-line utility.
Which also points to another thing where Java compatibility shines. One can have a GUI application that is from nineties and it still runs. It can be very ugly especially on a high DPI screen, but still one can use it.
eppp
I know that what you said is supposed to be true. However in my real world experience it is anything but. Cisco java programs are a disaster and require certain JVMs to run.
jsight
Yeah, that and the portability are really incredible and underrated. It is funny, because I constantly hear things like "write once, debug everywhere", but I have yet to see an alternative that has a higher probability of working everywhere.
Although Python is pretty close, if you exclude Windows (and don't we all want to do that?).
cbm-vic-20
I've got a jar that does one small thing and does it well that was compiled in 1998. Still works fine, no reason to update it.
brightball
That is an excellent point too.
It always made me wonder why I hear about companies who are running very old versions of Java though. It always seemed like backwards compatibility would make keeping up to date with the latest an almost automatic thing.
AnimalMuppet
That's not the virtues of Java the language. That's the virtues of Java the backward-compatible platform. That is, you didn't say anything about the language (syntax and semantics), you only talked about backward compatibility.
(It's still a valid point. It's just not the point you labeled it as.)
jbverschoor
Oh yeah. I still don’t understand why we even moved away from the original JEE model, including the different roles (app dev, deployed, etc).
The whole spec was great with the exception of entitybeans.
It provided things that are still not available it anything else.. why do we store configuration/credentials in git (encrypted, but still).
And the context were easy to configure/enter.
Caucho’s resin, highly underrated app server. Maybe not underrated, but at least not very well known
brightball
I remember Resin.
I grew to be a big fan of JBoss and was really disappointed when the Torquebox project stopped keeping up (Rubyized version of JBoss).
liveoneggs
resin was okay but I never got what it offered over tomcat
lelanthran
> Java performance isn't the fastest, that's ok, a close 3rd place behind C/CPP ain't bad.
When Java got popular, around 1999-2001, it was not a close third behind C (or C++).
At that time, on those machines, the gap between programs written in C and programs written in Java was about the same as the gap right now between programs written in Java and programs written in pure Python.
javier2
> Java syntax isn't perfect, but it is consistent, and predictable
This is something I greatly value with the recent changes to Java. They found a great way to include sealed classes, switch expression, project Loom, records that feels at home in the existing Java syntax.
The tooling with heap dump analyzers, thread dump analyzers, GC analyzers is also top notch.
aardvark179
I think Gavin Bierman is an unsung hero as far as steering the Java language is concerned. I had the privilege to sit next to him in the office when I was working on TruffleRuby, and our conversations on language design were always elucidating, and his ability to gently steer others away from pitfalls was something I wish I could do as well.
Hearing the work he and others did to gradually introduce pattern matching without painting themselves into a corner was fascinating and inspiring.
nxobject
Third best consistently used over 3 decades adds up to a great, great deal. Although, to be fair, a great deal has been invested in cutting edge GCs for the JVM – some fresh out of research.
interleave
I miss writing Java 1.4 with Eclipse and svn. Even though I am also super-happy with Ruby and Swift today, I know that control-space flow. Good times!
Edit: 1.4, not 1.7
dragandj
Throw in Clojure into the mix, and you get superpowers!
exabrial
I'm still trying to mentally grok the Clojure model and syntax hah. On my todo list. Clojure users seem to love it though. Do you have a tutorial that could sell it to me?
mark_l_watson
My Clojure AI book won't teach you the language, but afterward you read through a tutorial my book contains interesting examples; read it online https://leanpub.com/clojureai/read
dragandj
Many Clojure tutorials are free! It's difficult to say without knowing nothing about your preference and experience. Everyone's welcome to join Clojure Slack community (for example) which has several tens of thousands of members and dedicated beginners channel. I'm sure if you asked there, you'd get tons of recommendations tailored to you. https://clojurians.slack.com/
(BTW Clojure, as a Lisp dialect, has almost no syntax. You can learn THAT in 5 minutes. The challenge is in training your programming mind to think in totally new concepts)
wry_discontent
Start doing any year of Advent of Code with Clojure and you'll get it.
They're really amenable to the REPL.
jbellis
more like 100x faster than Python/Ruby
and that's before you throw in real multithreading
mark_l_watson
Right on, James Gosling's work is amazing, and he and the whole Java ecosystem have my gratitude: I went to the first Java World Tour conference and wrote a little blog article about it that was linked on Sun's home Java page for about a year. I was very lucky, and since I was the first search hit for 'Java consultant' for a very long time that gave my wife and I the freedom to live in a rural area and I could get remote work for a decade.
As long as I am expressing gratitude, I would also like to call out the Clojure team for developing a wonderful ecosystem in top of Java and the JVM.
It must be wonderful to do work that positively affects the lives of millions of people.
jgneff
I am also very grateful to James Gosling. I was working with C++ at Taligent (an Apple, IBM, and HP joint venture) in the fall of 1995 when I first downloaded Java to give it a try. I literally jumped up and down with joy after writing my first "Hello, World" program. It was such a breath of fresh air compared to the Taligent CommonPoint application framework we were building.
I took the severance package when Taligent imploded, dropped everything I was doing at the time, and have been working with Java and its related software ever since.
fidotron
I think it's incredible with hindsight how Java countered many of the mid 90s C++ problems, especially by avoiding multiple inheritance.
It remains a shame that it didn't launch with generics though, and I still think operator overloading would have been good. Had it done so I think a lot more people would have stuck around for when the performance improved with HotSpot.
dragandj
Both James Gosling (Java) and Rich Hickey (Clojure) are amazing creators! Each brought a breath of fresh air to programming at their respective times.
w10-1
Java is a great success story. Though, to be fair, James Gosling was the spark but has not been the steward.
Even as early as Java 1.1 and 1.2 he was not particularly involved in making runtime, library, or even language decisions, and later he wasn't the key to generics, etc.
Mark Reinhold has been the hand's-on lead since 1.1, first integrating early JIT's, HotSpot, the 1.2 10X class explosion, and has been running the team all the way through Oracle's purchase, making the JVM suitable for dynamic language like Kotlin and Clojure, open-sourcing, moving to a faster release cadence, pushing JVM method and field handles that form the basis for modern language features, migrating between GC's, and on and on.
As far as I can tell, everything that makes Java great has come down to Mark Reinhold pushing and guiding.
elric
The whole core team is amazing. Gosling wanted a language that was practical from a development POV. Over the years, it's been refined into a language with a fair amount of mechanical sympathy on top of the development experience. Thanks to folks like Mark Reinhold and Brian Goetz.
I have no love for Oracle the big bad company. But I am deeply greatful they've managed to keep that group moving forward.
keybored
I don’t think there’s a point to discussing Java. There’s two rhetorical lanes, and they can be switched between smoothly.
- Bad language and standard library design, all the inconsistencies that make you waste your time to this date unless perhaps you have very good static analysis: but history happened, nothing we can do about fate and circumstance
- Great implementation of the technology itself (surface design not really relevant): heroic deeds and feats triumphed over fate and circumstance, this is all to our own credit
throwaway7783
Java stagnated for a while, but has now picked up steam. With things like GraalVM, the stellar ecosystem, generally very good performance and changes to the language, it is more and more pleasant to use.
It may not be cool to use Java for startups, but we do and are immensely productive with it.
PathOfEclipse
I've been working in .NET/C# for the past few years, and while I'm happy with it, I still think the JVM/Java are the best ecosystem overall I've worked in. It's amazing how many things the Java ecosystem gets right that .NET gets wrong.
For instance, Java introduced the fork/join pool for work stealing and recommended it for short-lived tasks that decomposed into smaller tasks. .NET decided to simply add work-stealing to their global thread pool. The result: sync-over-async code, which is the only way to fold an asynchronous library into a synchronous codebase, frequently results in whole-application deadlocks on .NET, and this issue is well-documented: https://blog.stephencleary.com/2012/07/dont-block-on-async-c...
Notice the solution in this blog is "convert all your sync code to async", which can be infeasible for a large existing codebase.
There are so many other cases like this that I run into. While there have been many mistakes in the Java ecosystem they've mostly been in the library/framework level so it's easier to move on when people finally realize the dead end. However, when you mess up in the standard library, the runtime, or language, it's very hard to fix, and Java seems to have gotten it more right here than anywhere else.
MarkSweep
The thread pool starvation problem in .NET is annoying when you encounter it. Personally I have not bumped into since the .NET framework days.
The thread pool implementation has been tweaked over the years to reduce the impact of this problem. The latest tweak that will be in .NET 10:
https://github.com/dotnet/runtime/pull/112796
I’m not sure a thread pool implementation can immune to misuse (many tasks that synchronously block on the completion of other tasks in the pool). All you can do is add more threads or try to be smarter about the order tasks are run. I’m not a thread pool expert, so I might have no idea what I’m talking about.
neonsunset
> frequently results in whole-application deadlocks on .NET
Tell us you don't write any sort of .NET code without telling us so explicitly.
You should pick a platform you have better command of for back-handed comments.
Or at least you should try to do a better job than referencing a post from 13 years ago.
null
PathOfEclipse
That's a very harsh reply with zero evidence behind it. Based on your response, I am willing to bet I understand the platform better than you do. And the deadlocks I'm referring to are happening in apps written by other people who've been in the .NET ecosystem exclusively for more than a decade, or even two decades.
Here's an article from 5 years ago:
https://medium.com/criteo-engineering/net-threadpool-starvat...
But does citing a more-recent article matter to you? Probably not. A source being 13 years old only matters if something relevant has changed since then, and you certainly couldn't be bothered to point out any relevant change to support your otherwise fallacious and misleading comment.
What actually amazes me most about this is that people in .NET seem to want to blame the person writing sync-over-async code like they are doing something wrong, even going so far as to call it an "anti-pattern", when in reality it is the fault of poor decision-making from the .NET team to fold work-stealing into the global thread queue. The red-blue function coloring problem is real, and you can't make it go away by pretending everyone can just rewrite all their existing synchronous code and no other solution is needed.
If all you know is one ecosystem, then it seems you are susceptible to a form of Stockholm syndrome when that ecosystem abuses you.
neonsunset
> But does citing a more-recent article matter to you?
It does. For example, starting with .NET 6 there is a pure C# threadpool implementation that acts differently under problematic scenarios.
You do not understand performance profile and UX pros/cons of why async model is better than opting into stackful coroutine based design. You're probably of opinion that the only way to use async is to always await immediately rather than idiomatically composing tasks/futures.
I'm certain you're basing this off of your personal experience from more than a decade ago of some forsaken codebase written in an especially sloppy way. Do you know why sloppy async code is possible in the first place? That's because even the initial threadpool implementation was so resilient.
Because that's where this kind of sentiment from supposed "seasoned experts" on .NET stack usually comes from.
Moreover, there isn't a single mention that the real way to get into actual deadlock situation is when dealing with applications enriched with synchronization context. You will only ever run into this in GUI scenarios, where .NET's implementation of async continues to be a better alternative to reactive frameworks or, worse, manual threading.
> If all you know is one ecosystem, then it seems you are susceptible to a form of Stockholm syndrome when that ecosystem abuses you.
Pathetic attempt at strawman.
My opinion of .NET kept improving since .NET Core 2.1/3.1 days up until today because of researching the details of and getting exposed to other languages (like Rust, Go, Java, Kotlin, Swift, C and C++, you name it).
Hell, I'm not even arguing that what we have today is the holy grail of writing concurrent and parallel programs, only that most other alternatives are worse.
toprerules
I admire Java as a success story, but I still have a deeply ingrained aversion to it for many reasons. I will admit that many of the reasons are due to Java's legacy as the language of bloated corporations, and its creation of overly verbose, magic fueled frameworks and poorly written code. Java as a language goes hand in hand with the idea that code is coal to be shoveled into the furnace, and we should all throw our aspirations away and embrace mediocrity.
My other issues with the JVM is how much of a black box it is from a platform perspective, which makes debugging a PITA with standard ops tools like strace, gdb, etc. The JVM's over allocation of memory robs the kernel of real insight as to how the workload is actually performing. When you use the JVM, you are completely locked in and god help you if there isn't a JVM expert to debug your thing and unravel how it translates to a platform implementation.
Then of course there's the weird licensing, it's association with Oracle, managing JDK versions, it's lack of it factor in 2025, and a huge boatload of legacy holding it back (which is not unique to Java).
I have successfully navigated my career with minimal exposure to Java, and nowadays there's a glut of highly performant languages with GC that support minimal runtimes, static compilation, and just look like regular binaries such that the problems solved by something like the Java or Python VMs just aren't as relevant anymore - they just add operational complexity.
To reiterate, I admire JG just like any tech person should. Java's success is clear and apparent, but I'm glad I don't have to use it.
exabrial
>My other issues with the JVM is how much of a black box it is from a platform perspective, which makes debugging a PITA
Java has one the greatest debugging capabilities ever. dynamic breakpoints, conditional breakpoints, hell you can ever restart a stack frame after hot deploying code without a restart. You can overwrite any variable in memory, set uncaught exception breakpoints, and even have the JVM wait for a debugger to connect before starting. There is no equivalent in any other language that does _all_ of these things. And to top this off, there is 0 equivalent to Idea or Eclipse for any other language.
For runtime dynamics, JMX/JConsole is good enough for daily use, Java Flight Recorder gives you deep insight, or in a system you don't have direct access to. Hell even running jstack on a JVM is a good debug tool. If those don't do the trick, there's plain old HPROF (similar to other languages) and Eclipse Memory Analyzer.
>Then of course there's the weird licensing,
The JVM is open source. There are no licensing issues. OpenJDK can be freely downloaded and run in production without restrictions on any use. If you really want to buy a JVM from Oracle... well thats your prerogative.
> it's lack of it factor in 2025,
sdkman
> a huge boatload of legacy holding it back
what legacy code?
null
throwaway7783
In my 20+ years using java, not once have I used strace or gdb. Java itself has fantastic debugger support, and IDEs have built in step through capabilities.
Mentioning Java and Python in the same way in the context of performance is really odd. Python is nowhere near the JVM when it comes to performance
the_overseer
IT factor! Am I on a fashion website now? What kind of argument is that? Also, why on earth would you use strace or gdb for Java? It has enormously performant debugging tools in the JDK. Also, IDE debugging integration is second to none.
jcadam
Been coding on the JVM for a good chunk of my career. Though the last several years has been in languages other than Java - Scala, Clojure (my personal favorite), and Kotlin.
Finally managed to get a job offer (after being unemployed for a bit) doing Python. It's starting to look like demand for JVM experience is beginning to wane. Might be time to move on anyway :shrug:
I'm old... as long as there's a steady paycheck involved, I'll code in whatever language you say.
Though, currently working on a little personal project in Scala. :)
rootbear
When Gosling was at Sun, he was one of two principal architects of the NeWS Window system. The X Window system was designed for "dumb" display devices and so the display elements were all static, not requiring much work from the server. NeWS was designed to run on a (Sun) workstation, where there was a lot of computational power available, so it was based on Postscript. A NeWS client would send a program to the server, not just static commands.
Gosling, unsurprisingly, designed Java with the NeWS model in mind, where web pages were programs, not just static HTML documents. When I got him to sign my copy of "The Java Programming Language", I asked him if Java was the revenge of NeWS. He just smiled.
AStonesThrow
The corollary of this was Display PostScript. At my first job we had a SPARCStation 2 with a SPARCprinter. The SPARCStation was a mighty wonder to behold, with a storage pedestal and a lovely OpenWindows GUI on a luxurious Sun monitor and color framebuffer. The operator sitting at the desk was often just a novice clerical worker, but we ran a few Internet services on the machine as well. However, our department depended on that SPARCprinter to spit out hundreds of sheets of paper daily.
We could not depend on the printer to stay functional, though. Have you heard of a Winmodem? SPARCprinters were essentially that: they were configured as a "dumb display device" where all the imaging logic was contained in the software and run on the server. A page was written in PostScript, rendered on the print server, and dispatched to the printer as if it were a framebuffer/monitor.
Unfortunately, for whatever reason, the server software was not so reliable, or the printer hardware wasn't reliable, and because of this peculiar symbiotic parasitism, whenever our printer wedged, our server was also toast. Every process went into "D" for device wait; load averages spiked and all our work ground to a halt. We would need to pull the worker off the desktop, reboot the whole server, and start over with the printer.
That printer haunted my dreams, all though my transition from clerk, to network operator, to sysadmin, and it wasn't until 2011 when I was able to reconcile with printers in general. I still miss SunOS 4 and the whole SPARC ecosystem, but good riddance to Display PostScript.
aabajian
Just going to remind y'all of this: https://www.joelonsoftware.com/2005/12/29/the-perils-of-java...
I went to a Java school. I remember my operating systems class involved writing simulated OS code in Java (for example, round robin for context switching). The argument was that it would be easier to understand the algorithms if the hardware complexities were minimized. I understand that sentiment, but I don't think Java was the right choice. Python would have accomplished the same task even better (understanding algorithms). I think there was a huge influence from industry to teach college students Java from day one. I had taught myself BASIC and some C back in high school, so it was a bit of a step backwards to learn a high-level language just to do simulated low-level OS programming.
briankelly
My school started us off in microcontroller programming in C then Java for intro to data structures and OOP then back to C (and MIPS assembly) for systems/OS/concurrency. One thing I appreciate Java over Python for DS/Algo is the clear delineation between abstract data type and underlying data structure - IMO is easy to get a wrong mental model with Python. But teaching OS concepts in Java seems a little crazy to me.
Koshkin
Hm... Why? Java seems to be a perfect language in which to understand things at a conceptual level!
briankelly
Good to get your hands in the dirt as well.
cbm-vic-20
A lot of the arguments Joel makes in that article also apply to Python, and pretty much any other higher-level language that doesn't make you think about pointers. Ironically, he points out the Google had a great leap over Microsoft with MapReduce, which was built in Java.
jonhohle
Back in the early 2000s, I was taught in C, C++, Motorola 68HC11, and MIPs assembly. I can clearly understand how Java works, even if I don’t know its GC is implemented. I can understand how programs were written from the 80s to currently. Had I learned programming in Java or, worse, Python, I doubt I’d have the same understanding. It’s relatively easy to go from low level to high level languages if you’re willing to give up control. My experience is that the opposite is less true. It’s certainly possible, but not as straightforward as understanding some foundational ideas.
snovymgodym
Java, especially modern Java, is a fine language. The JVM is an awesome runtime. I'm tired of pretending it isn't.
I personally appreciate Java (and the JVM) much more after having tried other languages/ecosystems that people kept saying were so much better than Java. Instead, I just felt like it was a "the grass is greener" every time. The only other language that I felt was an actual massive improvement is Rust (which so far has been a joy to work with).
It's a shame imo that it's not seen as a "cool" option for startups, because at this point, the productivity gap compared to other languages is small, if nonexistent.