Nice concept. One question: was the data generated by an LLM? Don't mean this in a snarky way. The Lichess entry links to a non-existent HN thread[1], and "Show HN: Lichess" does not appear in HN search results. I found a hit for a Lichess client written in Elisp[2]. At least I discovered a cool piece of software.
Yeah, that one and 3-4 others were generated by Claude for local development. Unfortuantely, I didn't vet every link it generated. I'll fix them up now.
Like the other poster said, the vast majority of games are either generated by users or the script.
Suggest in the future not using LLM for random/placeholder data. Obvious placeholders work better (they're obvious. Obviously. Word fatigue, anyone?). For paragraph data that needs to be wrapped eventually, either use lorem ipsum or whatever random chain of thought about what you're building.
Items that were found by "HN scraper" have working Show HN links. The rest for whatever reason have a non-working link. Probably more likely that the code was generated by LLM and is full of bugs.
For targeting advertising expendatures at the site level. If most of my traffic, as revealed by referrer links, comes from social-media-platform-foo and only a little from social-media-platform-bar, then I am likely to spend more on ads from foo than from bar. I'll grant that it is a noisy measure, but doesn't need to be about tracking a particular individual.
Businesses survived just fine before this. Do personalised ads earn more money? Maybe. But they're invasive and if the governments bowed down to the people instead of corporations they'd be just as illegal as stalking a potential customer to harass them when they're most likely to see you
In the case of Lean, propositions are encoded as dependent types and the user typically has to encode that themselves then make use of e.g. tactics to derive a term of said type.
Writing a statement you don't understand then later getting a proof from an LLM doesn't seem all that useless to me; in my mind, it could still be useful as exploration. Worst case scenario: you encoded a tautology and the LLM gave you a trivial proof. Best case scenario: the proposition ends up being a lemma for something you want to prove.
I do think there is a kernel of truth in what you've stated: if the user does not actually understand the statement of a proposition, then the proof is not very useful to them, since they don't know what the statement's truthiness implies. As someone who used to do mathematics, I still find immense value in vibe-coding away mundane computations, similar to what Lean's `simp` tactic already does, but much more broad.
The worst case is that you vibe code a theorem that reads:
False => P
Then you vibe code a proof of this theorem. Then you get excited that you’ve proven P.
Some of the X discussion that prompted the OP was quite close to this. There are screenshots on X of Lean code that doesn’t compile, with Lean being blamed.
Right, the risk is encoding a vacuously true statement. I consider "false implies Q" and tautologies to be vacuously true statements, since both are truths that fail to convey any meaningful information.
In any case, the worst case scenario is having a vacuously true statement. I picked tautologies as an example since that and statements about the empty set are the first things that come into my mind.
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.
[1] https://andrewgy8.github.io/hnarcade/games/games/lichess
[2] https://news.ycombinator.com/item?id=46779861
reply