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 · 6h ago
> 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 · 5h ago
It's a core principle.
Don't communicate by sharing memory; share memory by communicating.
The overuse of Mutex and Lock are from developers bringing along patterns from other language where they are used to communicating via shared memory. So this aspect of the language just doesn't click as well for many people at first. How long it takes you to get it depends on your experience.
fidotron · 4h ago
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 · 5h ago
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.
eikenberry · 2h ago
For things like cache I generally have 2 goroutines communicating with it. One that directs reads and one that directs writes. Using CSP style you can pass the data (by value) through to the cache (or any other CSP style process) without copying and it performs quite well. I've written several high performance systems in this way with great results.
zwnow · 5h ago
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 · 4h ago
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 · 5h ago
The x86 instruction set is available as well.
Thaxll · 51m ago
Java is not ahead of Go, they're on part but often Go is faster while using 2-10x less memory. Value type makes optimization much easier in Go.
The fact that you specifically mention Go explains a lot. btw c# is faster than Java, so not third place, it's more a 5th~
Benchmarks aren’t all that useful since usually the bottleneck is File IO, external api calls, db calls, user latency or a combo of the 4.
Go’s main advantage in this matchup would be conciseness.
Go code looks so clean and nice, Java doesn’t.
I personally don’t care for Java, but I have bills so it’s always in my back pocket. Things happen , sometimes you need to write Java to eat.
“Fred, you really should just take the job.”
“Martha you don’t understand, it’s Java with an Oracle DB.”
“Fred, I know it’s bad, I know you still have nightmares about the 4 types of string in Java 8, but it’s not just us now.”
With a tear in his eye , fear in his heart.
“Martha, if I must… I’ll open Eclipse once more.”
vips7L · 21m ago
Go code is far from concise. Java is more expressive than Go in almost every way.
brightball · 10h ago
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 · 10h ago
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 · 5h ago
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 · 5h ago
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.
aaronbaugher · 4h ago
The enterprise Java applications we use require specific versions of specific Linux distros. It's possible that they would run on other distros, or even other operating systems, if you got the right JVM. But there's enough question about it that the companies that sell them for a substantial price aren't willing to promise even a little portability.
jsight · 10h ago
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?).
cestith · 9h ago
I can run basically any Perl code back to Perl 4 (March 1991) on Perl 5.40.2 which is current. I can run the same code on DOS, BeOS, Amiga, Atari ST, any of the BSDs, Linux distros, macOS, OS X, Windows, HP/UX, SunOS, Solaris, IRIX, OSF/1, Tru64, z/OS, Android, classic Mac, and more.
This takes nothing away from Java and the Java ecosystem though. The JVM allows around the same number of target systems to run not one language but dozens. There’s JRuby, Jython, Clojure, Scala, Kotlin, jgo, multiple COBOL compilers that target JVM, Armed Bear Common Lisp, Eta, Sulong, Oxygene (Object Pascal IIRC), Rakudo (the main compiler for Perl’s sister language Raku) can target JVM, JPHP, Renjin (R), multiple implementations of Scheme, Yeti, Open Source Simula, Redline (Smalltalk), Ballerina, Fantom, Haxe (which targets multiple VM backends), Ceylon, and more.
Perl has a way to inline other languages, but is only really targeted by Perl and by a really ancient version of PHP. The JVM is a bona fide target for so many. Even LLVM intermediate code has a tool to target the JVM, so basically any language with an LLVM frontend. I wouldn’t be surprised if there’s a PCode to JVM tool somewhere.
JavaScript has a few languages targeting it. WebAssembly has a bunch and growing, including C, Rust, and Go. That’s probably the closest thing to the JVM.
sigzero · 5h ago
> I can run THE SAME CODE on DOS, BeOS, Amiga, Atari ST, any of the BSDs, Linux distros, macOS, OS X, Windows, HP/UX, SunOS, Solaris, IRIX, OSF/1, Tru64, z/OS, Android, classic Mac, and more.
No, you really can't. Not anything significant anyway. There are too many deviations between some of those systems to all you to run the same code.
> I can run basically any Perl code back to Perl 4 (March 1991) on Perl 5.40.2 which is current.
Yes, but can you _read_ it?
I'm only half joking. Perl has so many ways to do things, many of them obscure but preferable for specific cases. It's often a write-only language if you can't get ahold of the dev who wrote whatever script you're trying to debug.
I wonder if modern LLMs could actually help with that.
fuzztester · 17m ago
>Yes, but can you _read_ it?
Java was marketed (at least in its early days) as a WORA language - WRITE ONCE RUN ANYWHERE.
Perl was unmarketed as a WORM language - WRITE ONCE READ MANY (TIMES). ;)
jk, i actually like perl somewhat.
but I think Larry and team went somewhat overboard with that human-style linguistics stuff that they applied to perl.
johnisgood · 3h ago
> I wonder if modern LLMs could actually help with that.
From experience, they can.
vram22 · 4h ago
Interesting about that long list of languages.
There's also Groovy.
I wonder what other languages run on the JVM. What about Perl, Icon, SNOBOL, Prolog, Forth, Rexx, Nim, MUMPS, Haskell, OCaml, Ada, Rust, BASIC, Rebol, Haxe, Red, etc.?
Partly facetious question, because I think there are some limitations in some cases that prevent it (not sure, but a language being too closely tied to Unix or hardware could be why), but also serious. Since the JVM platform has all that power and performance, some of these languages could benefit from that, I'm guessing.
#lazyweb
bhaak · 9h ago
I often run into problems running Python code under Linux.
I don’t know if it is a me problem or if I’m missing the right incantations to set up the environment or whatever. Never had that much problems with Java.
But I’m a Java and Ruby person so it might really be missing knowledge.
kevin_thibedeau · 5h ago
It's not you. Python packaging has regressed into a worse mess than it was 20 years ago. I limit myself to simple scripts that only rely on builtins. Anything more complicated goes to a more dependable language.
fuzztester · 5m ago
I don't know about the difference between 20 years ago versus now, but it's certainly doesn't seem to be clear now.
e.g. poetry, venv and pyenv have been mentioned in just the next few comments below yours. and this is just one example. i have seen other such seeming confusion and different statements by different people about what package management approach to use for python.
fuzztester · 10m ago
what languages do you use for the latter?
icedchai · 3h ago
I rarely run into issues when using Poetry. If you use pip, add packages to requirements.txt willy-nilly and don't pin versions then you are asking for trouble.
myko · 10m ago
i like poetry though i've moved to uv - both work really well
jonhohle · 9h ago
For anything more than just a one off script, look into venv. I’ve not written any python until this past year and can’t imagine maintaining an ongoing project without it.
Prior to that I would frequently have issues (and still have issues with one-off random scripts that use system python).
jsight · 4h ago
Honestly, it isn't just you. I had to hold off on 3.13 for quite a while too, because of various package conflicts. It isn't terrible, especially thanks to things like pyenv, but it is far from perfect.
cestith · 9h ago
Python can be tricky with the big differences between 2 and 3.
icedchai · 5h ago
As late as 2022, I was at a company still in the middle of "migrating" from 2 to 3. I wouldn't be surprised if the migration project was still going on. The system had gone beyond tech debt and was bordering on bankruptcy.
loloquwowndueo · 5h ago
Python 3 came out in 2008. If the 2 vs 3 differences are still biting you you probably have bigger problems to solve (deprecated, insecure, unmaintained dependencies for example).
invalidname · 9h ago
I just spent 30 minutes trying to get a python package running on my Mac... Not feeling that. Pythons version compatibility is just awful and the mix of native is deeply problematic. Don't get me started on tooling and observability.
cbm-vic-20 · 10h ago
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.
johnisgood · 3h ago
> You can take pretty much any code written for Java 1.0 and you can still build and run it on Java 24.
This is not my experience with Java at all. I very often have to modify $JAVA_HOME.
winrid · 2h ago
Are you using Gradle projects? Gradle is especially difficult for some reason.
johnisgood · 2h ago
Sadly. I would rather avoid Gradle and Java in general. I did not have good experiences with them. :/
brightball · 9h ago
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.
fpoling · 5h ago
Java version updates typically change GC behavior. If one has highly tuned setup there is no guarantee that a newer version would not regress.
Another problem is crashes. Java runtime is highly reliable, but still bugs happens.
Pet_Ant · 1h ago
Are you talking about performance or behaviour? I’ve never seen an issue caused by a GC.
worik · 3h ago
I have been badly burned, twice, by Python's cavalier attitude to backwards compatibility
AnimalMuppet · 4h ago
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 · 10h ago
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
icedchai · 3h ago
Entity Beans were terrible, representing the height of JEE over complexity. I remember editing at least 3 classes, a couple interfaces, and some horrific XML deployment descriptors to represent an "entity." A lot of the tooling was proprietary to the specific app server. On top of that, it was slow.
In the early 2000's, I used to work on JEE stuff for my day job, then go home and build PHP-based web apps. PHP was at least 10x more productive.
xienze · 2h ago
You have to keep in mind that entity beans were developed in a time before generics, annotations, and widespread use of byte code enhancement that made a lot of the easy, magical stuff we take for granted possible.
brightball · 10h ago
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 · 5h ago
resin was okay but I never got what it offered over tomcat
javier2 · 8h ago
> 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 · 5h ago
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.
lelanthran · 9h ago
> 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.
nxobject · 10h ago
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 · 4h ago
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
jbellis · 10h ago
more like 100x faster than Python/Ruby
and that's before you throw in real multithreading
dragandj · 10h ago
Throw in Clojure into the mix, and you get superpowers!
exabrial · 10h ago
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?
Zambyte · 2h ago
For syntax, maybe this general Lisp advice will help: consider a normal function call, like f(a, b). To make this into a Lisp function call, drop the unnecessary comma (whitespace is enough to separate tokens) like f(a b), and then move the function name inside the parentheses, like (f a b). Applying operators that are considered "primitive" in other languages are syntactically treated the same as functions. So imagine an add function like add(a, b), but instead of being named 'add', it's just named '+', like +(a, b). Applying the same transformation as before, this turns into (+ a b).
Using the function application syntax for primitives like + is nice because you get the same flexibility of normal functions, like variable argument length: (+ a b c).
Clojure is a little bit less uniform than other Lispy languages in that it has special brackets for lists (square brackets) and for maps (curly brackets), but that's pretty much it.
fuzztester · 29s ago
it also has the threading operator or macro.
i am not a clojure or lisp expert, just saying.
mark_l_watson · 9h ago
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
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 · 9h ago
Start doing any year of Advent of Code with Clojure and you'll get it.
They're really amenable to the REPL.
badc0ffee · 9h ago
> 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.
Fastest at what, exactly?
jonhohle · 9h ago
I’m slightly surprised there isn’t more KVM/Virtualized bare metal JVM environments. While I haven’t used it in a while, the decade+ I spent running Javan’s in production basically have the entire system over to the JVM (with some overhead for some small non-JVM background daemons). Most things were built not to use POSIX standards, but Java equivalents. Occasionally direct file system access for writes was necessary (logging being a big exception).
So giving the entire system to the JVM, performing some warmup prior to a service considering itself “healthy”, and the JVM was reasonably fast. It devoured memory and you couldn’t really do anything else with the host, but you got the Java ecosystem, for better or worse).
There was a lot of good tooling that is missing from other platforms, but also a ton of overhead that I am happy to not have to deal with at the moment.
briankelly · 8h ago
Having a hard time finding it now, but someone put together a benchmark with two categories - naive and optimized - comparing implementations across languages with a workload vaguely resembling a real-world business application server with a mix of long and short lived objects. Java was at the top of the naive benchmark by a landslide and behind C and C++ (edit: and probably Rust) for the optimized ranking, but with a gap before the rest of the field.
With the JVM you basically outsource all the work you need to do in C/C++ to optimize memory management and a typical developer is going to have a hell of a time beating it for non-trivial, heterogenous workloads. The main disadvantage (at least as I understand) is the memory overhead that Java objects incur which prevent it from being fully optimized the way you can with C/C++.
znpy · 10h ago
> Java memory management seems weird from a Unix Philosophy POV, till you understand whats happening. Again, not perfect, but a good tradeoff.
The GC story is just great, however. Pretty much the best you can get in the entire ecosystem of managed-memory languages.
You have different GC algorithms implemented, and you can pick and tune the one that best fits your use-case.
The elephant in the room is of course ZGC, which has been delivering great improvements in lowering the Stop-the-world GC pauses. I've seen it consistently deliver sub-millisecond pauses whereas other algorithms would usually do 40-60 msec.
Needless to say, you can also write GC-free code, if you need that. It's not really advertised, but it's feasible.
nxobject · 10h ago
> The elephant in the room is of course ZGC, which has been delivering great improvements in lowering the Stop-the-world GC pauses. I've seen it consistently deliver sub-millisecond pauses whereas other algorithms would usually do 40-60 msec.
As someone who's always been interested in gamedev, I genuinely wonder whether that would be good enough to implement cutting-edge combo modern acceleration structures/streaming systems (e.g. UE5's Nanite level-of-detail system.)
I have the ability to understand these modern systems abstractly, and I have the ability to write some high-intensity nearly stutter-free gamedev code that balances memory collection and allocation for predicable latency, but not both, at least without mistakes.
fidotron · 7h ago
> As someone who's always been interested in gamedev, I genuinely wonder whether that would be good enough to implement cutting-edge combo modern acceleration structures/streaming systems (e.g. UE5's Nanite level-of-detail system.)
The GC would be the least of your problems.
Java is neat, but the memory model (on which the GC relies) and lack of operator overloading does mean that for games going for that level of performance would be incredibly tedious. You also have the warm up time, and the various hacks to get around that which exist.
Back when J2ME was a thing there was a mini industry of people cranking out games with no object allocation, everything in primitive arrays and so on. I knew of several studios with C and even C++ to Java translators because it was easier to write such code in a subset of those and automatically translate and optimize than it was to write the Java of the same thing by hand.
astrange · 1h ago
I'm honestly amazed people say this about Java, because the language almost couldn't be worse at giving you tools to use memory efficiently.
There's no value types (outside primitives) and everything is about pointer chasing. And surely if there was less pointer chasing it'd be easier to do the GC work at the same time.
vips7L · 11m ago
When people talk about GC performance they’re not talking about using memory efficiently. They’re talking about how fast the GC can allocate and how long it will stop the world when it needs to collect. In both of these areas you won’t find GCs better than the ones provided by HotSpot. Even with what you mention, pointer chasing and lack of structs, they still outperform other implementations.
neonsunset · 8h ago
> Needless to say, you can also write GC-free code, if you need that. It's not really advertised, but it's feasible.
It is not feasible under the JVM type system. Even once Valhalla gets released it will carry restrictions that will keep that highly impractical.
It's much less needed with ZGC but even the poster child C# from the GC-based language family when it comes to writing allocation-free and zero-cost abstraction code presents challenges the second you need to use code written by someone who does not care as much about performance.
zdragnar · 54m ago
Zero-allocation (obviously different from zero GC) frameworks made a bit of a splash a little while back, but I'm not seeing much about them anymore from a brief search. I would have sworn that quarkus was one of them, but it looks like that's definitely not the case anymore.
The downside is that you sacrifice a lot of the benefits of guard rails of the language and tooling for what may not end up being much savings, depending on your workload.
tootie · 10h ago
The language has/had some rough edges that have been improved over the years, but the developer experience of using a strongly-typed, object-oriented language within a sturdy IDE like Idea is just second to none. The debugging process is so very straightforward. Java became synonymous with enterprisey bloated systems for good reason, but there is no pile of mud Java system that can't be stepped through cleanly with a debugger.
I'd also throw in what was possibly their greatest idea that sped adoption and that's javadoc. I'm not sure it was a 100% original idea, but having inline docs baked into the compiler and generating HTML documentation automatically was a real godsend for building libraries and making them usable very quickly. Strong typing also lined up nicely with making the documents hyper-linkable.
Java was really made to solve problems for large engineering teams moreso than a single developer at a keyboard.
Terr_ · 5h ago
I find these discussions have an interior split between the folks who are more concerned with getting the feature out now versus the folks who have had to keep a thousand ancient features running.
neonsunset · 8h ago
> a close 3rd place behind C/CPP
Not anymore, the competition is doing much better these days.
nelup20 · 4h ago
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.
deepsun · 4h ago
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.
sabellito · 3h ago
I've worked in 3 of the biggest rails codebases in the world (Shopify being the last) and I can say from experience that rails legacy monoliths are infinitely worse to work with than some awful, but harmless, sea of struts XML legacy.
kllrnohj · 3h ago
Personally I think C# is miles ahead of Java and in meaningful ways (like a drastically better implementation of generics, not to mention value types have existed for eons at this point and an FFI system that doesn't hate you for using it)
But nobody seems to talk about or care about C# except for Unity. Microsoft really missed the boat on getting mindshare for it back in the day.
bsaul · 3h ago
Problem with C# isn't the language, it's the enterprise ecosystem. You always feel like you're going to have to pay at some point down the road for using the tech.
cgh · 2h ago
Every large company I’ve ever worked at had a strict “no Microsoft on the server” policy and for better or worse, C# is closely identified with Microsoft.
runjake · 1h ago
IOW Linux on the server?
hu3 · 2h ago
I don't see Java being any better in this regard.
Microsoft has been historically much less aggressive with lawyers compared to Oracle.
antod · 1h ago
The poster was talking about the ecosystem not the core platform. The wider Java ecosystem was heavily dominated by many Apache (and other) open source libraries vs commercial products for the C# ecosystem.
neonsunset · 1h ago
Most of the features that require Apache or community packages in Java ship out of box in .NET (or via extension packages).
They also tend to be of higher quality and provide better performance.
frontfor · 2h ago
That might be true for other Oracle products like the DB, but has that been true for Java and openjdk?
cyberax · 1h ago
Java has a strong history of OpenSource, and a great set of libraries. It also pioneered the managed dependency system early (Maven), so these libraries have been centrally available for two decades.
Moreover, a lot of these libraries are well-supported to this day. For example, Hibernate (the best ORM in business) is 28 years old, and has just released a new version. I recently consulted my former client (from 15 years ago), and I still recognized most parts of the stack that I set up way back then.
wslh · 2h ago
I think OP means that .NET has strong connections with Microsoft technologies where it is a natural decision to use Azure instead of AWS.
dagw · 3h ago
nobody seems to talk about or care about C# except for Unity
C# is extremely popular in all kinds of 'boring' industries. Having worked in areas like logistics and civil engineering, C# is everywhere.
astrange · 1h ago
> But nobody seems to talk about or care about C# except for Unity. Microsoft really missed the boat on getting mindshare for it back in the day.
There was this guy Miguel de Icaza. From when I followed the open source ecosystem at the time, it seemed to be his personal mission to promote independent clones of a bunch of Microsoft technologies like C# on his own time even though they didn't ask him to do it.
I don't think I ever understood why someone would do this. It's like in the 2000s where people seemed to think you could solve all technical problems by inventing new kinds of XML.
nextos · 2h ago
C# had the chance to learn from Java. Java was a bit rushed. Gosling said he was not given enough time to add closures. Even without generics, Java would have been quite elegant and much less verbose. The alternative, anonymous inner classes, were quite clunky.
Nevertheless, as a platform, the JVM and JDK were fantastic and miles ahead most alternatives during the late 1990s and 2000s. The only platform for large development that offered some compelling advantages was Erlang, with BEAM and OTP.
hocuspocus · 2h ago
Java could have easily caught up with C# in the early 2000s. In 2001 Pizza (Scala's ancestor) showcased generics, higher-order functions, ADTs and pattern matching. Interestingly enough only generics made it to Java in a reasonable timeframe, the rest came only much later.
Aside from early versions being rushed, I feel that Java's success and adoption were the bigger issue. While Microsoft could iterate quickly and break backwards compatibility with major versions of C# and the .NET runtime, Java was deliberately moving at a much slower pace.
breadwinner · 2h ago
One area where C# really messed up is exception handling.
Java streams and a lot of other APIs are extremely ugly because of checked exceptions. Conversely, LINQ and delegates and a lot of other syntax is far cleaner in C#.
Your linked blog is pretty wild. Only throw RuntimeExceptions to crash? Why not just Exit if that's the proper thing to do?
If you treat all C# exceptions as RuntimeExceptions, then it satisfies the blog anyhow.
> Why not just Exit if that's the proper thing to do?
Because you won't get a stack trace.
easton · 1h ago
They intentionally chose to not have checked exceptions though, and people have different opinions on it. They believed that people would just catch Exception most of the time anyway instead of selecting on a very specific type (which is often how it works, in web apps anyway.)
IIRC all previous conversations about checked exceptions here ended up with the swift conclusion that they are heavily discouraged throughout Java code.
breadwinner · 1h ago
> they are heavily discouraged throughout Java code
And more. I'm not sure what you found in (checked) exceptions. If you'd like explicit error handling, we have holy grail in the form of Rust which beautifully solves it with implicit returns, error type conversions and disambiguation between error and panic model. I'd prefer to use that one as it actually reduces boilerplate and improves correctness, the opposite to the outcome of using checked exceptions.
breadwinner · 35m ago
> I'm not sure what you found in (checked) exceptions.
Crashy code: You have no compiler-enforced way to know what exceptions might be thrown from a method or library.
More crashy code: If a method starts throwing a new exception, you might not realize you need to update your error handling.
Dead code: If a method stops throwing an exception, old catch blocks may linger, becoming dead code.
astura · 1h ago
C# isn't popular in startups for the same reason Java isn't, it's "boring."
It's an extremely common language in "boring" companies doing "boring" (but profitable) work.
watwut · 3h ago
Definitely not. All the stuff I was used to get for free and advice I that was one google search away ... just dont exist in dotnet. Or is expensive. But most of the time, there is weaker library not doing nearly enough and that is all that exists.
echelon · 3h ago
That's because the Microsoft of 2000 - 2014, the Ballmer era, was Microsoft-first. It didn't care about other platforms, it didn't care about the web, and it didn't care about open source. C# could be great, but it existed in a bubble.
Java kept growing and wound up everywhere. It played nice with Linux. Enterprise Mac developers didn't have trouble writing it with IntelliJ. It spread faster because it was open.
Satya Nadella fixed a lot of Microsoft's ills, but it was too late for C# to rise to prominence. It's now the Github / TypeScript / AI era, and Satya is killing it.
The one good thing to say about Ballmer is that he kicked off Azure. Microsoft grew from strength to strength after that.
No comments yet
jayd16 · 3h ago
Its actually quietly very popular in very boring contexts outside of Silicon Valley. Its also slowly entering new areas now that Linux builds are rock solid.
MS does have an uphill PR battle though.
wokkel · 2h ago
It barely works on non MS platforms,has had many slightly incompatible versions so it's a non starter for many projects where I run into that might benefit from c#. I spoke to a manager recently who had invested in silverlight in the past. Based on that alone it was a no MS policy for his development teams.
runjake · 1h ago
AFIACT, either most or at least a significant percentage of dotnet code runs on Linux, depending on the industry.
neonsunset · 1h ago
Quite a few languages "loved" by "Linux communities" tend to have rather rudimentary integration with Linux kernel's facilities or worse packaging story.
For example, Go does not understand cgroups limits and needs an external package to solve this. .NET can read and accommodate those natively. It also ships with excellent epoll-based socket engine implementation. It's on par with Go (although I'm not sure which one is better, but .NET performs really well on high-throughput workloads).
bsaul · 4h ago
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 · 4h ago
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.
debugnik · 2h ago
Not all lifetime problems are just a matter of learning. I've been picking up Rust every few years to catch up, and every single time I've eventually expressed a lifetime that either required unstable Rust at the time or hit a known lifetime bug.
bsaul · 3h ago
i do feel much more comfortable with lifetimes than at the beginning. I get the general concept, and i barely have to explicitely set them (i did start by religiously reading the rust book, of course).
However, at the moment i still feel i'm using a huge amount of layers upon layer of complex type definitions in order to get anything done. Just using an object's reference across async calls in a safe manner leads to insane types and type constraints, which read like ancient egyptian scripture. And at every layer, i feel like changing anything could blow everything up with lifetimes.
The language has this very special feel of something both advanced and extremely raw and low-level at the same time. It's very unique.
charlotte-fyi · 3h ago
In my experience, beginners often make the mistake of assuming just because you can do things with references and lifetimes that you should. Unless you’ve done profiling, just start with the easy thing and clone an `Arc` (or whatever other data structure helps you avoid lifetime problems)!
Also, it’s worth saying, you probably don’t need async.
bsaul · 2h ago
oh, believe me, cloning and Arc-ing is something i realized very early that i was going to use. But that's the point: you still end up with things like : Arc<tokio::RwLock<dyn MyTrait>> for every single dependency.
Then you want to declare an async function that takes an async closure over that dependency. And you end up with a total garbage of a method signature.
As for async, the ecosystem for server-side is totally filled with async everywhere now. I don't think it's realistic to hope escaping those issues anyway in any real-world project. i thought i might as well learn to get comfortable with async.
worik · 3h ago
> 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
bsaul · 3h ago
I am keeping up, but honestly i feel like rust dev is a bit like a trap : people like us love challenges and solving technical problems. So whenever we "triumph" over a rust tricky compilation issue, we feel intense gratification in solving it.
However, at some point you have to ask yourself why you're accepting to face all those challenges. Is it worth it ? When was the last time i faced a race condition when developping a backend ?
The reason i started with rust was for a very specific need on building a cross-platform library (including wasm), and that was a good justification, and i'm happy that i did. However now that i'm using it for the server as well and face the same kind of challenges, i seriously question whether this is a wise choice.
mynameisash · 4h ago
> 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.
vips7L · 4m ago
> With respect, at two months, you're still in the throes of the learning curve,
It shouldn’t take 2 months of full time programming to beat the learning curve.
johnisgood · 3h ago
Okay, but I have hit the joyful part of some other languages long before a few months. What gives?
heavyset_go · 3h ago
IME, new users do weird things that can expose bugs no one ran into because they wouldn't think to do things the weird way.
bsaul · 2h ago
I hope the same, and TBH it's the only reason i'm keeping up developing that backend in rust. I hope that in the end, it's going to improve my style.
Go felt the same way (but with a much lower order of magnitude) : you feel like bumping into language limitations, but once you learn to do it "simply" in go, your style will have changed into something much more elegant.
As for the bug in question, it has been quite "popular" for about 5 years now, and is actively tracked : https://github.com/rust-lang/rust/issues/110338. Nothing really weird. Just async hitting the limits of the current rust design.
Simply using axum with code using multiple layers of async was enough.
But then again, it looked like this bug (the error message is the same), however at this point i'm really unsure if it's exactly the same. The error message and the method signature was so atrocious that i just gave up and found a simpler design using macros that dodged the bullet.
bdangubic · 4h ago
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 · 4h ago
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 · 4h ago
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.
skydhash · 3h ago
I think kotlin is what Java should have been like. The same capabilities but with less cumbersome constraints.
ori_b · 3h ago
When I used Kotlin, it felt like Java, but with the antipatterns baked in as language features.
complexworld · 2h ago
Could you explain which antipatterns you're referring to?
ori_b · 2m ago
Leaning heavily into object orientation, including baking in things like companion objects, object expressions, etc.
While operator overloading and infix functions aren't a Java anti-pattern, I also think the language would be improved by their removal.
Zambyte · 2h ago
It is all but impossible to use Kotlin without an IDE telling you everything, and for that I find the language interesting. And for comparison, I did in fact write Java without an IDE for an extended period of time.
whartung · 3h ago
The don't embrace that culture. Embrace a simpler culture. Strive for simplicity. Push for fewer dependencies.
Simple example, JAX-RS running on top of Java SE. I agree, JAX-RS is not what one might call "simple". It IS complex, or I should say, it CAN be complex. But Happy Path, staying in the middle of the road, it's pretty sweet for knocking out HTTP backed services. The Jersey reference implementation will do most anything you need (including stuff not "included" in raw JAX-RS). No need for a container, no need for a lot that stuff and all that hanger-on. The core runtime is pretty broad and powerful.
Consider my current project, it uses the built in Java HTTP server. Which works! It's fast, it's functional, it's free. (Yes, it's in a com.sun.net... package, but it's not going anywhere.) It's awkward to use. It's aggravatingly raw. It follows the tenet "why be difficult, when, with just a little effort, you can be impossible."
So, I wrote a simple "servlet-esque-ish" inspired layer for response and request handling, a better path based regex-y router, and a nicer query parser for queries and forms. 500 lines. Add on a JSON library and I can process JSON-y web request/response, easily. (I also wrote my own Multipart processor -- that was another 500 lines, boy that was fun, but most folks don't need that.)
A little bit of code and the built in server is MUCH easier to use. No tomcat, no deploys, zip. ...and no dependencies (save the JSON library).
Something all of these cool frameworks and such have shown me is what's really nice to have, but at the same time, just what isn't really necessary to get work done. I mean, CDI is really neat. Very cool. But, whoo boy. So I have a single singleton to handle application life cycle and global services. It works great with tests. I have a 50 line Event Bus. I have a 100 line "Workflow Engine". 150 line java.util.Logger wrapper (which is mostly, you know, wrapper). I wrote that way back whenever they introduced varargs to java (Java 5? 6?). The modern Java logging landscape is just...oh boy. I'm content with JUL -- I can make it work.
My current project is "magic free". I think @Overide in the single annotation anywhere in it. But it's comfortable to use, the cognitive load is quite load (outside of the actual application itself, which is NOT low -- sheesh). No swearing at frameworks. It's all my fault :).
Anyway, the point is that "simple Java" lurks in there. It needs a bit of uplifting, but not a lot.
password4321 · 9m ago
You've made the project yours, nice! How many others work on it?
It's an uphill battle to convince my co-workers to do things my way.
wpollock · 1h ago
You've made your point, but note the built-in HTTPS server only supports TLS 1.2, so don't use that for production code. (For testing it's probably fine.)
whartung · 47m ago
TLS is supplied by the underlying JDK, which has been 1.3 for some time. How is HttpsServer not 1.3?
LtWorf · 3h ago
True, but the culture around go isn't any better. In my experience go developers are former java developers so they have the same culture of thinking it's ok to ignore how a unix system works. So you will have awful logging, daemons that never report they're ready, badly handmade command line parsing and so on.
arccy · 3h ago
funny. java is known for its stacktraces where you need 3 vertical monitors stacked together to see the whole thing and it still doesn't tell you anything useful about why the app crashed.
marginalia_nu · 3h ago
I think that's a bit unfair. Generally the stacktraces tell you exactly what and where the problem is. Generally shouldn't be more than a dozen lines or so.
The main area they get excessively lengthy is in certain frameworks and testing tools that can add like 100 lines to the trace.
frontfor · 2h ago
Compared to Go where I always have to remember to print the stack trace in every goroutine’s panic handler or use a custom error type that includes the stack trace or I get nothing? And I have to do this very basic thing for every service I spin up? This might not matter for pet projects or CLI applications, but it matters a lot in large scale mission critical servers.
jjav · 1h ago
> stacktraces where you need 3 vertical monitors stacked together
If you wrote code with such deep stacktraces, it's all on you.
There's a performance cost to all that excessive stack depth too, often.
hu3 · 2h ago
as someone who had to deal with Java stack traces the entire week, I feel attacked.
God bless Gemini 2.5 Pro which ate all the traces for breakfast.
watwut · 3h ago
Same here. I started to really like java after working with js/ts on small to medium project. I started to love java after working in on medium to little big project.
mark_l_watson · 11h ago
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 · 11h ago
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 · 10h ago
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.
astrange · 1h ago
> I think it's incredible with hindsight how Java countered many of the mid 90s C++ problems, especially by avoiding multiple inheritance.
This is because Java is based on an older language called Objective-C that doesn't have multiple inheritance :)
It's not based on C++, that's just the other OO language from the era people usually think of.
dragandj · 11h ago
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 · 5h ago
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 · 4h ago
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.
PathOfEclipse · 10h ago
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 · 4h ago
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:
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.
deepsun · 2h ago
Interesting. I'm not a .Net programmer, but I always thought .Net takes winning approach from Java ecosystem and adopts it. Java approaches/frameworks are kinda pioneering and competing, while .Net follows and grabs the best. So instead of competing approaches/frameworks (like ORMs for example) .Net has only one, the best one, well adopted and used by everyone there.
But reading your message it doesn't sound like it.
neonsunset · 9h ago
> 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.
PathOfEclipse · 8h ago
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.
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 · 7h ago
> 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.
PathOfEclipse · 7h ago
> For example, starting with .NET 6 there is a pure C# threadpool implementation that acts differently under problematic scenarios.
We're seeing this issue entirely in .NET core. We started on .NET 6, are currently on .NET 8, and will likely migrate to 10 soon after it is released. It's again worth mentioning that you provide zero evidence that .NET 6 solves this problem in any way. Although, as we will see below, it seems like you don't even understand the problem!
> 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.
No, I'm referring to code written recently, at the job I work at now, at which I've been involved in discussions about, and implementations of, workarounds for the issue.
> 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.
100% false. This deadlock issue has nothing to do with synchronization contexts. Please actually read the 2020 article I linked as it explains the issue much better.
> Pathetic attempt at strawman.
I realize responding to this is to just fight pettiness with more pettiness, but I can't resist. You should probably look up the definition of a strawman argument since you are using the word incorrectly.
neonsunset · 7h ago
To me a claim "how many things the Java ecosystem gets right that .NET gets wrong" borders on insanity if we consider having to interact with Maven or even Gradle on a daily basis after .NET's CLI and NuGet, or having to deal with type erasure in generics, or weird stream API shape, or not having common slice and sequence types that everything nicely unifies under because primitives cannot be generalized, or not being able to author properties and extension methods, creating dozens upon dozens of type copies or just boilerplate accessors, or having to tolerate Hibernate after EF Core, and so on and so forth.
As for async and tasks - have you ever considered just not writing the code that is so bad it managed to bypass cooperative blocking detection and starvation mitigations? It's certainly an impressive achievement if you managed to pull this off while starting with .NET 6.
Edit: I agree with the subsequent reply and you are right. Concurrency primitives are always a contentious topic.
PathOfEclipse · 7h ago
I have no problem with you preferring .NET to Java, and I apologize that my first-cited article was not the best one to share to describe the problem (I should have read it more carefully first), but if you had responded with something like:
"Your deadlock scenario is related to synchronization contexts and can be avoided by ..."
rather than:
"You clearly don't know what you're talking about (but I won't bother telling you why)"
Then we could have had a much more productive and pleasant conversation. I would have responded with:
"Sorry, that article wasn't the right one to share. Here is a better one. The issue I am talking about isn't synchronization context-related at all. It's actually much more insidious."
octo888 · 5h ago
> having to tolerate Hibernate after EF Core,
Enjoying or tolerating Hibernate is undiagnosed Stockholm Syndrome :D
rootbear · 4h ago
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 · 4h ago
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.
SoftTalker · 2h ago
Gosling also developed a version of Emacs back in the early 1980s.
"Gosling Emacs was especially noteworthy because of the effective redisplay code, which used a dynamic programming technique to solve the classical string-to-string correction problem. The algorithm was quite sophisticated; that section of the source was headed by a skull-and-crossbones in ASCII art, warning any would-be improver that even if they thought they understood how the display code worked, they probably did not."
toprerules · 10h ago
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 · 5h ago
>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?
marginalia_nu · 3h ago
> what legacy code?
The Java API has its fair deal of baggage due to its extreme backward compatibility. Boolean.getBoolean[1] is one of the more accessible examples of a bad API that exists only because of legacy reasons, but there quite a number of them.
> My other issues with the JVM is how much of a black box it is from a platform perspective, which makes debugging a PITA
You state how you don't really use java, but the above confirms it.
Java debugging and diagnostic tooling is second to none.
toprerules · 45m ago
That's a really narrow view of the world, and I think another Javaism to think that Java is the entire world. Today's multi-service deployments run tens if not hundreds of auxiliary processes not using Java. They use network overlays that change how processes interact with the network core. A person who is debugging a knock on effect issues has to be able to look through many different layers of processes, many of which are written in C, C++, Go, etc. Having to learn an entire toolset to debug Python or Java is a huge burden and it makes introspection extremely difficult. Java essentially wants to be the entire platform, which isn't how the world works anymore.
the_overseer · 9h ago
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.
toprerules · 44m ago
Because if I'm debugging a critical issues and wading through multiple layers of processes and system interactions, I don't want to have to learn a bespoke toolkit and debugging system for every single process.
briankelly · 3h ago
The tooling is pretty easy to learn if scary looking at first and becoming a JVM expert, at least in the context of GC tuning, might take you a week or less. Some of the defaults are surprising though.
And I think there is some parallel with the kernel vs GC and mmap vs buffer pools - the GC simply has better context in the scope of the application. With other processes in the picture, though, yeah there is some provisioning complexity there.
throwaway7783 · 4h ago
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
toprerules · 43m ago
It sounds like you've only ever written code without dealing with it in production. You can't always plug your code into an IDE when your debugging someone else's JVM app on a remote server.
cgh · 2h ago
Debugging Java is great, as others have mentioned. This includes probably the best remote debugging capabilities available for any platform.
OpenJDK, the de facto standard version used by everyone, is licensed under the GPL version 2 with the classpath exception.
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 · 7h ago
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 · 5h ago
Hm... Why? Java seems to be a perfect language in which to understand things at a conceptual level!
briankelly · 4h ago
Good to get your hands in the dirt as well.
cbm-vic-20 · 9h ago
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.
telotortium · 43m ago
The original version of MapReduce was written in C++. The successor library, Flume, was however written in Java, but Spolsky would certainly have been referring to the original MapReduce, since the Flume paper wasn't published until 2010.
jonhohle · 8h ago
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.
neom · 10h ago
James Gosling, Robert Pike and Geoffrey Hinton are my top 3 "Canadians who meaningfully changed things in technology" (tho, I should probably make it a top 5, add Brian Kernighan and figure out someone else)
cmrdporcupine · 5h ago
Kenneth Iverson (APL) could be your fifth even if none of us use APL, its reputation and influence is probably deeper than we realize
snovymgodym · 9h ago
Java, especially modern Java, is a fine language. The JVM is an awesome runtime. I'm tired of pretending it isn't.
rr808 · 3h ago
Java is completely revitalized now and is my favorite platform.
The main problem is the legacy code and attitude out there, dependency injection, using Spring or Spring Boot etc SUCKS. VertX is/was good but now with virtual threads you dont need all the async complexity.
throwaway7783 · 4h ago
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.
jcadam · 4h ago
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. :)
kaliszad · 9h ago
The java.net.Inet4Address and Inet6Address could be more lightweight.
For a simple IPv4 address normally representable using 4 bytes/ 32 bits Java uses 56 bytes. The reason for it is Inet4Address object takes 24 B and the InetAddressHolder object takes another 32 B. The InetAddressHolder can contain not only the address but also the address family and original hostname that was possibly resolved to the address.
For an IPv6 address normally representable using 16 bytes/ 128 bits Java uses 120 bytes. An Inet6Address contains the InetAddressHolder inherited from InetAddress and adds an Inet6AddressHolder that has additional information such as the scope of the address and a byte array containing the actual address. This is an interesting approach especially when compared to the implementation of UUID, which uses two longs for storing the 128 bits of data.
Java's approach is causing 15x overhead for IPv4 and 7.5x overhead for IPv6 which seems excessive. What am I missing here? Can or should this be streamlined?
dmurray · 8h ago
What a wonderfully HN response to a biographical piece on James Gosling.
For my part, most of the Java code that I have written that needs to use IP addresses needs somewhere between 1 and 10 of them, so I'd never notice this overhead. If you want to write, like, a BGP server in Java I guess you should write your own class for handling IP addresses.
theanonymousone · 5h ago
I have heard it about the situation in 1995, but it probably also holds to a good extent now: You appreciate Java (only) after you have experienced/experience other languages.
cloudking · 11h ago
Why is Java so popular in enterprise?
izacus · 10h ago
Because there was nothing else quite like it at the time most enterprise software was created or recreated.
And it's still stable, fast and reliable with a massive ecosystem of stable, fast and reliable libraries and software. With good developer tooling, profilers and debuggers to go with it. And big enterprise support teams from RedHat, Oracle, IBM, etc. throwing in their (paid) support services.
It might not be the best language in any of the categories (speed - runtime and compile time, tooling, ecosystem, portability, employee pool), but there's pretty much almost no languages that are as good in all categories at once.
And to top it off, JVM can host other languages so it can easily interoperate with more modern takes on language design like Kotlin while still running on pretty much all major operating systems used in the wild and most CPU architectures as well. It'll run on your car's SoC, your phone and on your server. In many cases, using the same libraries and same code underneath.
js8 · 10h ago
I believe there were alternatives at the time, but expensive. Java was free and also syntactically compatible with C++. I think that rather these properties (than being somewhat unique) are the main causes of its success.
zabzonk · 5h ago
> syntactically compatible with C++
Not. And certainly not semantically.
Pet_Ant · 1h ago
That’s just obtuse. Compare Lisp, Forth, APL, Prolog, Ada, or Fortran. Java is just C++ with a few twists. You can literally write code that will compile in both.
hackthemack · 11h ago
I worked in IT from the 90s to today. My perspective is it grew and grew because Sun supported it, then IBM supported it, RedHat supported it. It had the glimmer that it was the "Enterprise Way" of doing "Real IT" programming for "Real Businesses". I am not saying any of that is the "Truth", just the perception that was held by the majority of people who could choose what to write enterprise code in.
fidotron · 10h ago
What was the viable alternative?
Microsoft had C#, at one point IBM pushed SmallTalk. C++ for these environments is doable but going to slow you down at development a lot, as well as being much harder to secure.
At that time the dynamic alternative was Perl, and that remained true basically until Rails came along.
hackthemack · 9h ago
I am not sure. C# came long after Java already made inroads into the Enterprise space. It was a different time.
I would say that many things in IT are not chosen on technical merits alone. You have people that do not want to accrue any blame. Back then, by choosing what IBM endorses or what Microsoft endorses, you absolve yourself of fallout from if and when things go wrong.
Back in the 90s, it felt like IBM, Redhat, Sun kind of, sort of, got together and wanted to keep Microsoft from taking over the Enterprise space by offering Java solutions.
nradov · 8h ago
Right. Before Microsoft created .NET and C# they first tried to play their "embrace, extend, extinguish" trick with Java. They released a JVM and "Visual J++" language which was sort of Java, but had incompatible proprietary extensions to lock customers in to Windows. Eventually they were forced to stop that for legal reasons so they completely dropped all Java support, and built their own replacement virtual machine and associated languages from scratch.
SoftTalker · 3h ago
C++ or maybe Objective-C.
Of course those were much more hazardous languages than Java.
fidotron · 2h ago
Oh yeah, WebObjects! I had forgotten that entirely, and it then transitioned to Java itself.
toyg · 10h ago
> Sun supported it, then IBM supported it, RedHat supported it
And Oracle (well before the Sun acquisition - in fact, control of Java was basically the main cause of that move).
Any technology that could bag both IBM and Oracle is (or rather was) likely to dominate the enterprise space.
aaronbaugher · 10h ago
Yes, its early popularity was very much management-driven, based on magazine articles and the like. Its object-oriented design (often presented as if something new) was supposed to make programmers fungible, and its portability was supposed to let you build an app that would run on anything. And it had a Real Corporation behind it, which appealed to corporate management.
In the late 90s, I got stuck making a scheduling program in Java, but it had to run on the 16-bit Windows systems of the time. That was a huge pain, because the 16-bit version didn't have all the capabilities that management was expecting based on the hype. These days, I sometimes have to install enormous enterprise applications that tie up north of 32G of RAM even though they're just basic hardware management tools that would take a fraction of that if built in something like C++ with a standard GUI library. I manage to avoid Java most of the time, but it's been an occasional thorn in my side for 30 years.
octo888 · 5h ago
It's safe. It's easy to hire anyone from anywhere to write Java. You generally can't create an ungodly mess apart from layers and thousands of classes. There's a library for almost everything. It'll still be around in 10/20 years. It's good enough
ben7799 · 10h ago
Java beta & 1.0 were released my Freshman year of college and I've been writing Java ever since. With the exception of one job where we tried to write a Java-style Enterprise security cloud application in Python every commercial product I've worked on has been built in primarily Java, often times with other languages on the edges of the application.
The key thing I think with Java is the programming model & structure scale well with team size and with codebase size, perhaps even in a way that tolerates junior developers, outsourced sub-teams, and even lower quality developers. All of those things end up becoming part of your reality on big Enterprise products, so if the language is somehow adding some tolerance for it that is a good thing.
The other things around Syntax and such that people complain about? Those are often minor considerations once the team size and code base size get large enough. Across my career there has always been the lone guy complaining that if we did everything in a LISP derived language everything would be perfect. But that guy has almost always been the guy who worked on a small tool off by himself, not on the main product.
Java has changed a tremendous amount as well. A modern Java system has very little in common with something written before Generics and before all the Functional code has been added. Where I work now we have heavily exploited the Functional java add-ons for years, it has been fantastic.
mpalfrey · 11h ago
Decent talent pool.
Decent tooling. Been around for long enough that a lot of the quirks of it are well known and documented. Basically it's a blue collar programming language without too many gotchas. Modern(ish) day Cobol.
(I'm predominantly a Java dev still, even after diversions over the years to Javascript, Python and C#).
lemonwaterlime · 11h ago
Among other things, because the structure of the code corresponds to the structure of the organization itself.
Things tend to form fractal systems of systems for efficiency. A cleanly delineated org chart maps to a cleanly delineated codebase.
keeganpoppen · 10h ago
on one level this is clearly “shipping the org chart”, but… honestly, even as no fan of Java this is clearly efficient on many levels, especially when you consider the humans and org to be part of the system (which everyone should. or it’s just my HCI brain talking.).
snovymgodym · 9h ago
Because it was in the right place at the right time to supplant C++ and C for application code.
locopati · 11h ago
it hits a sweet spot of reliable, C-like, fast enough for most things, with a ton of library/framework support. plus Sun and later Oracle pushed it hard in the 90s/00s. it'll be the new COBOL.
eBombzor · 11h ago
Spring Boot
tylerflick · 11h ago
My guess is the size of the talent pool to hire from.
j45 · 10h ago
Another way to look at it based on coming across it in enterprise:
How did he build something adopted by so many enterprises?
It does some things at scale very well and has been afforded the performance improvements of very smart people for 30y.
It’s not to say the language isn’t verbose, one of my favourite features was the ability to write code in other languages right inside the a Java app pretty well in-line by using the JVM, thanks to JSR-223.
It was possible to write Ruby or Python code via Jruby or Jython and run it in the JVM.
Ode to Java. Boy, I love Java. When I switched jobs way back, a condition was that the new project was going be using Java.
GC. Single file modules. No "forward". The Collection suite. Fast compiles.
The magic of the ClassLoader. The ClassLoader, that was insightful. I don't know how much thought went into that when they came up with it, but, wow. That ClassLoader is behind a large swath of Java magic. It really hasn't changed much over time, but boy is it powerful.
When I started Java, I started it because of the nascent Java web stack of the day. Early servlets and JSP. I picked because of two things. One, JSPs were just Servlets. A JSP was compiled down into a Servlet, and shazam, Servlet all the way down. Two, single language stack. Java in JSPs, Java in Servlets. Java in library code. Java everywhere. In contrast to the MS ASP (pre .NET) world.
Mono-language meant my page building controller folks could talk to my backend folks and share expertise. Big win.
Servlets were a great model. Filters were easy and powerful. Free sessions. Free database connection pools in the server. I mean, we had that in '98, '99.
And, of course, portability. First project was using Netscapes server, which was spitting up bits 2 weeks before we went live, so we switched to JRun in a day or two (yay standard-ish things...). Then, Management(tm) decided "No, Sun/Oracle, we're going NT/SQL Server". Oh no. But, yup, transitioned to that in a week. Month later, CTO was fired, and we went back to Sun/Oracle.
Java EE had a rough start, but it offered a single thing nobody else was offering. Not out of the box. Not "cheap", and that was a transaction manager, and declarative transactions on top of that. We're talking about legit "Enterprise grade" transaction manager. Before you had Tuxedo, or MS MTS. Not cheap, not "out of the box", not integrated. JBoss came out and gave all that tech away. Then Sun jumped on with early, free, Sun Java Enterprise 8 which begat Glassfish which was open source. Glassfish was amazing. Did I mention that the included message queues are part and parcel of the integrated, distributed transaction model for Java EE? Doesn't everyone get to rollback their message queue transactions when their DB commit fails? Message Driven Beans, sigh, warms my heart.
There were certainly some bad decisions in early Java EE. The component model was far too flexible for 95% of the applications and got in the way of the Happy Path. Early persistence (BMP, CMP) was just Not Good. We punted on those almost right away and just stuck with Session Beans for transaction management and JDBC. We were content with that.
The whole "everything is remote" over CORBA IIOP and such. But none of that really lasted. EJB 3 knocked it out of the park with local beans, annotations in lieu of XML, etc. Introduction of the JPA. Modern Jakarta EE is amazing, lightweight, stupid powerful (and I'm not even talking Spring, that whole Other Enterprise Stack). There's lots of baggage in there, you just don't have to use it. JAX-RS alone will take you VERY far. Just be gentle, Java Enterprise offers lots and lots of rope.
None of this speaks to the advances in the JVM. The early HotSpot JIT was amazing. "Don't mind me, I'm just going to seamlessly sneak in some binary compiled code where that stack machine stuff was a nano-second ago. I've been watching it, this is better. Off you go!" Like presents from Santa. The current rocket ship that in JDK development (this is good and bad, I still do not like the Java 9 JPMS module stuff, I think it's too intrusive for the vast majority of applications). But OpenJDK, the Graal stuff. Sheesh, just get all light headed thinking about it.
Along with the JVM we have the JDK, its trivial install. Pretty sure I have, like, 20 of them installed on my machine. Swapped out with a PATH and JAVA_HOME change. The JVM is our VM, the Servlet container is our container. Maven is our dependency manager. Our WAR files are self-contained. And all that doesn't go stomping on our computer files like Paul Bunyan and Blue making lakes in Minnesota.
It's no wonder I was struggling to grok all the talk about VMs, Dockers, and containers and all that stuff folks mess with to install software. We never had to deal with that. It just was not an issue.
I can distribute source code, with a pom.xml, and a mvnw wrapper script, and anyone can build that project with pretty much zero drama. Without breaking everything on their system. And whatever IDE they're using can trivially import that project. It's also fast. My current little project, > 10K lines of code, < 3s to clean/build/package.
Obviously, there's always issues. The Stories folks hear are all true. The legacy stuff, the FactoryInterfaceFactoryImpl stuff. The Old Days. It's all real. It's imperfect.
But, boy, is it impressive. (And, hey, portable GUI folks, Java FX is pretty darn good...)
kccqzy · 5h ago
The servlet really is a powerful concept behind a bad name. I've seen more than once where people reinvent servlets in other languages.
Koshkin · 4h ago
Also, λs and μservices...
kubb · 4h ago
Worth remembering how much marketing effort and money there was in pushing Java in the 90s:
On my list of programmers I want to meet before it's too late, along with Brian Kernighan.
lkuty · 10h ago
I am wondering what was the role of Guy L. Steele in the creation of Java if he had any. From the article, it looks like it was Gosling alone. I did not cheat by checking on Wikipedia
steelbird · 10h ago
He worked on it after, no?
kazinator · 5h ago
Mr. Gosling; please hunt down and release the source code for Ace: a syntax-driven C preprocessor.
You can keep the Java, thanks.
geodel · 10h ago
> Growing up with “pretty close to zero money,”
Zero money programmers >> Zero interest rate programmers :-)
lysace · 2h ago
The JVM was the first VM I got to know, at uni in like 1996 or so. Had fun building stuff using the Jasmin "assembler". Seems like it's on Github now: https://github.com/davidar/jasmin
> Jasmin was written because, at the time that we wrote the Java Virtual Machine book for O'Reilly, Sun had not published an assembler format for the Java virtual machine.
> Generating a binary Java .class file is pretty fiddly. Its like creating an a.out (or .exe) file by hand. Even using a Java package like JAS (a Java API for creating class files, used internally by Jasmin and written by KB Sriram), you need to know a lot about the philosophy of the Java Virtual Machine before you can write something at the Virtual Machine level and generate a Java class.
> We wanted something that made it very easy for a student or programmer to explore the Java Virtual Machine, or write a new language which targets the VM, without getting into the details of constant pool indices, attribute tables, and so on.
zombiwoof · 4h ago
Legend
klim2media · 8h ago
My biggest gripe with Java is the only really viable IDE option is from a for-profit company and that it routinely gobbles up my RAM. I used Eclipse and Netbeans back in the day but IntelliJ is superior before it becomes unusable.
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.
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.
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.
The patterns are available, its up to the community to apply proper concurrency patterns.
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.
The fact that you specifically mention Go explains a lot. btw c# is faster than Java, so not third place, it's more a 5th~
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Benchmarks aren’t all that useful since usually the bottleneck is File IO, external api calls, db calls, user latency or a combo of the 4.
Go’s main advantage in this matchup would be conciseness.
Go code looks so clean and nice, Java doesn’t.
I personally don’t care for Java, but I have bills so it’s always in my back pocket. Things happen , sometimes you need to write Java to eat.
“Fred, you really should just take the job.”
“Martha you don’t understand, it’s Java with an Oracle DB.”
“Fred, I know it’s bad, I know you still have nightmares about the 4 types of string in Java 8, but it’s not just us now.”
With a tear in his eye , fear in his heart.
“Martha, if I must… I’ll open Eclipse once more.”
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.
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.
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.
Although Python is pretty close, if you exclude Windows (and don't we all want to do that?).
This takes nothing away from Java and the Java ecosystem though. The JVM allows around the same number of target systems to run not one language but dozens. There’s JRuby, Jython, Clojure, Scala, Kotlin, jgo, multiple COBOL compilers that target JVM, Armed Bear Common Lisp, Eta, Sulong, Oxygene (Object Pascal IIRC), Rakudo (the main compiler for Perl’s sister language Raku) can target JVM, JPHP, Renjin (R), multiple implementations of Scheme, Yeti, Open Source Simula, Redline (Smalltalk), Ballerina, Fantom, Haxe (which targets multiple VM backends), Ceylon, and more.
Perl has a way to inline other languages, but is only really targeted by Perl and by a really ancient version of PHP. The JVM is a bona fide target for so many. Even LLVM intermediate code has a tool to target the JVM, so basically any language with an LLVM frontend. I wouldn’t be surprised if there’s a PCode to JVM tool somewhere.
JavaScript has a few languages targeting it. WebAssembly has a bunch and growing, including C, Rust, and Go. That’s probably the closest thing to the JVM.
No, you really can't. Not anything significant anyway. There are too many deviations between some of those systems to all you to run the same code.
There are differences, but they’re usually esoteric ( https://perldoc.perl.org/perlport#PLATFORMS ).
I'm only half joking. Perl has so many ways to do things, many of them obscure but preferable for specific cases. It's often a write-only language if you can't get ahold of the dev who wrote whatever script you're trying to debug.
I wonder if modern LLMs could actually help with that.
Java was marketed (at least in its early days) as a WORA language - WRITE ONCE RUN ANYWHERE.
Perl was unmarketed as a WORM language - WRITE ONCE READ MANY (TIMES). ;)
jk, i actually like perl somewhat.
but I think Larry and team went somewhat overboard with that human-style linguistics stuff that they applied to perl.
From experience, they can.
There's also Groovy.
I wonder what other languages run on the JVM. What about Perl, Icon, SNOBOL, Prolog, Forth, Rexx, Nim, MUMPS, Haskell, OCaml, Ada, Rust, BASIC, Rebol, Haxe, Red, etc.?
Partly facetious question, because I think there are some limitations in some cases that prevent it (not sure, but a language being too closely tied to Unix or hardware could be why), but also serious. Since the JVM platform has all that power and performance, some of these languages could benefit from that, I'm guessing.
#lazyweb
I don’t know if it is a me problem or if I’m missing the right incantations to set up the environment or whatever. Never had that much problems with Java.
But I’m a Java and Ruby person so it might really be missing knowledge.
e.g. poetry, venv and pyenv have been mentioned in just the next few comments below yours. and this is just one example. i have seen other such seeming confusion and different statements by different people about what package management approach to use for python.
Prior to that I would frequently have issues (and still have issues with one-off random scripts that use system python).
This is not my experience with Java at all. I very often have to modify $JAVA_HOME.
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.
Another problem is crashes. Java runtime is highly reliable, but still bugs happens.
(It's still a valid point. It's just not the point you labeled it as.)
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
In the early 2000's, I used to work on JEE stuff for my day job, then go home and build PHP-based web apps. PHP was at least 10x more productive.
I grew to be a big fan of JBoss and was really disappointed when the Torquebox project stopped keeping up (Rubyized version of JBoss).
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.
Hearing the work he and others did to gradually introduce pattern matching without painting themselves into a corner was fascinating and inspiring.
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.
Edit: 1.4, not 1.7
and that's before you throw in real multithreading
Using the function application syntax for primitives like + is nice because you get the same flexibility of normal functions, like variable argument length: (+ a b c).
Clojure is a little bit less uniform than other Lispy languages in that it has special brackets for lists (square brackets) and for maps (curly brackets), but that's pretty much it.
i am not a clojure or lisp expert, just saying.
(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)
They're really amenable to the REPL.
Fastest at what, exactly?
So giving the entire system to the JVM, performing some warmup prior to a service considering itself “healthy”, and the JVM was reasonably fast. It devoured memory and you couldn’t really do anything else with the host, but you got the Java ecosystem, for better or worse).
There was a lot of good tooling that is missing from other platforms, but also a ton of overhead that I am happy to not have to deal with at the moment.
With the JVM you basically outsource all the work you need to do in C/C++ to optimize memory management and a typical developer is going to have a hell of a time beating it for non-trivial, heterogenous workloads. The main disadvantage (at least as I understand) is the memory overhead that Java objects incur which prevent it from being fully optimized the way you can with C/C++.
The GC story is just great, however. Pretty much the best you can get in the entire ecosystem of managed-memory languages.
You have different GC algorithms implemented, and you can pick and tune the one that best fits your use-case.
The elephant in the room is of course ZGC, which has been delivering great improvements in lowering the Stop-the-world GC pauses. I've seen it consistently deliver sub-millisecond pauses whereas other algorithms would usually do 40-60 msec.
Needless to say, you can also write GC-free code, if you need that. It's not really advertised, but it's feasible.
As someone who's always been interested in gamedev, I genuinely wonder whether that would be good enough to implement cutting-edge combo modern acceleration structures/streaming systems (e.g. UE5's Nanite level-of-detail system.)
I have the ability to understand these modern systems abstractly, and I have the ability to write some high-intensity nearly stutter-free gamedev code that balances memory collection and allocation for predicable latency, but not both, at least without mistakes.
The GC would be the least of your problems.
Java is neat, but the memory model (on which the GC relies) and lack of operator overloading does mean that for games going for that level of performance would be incredibly tedious. You also have the warm up time, and the various hacks to get around that which exist.
Back when J2ME was a thing there was a mini industry of people cranking out games with no object allocation, everything in primitive arrays and so on. I knew of several studios with C and even C++ to Java translators because it was easier to write such code in a subset of those and automatically translate and optimize than it was to write the Java of the same thing by hand.
There's no value types (outside primitives) and everything is about pointer chasing. And surely if there was less pointer chasing it'd be easier to do the GC work at the same time.
It is not feasible under the JVM type system. Even once Valhalla gets released it will carry restrictions that will keep that highly impractical.
It's much less needed with ZGC but even the poster child C# from the GC-based language family when it comes to writing allocation-free and zero-cost abstraction code presents challenges the second you need to use code written by someone who does not care as much about performance.
The downside is that you sacrifice a lot of the benefits of guard rails of the language and tooling for what may not end up being much savings, depending on your workload.
I'd also throw in what was possibly their greatest idea that sped adoption and that's javadoc. I'm not sure it was a 100% original idea, but having inline docs baked into the compiler and generating HTML documentation automatically was a real godsend for building libraries and making them usable very quickly. Strong typing also lined up nicely with making the documents hyper-linkable.
Java was really made to solve problems for large engineering teams moreso than a single developer at a keyboard.
Not anymore, the competition is doing much better these days.
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.
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.
But nobody seems to talk about or care about C# except for Unity. Microsoft really missed the boat on getting mindshare for it back in the day.
Microsoft has been historically much less aggressive with lawyers compared to Oracle.
They also tend to be of higher quality and provide better performance.
Moreover, a lot of these libraries are well-supported to this day. For example, Hibernate (the best ORM in business) is 28 years old, and has just released a new version. I recently consulted my former client (from 15 years ago), and I still recognized most parts of the stack that I set up way back then.
C# is extremely popular in all kinds of 'boring' industries. Having worked in areas like logistics and civil engineering, C# is everywhere.
There was this guy Miguel de Icaza. From when I followed the open source ecosystem at the time, it seemed to be his personal mission to promote independent clones of a bunch of Microsoft technologies like C# on his own time even though they didn't ask him to do it.
I don't think I ever understood why someone would do this. It's like in the 2000s where people seemed to think you could solve all technical problems by inventing new kinds of XML.
Nevertheless, as a platform, the JVM and JDK were fantastic and miles ahead most alternatives during the late 1990s and 2000s. The only platform for large development that offered some compelling advantages was Erlang, with BEAM and OTP.
Aside from early versions being rushed, I feel that Java's success and adoption were the bigger issue. While Microsoft could iterate quickly and break backwards compatibility with major versions of C# and the .NET runtime, Java was deliberately moving at a much slower pace.
See https://mckoder.medium.com/the-achilles-heel-of-c-why-its-ex...
Your linked blog is pretty wild. Only throw RuntimeExceptions to crash? Why not just Exit if that's the proper thing to do?
If you treat all C# exceptions as RuntimeExceptions, then it satisfies the blog anyhow.
Because you won't get a stack trace.
https://www.artima.com/articles/the-trouble-with-checked-exc...
Their belief was wrong. Microsoft now recommends against catching Exception.
The article you linked to is addressed at the bottom of this article: https://mckoder.medium.com/the-achilles-heel-of-c-why-its-ex...
That's so ignorant. Read the article please.
- https://news.ycombinator.com/item?id=43226624
- https://news.ycombinator.com/item?id=43584056
- https://news.ycombinator.com/item?id=36736326
And more. I'm not sure what you found in (checked) exceptions. If you'd like explicit error handling, we have holy grail in the form of Rust which beautifully solves it with implicit returns, error type conversions and disambiguation between error and panic model. I'd prefer to use that one as it actually reduces boilerplate and improves correctness, the opposite to the outcome of using checked exceptions.
I could copy/paste the entire article here... but it would be easier if you could take a gander: https://mckoder.medium.com/the-achilles-heel-of-c-why-its-ex...
Summary:
Crashy code: You have no compiler-enforced way to know what exceptions might be thrown from a method or library.
More crashy code: If a method starts throwing a new exception, you might not realize you need to update your error handling.
Dead code: If a method stops throwing an exception, old catch blocks may linger, becoming dead code.
It's an extremely common language in "boring" companies doing "boring" (but profitable) work.
Java kept growing and wound up everywhere. It played nice with Linux. Enterprise Mac developers didn't have trouble writing it with IntelliJ. It spread faster because it was open.
Satya Nadella fixed a lot of Microsoft's ills, but it was too late for C# to rise to prominence. It's now the Github / TypeScript / AI era, and Satya is killing it.
The one good thing to say about Ballmer is that he kicked off Azure. Microsoft grew from strength to strength after that.
No comments yet
MS does have an uphill PR battle though.
For example, Go does not understand cgroups limits and needs an external package to solve this. .NET can read and accommodate those natively. It also ships with excellent epoll-based socket engine implementation. It's on par with Go (although I'm not sure which one is better, but .NET performs really well on high-throughput workloads).
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" ?
However, at the moment i still feel i'm using a huge amount of layers upon layer of complex type definitions in order to get anything done. Just using an object's reference across async calls in a safe manner leads to insane types and type constraints, which read like ancient egyptian scripture. And at every layer, i feel like changing anything could blow everything up with lifetimes.
The language has this very special feel of something both advanced and extremely raw and low-level at the same time. It's very unique.
Also, it’s worth saying, you probably don’t need async.
Then you want to declare an async function that takes an async closure over that dependency. And you end up with a total garbage of a method signature.
As for async, the ecosystem for server-side is totally filled with async everywhere now. I don't think it's realistic to hope escaping those issues anyway in any real-world project. i thought i might as well learn to get comfortable with async.
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
However, at some point you have to ask yourself why you're accepting to face all those challenges. Is it worth it ? When was the last time i faced a race condition when developping a backend ?
The reason i started with rust was for a very specific need on building a cross-platform library (including wasm), and that was a good justification, and i'm happy that i did. However now that i'm using it for the server as well and face the same kind of challenges, i seriously question whether this is a wise choice.
> 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.
It shouldn’t take 2 months of full time programming to beat the learning curve.
Go felt the same way (but with a much lower order of magnitude) : you feel like bumping into language limitations, but once you learn to do it "simply" in go, your style will have changed into something much more elegant.
As for the bug in question, it has been quite "popular" for about 5 years now, and is actively tracked : https://github.com/rust-lang/rust/issues/110338. Nothing really weird. Just async hitting the limits of the current rust design.
Simply using axum with code using multiple layers of async was enough.
But then again, it looked like this bug (the error message is the same), however at this point i'm really unsure if it's exactly the same. The error message and the method signature was so atrocious that i just gave up and found a simpler design using macros that dodged the bullet.
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.
While operator overloading and infix functions aren't a Java anti-pattern, I also think the language would be improved by their removal.
Simple example, JAX-RS running on top of Java SE. I agree, JAX-RS is not what one might call "simple". It IS complex, or I should say, it CAN be complex. But Happy Path, staying in the middle of the road, it's pretty sweet for knocking out HTTP backed services. The Jersey reference implementation will do most anything you need (including stuff not "included" in raw JAX-RS). No need for a container, no need for a lot that stuff and all that hanger-on. The core runtime is pretty broad and powerful.
Consider my current project, it uses the built in Java HTTP server. Which works! It's fast, it's functional, it's free. (Yes, it's in a com.sun.net... package, but it's not going anywhere.) It's awkward to use. It's aggravatingly raw. It follows the tenet "why be difficult, when, with just a little effort, you can be impossible."
So, I wrote a simple "servlet-esque-ish" inspired layer for response and request handling, a better path based regex-y router, and a nicer query parser for queries and forms. 500 lines. Add on a JSON library and I can process JSON-y web request/response, easily. (I also wrote my own Multipart processor -- that was another 500 lines, boy that was fun, but most folks don't need that.)
A little bit of code and the built in server is MUCH easier to use. No tomcat, no deploys, zip. ...and no dependencies (save the JSON library).
Something all of these cool frameworks and such have shown me is what's really nice to have, but at the same time, just what isn't really necessary to get work done. I mean, CDI is really neat. Very cool. But, whoo boy. So I have a single singleton to handle application life cycle and global services. It works great with tests. I have a 50 line Event Bus. I have a 100 line "Workflow Engine". 150 line java.util.Logger wrapper (which is mostly, you know, wrapper). I wrote that way back whenever they introduced varargs to java (Java 5? 6?). The modern Java logging landscape is just...oh boy. I'm content with JUL -- I can make it work.
My current project is "magic free". I think @Overide in the single annotation anywhere in it. But it's comfortable to use, the cognitive load is quite load (outside of the actual application itself, which is NOT low -- sheesh). No swearing at frameworks. It's all my fault :).
Anyway, the point is that "simple Java" lurks in there. It needs a bit of uplifting, but not a lot.
It's an uphill battle to convince my co-workers to do things my way.
The main area they get excessively lengthy is in certain frameworks and testing tools that can add like 100 lines to the trace.
If you wrote code with such deep stacktraces, it's all on you.
There's a performance cost to all that excessive stack depth too, often.
God bless Gemini 2.5 Pro which ate all the traces for breakfast.
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.
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.
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.
This is because Java is based on an older language called Objective-C that doesn't have multiple inheritance :)
It's not based on C++, that's just the other OO language from the era people usually think of.
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.
I have no love for Oracle the big bad company. But I am deeply greatful they've managed to keep that group moving forward.
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.
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.
But reading your message it doesn't sound like it.
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.
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.
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.
We're seeing this issue entirely in .NET core. We started on .NET 6, are currently on .NET 8, and will likely migrate to 10 soon after it is released. It's again worth mentioning that you provide zero evidence that .NET 6 solves this problem in any way. Although, as we will see below, it seems like you don't even understand the problem!
> 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.
No, I'm referring to code written recently, at the job I work at now, at which I've been involved in discussions about, and implementations of, workarounds for the issue.
> 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.
100% false. This deadlock issue has nothing to do with synchronization contexts. Please actually read the 2020 article I linked as it explains the issue much better.
> Pathetic attempt at strawman.
I realize responding to this is to just fight pettiness with more pettiness, but I can't resist. You should probably look up the definition of a strawman argument since you are using the word incorrectly.
As for async and tasks - have you ever considered just not writing the code that is so bad it managed to bypass cooperative blocking detection and starvation mitigations? It's certainly an impressive achievement if you managed to pull this off while starting with .NET 6.
Edit: I agree with the subsequent reply and you are right. Concurrency primitives are always a contentious topic.
"Your deadlock scenario is related to synchronization contexts and can be avoided by ..."
rather than:
"You clearly don't know what you're talking about (but I won't bother telling you why)"
Then we could have had a much more productive and pleasant conversation. I would have responded with:
"Sorry, that article wasn't the right one to share. Here is a better one. The issue I am talking about isn't synchronization context-related at all. It's actually much more insidious."
Enjoying or tolerating Hibernate is undiagnosed Stockholm Syndrome :D
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.
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.
https://en.wikipedia.org/wiki/Gosling_Emacs
"Gosling Emacs was especially noteworthy because of the effective redisplay code, which used a dynamic programming technique to solve the classical string-to-string correction problem. The algorithm was quite sophisticated; that section of the source was headed by a skull-and-crossbones in ASCII art, warning any would-be improver that even if they thought they understood how the display code worked, they probably did not."
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.
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?
The Java API has its fair deal of baggage due to its extreme backward compatibility. Boolean.getBoolean[1] is one of the more accessible examples of a bad API that exists only because of legacy reasons, but there quite a number of them.
[1] https://docs.oracle.com/javase/8/docs/api/java/lang/Boolean....
You state how you don't really use java, but the above confirms it.
Java debugging and diagnostic tooling is second to none.
And I think there is some parallel with the kernel vs GC and mmap vs buffer pools - the GC simply has better context in the scope of the application. With other processes in the picture, though, yeah there is some provisioning complexity there.
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
OpenJDK, the de facto standard version used by everyone, is licensed under the GPL version 2 with the classpath exception.
No offence, but you simply aren’t well informed.
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.
The main problem is the legacy code and attitude out there, dependency injection, using Spring or Spring Boot etc SUCKS. VertX is/was good but now with virtual threads you dont need all the async complexity.
It may not be cool to use Java for startups, but we do and are immensely productive with it.
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. :)
For a simple IPv4 address normally representable using 4 bytes/ 32 bits Java uses 56 bytes. The reason for it is Inet4Address object takes 24 B and the InetAddressHolder object takes another 32 B. The InetAddressHolder can contain not only the address but also the address family and original hostname that was possibly resolved to the address.
For an IPv6 address normally representable using 16 bytes/ 128 bits Java uses 120 bytes. An Inet6Address contains the InetAddressHolder inherited from InetAddress and adds an Inet6AddressHolder that has additional information such as the scope of the address and a byte array containing the actual address. This is an interesting approach especially when compared to the implementation of UUID, which uses two longs for storing the 128 bits of data.
Java's approach is causing 15x overhead for IPv4 and 7.5x overhead for IPv6 which seems excessive. What am I missing here? Can or should this be streamlined?
For my part, most of the Java code that I have written that needs to use IP addresses needs somewhere between 1 and 10 of them, so I'd never notice this overhead. If you want to write, like, a BGP server in Java I guess you should write your own class for handling IP addresses.
And it's still stable, fast and reliable with a massive ecosystem of stable, fast and reliable libraries and software. With good developer tooling, profilers and debuggers to go with it. And big enterprise support teams from RedHat, Oracle, IBM, etc. throwing in their (paid) support services.
It might not be the best language in any of the categories (speed - runtime and compile time, tooling, ecosystem, portability, employee pool), but there's pretty much almost no languages that are as good in all categories at once.
And to top it off, JVM can host other languages so it can easily interoperate with more modern takes on language design like Kotlin while still running on pretty much all major operating systems used in the wild and most CPU architectures as well. It'll run on your car's SoC, your phone and on your server. In many cases, using the same libraries and same code underneath.
Not. And certainly not semantically.
Microsoft had C#, at one point IBM pushed SmallTalk. C++ for these environments is doable but going to slow you down at development a lot, as well as being much harder to secure.
At that time the dynamic alternative was Perl, and that remained true basically until Rails came along.
I would say that many things in IT are not chosen on technical merits alone. You have people that do not want to accrue any blame. Back then, by choosing what IBM endorses or what Microsoft endorses, you absolve yourself of fallout from if and when things go wrong.
Back in the 90s, it felt like IBM, Redhat, Sun kind of, sort of, got together and wanted to keep Microsoft from taking over the Enterprise space by offering Java solutions.
Of course those were much more hazardous languages than Java.
And Oracle (well before the Sun acquisition - in fact, control of Java was basically the main cause of that move).
Any technology that could bag both IBM and Oracle is (or rather was) likely to dominate the enterprise space.
In the late 90s, I got stuck making a scheduling program in Java, but it had to run on the 16-bit Windows systems of the time. That was a huge pain, because the 16-bit version didn't have all the capabilities that management was expecting based on the hype. These days, I sometimes have to install enormous enterprise applications that tie up north of 32G of RAM even though they're just basic hardware management tools that would take a fraction of that if built in something like C++ with a standard GUI library. I manage to avoid Java most of the time, but it's been an occasional thorn in my side for 30 years.
The key thing I think with Java is the programming model & structure scale well with team size and with codebase size, perhaps even in a way that tolerates junior developers, outsourced sub-teams, and even lower quality developers. All of those things end up becoming part of your reality on big Enterprise products, so if the language is somehow adding some tolerance for it that is a good thing.
The other things around Syntax and such that people complain about? Those are often minor considerations once the team size and code base size get large enough. Across my career there has always been the lone guy complaining that if we did everything in a LISP derived language everything would be perfect. But that guy has almost always been the guy who worked on a small tool off by himself, not on the main product.
Java has changed a tremendous amount as well. A modern Java system has very little in common with something written before Generics and before all the Functional code has been added. Where I work now we have heavily exploited the Functional java add-ons for years, it has been fantastic.
Decent tooling. Been around for long enough that a lot of the quirks of it are well known and documented. Basically it's a blue collar programming language without too many gotchas. Modern(ish) day Cobol.
(I'm predominantly a Java dev still, even after diversions over the years to Javascript, Python and C#).
Things tend to form fractal systems of systems for efficiency. A cleanly delineated org chart maps to a cleanly delineated codebase.
How did he build something adopted by so many enterprises?
It does some things at scale very well and has been afforded the performance improvements of very smart people for 30y.
It’s not to say the language isn’t verbose, one of my favourite features was the ability to write code in other languages right inside the a Java app pretty well in-line by using the JVM, thanks to JSR-223.
It was possible to write Ruby or Python code via Jruby or Jython and run it in the JVM.
https://www.jython.org/
https://www.jruby.org/
Clojure also runs on the JVM.
https://docs.oracle.com/javase/8/docs/technotes/guides/scrip...
GC. Single file modules. No "forward". The Collection suite. Fast compiles.
The magic of the ClassLoader. The ClassLoader, that was insightful. I don't know how much thought went into that when they came up with it, but, wow. That ClassLoader is behind a large swath of Java magic. It really hasn't changed much over time, but boy is it powerful.
When I started Java, I started it because of the nascent Java web stack of the day. Early servlets and JSP. I picked because of two things. One, JSPs were just Servlets. A JSP was compiled down into a Servlet, and shazam, Servlet all the way down. Two, single language stack. Java in JSPs, Java in Servlets. Java in library code. Java everywhere. In contrast to the MS ASP (pre .NET) world.
Mono-language meant my page building controller folks could talk to my backend folks and share expertise. Big win.
Servlets were a great model. Filters were easy and powerful. Free sessions. Free database connection pools in the server. I mean, we had that in '98, '99.
And, of course, portability. First project was using Netscapes server, which was spitting up bits 2 weeks before we went live, so we switched to JRun in a day or two (yay standard-ish things...). Then, Management(tm) decided "No, Sun/Oracle, we're going NT/SQL Server". Oh no. But, yup, transitioned to that in a week. Month later, CTO was fired, and we went back to Sun/Oracle.
Java EE had a rough start, but it offered a single thing nobody else was offering. Not out of the box. Not "cheap", and that was a transaction manager, and declarative transactions on top of that. We're talking about legit "Enterprise grade" transaction manager. Before you had Tuxedo, or MS MTS. Not cheap, not "out of the box", not integrated. JBoss came out and gave all that tech away. Then Sun jumped on with early, free, Sun Java Enterprise 8 which begat Glassfish which was open source. Glassfish was amazing. Did I mention that the included message queues are part and parcel of the integrated, distributed transaction model for Java EE? Doesn't everyone get to rollback their message queue transactions when their DB commit fails? Message Driven Beans, sigh, warms my heart.
There were certainly some bad decisions in early Java EE. The component model was far too flexible for 95% of the applications and got in the way of the Happy Path. Early persistence (BMP, CMP) was just Not Good. We punted on those almost right away and just stuck with Session Beans for transaction management and JDBC. We were content with that.
The whole "everything is remote" over CORBA IIOP and such. But none of that really lasted. EJB 3 knocked it out of the park with local beans, annotations in lieu of XML, etc. Introduction of the JPA. Modern Jakarta EE is amazing, lightweight, stupid powerful (and I'm not even talking Spring, that whole Other Enterprise Stack). There's lots of baggage in there, you just don't have to use it. JAX-RS alone will take you VERY far. Just be gentle, Java Enterprise offers lots and lots of rope.
None of this speaks to the advances in the JVM. The early HotSpot JIT was amazing. "Don't mind me, I'm just going to seamlessly sneak in some binary compiled code where that stack machine stuff was a nano-second ago. I've been watching it, this is better. Off you go!" Like presents from Santa. The current rocket ship that in JDK development (this is good and bad, I still do not like the Java 9 JPMS module stuff, I think it's too intrusive for the vast majority of applications). But OpenJDK, the Graal stuff. Sheesh, just get all light headed thinking about it.
Along with the JVM we have the JDK, its trivial install. Pretty sure I have, like, 20 of them installed on my machine. Swapped out with a PATH and JAVA_HOME change. The JVM is our VM, the Servlet container is our container. Maven is our dependency manager. Our WAR files are self-contained. And all that doesn't go stomping on our computer files like Paul Bunyan and Blue making lakes in Minnesota.
It's no wonder I was struggling to grok all the talk about VMs, Dockers, and containers and all that stuff folks mess with to install software. We never had to deal with that. It just was not an issue.
I can distribute source code, with a pom.xml, and a mvnw wrapper script, and anyone can build that project with pretty much zero drama. Without breaking everything on their system. And whatever IDE they're using can trivially import that project. It's also fast. My current little project, > 10K lines of code, < 3s to clean/build/package.
Obviously, there's always issues. The Stories folks hear are all true. The legacy stuff, the FactoryInterfaceFactoryImpl stuff. The Old Days. It's all real. It's imperfect.
But, boy, is it impressive. (And, hey, portable GUI folks, Java FX is pretty darn good...)
https://m.youtube.com/watch?v=NVuTBL09Dn4
You can keep the Java, thanks.
Zero money programmers >> Zero interest rate programmers :-)
> Jasmin was written because, at the time that we wrote the Java Virtual Machine book for O'Reilly, Sun had not published an assembler format for the Java virtual machine.
> Generating a binary Java .class file is pretty fiddly. Its like creating an a.out (or .exe) file by hand. Even using a Java package like JAS (a Java API for creating class files, used internally by Jasmin and written by KB Sriram), you need to know a lot about the philosophy of the Java Virtual Machine before you can write something at the Virtual Machine level and generate a Java class.
> We wanted something that made it very easy for a student or programmer to explore the Java Virtual Machine, or write a new language which targets the VM, without getting into the details of constant pool indices, attribute tables, and so on.