pron

7 ms·

31.
by pron 27d ago
> Rust is just as ergonomic as any other popular language today if you're using an agent Have you worked on large (>500KLOC) codebases with an agent? Not only do you have to be an expert at the language, but even if you're l
32.
by pron 27d ago
Oh, sorry, missed a few words. Their CPU time.
33.
by pron 27d ago
> However, such optimization is theoretically possible. The stack is definitely faster than anything else. What you're describing isn't a stack, but an automatic arena, and this optimisation is easier to do in Java. It's e
34.
by pron 27d ago
> the situation is very much the opposite when it comes to Rust. It isn't, and the problem isn't Rust specifically, but all low-level languages. They can offer very good performance (often better than Java) when small. But as t
35.
by pron 27d ago
> I use Java every day but just to point out that your info about Go‘s GC seems out of date. I'm well aware that Go's GC has improved, but the moving algorithm was designed not just to be fast for a GC, but to be faster than no
36.
by pron 27d ago
> Which specific optimizations are you referring to? A JIT with speculative optimisation and a moving GC. There are two constraints in low-level languages that trump any of their performance goals, one technical and one a matter of prefe
37.
by pron 27d ago
I agree that it matters, but whether and how to do it depends on the standard practice in the relevant forum. On HN, it's rare for people to disclose affiliation even in their profile, so I think I'm already better than the norm h
38.
by pron 27d ago
Quite the opposite, and the reason is that you can't extrapolate from small programs to large ones. Low-level languages (like C++) incur some significant overheads as they grow large (because of essential constraints of low-level langu
39.
by pron 27d ago
First, they do. Second, most software is not only not produced by software startups, it's not even produced by software companies. Do you know how much software a bank, or a credit card company, or a telecom provider, or a car manufact
40.
by pron 27d ago
Right. There's a "Java SE" (platorm spec) version, and a JDK version that corresponds to it, but not everything in the JDK affects or is dictated by the spec. BTW, Java is developed "code first", which means that we
41.
by pron 27d ago
It's disclosed right there in my profile (I don't see your professional affiliation disclosed in your comment; or your profile, for that matter). Of course, I, like other runtime and compiler people, joined the Java team because
42.
by pron 27d ago
I don't know what compiler and GC quality has to do with how people are making software these days, and I don't think state-of-the-art optimising compilers and GCs are terrifying at all. Go opts for more traditional, simpler algor
43.
by pron 27d ago
Open telemetry is about how telemetry data is reported, not how it's collected. It's hard to compete with JFR on the breadth and depth of low-overhead, in production telemetry, built into the standard library and the JVM itself.
44.
by pron 27d ago
There's a difference between number of programs and number of LOC (the latter is related to the number of people involved). I am not aware of any SDK targeting the industries I mentioned that "doesn't bother with Java".
45.
by pron 27d ago
They lack in performance, stability (compatibility), observability (telemetry), productivity, or some combination thereof. They are chosen, of course (especially C#; Go and Rust are far behind), but not as much as Java.
46.
by pron 27d ago
You could, but it's not as fast as Java, especially under heavy workloads, its telemetry is nowhere near as good, and it's much less popular.
47.
by pron 27d ago
These days, Java is mostly used in greenfield software that has to be very reliable, very performant, and last for many years. So it's often the first choice for banking, telecom, finance, government, defence, manufacturing control, lo
48.
by pron 27d ago
The Java language and runtime have been co-designed as a unified platform for many years now. Virtually every significant feature has language, library, and VM people working on it, and we often don't even know when we start how much o
49.
by pron 28d ago
Upgrading JDK versions isn't all that much work, and it offers very significant benefits especially when it comes to performance. Applications that don't upgrade don't have the resources to do even that; they're in minim
50.
by pron 1mo ago
> Women are currently viewed as intrinsically a good thing to run a company Why would anyone think that having significantly less than 50% women requires no investigation if they didn't think women are intrinsically bad for a compan
51.
by pron 1mo ago
Are you talking about G1 in JDK 25, JDK 26, or JDK 27? While G1 isn't changing quite as fast as ZGC, it changes quite a bit from release to release. I believe that G1 has been made the default even for small machines in JDK 27 because
52.
by pron 1mo ago
> I would be very surprised if ZGC became the default, because it incurs a significant overhead penalty to eliminate those GC pauses That throughput penalty is not very high with generational ZGC. It's not zero, but it's not ve
53.
by pron 1mo ago
The problem is that 1. it's not easy to beat the JDK's GCs at memory management (assuming you've picked the right GC for your workload) especially as they keep getting better and better, and 2. how a pool behaves relative to
54.
by pron 1mo ago
If anything, I think it's not unlikely that ZGC will become the default at some point, as it matures. It's hard to beat Parallel on batch workloads, although G1 is getting there. ZGC is unparalleled for low-latency (GC pauses are
55.
by pron 1mo ago
There are two practical lessons here: 1. Upgrade your JDK for the best performance (as the article says, the slowdown is gone in JDK 26). 2. Don't try to help the GC by pooling objects. Mutating old objects can be expensive, while allo
56.
by pron 1mo ago
If that were the actual tradeoff, I'd take it, too (and BTW, Java's memory safety is much better than Rust's, but that's beside the point now). Remember that even 25 years ago you had a very similar thing with C++ vs Jav
57.
by pron 1mo ago
> That's not true, as evidenced by the fact that this move has started before extremely sophisticated JIT compilers or garbage collectors were invented. I don't know how long you've been programming, but that's not tr
58.
by pron 1mo ago
> I know that. I also know that JITs cannot optimize to the same amount as LLVM due to the time limit Yeah, this is not true, and there's no time limit. I mean, maybe some JIT compilers, like JavaScript's have a time limit, but
59.
by pron 1mo ago
Well, if you have a couple of decades of experience with low-level programming, you know that AOT compilation and non-moving pointers carry intrinsic runtime overheads that manifest as programs grow large and complex, and run for a long tim
60.
by pron 1mo ago
> The complexity is made worse for specific, isolated, encapsulated and reusable code, while all other code becomes significantly safer? That's a deal I'll take at any time. That's not the deal I'm getting on either s

More ›