To add to the author's list of examples, the regex test site Regex 101 (http://regex101.com/) relies on WebAssembly. To verify this in Firefox, you can set javascript.options.wasm to false, and you will be instructed to use a browser supporting WebAssembly.
If you're willing to risk some safety guarantees, then you can embed SQLite in Go without cgo by using WASM builds of SQLite. In particular, this package: https://github.com/ncruces/go-sqlite3
Note: the risk here is that it's unclear how well-tested SQLite WASM builds are compared to native builds for things like data integrity. With that said, in most of my personal projects using Go, I frequently reach for the WASM builds because it keeps builds fast and easy.
Also, I want to mention that I have seen web apps that are C# / Blazor programs compiled into WebAssembly. The accessibility is predictably terrible, but I have seen at least one such web app in the wild. I assume this is largely why one doesn't encounter WASM web frameworks often. In any case, WASM is surprisingly useful in many niches, and that's kind of the problem for WASM's visibility: the niches where I find WASM useful are almost completely disjoint from each other. But it's a solid technology nowadays. The only real gripe I have is the fact that only wasmtime seems to fully support wasm32-wasip2. You can actually compile quite a lot of Rust backend stuff into WASM and run that instead of a container. Not that this is particularly useful, but I've found it interesting as an exercise.
It's a Chinese character and there are two variants. The left-hand variant (卍) represents 和 (peace) in religious contexts, whereas the right-hand variant represents 力 (power). The specific glyph the Nazis co-opted is the right-hand variant, and it is considered inappropriate to use in the West (for this reason, I am not reproducing the character here).
The glyph appears in texts predating the existence of Nazi Germany, and I assume that is the reason the Unicode Consortium has not removed the glyph yet.
Note that I am not defending this decision (nor the usage of the glyph today). One could argue that historians should use a special font that can render these two glyphs, but the problem is likely a lot more subtle than I am thinking.
As an aside: the left-hand variant is used in Japanese maps to mark the location of Buddhist temples.
> Note that I am not defending this decision (nor the usage of the glyph today). One could argue that historians should use a special font that can render these two glyphs, but the problem is likely a lot more subtle than I am thinking.
Having a deliberate policy of granting bad people permanent sole ownership of whatever symbols they use seems less than ideal.
I used to be a daily Emacs user (both at work and for personal projects). Since trying out Zed a little over a year ago, now I only use Emacs for Magit and the occasional IRC message through the built-in ERC client.
For VS Code users, there's actually a special feature where a subset of VS Code settings can be migrated to Zed settings. Cannot vouch for its stability, but the functionality is there.
Sorely missing a REPL for Lisp languages, but for statically-typed languages like Rust and TypeScript, Zed works pretty well. I appreciate that Zed works smoothly with Nix and Direnv, even through remote projects. I do wish the collaboration features would receive a bit more attention, though. It feels like that functionality has slowly been bitrotting, and it's always unfortunate when my friends on Linux cannot share their screen. Then there's other little regressions, like the audio bit depth being incorrect on MacBooks connected to external monitors -- they did fix this with the experimental Rodio backend, but I am not sure if that is stabilized yet.
However, AI-related features are fairly stable and it's amazing how far it has come in less than a year. That and things like the debugger UI.
The perfect square year is now over...next one is 2116. Silly thing to note, but I am thankful for being able to live in such a year. Additionally, 2025 was quite transformative to my life. Where I am today, in terms of career and personal connections, I wouldn't have expected to be here even two years ago.
This is what I find a bit alarming, too. My M3 Max MacBook Pro takes 2 full seconds to boot Slack, a program that used to literally be an IRC client. Many people still believe client-side compute is cheap and worrying about it is premature optimization.
Of course, some performance-focused software (e.g. Zed) does start near-instantly on my MacBook, and it makes other software feel sluggish in comparison. But this is the exception, not the rule.
Even as specs regress, I don't think most people in software will care about performance. In my experience, product managers never act on the occasional "[X part of an app] feels clunky" feedback from clients. I don't expect that to change in the near future.
Software has an unfortunate attribute (compared to hardware) where it's largely bound by what users will tolerate as opposed to what practically is possible.
Imagine Ford, upon the invention of push-button climate controls, just layered those buttons on top of the legacy sliders, using arms and actuators so pressing "Heat Up" moved an actuating arm that moved that underlying legacy "Heat" slider up. Then when touch screens came about, they just put a tablet over those buttons (which are already over the sliders), so selecting "Heat Up" fired a solenoid that pressed the "Heat Up" button that moved the arm to slide the "Heat Up" slider.
Ford, or anyone else doing hardware, would never implement this or it's analog, for a long obvious list of reasons.
But in software? That's just Thursday. Hence software has seemed stuck in time for 30 years while processing speed has done 10,000x. No need to redesign the whole system, just type out a few lines of "actuating arm" code.
Love seeing the custom HN theme every year. Sometimes after Christmas, I avoid refreshing an HN tab, so I get to see the theme just a little bit longer :)
This year is a bit special to me. I recently moved countries for a new job, but I moved a bit too soon. Now I am spending the holiday season alone for the first time in my life. Learned a lot of lessons the hard way over the past week.
Yeah, I'm aware of extensions like Stylus and use it on a few sites. But my brain is irrational and doesn't treat it the same as having a snapshot of HN during Christmas.
I was a bit eager to start work after three months of waiting for the HSP 1b visa. Tried to keep myself busy with side projects, and got quite far with embedded Rust. But the lack of a "regular schedule" from a job was making me eager to start "proper work" again.
So far, it has been a mixed bag of trade-offs. Made it in time for various events, got to see a few friends for the first time in a while, etc. However, nothing beats the comfort and security of one's parents home, especially during the holiday season.
Probably obvious to everybody, but seriously do not schedule a move in December. If it is feasible, spend the time to make memories with your family and loved ones.
> nothing beats the comfort and security of one's parents home, especially during the holiday season.
A bit morbid, but reminds me of this passage by John Quincy Adams:
> Everything about the house is the same. I was not fully sensible of the change till I entered his bedchamber [...] That moment was inexpressibly painful, and struck me as if it had been an arrow to my heart. My father and mother have departed. The charm which has always made this house to me an abode of enchantment is dissolved; and yet my attachment to it, and to the whole region around, is stronger than I ever felt it before.
Hope you get to spend the next Christmas with your family!
This reminds me of a story where an OCR error[1] likely contaminated training data (and the English language) with the term "vegetative electron microscopy". The article I linked also shows that some journals defended the legitimacy of the terminology.
I'm not sure if this class of error really counts as a hallucination, but it nonetheless has similar consequences when people fail to validate model outputs.
I think the same will happen over time with the AI voice over slop that people don't bother correcting. These include weird pronunciations, missing punctuation that leads to weirdly intonated run-on sentences, pronounced abbreviations like "ickbmm" instead of "icbm", or the opposite, "kay emm ess" instead of "kilometers" and so on.
Bun disables post-install scripts by default and one can explicitly opt-in to trusting dependencies in the package.json file. One can also delay installing updated dependencies through keys like `minimumReleaseAge`. Bun is a drop-in replacement for the npm CLI and, unlike pnpm, has goals beyond performance and storage efficiency.
> I don't think I've ever seen a crate or production codebase that documents infallibility of every single slice access.
The smoltcp crate typically uses runtime checks to ensure slice accesses made by the library do not cause a panic. It's not exactly equivalent to GP's assertion, since it doesn't cover "every single slice access", but it at least covers slice accesses triggered by the library's public API. (i.e. none of the public API functions should cause a panic, assuming that the runtime validation after the most recent mutation succeeds).
I think this goes against the Rust goals in terms of performance. Good for safe code, of course, but usually Rust users like to have compile time safety to making runtime safety checks unnecessary.
If you're willing to risk some safety guarantees, then you can embed SQLite in Go without cgo by using WASM builds of SQLite. In particular, this package: https://github.com/ncruces/go-sqlite3
Note: the risk here is that it's unclear how well-tested SQLite WASM builds are compared to native builds for things like data integrity. With that said, in most of my personal projects using Go, I frequently reach for the WASM builds because it keeps builds fast and easy.
Also, I want to mention that I have seen web apps that are C# / Blazor programs compiled into WebAssembly. The accessibility is predictably terrible, but I have seen at least one such web app in the wild. I assume this is largely why one doesn't encounter WASM web frameworks often. In any case, WASM is surprisingly useful in many niches, and that's kind of the problem for WASM's visibility: the niches where I find WASM useful are almost completely disjoint from each other. But it's a solid technology nowadays. The only real gripe I have is the fact that only wasmtime seems to fully support wasm32-wasip2. You can actually compile quite a lot of Rust backend stuff into WASM and run that instead of a container. Not that this is particularly useful, but I've found it interesting as an exercise.
reply