winwang

I'm not sure I'm arguing what you think I'm arguing. I'm not arguing against measurements. I'm saying that it's relevant to recall that honeymoon phases exist in the general human behavior, whether it applies here or not.

The force of convergence should almost make us care more about other languages, since the explosion of software is a multiplier on good/bad designs, and we should consider what we want our AIs to be using.

Or mathematicial progress helps advance society and AI mathematical velocity doesn't offset certain blows to human mathematical velocity yet, so we get to lose progress for the good of an AI company's advertisement.

Nice, I like this style of exposition. "Let's do this one thing -> well, shit -> (loop)". Term rewriting (graph reduction as you've said) is evaluation.

Complete anecdote, and nothing to do with relative nerfing or not: Opus 5.5 has been surprisingly good for me (including the past couple hours), especially for following research-level questions/directions.

That's a good observation, though I'd say here that two things could be true at the same time. But, I do personally believe that most of the reported nerfing is the case of your chart + latent evidence-less complaining. Honeymoon phases are real.

You can just have your agent find the evidence, review it, copypaste it.

That's wild. (Aside from the already-made points on explorations and learning) RC has no monetary transaction here, yet RC itself is somehow a business with revenue. Think on that for a second.

Here's my low-bar result, mostly from my time at RC. Is it literally published? No. Does it have novel arguments and code? Yes. winwang.blog/posts/dphm-1

Rather than entire languages, I'd say that feature adoption is more likely the better indicator. Like generics, first-class functions, lambdas, error-handling (I'm partial to monads like `Result`), etc.

If one wanted, they could put ecosystem tooling here as well (e.g. `gofmt` saving everyone time and mental health).

Also, to clarify, I'm not arguing that Erlang > Go, I don't (purposefully) use either, though I have to read Go sometimes.

Slightly irrelevant but that's a part of my issue with Go. I personally feel the chances are slim that "familiar programming concepts" (i.e. as taught by most intro CS courses) are optimal by themselves. And I know it's an old thing, but the fact that Go was once adamantly against generics...

I had an agent (SOTA models, xhigh reasoning, etc.) write and optimize some CUDA code recently. They've gotten a lot better at this stuff. And yet, they couldn't (self-)realize the obvious issue with their code: it was written as if for a typical multicore CPU. What the heck was a (serial) queue doing there? "Work efficiency" as a tradeoff for stalling 20k threads. Its later proposed optimizations were all about "can we get the queue faster" rather than "maybe we should actually parallelize the work for our very-parallel processor".

Funny stuff, as if it were hell-bent on writing a paper rather than actual software.

I don't know. For many operations, you can encode "how" by saying "under any permutation of this sequence of applications". At least, for EREW machines.

Pretty sure context is in SRAM, and then you have that as a blocker for tasks.

I'll be even more contrarian: I don't care if someone didn't write it as long as it's good (that's the major problem). I don't mind people using quotes when writing either. It's just that typically people (used to) curate their words before presenting them as writing. Although I'd prefer it if they also credited/explained what they used to write it in the case of heavy AI generation.

Hah, yeah that's definitely interesting, though maybe a general platform for this stuff would be even more interesting.

Although, maybe benchmarking an agent on "how well can you command a swarm to annihilate the Terrans" is how it all starts going downhill...

Would be interesting if you could team a fast and slow agent together -- slow model can either act directly or maybe just communicate to the fast model.

Another commenter appreciated the move towards a sane/nice standard. I am definitely on that side of the table. I'd rather feel good about the move -- good enough to ignore the other implied issues, lol.

I also think your point has at least one decent reading: that the upvotes help other practictioners update their mental model of their tools. There's probably also some value due to being an implicit "Claude Code megathread" for commenters to congregate around. News so minor that it does't even really make sense to force people to fully stay on topic, hah.

Gotta say, it is hilarious that this is the current top HN post. I feel like it's gotta say something about our current AI zeitgeist, that there is such vigorous attention on a seemingly-minor change. Feels like something is on the tip of my tongue but I can't name it at the moment.

If anyone wants to write/link a much better-thought-out post, I'm all ears!

Having also played with Metal and WebGPU (at least years ago), I would say that CUDA is, amazingly, the best GPGPU API we have. Do I wish we had an open source parallel programming language as good or better than it? Yes. But asymmetrically hating on CUDA like this is how we continue to lag behind it in UX.

> The best way to program GPUs is face up to the reality that they are not the same machine as the CPU, write your kernels in separate files, and launch them manually

Not to mention that this is a completely sane way to use CUDA as well.

Really exciting but it reads like Claude instead of what Nvidia posts have generally been like in the past. I don't need nor want my tech blogs to sound like a young adult novel.

(Without profiling or looking into this at all) I'd guess this has to with thread creation, inter-core communication/latency, and possibly having to merge results or otherwise interleave operations. SMT is another likely candidate.

Regardless, CPUs are really good at single-thread.

imo, partially because it's still not easy (in terms of code -> formal proof). With AI, I've been Lean-ifying a simpler (but non-trivial) algo. Pointing (current) AI at it only goes so far and in fact might go "too far" in certain cases, where a non-formalized argument would have sufficed. There's also "who watches the watcher" -- did it really prove what we're supposed to prove?

For something like these compression algos, though, I imagine it would be much easier since they already have actual proofs out there.

"maybe even psychologists" -- unironically true, but maybe I am talking about something different from you. The basis of (higher-level) math seem to mostly be "am I psychologically (emotionally...?) comfortable with accepting annoying ideas?" At least from my experience.

Every day, we stray closer to Haskell. Dare I say it: good!

(not the above poster but) I set up a local workspace for it to read/write from, so that edit is effectively just VSCode/vim. Unfortunately, it seems more verbose when writing out to file.

I decided to ask chatgpt for a fermi estimate of cores/datacenter, which you can check for yourself: 1~10 million physical cores. The surprising part of this for me was the "low" power usage (it used 20MW/"datacenter" as another point for estimation).

1MW ~ 6700 NYC citizens' residential usage, apparently, lol. I don't know exactly why, but that citizen number seemed a surprisingly large (well, probably because I've played with approximately-MW lasers).

Back of the envelope math, if anyone wants to correct my mental model: 2.1B (mincore)/week ~ 300M (mincore)/day. Assuming ~300k cores (~3k physical server CPUs, seems fine), that's 1k min/day. Seems about right, though obviously not uniformly distributed.

In any case, the number I'm focusing on here is the 300k cores part (x2 if you're counting in vcores). It does not seem like too much to ask for (significantly) more than that at github scale. It doesn't feel like a hardware issue, is what I'm getting at.

I don't GR but I'm fairly certain dipole does not work for gravitational waves (i.e. two objects accelerating straight at each other). Supposedly, there's a specific definition of "gravitational wave" here. You can, of course, detect the change in gravity though, regardless of "gravitational wave" or not.

Wouldn't discretion "just" be a really good rules engine?

I used Claude to generate technical SVGs (which are verifiable correct) because I wasn't going to take the time to draw the grid/arrows/etc.