delta_p_delta_x

> They’ve had decades to catch up already

No, they haven't. They spent the first decade after WW2 repairing the damage left behind by the Japanese and their Civil War. Subsequently they managed to starve tens of millions afterwards in several missteps, and then righted themselves.

They then spent three to four decades lifting about thrice the US population out of extreme abject poverty, and then in the last 20 years catching up. And catch up they have; they are already the leaders in green technology and EVs, already manufacture some of their own chips, already have indigenous military aerospace capability, which they are now expanding to civilian use. They make almost everything in the average household.

> A) He never made a single product himself

This is demonstrably untrue. Jensen is an engineer through and through, and contributed significantly to Nvidia's early accelerators: from the NV1, at least to the earliest GeForces.

> except scripting

PowerShell says hello :)

> C# is indeed the .NET darling but you can also use F# if you feel like living in the future. Or VB if you feel nostalgic

Or PowerShell if you want to hash out something really quick.

> Win32 APIs

Everything boils back down to Win32, including WPF, WinForms, WinUI2, and WinUI3.

> is a bit of a junior- to mid-level engineer tell in my eyes

There is absolutely no reason for Discord—a chat application—to run everything a browser does. Why do I need to play videos in the chat application? Why do individual avatars and even tags have to run custom shaders? It's called scope creep.

> a11y, IME, RTL

All of this can be done at the platform level. Win32 did this three decades ago. Comes with entire language packs.

> so you add a scripting layer, maybe integrate a little Lua VM or something that lets you execute JavaScript

See above: scope creep; features for features' sake.

I don't think we should just 're-vibe' it as you put it. Naturally the rewrite should be progressive and thoughtful, backed by test-driven development at all levels, and regression tests every step of the way. To reiterate: writing code used to be a lot more expensive, which justified foisting React, Electron, JS on everyone. No longer the case.

I've mentioned in another comment, but my biggest pet peeve is that AI agent applications (Claude, GPT, etc) are themselves just Electron wrappers over their web pages. What a waste.

Unironically, with LLMs, everyone should be looking to cut their system resource consumption (memory, disk, network, GPU, I/O traffic in general) and rewrite everything natively. Have a platform-independent business logic layer, and a platform-dependent UI/UX layer. Done. It's not even that hard, and has been done several times over; we quite literally have MVC/MVVM/etc that were invented two decades ago.

Operating systems developers should be looking to profile everything. Benchmarking and profiling used to be horribly time-consuming; nowadays, with agents, this is almost trivial. Then valuable engineer time can be spent looking at actually solving and optimising the workloads, from the kernel, to drivers, to user-mode libraries, to vendored applications.

About a decade ago programming was expensive, and we decided writing everything in JavaScript was OK, and wasted everyone's memory instead of using programmer time to write fast and efficient native applications. This is no longer the case.

> but they were all really just void* renamed

The good thing is that all of these can and have been quite neatly put into RAII[1] or some memory arena with custom deleters which use the Win32 functions. One could manually `delete` those handles, but there be dragons. Vulkan does something similar; everything is a VkSomething handle. They may just be pointers directly exposed by the driver, but even so, users are explicitly supposed to use vkDeleteSomething functions to delete them.

[1]: https://github.com/microsoft/wil

> an actual premium EV

Porsche Taycan.

WebOS and Android are broadly the same thing: custom user-mode applications and layers on top of a Linux kernel.

> Trains shouldn’t even be manually driven in 2026

Potentially, but the point is that signallers should physically be unable to allow trains to proceed, and drivers should physically not be able to override them. British signalling from the 1800s has physical interlocks; this isn't a matter of manual versus automatic train operation. It is clearly systemic.

> whether you could put a train from 1845 on a modern track

This quite literally happens all the time in the UK. There are heritage railways, and steam rolling stock regularly shows up on various routes as part of heritage rides.

On the other hand, I ride almost daily on a track bed that was laid almost 180 years ago, and through tunnels and on viaducts that are equally as old. The rails, sleepers, signals, and rolling stock have all changed, no doubt, but the base infrastructure is old hat.

The oldest bits of the London Underground are from 1863. The tunnels are exactly the same, the stations and stairways, and even some of the sign boards completely unchanged from then.

Railways are the epitome of forever infrastructure.

> Good luck finding g a C++ library using modules

There are, surprisingly, quite a few, including some very high-profile ones.

https://arewemodulesyet.org/projects/

Cheers; we try, but I wish we didn't have a memory crunch to get this effort going. I suspect at the end of all this we will have more memory-efficient code.

> try promoting Claude to profile

Oh, the irony. Claude is itself an Electron app and lags horribly.

At this point, all these agent apps—Claude, Copilot, ChatGPT—are just calling remote APIs. Why not train them on the native toolkits for each OS (Win32/WinUI3, Cocoa/SwiftUI, GTK, Qt, Jetpack Compose), and make the experience better for users?

The app data directory on Windows is quite literally a subdirectory of the user directory; `%APPDATA%` == `%USERPROFILE%\AppData\Roaming`.

> I will never understand paying $50 for a font.

I will never understand people who expect fonts for free. They don't grow on trees. Font development is extremely involved, and I am happy to die on this particular elitist hill: the overwhelming majority of free fonts are absolutely rubbish, including the Liberation family, which is available by default on most Linux distros.

Any font that is free and is still reasonably good is almost certainly designed by a type foundry for a megacorp's branding and user interface (so, things like SF Pro, Segoe UI, Open/Noto Sans, Roboto, JetBrains Mono, IBM Plex, Source Sans, Fira Sans, Inter, etc), or are historic properties of the type foundries themselves, like Garamond, Helvetica, Didot, Minion, etc.

ASCII isn't the only set of characters. Just the LGK (Latin, Greek, Cyrillic) set of glyphs alone including combining marks, diacritics, contextual alternates and ligatures alone amount to several thousand glyphs, each of which has to be individually tuned for different weights, hinted for different display resolutions, hinted for RGB/BGR subpixel rendering, and more.

> our software would be written to deal with that

I work at a place which offers a well-known operating system and also sells hardware which runs said OS. This is exactly what we have done, because the hardware releases this year have had to come with a quarter less memory. There is an internal effort to reduce memory consumption by a quarter at all levels of the platform, from the kernel, to the drivers and user-mode libraries, to the toolkits and user-mode applications. This has been remarkably successful.

The overall shape of the glyphs (excluding lowercase 'l', that is, 'ell', not 'eye') is that of Berkeley Mono.[1]

[1]: https://usgraphics.com/products/berkeley-mono

Most of the heavy elements beyond ruthenium or so were created by neutron star mergers rather than red giant or supernova nucleosynthesis[1]. It could be argued that this is technically fission, since neutron stars are, to a first order, giant atomic nuclei.

[1]: https://upload.wikimedia.org/wikipedia/commons/3/31/Nucleosy...

By 'impossible', I mean it in a very strict sense of blitting full-screen frames directly into the framebuffers provided by HDMI or (e)DP representing a visible surface. This is still kind of possible in Windows when games are properly full screen and not 'borderless full screen', but the OS still does compositing in the background, and the GPU is still involved to some extent.

Of course, offline rendering is a different story.

Indeed. I wrote up a commment[1] explaining why code editors needed graphics acceleration some months ago; this ties in to that.

[1]: https://news.ycombinator.com/item?id=44966266

Indeed. Personally I am quite old-school, I like MSAA (despite the performance hit) and subpixel morphological AA (SMAA, used to great effect in Crysis). DLSS is interesting but I cannot unsee the artifacts.

> If you mean that this style can be achieved with graphics hardware

I really ought to have been more specific with my first sentence to ward off any hair-splitting.

The author claimed to love software rendering, but the examples given to highlight the supposed positives of software rendering can all be achieved on GPUs. If the author had instead highlighted the ability to easily debug and inspect the inner workings of the rasterisation pipeline with a software renderer, that might have been a much more relevant argument.

I've mentioned this elsewhere, but nowadays, anything you see out of an HDMI/DP/eDP cable comes out of a GPU. Modern OSs make it impossible to do 'software rendering' any more; it's just that much faster and that much more efficient, even if it is harder to program directly. Even IPMI BMCs have a tiny GPU doing stuff.

This isn't software rendering, it's called turning off spatial anti-aliasing. You can still do that in the modernest of modern games. Software rendering went out of the window because the CPU tends to have other things to do whilst playing the game besides only multiplying 4x4 matrices, which was shifted to the shader cores of GPUs. The look-and-feel that the author is discussing including shadow and texture LUTs can also be done on GPUs by passing the tables in to shaders as constant read-only storage buffers; that is not specific to software rendering. It bears mentioning that many modern software renderers (LLVMpipe/Lavapipe, OpenSWR, WARP) are basically full D3D/OpenGL/Vulkan devices in their own right, including shader compilers.

Also, modern spatial anti-aliasing works by multisampling within a pixel (or even neighbouring pixels) and taking the average, rather than filtering across singly-sampled pixels, which massively reduces the quality. Not to mention temporal and machine learning AA techniques including DLSS, XeSS, FSR, and all the TAA implementations in many games.

Big company does big company things like cross-category marketing for a new product.

Fair response.

I singled it out because I've been badly burnt by it in the past, and I dislike how it works compared to Win32. Back-targeting old glibc from newer (a very common case because developers tend to have newer distros than their users), requires either changes in source code (not build code, which is where it ought to be) to explicitly pin versions, or the ridiculousness of firing up an entire Docker container just for old glibc. It has regularly caused issues for things like Steam on Linux.

There is not some arbitrary notion of wheel reinvention just for browsers. Calling browsers 'just browsers' is doing their feature set a huge disservice: they are bona fide operating systems or virtual machines, which have to load and run untrusted, unverified data and code within critical system libraries (many of which with kernel-mode access, such as GPU drivers, sound drivers, USB subsystems, and more), and do a huge amount of sandboxing to guard against escalations.

Within Google, a Chromium build uses remote build execution by default, upstream Clang by default (for the latest features and fixes, and Chromium developers regularly contribute to LLVM), and needs to cross-compile easily for at least a dozen different OS-architecture triples (Linux x86-64, Linux ARM, macOS, Windows x86-64, Windows on ARM, iOS, Android x86-64, Android ARM, Android TV, some BSDs, etc).

Everything you've listed—from ninja, to Clang, to libraries with custom patches, to Clang releases, including requiring pre-releases sometimes—is optimised for Google's scale, rather than the lone warrior developer. What you call 'sane Linux defaults' (especially the examples you have listed: GCC, automake, so-called 'system libraries') are highly antagonistic to all of the above.

They may make life easy for the so-called 'default case' of desktop Linux (arguable; Chromium was first released on Windows, and secondly since desktop Linux's most common C library, glibc has an unstable ABI, making back-portability impossible), but make it incredibly hard to get out a project of such immense complexity. All of Chromium's tooling and 'complexity' was developed in response to the 'sane' defaults being not so sane after all.

To get a GCC cross-compile for a given set of architecture triples, one needs a complete graph of GCC toolchains targeting every pair of host and target. On the other hand Clang is natively a cross-compiler; pass in `--sysroot` and the host compiler will redirect for the target instantly. Automake (and the autotools in general) is slow as molasses compared to ninja. It is based on computing and compilation from the 1970s, and their defaults probe for long-since-dead string comparison functions that are expected to work by default nowadays on most hosted systems. Not to mention it has an extraordinarily complicated configure step[1], and an equally appalling macro-based configure language.

Ninja is purely declarative, and is not even meant to be human-readable, as it is a back-end for a variety of build generator tools (CMake, XMake, build2, Bazel (Blaze internally at Google), Meson, probably more). Google have in fact rewritten Ninja to be a remote-build-capable tool from the outset[2], and they call it Siso. Siso has more than halved my Android build times even compared to Ninja because of its incredible use of RBE.

Frankly I think it should be evident why they have opted for 'rewriting the world' including vendoring and modifying system libraries, as well as including efforts like Skia, ANGLE, and more: directly relying on 'system libraries' is painful. I mentioned GPU drivers. Imagine rewriting the same code over and over to have precisely the same behaviour on D3D, Vulkan, OpenGL, Metal, and every single vendor GPU driver on every single system (and there are a lot more on mobile than on desktop: ARM Mali, Qualcomm Adreno, Samsung Xclipse, Imagination PowerVR, Huawei, MediaTek; this is not even close to exhaustive, just look at the Khronos vendor list).

When comments like yours are made I wonder if there is ever a consideration beyond 'it makes the developer's life hard'. As developers, our ultimate target audience are the users of our software. We should be willing to do anything come hell or high water, even making the dev-ex extraordinarily convoluted, if it means the user experience will be the smoothest and fastest possible. Sure, there is a balance, but I believe it should be strongly skewed towards the user story first.

[1]: https://upload.wikimedia.org/wikipedia/commons/8/84/Autoconf...

[2]: https://chromium.googlesource.com/build/+/refs/heads/main/si...

> Have a universal Path env var that isn't tied to a specific shell

This sounds like Windows. ;)

Environment variables are stored in the registry; for the user, it's

  HKCU\Environment

and for system-wide env vars, it's

  HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment