winwang
winwang on Hacker News
I'm not suggesting anything like "rewrite in Rust", at least not in general. I'm simply poking at the fact that use-after-free (and other such issues) are effectively deprecated classes of bugs.
It's okay guys, the authors simply don't know how to write good C. A real C programmer would not have shipped such a basic use-after-free bug. Rust is just a crutch.
It's because the cache comes from the prefix. `f(f(f(A,B),C),D)` is quite different from `f(f(A,B),D)`.
That may be a not-terrible idea (possibly even great idea), though it's not quite the base language I'm looking for. Maybe I need to just experience it more.
I find that frontier AI is very good at understanding new syntax/semantics, for whatever reason. But that's moreso "why is it not just a huge waste immediately".
I want a new language because current GPU (and really, parallel programming) languages are just not it. Also, I think we'd be better off if it weren't just CUDA dominating the developer experience.
Moreover, I feel that we should be embracing advanced type systems with AI. The past couple decades have shown that people do want advanced typing even without AI. And now we have stuff like "Lean is faster than Rust" (https://kim-em.github.io/blog/2026-7-24-why-lean-is-faster-t...).
Programming is hard. Programming when you can't just rely on the classic RAM model is harder. Parallel programming at scale on vector processors with small amounts of cache (and slow cache at that) is even harder. We can do better. Rust has already shown this for normal systems programming.
I disagree. There are things which are very annoying outside of core ideas or otherwise take a lot of time. Too much time and energy to justify normally. Personal example:
https://github.com/wiwa/gpu-typingTypechecking with my own algorithm. Simple enough to specify in Python. Annoying with much boilerplate in CUDA. Similarly annoying to test.
I've been thinking about building a GPGPU language, but it's definitely going to take a while, even with AI. AI, unfortunately(??), cannot replace taste at the moment, and generally cannot unless it becomes a lot more disagreeable.
Taste is disagreeable.
Maybe Claude should not let me build a two-level type theory with just a "You're absolutely right!". In fact, now it will say "You're absolutely right, and it would be so amazing to use cubical types for blah blah", and adamantly defend it with several paragraphs of vomit.
Why would I assume it would be credible? Instead, I simply proposed some designs and had it find out if such hardware existed / was feasible.
I remember chatting with about AI a few months ago about the issue of foreign RAM sticks being able to cooperate with websites to serve different files/instructions, undetectably. Scary stuff.
Lol, this feels like it would otherwise be a good thing, out of context.
It depends on what you're doing to the integers. You still cannot comparison-sort arbitrarily large integers in linear time.
Also, consider this: it would have been trivial to get a so-called "better bound" on FFT if such a "cheat" were what people allowed.
The idea that FFT's decomposition is non-optimal is surprising. What the new bound means is we basically were looking at the problem and its structure incorrectly, and therefore implicates other problems for which we have used recursion to get to our currently-best bounds.
Almost no interesting math problems are just sitting there alone in their little corner. Getting a hint like that is a big deal.
I find it highly ironic that many people here seem to believe mathematicians should just accept LLM proofs, but software projects shouldn't accept LLM code.
Why would anybody need more than `268 435 456 ^ 62` KB of RAM?
Good point, I think a better way to have said it would be something like: to almost everyone, there's some music or graphic which resonates with them emotionally, and this has been true for thousands of years. There are very few such admirers for code, which has also only existed for a few decades. Perhaps worse is that it is mainly a profession for even most programmers, and not something they automatically see as expression.
"making a butt print in my office chair can be art." -- There were literally butt prints displayed at the Whitney a couple months ago. Just because it's in resin, so what? If I have fun making butt prints on my chair, is that worse because I didn't seal the form?
Yep, and that's fine. I just think that for the people who do treat something as art, that I'd want to respect their opinion and emotions. Photography was not art, and now is.
Whatever moves people, however people wish to express themselves, whatever people find beautiful, all that is "art" to me. There's much which is art to others, perhaps, that I would not understand as art for myself.
I disagree. It's not just a logic puzzle. If I haven't communicated that to you, that's also my failure. I've written stories short and long as well. It's a different kind of art.
"Art is something done with the purpose of exploring emotions, aesthetic beauty, question societal norms, etc."
I apologize if my emotions and aesthetics are not communicated, but I can only say that they were there. As for societal norms, I doubt that "embedding digital logic in types" is a "norm" of the programming society.
And though it's an appeal to patterns, I will have to bring up the general repeated failure of humanity to recognize art.
Hmm. I had an issue once with numpy shape mismatch errors appearing after 18+ hours of computation. Frustrating, because it could be caught at compile time.
Later, I learned some typelevel programming (in Scala), and by encoding a digital (binary) adder and multiplier at the type level, I showed -- at least to myself -- it was possible to compute and check linear algebra shapes at compile time (without a compiler plugin). It was rather magical and funny to think that I just embedded basic digital logic in such a higher-abstraction world.
It was slow for the inputs I cared about, so I added some optimizations, like an if-statement at the type level, for example, so that it bit-shift for multiplying powers of 2 (multiplication for tensor products). The compile time difference being palpable was a testament to how "some 'ideas' are surprisingly close to others" (err, 'ideas' ~ 'numbers' in this case). There is a connection to the p-adic numbers here, courtesy of dyadics, and some connection to the more-natural "last-mile" problem.
It's not REST, maybe. But I felt it was magical.
Why? Is it because most programmers can get paid from a company and not most drawers or musicians? Is it that programmers don't give enough free code on Github, or that their PRs don't wax and wane about how beautiful they found their specific bugfix to be?
I am a programmer who likes aesthetics. I think about how aesthetic it is to not have to deal with certain production incidents for certain blocks of code because the typelevel computation tells me it would be a compiler bug if it screwed up. I like the feeling of realizing those 100 LOC could just be 10.
I sometimes tell people of when I came down from Mt. Fuji, there were wispy clouds and grand nature below me, picturesque like a painting. At that time, I likened it to the beauty I felt when I was first learning Haskell. But I say it because I expect it to be a rare kind of sentiment.
The thing with art and music is that they are easy to appreciate, and the appreciation grows deeper with more consideration. I love reading the placards in museums and attempting to understand why the artist did what they did, I like it more than even looking at the piece itself.
Code (and math, for that matter) is almost the same except for one key difference: they are not easy to appreciate without deliberate training, training which is often far to the side of anything most people need/want to deal with.
Strange. That's like saying no one cares about the technicals of art, just how they feel about looking at an image.
As a consumer of graphics and music, let me "agree" for just a moment. I might not care how the music or image came to me. I just care that I like the final product. Which is why most paintings are trash, because I prefer highly saturated colors.
...I suppose this is somewhat true of many people already.
*For now. If a company were to degrade something, it shouldn't be so obvious that the "goodwill" was just a reallocation. Just a good strategy. For example, it allows them to claim that they're "just going from 150% to 125% usage allowance, which is still more than 100%".
It seems normal to talk about 4% perf increases for compiler releases.
Love it. Unfortunately, for some benchmarks, it can be bit difficult to get representative inputs which take hundreds of milliseconds. I'm curious as to why the author doesn't loop 1-10ms inputs to deal with variance? Which also deals with startup costs. Rust microbench harnesses were already good at this stuff-out of-the-box (run-to-run variance, etc) several years ago.
Depends on what you're doing. For example, I'm having one chat extend/optimize a (mildly-novel) CUDA program. Opus 5.5 (high/xhigh) is very efficient, but a single thread would still cost me the Pro plan usage in ~2 days (less if I were just running it unattended). This is one mostly-bounded program, and it's not even that large.
In fact, before 5.5, I would have just used Fable instead.
I find it much stranger to believe that having/not-having the code would mean anything about consciousness.
While this is an interesting point, I'd say that this is also true of a human brain.