Not quite, because "the quiet part" is that space-based datacenters, space exploration, Mars colonization, asteroid mining, and all the rest are just a smokescreen for the rapid and thorough militarization of Earth's orbit. It's a play for global domination through the ultimate air superiority.
The money they make from MacOS is a footnote compared to the money they make from phone hardware, the app store transaction tax, and ads. To a first approximation, the only reason that Apple cares about MacOS is so that people can make iOS apps.
This is a poor approximation, as there would be no need for such an extensive Mac product lineup if this were true. The Mac mini and one laptop product line with two or three sizes would be more than sufficient, and continuing development of first-party Mac applications like Logic and FCP would serve little purpose.
Fortunately for gamers, Rust doesn't do anything to stop physics engines from going haywire or preventing players from clipping out of bounds. A Mario 64 written in Rust still has parallel universes (well, assuming that you carefully translated the out-of-range float-to-short cast as having modulo semantics, an operation which doesn't have any defined semantics in C).
C doesn't bounds check arrays. A C compiler is perfectly capable of producing the same machine code as an assembler when given a loop that writes bytes to an array and then keeps writing beyond the space allocated for the array.
Missingno wasn't the result of an array overrun, it was due to data in a set of registers (which had temporarily been used to store a string) being arbitrarily reinterpreted as structured data governing which pokemon were allowed to be encountered. It more closely resembles a compiler miscompilation than a typical logic bug that you'd encounter in a C program. An idiomatic C implementation of Pokemon Red/Blue (ignoring hardware limitations, which is of course why it was written in assembly in the first place) would have used a static array to hold the per-area pokemon encounter table, and would have used a global variable to hold the index into this array representing the player's currently-loaded encounter zone; at no point would the static encounter array have been overwritten by a string temporary (which, in our C implementation, is just a function local variable on the stack), and at no point would the global location index be overwritten with garbage, because just like in the original game it only gets updated when we load a zone where wild pokemon can be encountered (which means that surfing on the side of Cinnabar Island would result in encounters drawing from whatever encounter zone we had most recently visited).
> Most modern processors (if we ignore x86) support some form of sticky arithmetic flags. Unfortunately, programming languages don’t support them, so they aren’t used.
I'd say the reason that programming languages don't have built-in support for checking the CPU's sticky status flags is precisely because of a lack of x86 support. Plenty of languages do have support for checking overflow on each individual operation, e.g. Rust's `overflowing_foo` methods, which return a tuple whose second member is a boolean indicating overflow: https://doc.rust-lang.org/std/primitive.i32.html#method.over...
Sticky flags tend to be really annoying for a compiler to support for various reasons, but principally it makes every operation have a hidden dependency to shared global state that is almost never read. Note that IEEE 754 standardized support for sticky flags 40 years ago, but support for these sticky bits is still poor to nonexistent in most programming languages, and sticky bit stuff for floating-point operations is less problematic than integer operations because FP math is already far more black box in practice.
No, the reverse. Mozilla opposed Google's original attempt to push JPEG XL years ago, and declined to ship without an implementation that they could confidently say was safe. See https://hacks.mozilla.org/2026/08/intent-to-ship-jpeg-xl/ :
"We added experimental support for JPEG XL behind a flag back in 2021. But, at 100,000 lines of multithreaded C++, we were concerned about the attack surface this added to Firefox. So, we laid down a challenge to the JPEG XL team at Google Research: Build a safe, performant, compact, and compatible JPEG XL decoder in Rust, and we’ll ship it. That challenge was met; Google Research built jxl-rs, and it’s the core of our JPEG XL support in Firefox."
Years ago, both Chrome and Firefox had experimental support. In October 2022, Chrome suddenly announced their decision to drop it (citing dubious reasons like lack of interest or improvements over existing formats). [1] It was only later, in January 2023, that Mozilla announced their formal position of not really caring about the format. [2]
In October 2023, one of the JPEG XL devs said that the responsible team at Google was ready to write a decoder in Rust if that was the only reason holding adoption back, even offering to work on browser integration. [3] One month later, another dev confirmed that a different pre-existing decoder written in Rust was already standard-conformant. [4]
It wasn’t until September 2024, nearly a whole year later, that Mozilla changed their official position from not caring to waiting for a suitable decoder written in Rust. [5] And it was only then that jxl-rs development really picked up. [6] Only later on, Chrome decided to change their position as well, but we can only speculate on what actually changed their mind.
There was no Google shoving JPEG XL down everyone’s throat like they once did with WebP. There was no Mozilla taking a clear, principled stance from the get-go. Whether or not JPEG XL was worth it, neither of these companies has acted in a transparently fair, exemplary way. And of course the first major browser to ship JPEG XL support to users was Safari, which may well have played a role in the others’ decision-making.
Firefox did not take very long to support AVIF (another recent image format clearly favoured by Google). Please do correct me if I’m wrong, but I’m not aware of Mozilla expressing any reluctance over AVIF’s abysmal lossless performance or other shortcomings (some of which have been addressed since), or insisting on using a memory-safe decoder like they have for JPEG XL. Why the stark difference in treatment?
We may not be able to say for certain, but Google’s massive influence is by far the most plausible explanation I can think of. And if the first step in your decision making is looking at what Google is doing, then ‘following marching orders’ is suddenly not such a bad description. (One can argue that with 3 % market share they don’t have much choice, but that’s beside the point.)
Mozilla was a founding member of the Alliance for Open Media, having sponsored Xiph to create Daala, which was later polymerized with Google's VP10 to create AV1. Mozilla has a vested interested in pushing all things related to AV1, including AVIF. That has nothing to do with Google's favor and everything to do with Mozilla's favor. Their hope was to use the existence of AVIF as leverage to give hardware vendors more incentive to provide hardware support for AV1.
> Mozilla has a vested interested in pushing all things related to AV1, including AVIF.
Why? AV1 was developed as a video codec. That doesn’t imply it’s as good of an image format nor that everyone who supported its development has vested interest in making it into one. Just because someone has made a cool hammer doesn’t imply they now need to view everything as nails. (This provenance even brings some drawbacks with it, yet this time seemingly no one took a pause before tossing in yet another image format.)
> Their hope was to use the existence of AVIF as leverage to give hardware vendors more incentive to provide hardware support for AV1.
This is the first time I’m reading about this and I’m having a hard time seeing how decoding images would make for a significant incentive to provide hardware support (especially when everyone was already more or less on board with AV1 as a video codec). But I could be wrong, of course. If you can provide any links where Mozilla gives this reason for adopting AVIF or any hardware vendor gives significant consideration to decoding AVIF in hardware, it would be much appreciated.
[2] was anticipatory obedience from Mozilla. Good for them that they grew a spine later (or more likely: they knew that Google will implement it some time later, so the change of opinion cost them nothing).
This is mental gymnastics. If Mozilla were following Google's orders we would not need to resort to phrases like "anticipatory obedience" to describe a neutral non-position; if they were following Google's orders, they would have simply endorsed it, end of story, and then they would have revoked that endorsement in lockstep with Google as well, which they didn't.
Again, when exactly has Google endorsed JPEG XL? When did they promise to ship it in Chrome stable? Sure, they had it in development as an experimental feature at first, but so did Firefox.
The way I read it, both companies were tentatively interested until Google said they changed their mind, and shortly after Mozilla decided they didn’t really care. Correlation doesn’t imply causality, but their positions followed a somewhat similar trajectory at the very least. (In contrast with, say, Apple.)
I just don’t see where you keep getting the idea that Google was at some point far more supportive of JPEG XL adoption than Mozilla was.
> I kinda thought something like this was already being done
It is. When building a crate, Cargo doesn't need to wait for all of that crate's dependencies to be completely finished compiling, instead it only needs to wait for each dependency to produce its metadata. The prototype here builds upon that existing machinery by causing metadata to be written earlier than it would otherwise be, prior to complete typechecking. It has the potential to increase the level of effective parallelism, so whether or not this has a benefit for a particular crate graph will depend on whether or not all of your cores are already effectively occupied during compilation or whether Cargo is letting cores lie idle while waiting on metadata to be produced.
Yes, if you mostly have no extra cores already or if you have very wide unrelated deps, this mostly does nothing. Typically, this is not the case though so there is some good perf gains.
Rust has been taking steps in this direction for several years now, having first added pipelining via eager metadata emission in 2019: https://internals.rust-lang.org/t/evaluating-pipelined-rustc... . There have been several other steps in this process since then, e.g. working to make metadata less verbose, experimenting with different approaches to compression, etc. People have been eyeing making pipelining even more eager for a while now, as the submitter here noted a few days ago: https://news.ycombinator.com/item?id=49924257 , but there remain some decisions to be made regarding what to do when encountering errors in crates that were speculatively approved.
If there's a project that takes 45 minutes to produce a debug build from scratch, that's not a Rust problem, that's a them problem.
Let's compare. I just checked out ripgrep and built it and all its dependencies from scratch. Total time to produce a debug build: 6.92 seconds. This is inside a 16GB VM on a random Linux laptop (on battery); no beefy hardware here.
Let's try something beefier. I just checked out uutils (an implementation of coreutils) and built it from scratch. Total time to produce debug builds, for eighty binaries and all their dependencies: 30.26 seconds.
Let's try something beefier. I just checked out Servo, an entire browser engine, and built it and all its dependencies from scratch. Total time to build and link its one-thousand one-hundred and ten compilation units (along with its infamously huge and serial servo-script bottleneck) into a binary: 4 minutes and 38 seconds.
If Codex takes 45 minutes to build from scratch, that's an indictment of OpenAI and their development processes.
Arguably it is a rust problem. Rust can be improved to reduce the need to do as much manual maintenance of crates dynamics to allow for faster build times. The "you're holding it wrong" answer is not a good perspective to apply and I am surprised to see a prominent member of the rust community using it.
No, one can write pathological code in any language. I welcome efforts to improve the performance of the Rust compiler, but nobody is served by optimizing for degenerate use cases to the detriment of legitimate use cases. It is, in fact, possible to hold it wrong; this isn't blithe dismissiveness, but rather an accurate statement of reality, and pretending otherwise doesn't lead to a better language.
I feel like there is an assumption here that solving the problems described will result in a worse outcome for the average rust user, but I'm not sure that's the case. Perhaps the existing way of compilation makes sense for release mode, but a different tact could be taken for compilation modes which are optimized for developer productivity.
I agree with the sentiment that you can't solve for everyone, but if a problem is prevelant in your userbase, it's worth optimizing for solving it. Not every tool will be used the way it was designed to be used.
Compilation times were a consideration, but they were a subservient consideration to the prime considerations of 1) being as memory-safe as GC'd languages, 2) exploring the limits of statically-guaranteed thread safety, and 3) being as fast and memory-efficient as C and C++. If Rust had been willing to compromise on those goals and instead had just, for example, used a virtual machine with pervasive garbage collection and been designed for dynamically-dispatched generics then you'd get a lot of compilation time reductions for free, but the world didn't need another Java, it needed a more secure systems language to stand up against C++ where every previous challenger had failed.
While it has found success on mainstream, it basically proven Cyclone ideas were right, and now we have other languages adopting similar ideas into their type systems, which helps closing the gap with 3).
Since the 2000's we have been on the wrong path, many developers kept reaching for C and C++, not because they needed the actual features of a systems programming language, rather they didn't knew anything else that would ahead of time compile to native code, or even if they did the mindshare wasn't relevant for them.
Now thankfully we are circling back to how it should have been all along.
However all of this might be meaningless in the age of AI driven programming, where developers have no clue if the agent is driving automatic or stick, while delivering on the Markdown file plan.
No, Rust is not at the paretto frontier for your mentioned 1, 2, 3 and also 4 compilation speed. It could have all of those things and also just have faster compilation. Rust devs have talked about how they have some regrets about not optimizing more for compilation, but instead another attribute got optimized in terms of paretto efficiency - the language's development time. Arguably I think that is the single worst trait you can optimize for in language development, because by saving a little time developing the language you cost humanity, let's say hundreds of millions of hours of development time downstream from you, with millions of users being less productive.
> It could have all of those things and also just have faster compilation.
Rust was originally a research language. It wasn't even clear that their primary three goals--"safe, concurrent, fast"--were simultaneously achievable to their desired degree. That it turned out to be possible was one of the most surprising and impactful results in the history of language design; even the early formulations of Rust assumed that both a garbage collector and a green thread runtime would be necessary, neither of which turned out to be true. That Rust could have faster compilation is both true and vacuous; there's always more optimizations to be eked out. The main question is whether or not significant performance wins could be gained by having made different, fundamentally-backwards-incompatible design decisions, and the answer is no, not really. Performance-related features like referentially-transparent procmacros can easily be made the default over an edition, and polymorphization can be implemented via an alloca-based virtual-dispatch ABI vis-a-vis Swift.
> Rust devs have talked about how they have some regrets about not optimizing more for compilation, but instead another attribute got optimized in terms of paretto efficiency - the language's development time.
No, the early Rust devs got this right. They were in fact highly incentivized to care about compiler performance, because rustc has been bootstrapped since 2011, making them the most serious users of the language in earnest (with the second-most serious users being the Servo devs one cubicle over). Rust spent years getting its basic design nailed down, then it did the hardest thing for any language: understanding the importance of shipping, resisting the urge to endlessly pursue perfection, and future-proofing what they could. Without shipping a useful language you can't get in the hands of users, and without getting in the hands of users you can't discover your most important flaws in practice. And because Rust shipped in 2015, it had ten years to hammer itself into shape to weather the agentic era; it could have easily still been on version 0.113 by now, puttering around in an ivory tower with no commitment to stability and no real users to give feedback.
reply