chubot
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)
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.
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)
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.)
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 !
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.
https://firecracker-microvm.github.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.
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?
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.
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...
(allocation happens in the mutator, GC happens in the collector -- there is a symmetry)
The constant factor could be 500 or 50,000, but it's still proportional.
And allocations are some subset of the operations of the algorithm itself.
So then GC can't increase the overall time by more than a constant factor. So the big-O is the same.
(You could have some nuance on how to match GC operations to mutator operations, but the overall point is still true)
Yet for some reason I can’t escape these annoying pixel cleaning interruptions. Seems like a bug in the firmware.
Complexity becomes a way to postpone the verdict. etc.
Meh
Hm on first reading I was confused by the extern "fil-c" framing -- that seems to imply a bridge between C and Fil-C, which introduces some nasty language/runtime inter-op issues.
But I like this part
I want a Rust FFI that speaks the Fil-C ABI. ... We could use Rust for compile-time safety and then pay a performance penalty for using C.
A rough proxy for this would be if they say contribute to the C++ standards process, which Google Microsoft nVidia do, and basically zero "normal" companies (say SaaS) do. It means they are investing in multi-decade maintenance of their codebase
Speaking personally, the fate of Docker, Inc. was clear to me when they took their $40M Series C round in 2014. I had met with Solomon in April 2014 (after their $15M Series B) and tried to tell him what I had learned at Joyent: that raising a ton of money without having a concrete and repeatable business would almost inevitably lead to poor decision making
And it's hard not to see the same pattern here: https://fly.io/blog/we-raised-a-bunch-of-money/ - June 2023
This past July, we raised $25MM from A16Z and our existing investors, including Intel Capital and Dell. Recently, we raised an additional $70MM led by EQT Ventures.
Basically Scott Johnston is the guy that recoups money for investors, and in Docker's case, I recall that involved clawing back some value from users
From OP: As a shareholder of Fly.io, for this stage in Fly.io’s lifecycle, I liked his playbook better than mine. As the CEO of Fly.io, I liked the prospect of him doing all this work more than I liked the prospect of me doing it. We took a lot of time to work this out, and ultimately the board and I convinced him to take the job.
I just Googled and it turns out it was https://wkdu.org/ 91.7 FM, Drexel University college radio! Woohoo something is alive out there !!
And I just found the playlist of the exact show I listened to, on Thursday July 16th - https://wkdu.org/playlist/71388
This seems either mathematically impossible or vacuous, depending on what you mean ...
But it does feel complex to me.
Personally I just write in the common subset of bash and OSH, which is very large. I never need to support say dash, since every machine that has dash also has bash, which is less broken in terms of 'echo' and so forth.
bash has its own broken-ness, but running under OSH solves that.
And OSH also supports some busybox idioms -- we learned last year that bash cannot run busybox ash scripts on Alpine
e.g. 'chdir' is an alias for 'cd' in busybox, but not in bash. And Alpine scripts use it, so bash can't run Alpine scripts, but OSH can (as of last year).
$ dash -c 'echo "c:\\new"'
c:
ew
$ busybox ash -c 'echo "c:\\new"'
c:\new
It requires 4 backslashes: $ dash -c 'echo "c:\\\\new"'
c:\new
$ busybox ash -c 'echo "c:\\\\new"'
c:\\new
I am not sure this is a matter of "undefined behavior in POSIX" -- I think it might just be dash being wildly unconformant, which I have seen in other cases.It's one of the least POSIX compliant shells. It is derived from the same codebase as busybox ash, but busybox receives more maintenance.
---
In any case, it is pretty sad that sh is in such poor shape than the default /bin/sh on Debian has different behavior in this basic case.
I built OSH to be a set of semantics agreed upon by many shells. I don't think any cross-shell test suites like our spec tests had existed in the past - https://oils.pub/release/0.37.0/quality.html
But there is little coordination among shell authors, and no real motivation to fix the gaps. In contrast, there is A LOT of coordination among JavaScript engine authors, mostly because there are people paid to work on them.
osh-0.37$ echo "c:\new"
c:\new
osh-0.37$ shopt --set no_parse_backslash
osh-0.37$ echo "c:\new"
echo "c:\new"
^
[ interactive ]:6: Invalid char escape in double quoted string (OILS-ERR-12)
It really should be echo "c:\\new" # with two backslashes
That is an unambiguous program that works in every shell. In a well-written shell program, the only things that should follow a single backslash in a double quoted string are \ " ` $
(Although I found that this option is only on in ysh, not in shopt --set strict:all ... arguably that should be changed)Nine Reasons to Use OSH - https://oils.pub/osh.html
I always appreciated Jeff having a level head ... which this article seems to confirm:
https://www.yahoo.com/news/articles/google-cracks-down-posts...
I think it's a pretty deep point -- your memory and consciousness are shaped by the media environment (media being the thing that Klosterman thinks about obsessively)
And the media environment drastically changed after the 90's -- because of the Internet
I think his main point was about access to media in different eras, but it's worth reading directly if you feel like that