Recent submissions

Comment · 6 days ago
In Google's case it was absolutely true though. The stock was NOT over-valued.

The IPO was at a market cap of $20 B. And it never dipped below IPO price -- it doubled within a year.

And now GOOG has a market cap of $4 T, so that's 200x in 22 years.

I like Claude, but I think the likelihood that it is over-valued already is higher than it was for Google. (Though I would not really be surprised if it keeps the $2 T valuation and grows. Who knows? And it doesn't matter to me personally)

Comment · 13 days ago
Well I wouldn't say "invented", but I'd agree with "incentivized at scale until it became a cancer on the web"

The weird thing is that YouTube seems to have incentivized a lot of good content. Sure there is "scalable slop" like Mr. Beast, but there is also good content on YouTube (Fall of Civilizations podcast, etc.).

Somehow on the web I am not seeing a lot of good content incentivized by ads. I see a lot of WikiHow-type stuff.

It seems like writing moved to Substack and so forth.

Comment · 20 days ago
Yesterday I was trying to add a patio to some real estate photos, i.e. "virtual staging".

I uploaded 4 different photos of the same house, from different angles.

I asked Gemini, ChatGPT, and Grok add the same patio to each photo. The results were laughably incoherent (not to mention ugly).

I repeatedly asked them to make the 4 photos consistent in 3D, and it's obvious that they have no way to do this -- no understanding of the scene.

They also could not understand the concept of "back patio" and "side patio" -- relative to the house, when the house was being photographed from different angles. Even when I pointed out which one was the side patio, they would get it confused in a different image.

(I should not be surprised by this, and yeah I know everyone says LLMs have "jagged" capabilities. But to me this shows how bad all the extrapolation of AI I read on say Hacker News has been)

Comment · 20 days ago
Even in software, there are many things that haven't changed.

e.g. Why do Rust and CPython still have over 5,000 open issues each? At some point, will the superintelligence fix all the bugs autonomously? When is that going to happen?

https://github.com/rust-lang/rust/issues

https://github.com/python/cpython/issues

What about new features? In every thread about Rust, people are clamoring for new features and libraries. People wonder why there can't be a batteries-included standard library like Go.

So now that LLMs are so smart, is that a solved problem? Or are we still bottlenecked on the expertise of a few experts?

---

Also, what happened to AI's passing the Turing test? I see tons of slop articles that are obvious to most HN readers. They haven't fooled us apparently -- the longer the interaction, the more obvious it becomes whether it's AI.

(That said, I use AI all the time and find it to be a great tool. IMO is is a tool, not an autonomous intelligence with a will of its own.)

Comment · 22 days ago
Yeah, I'm thinking of the one time I was in a band where we gelled musically, and I noticed I started writing more/better music subconsciously. And a particular type of music that would fit with the band.

I think it's not always a voluntary response. If you're involved in some kind of social situation, your mind automatically points a certain way.

If you lack an enriching situation, then your mind might just get lost !

Comment · 24 days ago
So were the 3 withdrawn proofs the ones without Lean verification?

If so, why did they mix proofs that were verified with Lean, and proofs in natural language?

I was wondering that while reading Aaronson's blog:

https://scottaaronson.blog/?p=10169

Or at least, we’re pretty sure that it’s a proof! There’s a Lean certificate, as there are for some of the other 372 breakthrough results (not all of them). But it also appears that no human has understood just about any of these proofs yet

It seems that the obvious thing to do would be to release in TWO parts: the ones that are verified, and the ones that might have some good ideas but also might have some mistakes. Presumably the latter would be much more epxensive for humans to verify.

Comment · 27 days ago
As far as I know, Firecracker, gVisor, and Kata Containers are the solution here. They use VM primitives (x64_64 and ARM64 extensions) and have lighter codebases

https://firecracker-microvm.github.io/

https://gvisor.dev/

https://katacontainers.io/

But I don't have any direct experience with any of them. I'd be curious what people who have built on top of them think

edit: OK it looks like Kata can use Firecracker, so as far as isolation, it's either Firecracker or gVisor. And Firecracker is the VMM I mentioned, but gVisor is quite different -- it's more like a user space kernel that emulates syscalls.

Comment · 29 days ago
I would like something Unix-y and Linux-compatible that follows the principle of least authority.

Linux namespaces and cgroups and seccomp are a mess ... but actually they are probably more functional than what OS X or Windows provides.

I wonder if we can do better. But maybe not in this project?

Comment · 1 month ago
Just curious, what kind of jobs did they transition to? Or were they forced to take a break, or left in job application hell, etc?
Comment · 1 month ago
James Mickens! I was hoping for more jokes …
Comment · 1 month ago
Yes!
Comment · 1 month ago
Yes thanks for finding the Python 2.4 release page which shows the optimization! So I remembered correctly -- Python already had that optimization back then. (There seems to be a large amount of confusion on that in this subthread)

And the March 2005 Artima post is also a very good reference! That actually predates my story, since Guido hadn't joined Google by then. I recall that he joined in December 2005.

So maybe the bug I remember was more of a "push" in the direction he had already thought of, not the direct inspiration.

It's clear from the blog post that he disliked all of map / filter / reduce, and then I'm sure that users or python-dev pushed back on removing them, so he settled for banishing reduce() to the stdlib.

Comment · 1 month ago
Python has always had a bytecode compiler that did some minor optimizations, since its inception in the 90's. The issue is that optimizations are very hard to do correctly in the compiler because Python is so dynamic. Any piece of code could suddenly redefine mytype.__add__() and so forth.
Comment · 1 month ago
Related to the point about worse performance, I'm pretty sure I was there when reduce was "banished" from Python 3 -- demoted to functools.reduce(), instead of the builtin reduce() in Python 2

The story is that sometime in 2006 or 2007, Guido van Rossum was debugging why a web page in Google's internal code review tool (which he wrote) was taking 30+ seconds to render.

This is basically a "production" incident, since thousands of Google engineers relied on the tool. Requests like this were probably tying up threads and exhausting thread pools, perhaps

Eventually it was tracked down to a line wrapping algorithm written with reduce(). I don't think he wrote it -- it may have come in through a dependency. As many know, reduce() is basically:

     s1 + s2
     s1 + s2 + s3
     s1 + s2 + s3 + s4 
     ...
And that's O(n^2) when s_i are strings. And I think it showed up if you viewed a 5000+ line diff, or a 5000+ line file. (Newer programs like Github also suffer here)

I believe, in Python at that time, += was already optimized to avoid this (just like essentially all JS VMs are). Or you can use the idiom of append() to list and join() after.

But reduce() basically forces the inefficient implementation, and I'm sure this is still true in Python 3.

---

So basically Guido spent a long time debugging a performance problem related to reduce(), and made the decision to eject it, to help users avoid "footguns". I was his officemate at the time, so I recall this, but I wasn't involved directly

Also, somebody contributed reduce() to Python way back in the 90's, as well as other functional idioms. He wouldn't have added that himself -- it was never his preferred style.

He preferred a more imperative style. But he allowed those contributions, and then slightly regretted it later.

https://docs.python.org/3/library/functools.html#functools.r...

Comment · 1 month ago
What metrics were you tracking that moved?

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton