391–400 of 464 posts
Earlier quoted context omitted.
>> I will continue to enjoy writing once and deploying anywhere! Except to the browser, iOS, embedded systems... WebAssembly is the real write once deploy anywhere tech now. JVM had its turn and lost.
Embedded systems? Like sim cards? There's even real time Java, I think they used it for some missile guidance stuff aswell at some point
Earlier quoted context omitted.
Part of the reason Java hasn't reified generics is because C# did and it was a real big headache that also limited non-C# languages on the C# runtime (CLI?). Everything had to be recompiled to work with newer C# runtimes. While it's pretty easy to run a bunch of language on the JVM (Javascript, python, ruby, clojure) doing the same for C# is somewhat a nightmare, particularly for non-type aware languages. For example…
IronPython did just fine with reified generics.
Nowadays largely abandoned, and I think not everything survived the transition from .NET Framework into modern .NET.
Earlier quoted context omitted.
Regarding "What's wrong with what .NET did with threads?", see https://cr.openjdk.org/~rpressler/loom/Loom-Proposal.html (relevant part below): An alternative solution to that of fibers to concurrency's simplicity vs. performance issue is known as async/await, and has been adopted by C# and Node.js, and will likely be adopted by standard JavaScript. Continuations and fibers dominate async/await in the sense that asyn…
So does Java provide an API for continuations or just the virtual threads hidden behind the threading API? You can't use threads to wait for something on the UI thread (which is why e.g. SwingWorker exists), but you can with await.
Structure concurrency/virtual threads seem like a good fit for Swing; just have your event handler fire off virtual thread[s] and do your work and call SwingUtilities.invokeLater to schedule the result to be applied on the event loop thread when you're done. Structured concurrency simplifies managing groups of concurrent tasks, cancelation, etc.
Earlier quoted context omitted.
Ah, INT_MIN. If I had a nickel every time I saw an implementation of inttostr/strtoint that don't properly handle it, I'd probably have about $5. So I too thought about possibility of it serving as a NaN of signed integers... but I doubt we'll see it any time soon. Also, apparently, shifting a negative number to the left is UB in C.
Left shifting a large positive number is also UB. C made a lot of things undefined that would make much more sense as implementation defined.
> a lot of things... would make much more sense as implementation defined.
Or even just defined. Apparently, the fact that shifting right a signed number is done arithmetically, not logically, is implementation-defined too.
Well, at lest bitwise not/and/or are (almost) fully defined even for signed integers, so that's something.
A lot of the comments on here are a bit unfair on what is great work being done and even more awesome work (JEPs) in the pipeline for the future. If Java was a child, imagine it being brought up by loving parents for the first few years (Sun) then it was thrown in a garage with some other children and neglected by its evil guardian (Oracle) Neglected and unloved till JDK 8, its basically been playing catch up. So whe…
Earlier quoted context omitted.
First, your parent comment misunderstood what the section they were critiquing is referring to. It's not about nullability (which is orthogonal) but about reference/value projections. Now, as a member of the Java team (although I'm not directly involved in Valhalla), I'm obviously biased so let me just say that both designers and fans of programming language features would do well to remember two things: 1. Opinions…
This is pretty funny... "All differences are opinions....except what .net did. Those are wrong!" I personally think Java continues to to waste a lot of time and come to a slightly more verbose and worse solution again and again. Structured concurrency is like c# async/await with less sugar. Streams are just LINQ but worse. It's probably exactly because of the "not like .NET! We must be different to explain being late…
But that doesn't mean the preferences are equally distributed. Some people liked Betamax's better picture quality while others liked VHS's better recording times, but they didn't do it in equal numbers. And that's what's funny, because there are two languages doing as well as Java or better (one of them is much more popular), and yet what's almost universal is that when people say "Java is worse than X", X is invariably a language that's doing much worse than Java.
I'm not saying that there isn't much to learn from less popular languages, but the claim "Java is consistently making the wrong decisions compared X" doesn't make sense when X is consistently losing to Java.
And I can even give you the secret to our strategy: Make Java the language that people who choose it regret less than people who choose other languages.
Earlier quoted context omitted.
> including providing less control and making interop a pain This is true in some languages but not in Java. The limitations (and performance cost) are not from the nature of continuations/stackful coroutines/"colourless functions", but from their interaction with other constraints and existing designs in the language. E.g. in Java, virtual threads have zero impact on FFI. In general, the costs and limitations associ…
How can green threads have zero impact on FFI in the presence of callbacks across the boundary? I mean, as soon as the other side uses TLS in any way, for example, you have to figure out how to handle that, and it's not free.
But 1. there's no speed penalty in Java for doing that, and 2. In Java, calling native functions that block (which is the only time this limitation matters) is rare, especially in high concurrency situations where you'd use virtual threads in the first place.
Earlier quoted context omitted.
I have no idea about MySQL, but what I always remind people is that HN is more GQ/Vogue than the NYT. It focuses on novelty and aspiration more than on coverage of what the industry is actually doing. Like others, I enjoy it because it's aspirational/inspirational, but I try not to confuse it with a reflection of reality. E.g. there's little correlation between programming languages that are discussed a lot on HN and…
Where do you find more nuanced discussions?
People come to HN because they want to hear or talk about things that most people don't usually do; it's more interesting because it's different! I'm not saying they always say positive things, but positive or negative, this is what we like talking about online. This is why people buy GQ or Vogue. If you want to talk about boring work stuff, talk to people at work :)
I know its a faux pas in the Java world to acknowledge the existence of .NET, but how does this differ from .NET structs? Value types, generic specialization, boxing - a quick skim makes it looks like they picked the same choices.
I made a comment on my understanding of the difference in implementation here: https://news.ycombinator.com/item?id=48606173 The ramifications for backwards compatibility is that the JVM won't have CLR features such as stackalloc (allocation of blocks of memory on stack), ref parameters (pass-by-reference of stack allocated value types), and all the other low-level/high-performance programming features available in t…
Why couldn't it be done? Like sure, it won't happen in every case (e.g. too big value classes), but for a typical local variable of a value type, it's a trivial optimization to make it stack allocated. Even now it happens quite often (requires escape analysis), but the semantics change of value classes allows for it to be done "freely".
After reading a lot of comments in here, there is one thing that always repeats itself in Java/JVM-related comment sections on HN. There are a surprising number of people who have an idea of what the JVM or Java used to be and have very little idea of what it is today. It is a very fit predator in 2026. Does it have its warts? Yes, but the substrate is extremely good.
Many of us work on Java monoliths that started in the 2000s when it was in vogue and we still have to keep them chugging along on Java 8. Personally I'm familiar with all the new features that have come out in the last few years, but for my actual work, java is literally stuck in the past.
There's something else amiss here. Compared to other platforms, upgrading Java, even on complex codebases, has never been a nightmare for me.