- The computer is plugged to an infinite source of unlimited power
This was big before the mobile era and is true to this day to an extent. Many mainstream languages created in the 1990s (I call them "the children of the 1990s") were designed with this fallacy plus the ones you listed as a basis: JavaScript, Python, Ruby, Java, etc.
Java is basically the "greenest" managed language out there, so not sure putting it into the same list for energy efficiency is warranted. Though of course energy efficiency is fundamentally linked to memory usage, not destructing/collecting dead objects will increase memory usage but increase efficiency.
Reading your link IMHO in today's world I would set a basic rule, if you're touching >20% of a Java codebase you should refactor to Rust. With AI-Native development practices it's worth the SDE time to refactor, replace the underlying subsytem and reduce your fleet by 50% or more.
Unless you are doing something very specific where rust is truly the best choice, I have to disagree.
Rust has overly strict locking (otherwise it couldn't determine safety) that makes certain concurrent algorithms harder to implement, its concurrency model is significantly more complex (for an absolutely good reason, it's a low-level language where the developer should be in control), meanwhile for many applications Java can just have you write ordinary blocking code and they will automagically turn into non-blocking.
For most domains Java has a richer "industry-strength" library ecosystem, and absolutely not even close observability tools. So not really sure what would one win for e.g. a typical backend service doing web and db requests.
JIT gives you almost native performance. AI rewriting tools give you none of the knowledge of running the thing in production. A couple of noticeable mishaps could cost more than halving your fleet saves.
Today even tiny CPUs are really fast. Locally you have to mess up badly to run into trouble. But of course people will do exactly that...
Most real world problems still can be solved with 32-bit software, so the last ~20 years running out of RAM always counted as "using defective hardware". AI workloads now make things interesting again, but it's not that easy to hit the ceiling with real world workload.
Cache is indeed very important. Optimisations like that are gone when you go for distributed computing. Sometimes adding a single nop can do wonders. I wonder how many percent of developers have something in their toolbox to profile for that.
I think there's a very different perspective on this between people old enough to have written assembly for 8 bit cpus like 6502 or Z80 often with well under 64kb of total system memory - compared to people who grew up in the age where the "starting coding" choices were something like "Angular or React?" and each browser tab could consume a GB or two of memory.
I'm not trying to say "greybeards are better" or "younger developers don't understand fundamentals" - it's more that the learned/ingrained abstractions those two types of developers start from are very very different. People who were familiar with concepts like the 6502's zero page where you get faster performance because you can use 8 bit addressing to access the first 256 _bytes_ of memory, end up with different mental tools and thinking than, say, people who started out their development learning about asynchronous callbacks and promises. One isn't better or worse than the other - but they are very very different.
(Even today's "tiny" CPUs are commonly 32 bit multi core SOCs. ESP32 kinda took over what used to be done with 8bit atmel Arduino class CPUs)
Arguably cache concerns are distributed computing concepts moving closer to the core. Same with concurrency semantics. These were far more exotic concepts when the fallacies were first written.
Very easy to hit the 3GB limit imposed by 32-bit architecture for any non trivial data processing app but luckily 64-bit is firmly established for at least 10 years
It's more niche but also underestimating the impact of using SIMD in places where it makes sense. Especially in higher level, interpreted programming languages where the overhead for each iteration is much larger than the few assembly instructions it would take to perform that iteration without vectorization in a low level language.
Chalmers’ claim is that the fact that it really exists and the fact that we can talk about it are unrelated and basically a coincidence, which I think is completely absurd… If you really believe in qualia IMO you have to bite the bullet and say that there must be physics that we don’t yet understand.
We're approaching the definition of magic here aren't we. And I think this is what really divides this discussion. There is one set of people who insist that things must be explainable. And if something is explainable, it yields to science and is no longer magic.
On the other side, you have people who insist that there are things which do not yield to science. So whether they admit it or not, they insist upon the existence of magic.
In fact, the definition of magic might as well be, that which does not yield to explanation. The only question once you believe in magic is, what alternative epistemology do you accept? Scripture? Tradition? Divine revelation?
Not at all. Saying that science does not yet explain some observed phenomenon is precisely how one starts to make scientific progress. Saying that qualia don’t exist because they are “magical” is like someone telling you lightning doesn’t exist before the understanding of electromagnetism.
> On the other side, you have people who insist that there are things which do not yield to science. So whether they admit it or not, they insist upon the existence of magic.
This is a really valuable framing for this sort of conversation.
We don't experience the sun going up and down, we experience its direction changing relative to the horizontal plane, and it is not an illusion: it matches planetary motion. The mistake arises when interpreting the raw experience. Sensations don't lie.
Another example: Metal feels colder than plastic, but the sensation is right again: you are loosing more heat when touching metal.
But the sensation in a sense is a lie. Cold strictly speaking isn't real. And for much of human existence we spoke of it as if it was a substance due exactly to this specific sensatation.
And to add to this, sensations do lie. We hear voices that aren't there, things feel hot when they're cold, we feel stationary when we're hurtling around the sun at high speed. Our bodies are not built to sense the truth of the world, only to survive in it. Sometimes those things coincide, sometimes not.
Bounded collections still allow for useless reachings of their bounds, and corresponding memory and CPU wastes (and possibly functional/domain issues).
The main reason I saw around me for memory leaks in GC'ed languages, is devs only thinking about the 'add' part, not the 'when-to-remove' part. I always think of both and the only leaks I got were from slowdowns causing events to pile up in scheduler queues (deliberately not bounded).
Before, not after: when the code makes it hard to implement a new feature (the definition of technical debt: code that is properly designed but only for previous features), first refactor the code to make the feature easy to implement, then implement the feature.
The greatest barrier to understanding is not lack of knowledge but incorrect knowledge. That's why good names matter. And naming things is hard, which is why it makes sense to comment on variable names in a review.
Unless the naming convention were written in the 90s and all variable must follow a precise algorithm to be made of only abbreviation and a maximum length of 15.
Or for some, if it contains the value of a column in the db, it must have the same name as the column.
So yeah, instead of "UsualQuantityOrder", you get "UslQtyOrd" or "I_U_Q_O"... And you must maintain the comments to explain what the field is supposed to contain.
As John Carmack said: "if a lot of operations are supposed to happen in a sequential fashion, their code should follow sequentially" (https://cbarrete.com/carmack.html).
A single method with a few lines is easy to read, like the processor reading a single cache line, while having to jump around between methods is distracting and slow, like the processor having to read various RAM locations.
Depending on the language you can also have very good reasons to have many lines, for example in Java a method can't return multiple primitive values, so if you want to stick to primitives for performances you inline it and use curly braces to limit the scope of its internals.
I can guarantee you that I have been doing just that for 20 years, creating and working on the same codebase, and that it only got better with time (cleaner code and more robust execution), though more complex because the domain itself did.
We would have been stuck in the accidental complexity of messy hacks and their buggy side effects if we had not continuously adapted and improved things.
In manufacturing there are economies of scale and adding more people increases workforce, in mindfacturing there are diseconomies of scale and adding more people increases confusion, yet many managers view software with a manufacturing mindset.
- The CPU is infinitely fast.
- RAM is infinite.
- CPU caches don't exist.
- Cache lines don't exist.
reply