pron
VS Code might be using close to 1GB with nothing loaded, but it doesn't go much higher with stuff loaded, at least not that I've noticed. I do have 16GB because that's what you get in a laptop these days, and I'm always running at least three Electron apps concurrently, a browser with about 200 open tabs, and then another one or two browser with a few tabs each (plus an email client, and of course, agents and compilers running in the background). The only time I notice an issue is when a program leaks memory.
But again, I try not to look at numbers unless I know exactly what their effect is, and I rarely if ever notice any ill effects caused by well-behaving Electron apps, and unless I notice an actual problem I try not to look at numbers, because they can lead you down the wrong path and distract you from what actually matters. Overall RAM in particular, especially when combined with low-CPU (which makes swapping cheap), is a very misleading metric because it's not easily translatable to value without lots of other pertinent information (such as how many copies of the program the average user is expected to run concurrently, how many other programs the user is expected to run and what the CPU utilisation is).
In the nineties and early oughts, I, like many other developers, obviously focused a lot on reducing RAM because it mattered a lot under the conditions back then. Over the years, it started mattering less and less, to the point that you need a very clear justification to optimise it (in fact, you need a clear justification to optimise anything, or you'd end up wasting your time on optimising the wrong thing at the expense of the right thing). These days, I too often see developers trying to reduce RAM without being able to point at an actual (not hypothetical) user-experience problem they're solving.
No, that's not the conclusion. If using models costs you, say, $10 an hour, and a GB of RAM costs you, say, $0.0001 an hour, then clearly you shouldn't spend your time on reducing the insignificant cost if you want your work to deliver the most value to users.
But again, "less RAM" is more or less meaningful whether you're reducing the RAM usage from, say, 5% to 1% or from 80% to 40%. The latter is more valuable even though it's a lower relative reduction. That's because what the users care about is in what conditions they reach 100% of either CPU or RAM, and the second 2x reduction, therefore, offers more value than the first 5x one. This is similar to how a 10% discount on a car offers far more value than a 99% discount on a pack of chewing gum. This is still the case if you're buying 100 packs, but maybe not 10,000, and the same goes for software: it may also matter how many copies of the app the user is expected to run concurrently. The point is that you can't assign a value to a 10x reduction if that's all you know.
> I'm entertaining this nonsense because I want to clarify, that I use a 20 year old web gui and it consistently eats 8 gigs of ram in Webkit because it uses CSS to update the forms.
And I'm entertaining this nonsense because you're clearly not a very experienced engineer and you may learn something. In the ninetees, when nearly all GUI apps were written in C or C++, we had plenty of examples where a C++ GUI app consumed 50% RAM. That doesn't mean that C++ is worthless, only that some software has serious resource bugs, and it sounds like that web page you're referring to is a case of that. Most web-based GUI apps today do not consume a higher portion of RAM than their C++ counterparts did 30 years ago. Today's browser-based MS Word consumes less (relative) RAM than the C++ version did in 1998, and it certainly has a far smaller negative impact on concurrently using other apps on the machine.
And, of course, there are buggy/leaky programs now just as there were then. It's silly to say that the existence of such programs means that the approach is bad, because that would apply to any sufficiently-popular language or toolkit.
Anyway, our job is to offer the most value to our users, and reducing RAM consumption by 3% or even 5% (of available RAM) is usually not where you'd find much value.
Because that's not what I said. My point was more that a "1000% memory inflation" is not a meaningful cost metric to begin with (to use just one toy example, perhaps you'd agree that going from 10% RAM to 100% has a very different impact than going from 1% to 10%, even though both are a "1000% inflation").
Memory (at least on a personal computer) is not rented by the hour on a per-MB basis; you buy it in bulk. What matters isn't how much memory you could have used but what you'd use the "saved" memory for. Also, when you buy a resource like RAM or CPU as a package, nominal values matter less than under what conditions one of these would reach 100% and your experience may be degraded.
For example, if you have 16GB of RAM and you only ever run one program at a time, it doesn't matter to you at all if it uses 3GB or 3MB: you've paid for 16 and the total savings of the 3MB app are zero and in this hypothetical case, there's no tradeoff at all. Now, the average user on the average hardware doesn't use only one GUI app at a time, but they're also not using 200. The only relevant question pertaining to waste is what is the value of 3% memory to your users (integrated over all of them)? In many situations (again, not all), the answer is not much. (And BTW, some developers seem to care about 3% memory more than they do about 3% CPU, even though CPU is much more expensive).
When it comes to agent harnesses, the analysis is clearer. On the one hand, people using coding agents are more likely than others to put even a little extra free RAM to some good use, but on the other hand, the cost of using the models themselves is so high that it makes the cost of RAM for the GUI negligible.
Saying that a number going up by 1000% is bad is not good engineering. Good engineering requires thinking about the actual value and cost of that number. It varies over time, over app type, over different types of users, and over different kinds of deployments (i.e. how RAM is packaged and paid for).
The first use case is the very common one (for Java) where developers control deployment (internal deployment). The last basic building block, caching machine code, will be released next year in JDK 28, and then the feature is likely to evolve to better support other use cases, such as external deployment.
[1]: More precisely, the work they need to do doesn't scale linearly with the allocation rate as is the case with non-moving approaches. Of course, arenas are sort of degenerate moving collectors, so they also display the same effect, but they can't always be used.
The way this works is that you allocate in the young generation with a pointer bump, and to free memory you compact (move) the surviving objects, which make up a small minority, a few times and then promote (move) them to the old generation (where you either manage memory with the same technique or a different one). And so the total amount of moving is not high (objects either never move or rarely move), and what you end up with is essentially two heaps, one where the allocation rate may be high but you can completely negate all the extra work by increasing the size of that heap, and one where the allocation rate is low. This ability to, optionally, not double the amount of work when the allocation rate doubles is what gives moving collectors their efficiency (and that you can bump-allocate in virtually all cases).
Of course, it's possible to come up with programs where objects do move a lot (or there's some other common work), e.g. programs that don't exhibit the behaviour of the generational hypothesis, but the point is that in a very large class of programs, this technique is hard to compete with.
2. Heap allocation is a very common cause of serious performance problems in low-level programs because malloc/free overhead is so high. Some languages have a moving GC to reduce the high overhead of heap allocation, but low-level languages typically can't use that optimisation, so you have to resort to arenas (which offer a similar optimisation to that of moving collectors). This isn't always faster than malloc/free, but it usually is, and if you want malloc/free you can pick that.
Anyway, I wouldn't say that the default in Zig is to use an arena, rather it's to give you the control that's the whole purpose of low-level languages.
It's not those features, though! Obviously, a hoarder has everything, so anything you buy is something he has. We are adopting a small portion of the features that feature-rich languages have, which is exactly the difference between a more feature-rich language and a more minimal one.
> ...aaand there it is again. "The lesser languages".
Again? I haven't said "the lesser language" once, although you've now said it a few times as if quoting me. You're arguing with things I haven't said and then misquote me to completely change the meaning of what I actually wrote.
No one, on the Java team or outside it, considers Lisp, Smalltalk, and ML - the languages that inspired Java - "lesser" languages. They are, however, all less successful languages as a matter of fact. It is because they are not lesser but they are less successful that we selectively adopt a portion of their ideas but do not adopt their strategy.
It's not about snobbery, but basic business strategy. Suggesting that it's good business for a product to adopt the strategy of some competitor product doesn't make much sense when that other product is doing worse than your own. I mean, maybe it could be interesting if there were some other key element to the plan, but not on its own.
Almost every single feature in Java was inspired by (or sometimes copied from) a feature in a less successful language (although not always less successful at the time the feature was adopted), but Gosling was always very clear about copying good ideas into a product with a very different strategy (he thought it was the strategy that hindered those other products, not their ideas).
> When Java ends up adopting those features, suddenly it's "we accommodate a non-minority number of developers" and "we've been thinking about this since before Java was released".
No, we've also been thinking about features that may well probably never make it. I'm not even sure what you're trying to say, but you should know that anyone who works in language design has been familiar with type inference, generics, typed lambdas, pattern matching, and algebraic data types at least since the late eighties because ML has been the biggest single influence on language designers and other PL fans in the past couple of decades (ML was released in the early seventies, but it didn't become so influential right away).
> I'm glad it seems you're in the minority seeing how Java has picked up its development pace.
Java has picked up its development pace compared to the time we were involuntarily stagnant due to declining investment from our corporate overlords. As always, most of the development is in the runtime, as that has always been our strategy, and we all think it's a good one. I'm very happy that we can do more now than we could fifteen years ago, but the Java language won't become a (relatively) feature-rich language, even though it will continue to add features.
I said "strategy" not "feature". That adopting a feature that a less successful language had invented or adopted is not the same as adopting the strategy of a less successful language was precisely my point about buying a sofa not being the same as "catching up" to a hoarder.
I said "we shouldn't be a hoarder", not "we shouldn't get a sofa".
> Now you're suddenly saying "we're aware that a non-tiny minority of developers prefer richer languages, and so we accommodate them, too" and "oh yes, we've been thinking of these features since 1991".
But Java started adopting ML features over twenty years ago. Where do you think we got generics from? The discussion about lambdas and generics between Gosling and Joy, even predating Java's release are Java lore (https://archive.computerhistory.org/resources/access/text/20...).
> Than whatever your ever-changing definition is. Java, thankfully, is no longer a small/smaller language, and is rapidly adopting actual useful features, including those from lesser products.
My definition isn't ever-changing, it's just relative. Being a relatively small language means, at the same time, not adopting the strategy of richer languages and adding select features but at a slower pace. This was Gosling's "a wolf in sheep's clothing" strategy since the very start: a very innovative, fast-moving runtime (where most of the benefits to the software's end user are hidden) wrapped in a non-threatening, conservative language. Conservative doesn't mean frozen and relatively small doesn't mean never-growing, but they do mean not adopting relatively rich fast-changing language strategy either. Our strategy has worked well for us, and yes, I still think it's silly to suggest we should change it because languages that aren't doing as well have a different strategy.
Even Java's GC and JIT came from Lisp and Smalltalk, but not the strategy (which was Gosling's point that these helpful features were part of thretening products).
> but anyone who cares about new features like pattern matching was already on Kotlin a long time ago.
First, that doesn't mean it's not a minority of people. And by the way, we don't base our decision on which language feature to include on the number of people who are already asking for a feature (which is always a small minority) but on the number of people we believe will be significantly helped by a feature once they learn about it. I.e. it is perfectly possible that 100% of the people who wanted pattern matching before we added it had left for Kotlin or Scala and at the same time that number amounts to only 10% of the people who enjoy the feature and benefit from it in Java. That many mainstream languages add a feature is only a signal to us that the median developer is ready for it if we decide it's a good feature to add. I've been using pattern matching since the late nineties when I first learnt ML and a bit of Haskell (Haskell was the language of the future back then), but if I were a language designer back then, I'm not sure I would have thought that it's a feature a mainstream language should have prioritised in 1998.
Second, we don't have usage telemetry in the JDK so we don't get a full picture, and instead we rely on the usual sources for this kind of information: meeting with large customers and analyst reports. If you have access to more comprehensive statistical data, then I would be interested in seeing it, but it's a well-known phenomenon that people are usually only directly exposed to information about their own circles and don't have industry-wide data. The Java ecosystem is huge, and like the situation with the software industry in general and enterprise software in particular, most Java software isn't even written by software companies.
BTW, SGCL is a non-moving mark-and-sweep collector and non-moving collectors are no more similar to moving collectors than malloc/free is similar to moving collectors. Garbage collection contains different classes of algorithms with different goals that are so different from one another that it's almost pointless to put them in the same category. Java uses moving collectors because it's the class of algorithms designed to reduce the throughput overhead of all non-moving approaches (from manual malloc/free, through automatic RAII and refcounting GC, through tracing mark-and-sweep collectors like SGCL or Go's GC). In important ways, all non-moving approaches are more similar to each other (regardless of the use of a GC) than any of them are to moving approaches. (Java did have a concurrent mark-and-sweep collector at one time, but we removed it some years ago)
Except it wasn't, because adopting ML features, especially lambdas and generics, were discussed in the Java team even before Java was released.
Also, the "accelerated pace" is only compared to a dry spell where development stagnated not by choice but by Sun's problems. We had a pace we liked, then we were forced to slow down, and now we're back to the pace we like again.
Also, it has always been a stated strategy to focus on innovation more in the runtime than in the language (Gosling called it "a wolf in sheep's clothing"). Java has always aimed to innovate in compiler technology, garbage collection, and telemetry as fast as it could, and we innovate faster than most in these areas.
> And Java is no longer a smaller language.
No longer smaller than what? We aim to keep the language relatively small, i.e. smaller than mainstream languages that are more eager to add features. So Java is bigger than Go, but it's smaller than C# or Kotlin or Rust, and is roughly comparable to TS or Swift in its "size".
I disagree for an obvious reason: only a small minority of Java developers know Kotlin. When we want to see if the median developer is ready for some ML feature, we certainly look at other languages, but Kotlin doesn't matter beyond its size (which is not inconsiderable, but is also nowhere near the largest Java competitor that's quick to adopt features).
> Of course, java has had the advantage of enhancing the jvm while adding the features, where Kotlin had to work around the jvm in some cases (like green threads vs coroutines).
And C# could have done the same as Java but instead did what Kotlin did (or, rather, Kotlin did what C# had done), and we looked at both and said: we don't want that. That's why I'm saying that the "catching up" narrative doesn't hold up to any scrutiny.
Obviously, Java has been a huge innovator in optimising compilers, garbage collection, and low-overhead telemetry — areas where it's ahead of virtually everyone else — and focusing innovation on the runtime rather than the language has been one of James Gosling's stated goals since the beginning. So catching up is also silly when talking about a technological leader.
> But I feel it's wrong to downplay Kotlin's role in modernizing things on the jvm.
I'm neither downplaying nor overplaying it. As one of the Java architects, I'm telling you what it is. And "modernising things" on the Java Platform ecosystem is quite a different thing from influencing Java language features.
When we discuss other languages, and we discuss all of them, the ones that are discussed more are either the bigger ones or the more novel ones. Kotlin has shown some novelty, especially around its design of generics and of nullability types, but these happen to be two areas where we have actually not (yet?) made changes.
> Heck, if it weren't for kotlin as a temporary stopgap, I'd probably would've left the jvm while the features were still lacking in java.
That may be true, but it's irrelevant to what we're discussing. If anything, if Kotlin had served as a significant enough stopgap for those developers who prefer richer languages, it would have helped us not to adopt certain features or to adopt them more slowly.
I'm not saying Kotlin hasn't had a positive influence on the platform and, indeed, it may have helped especially in those years when Java stagnated, but it didn't push Java toward adopting more ML features.
BTW, even if you're not aware of ML's extraordinary influence on most programming languages, surely you're aware there are competitors to Java with analogous features that are far bigger than Kotlin.
As for string templates, our intent is not to have a feature simiar to what Kotlin offers. We obviously look at all languages regardless of popularity, but in that case, as we did in the case of virtual threads or records, we'll probably say, no, that's not what we want, to Kotlin's approach (even the Preview that we pulled was nothing like Kotlin's approach).
> I'm sure there's tech-debt and esoteric compatibility concerns which make evolving Java hard
Backward compatibility is rarely a hindrance at all. People just talk about it a lot because most organisations consistently say that backward compatibility is much more important to them than any language feature, but it's not all that hard to maintain.
> but from a developer's perspective it's just glacial to evolve and the result is weaksauce.
I find that statement hard to reconcile with the fact that the only languages as popular as Java or more are JS/TS and Python, while all the languages that are not "weaksauce" from "a developer's perspective" are doing far, far worse than Java. There has never, ever, been any sort of consensus among developers on the right set of features, and there have always been developers who prefer more features and those who prefer less. It's perfectly fine to be on one side or the other or even to say, "yes, I'm in the minority, but I still think I'm right", but I find it strange to claim to represent "the developer's perspective" when your preferences are mostly associated with languages that are doing worse rather than better.
But if in 2026 Java is the third or second most popular language in the world overall and the #1 choice large applications that are both performance-sensitive and need to be maintainable, but is it possible that in 20 years, despite our best efforts, Java will decline sharply, perhaps even to the point of being only as popular as, say, Go is today? Sure.
If you like a richer language, the Java platform offers you options, but many people prefer smaller languages (the number of Java Platform developers who use the Java language has remained pretty much at a constant ~90% for the past 15 or more years), but we're aware that a non-tiny minority of developers prefer richer languages, and so we accommodate them, too. Either way, 95% of the JDK is runtime (standard library and the JVM) and tooling, and you'll enjoy it regardless of which frontend language you prefer.
> The AI can just write in rust if you need to optimise a hot loop
Why would it when it could just write it in Java? The JVM was invented not because we couldn't write code in C++ but, among other things, to optimise things (especially around memory management and inlining) that low-level languages have trouble optimising in a large class of applications. If you're after the best performance, then you'll ask AI to use a low-level language when a low-level language offers better performance, and to use Java for applications when Java offers better performance.
People who think low-level languages always offer better performance are people who have not had much experience with low-level languages. I originally came to Java from C++ because Java has optimisation opportunities that low-level languages don't (they have to compromise on performance in some situations for the sake of low-level control) that matter in certain but very common kinds of programs.
> zgc is a lot better for pauses
It has no real GC pauses. It does have minuscule pauses for synchronisations, but those are an optimisation, and they're no worse than OS jitter. In other words, if ZGC's pauses are a problem for you, then you won't use a non-realtime kernel, as you'll get similar pauses even in a C program on the same OS.
> I'd still say that it pulls along a fair bit of incidental complexity - it encourages you to allocate a fair amount of memory to your heap, which isn't ideal in this world of kubernetes and microservices.
It really doesn't. All of our GCs are optimised for a natural rate of allocation. They do discourage pooling objects to artificially reduce allocation rates, though, but it's easier to not pool than to pool.
> If you leave on uncommit (returning memory to he OS periodically) you get extra latency penalties which are just as painful as garbage collection stalls IMHO.
You get such stalls and worse with C++ or any other low-level language.
> Contrast it to Elixir on the BEAM;
Java is in the same performance class as C++. BEAM is wonderful in its own way, but it's not even in the same performance class as Go.
BEAM was designed for some interesting resilience in distributed systems. The JVM was designed to address the performance issues that programs in C++ and other low-level languages suffer from when they get large and/or are maintained/evolved for a long time.
> long pauses due to gc? They just don't happen - everything is isolated and can be cleaned up in parallel.
GC pauses in the JVM have been optional for a few years now. ZGC doesn't have GC pauses.
Java doesn't have this problem.
> As soon as you have something larger than the hardware atomic size (or unaligned in memory) you risk torn reads/writes. So a pointer + a size for example on some architectures (some hardware like x86 has a double word atomic support, but on embedded you usually only get up to word size atomics).
Well, the reading of a stale pointer alone could lead to UAF even without tearing.
> All this means that you can't (in a systems level language) feasibly make everything atomic and ensure no UB.
I didn't say no UB. I get that Rust decided to do something (no UB in the safe subset) and this is a consequence of that, but my point is that it's not obvious it's the best goal in the first place. Certain patterns are known to be the cause of a majority of vulnerabilities in C and C++, so it makes sense to sacrifice something to address them, but once you get to bugs that are no more common as vulnerabilities as many other bugs that Rust doesn't stop, saying we must stop these bugs and not others, even at the cost of requiring more programs to use the unsafe subset is one possible tradeoff but not a universally superior one.
Yes, that is true, but 1. that's not the same justification as for memory safety, and 2. that's a decision made by Rust, but it's not the only valid one (e.g. Zig has the "unordered" ordering, using LLVM's Java memory model support).
> In practice rust also tries to guide you towards patterns that reduces the risk of other bugs.
I understand that perspective, but let's say it's not hard to debate, and there's a clear difference between something that prevents a cause of a majority of vulnerabilities and something that prevents a small minority (while not preventing bigger causes).
> So I think that the multithreading approach in Rust is really good and what we want, not a hindrance. It is absolutely the right thing to do.
Well, it is absolutely what some people think is the right thing to do and also absolutely what others don't think is the right thing to do. It's an approach with both supporters and critics.
And I wasn't saying there's an actual slippery slope, only that the argument that if something is tricky it should be moved out of the safe subset is not a good one. The justification Rust uses to do this for memory safety is because memory safety was empirically found to be special, but that particular justification doesn't work for concurrency (nor is it the one used; again, in Rust this is a side-effect).