habitue

Bun obviously: they swapped the engine under claude code from zig bun to rust bun and it worked fine.

pgrust, high profile rewrites all over the place.

When you have an oracle to check behavior against, it is really easy to build a robust testing machine with property tests against the original.

Not necessarily, a rewrite can just move to a language that's easier to maintain (off C / cobol).

Honestly though, it's pretty clear the AI rewrites work, we have a ton of high profile examples. It's just a holdover attitude about rewrites from before AI. In reality, AI is going to make the code better when it rewrites

Why exactly? Even after this move, iPhone is less open. Apple doesn't have the 24h escape hatch.

Now people just wonder why you didn't write it in rust

It was intentional, sure. It was an attempt to solve a particular kind of problem.

In hindsight though, it was a mistake.

Evidence: when the world moved to 64 bit, we didnt just let int mean 8 bytes on amd64. That's a clear acknowledgement that the design was not correct once we understood things better.

Ideas can stand for themselves, the quote can stand for itself. You don't need to take all the things Tolstoy ever said and average their badness to decide whether a quote is true. You can read it yourself and see if it resonates with how you think of things.

Similarly, if you find that the quote resonates with you, you are not on the hook as endorsing every bad thing he ever did, or stupid thing he ever said.

You kind of need to be more specific about what you mean by sovereign. Federal pre-emption exists[0]. There are lots of ways in which the federal government can enforce their will (constitutionally!) on states.

But it's super complicated, and in this particular case does the state have some special right to name the body of water it's adjacent to that pre-empts the federal government? I dont know. Probably not, but I think the argument would need to be more explicit about what that right is rather than just claiming states are sovereign.

[0]: https://en.wikipedia.org/wiki/Federal_preemption

Exact match on a typo brings up a submission with that typo, which is likely low quality

"If an elderly but distinguished scientist says that something is possible, he is almost certainly right; but if he says that it is impossible, he is very probably wrong." Arthur C. Clark

I'm no Musk fanboy but I think this kind of maximally cynical take is tiresome. They thought it would work, they expended significant engineering effort and money making it real and producing it and selling it to customers.

The simplest explanation is that they did all that and the market didn't want it. The economics of traditional panels outweighed the aesthetic advantages of tiles and they're pivoting. No conspiracy or fraud need be invoked.

I am confused about why Gary Marcus thinks it's so obvious that Claude isn't conscious. As he points out, Dawkins is just taking a bog-standard behaviorist position: that he can't distinguish Claude from a conscious being just by the behavior here.

Marcus is saying "Well, if you knew they were trained to mimic, then you'd understand it's just mimicry and not real consciousness" The problem with this argument is that we just don't have a good idea what "real consciousness" is. What if, in order to simulate human text prediction with sufficient accuracy, the model has to assemble sub-networks internally into something equivalent to a conscious mind? We could disprove that kind of thing really quickly if we knew how to define consciousness really well, but we kinda don't!

Philosophers are genuinely split on this question, it's totally reasonable to be on either side of this based on your personal intuition. Marcus's position seems to be actually based on his own personal incredulity, despite his claims that understanding LLM training methodology gives him some special insight into the internal experience (or lack thereof) of an LLM.

(The Claude Delusion is a banger title though)

The first edition is expensive. The current edition is ~$90 for a full color hardcover (expensive but not ruinius if you really want it)

Sometimes, in the interest of having something rather than nothing, I have to press publish. This entails getting things wrong, which is regrettable.

I will say, that I'm trying to steelman the code-as-assembly POV, and I dont think the exact historical analogy is critical to it being right or wrong. The main thing is that "we've seen the level of abstraction go up before, and people complained, but this is no different" is the crux. In that sense, a folk history is fine as long as the pattern is real

This is an interesting distinction, but it ignores the reasons software engineers do that.

First, hardware engineers are dealing with the same laws of physics every time. Materials have known properties etc.

Software: there are few laws of physics (mostly performance and asymptotic complexity). Most software isnt anywhere near those boundaries so you get to pretend they dont exist. If you get to invent your own physics each time, yeah the process is going to look very different.

This just doesn't explain things by itself. It doesn't explain why humans would care about reasoning in the first place. It's like explaining all life as parasitic while ignoring where the hosts get their energy from.

Think about it, if all reasoning is post-hoc rationalization, reasons are useless. Imagine a mentally ill person on the street yelling at you as you pass by: you're going to ignore those noises, not try to interpret their meaning and let them influence your beliefs.

This theory is too cynical. The real answer has got to have some element of "reasoning is useful because it somehow improves our predictions about the world"

...and will also have a deeper understanding of the problem that will help solving other problems down the line?

Skills wont use less context once invoked, the point is that MCP in particular frontloads a bunch of stuff into your context on the entire api surface area. So even if it doesn't invoke the mcp, it's costing you.

That's why it's common advice to turn off MCPs for tools you dont think are relevant to the task at hand.

The idea behind skills us that they're progressively unlocked: they only take up a short description in the context, relying on the agent to expand things if it feels it's relevant.

These kinds of tools should be standard in understanding code

Pylon (https://pylonlending.com) | ONSITE Menlo Park, CA

What Stripe did for payments, Pylon is doing for the mortgage industry: We're taking a sleepy industry with backward technology and re-building the stack from the ground up. We're first-principles thinkers, and our team is small, talented and ambitious.

I'm hiring generalists who love coding and want to build something beautiful in an industry where technology written in the 90s is the norm. We're Series A, well funded, and we have traction with customers. Come to Menlo Park and help us turn the $13 trillion US mortgage industry into a set of APIs.

https://jobs.ashbyhq.com/pylon?utm_source=hn-whos-hiring

If you like:

- Programming languages

- Functional or Logic programming

- Operations research & optimization

- Working on an amazing team on a really hard problem

Come join us!

I mean, bcachefs is basically the equivalent of rewriting all that code, without explicitly trying to be a clone. Same for btrfs

I think Co-* is probably better, though more obscure I guess

We did this at stripe when deprecating TLS 1.0, and called it a brown out (I don't know the origin of the term in software).

You do it when you have a bunch of automated integrations with you and you have to break them. The lights arent on at the client: their dev teams are focused on other things, so you have to wake them up to a change that's happening (either by causing their alerting to go off, or their customers to complain because their site is broken)

There has to be adverse selection here from the amount of money being offered right? Like ok, very few people could turn it down, but it's not going to result in a motivated team.

I am imagining all these overpaid founders etc just sitting in a room like reality show contestants. Trying to make smalltalk, brainstorm jamming for months, not really producing much because... who cares, they have unbelievable money and this is the weirdest scenario ever.

Maybe chess was wrong, it's adversarial. But there's definitely a qualitative leap between "adversary withing defined rules in a particular context" and "anything is on the table, they could kill you etc." kind of adversary

I mean C89 has no support, it's not getting an update or a bugfix, the standard is what it is. So if vendor support is your overriding concern, you should be constantly updating your software to LTS versions.

I meant support in terms of there's an active community of people using the language and building things with it. It's not going to die as a language like Algol 68 or Pascal.

Started watching, but "C89 is the safe option for long lived software" kind of turned me off. There are plenty of safe long lived stable languages out there where you dont have to manually manipulate memory. At the very least, this guy should be advocating for Java.

But even that's too far really. Like it or not, "shiny fad" languages like Python & Javascript have been around forever, support for them isn't going away, this should be a non-concern at the architectural level. (Bigger language concerns: is it performant enough for my expected use? Does it have strong types to help with correctness? Can I hire programmers who know it? etc)

> Symbols, by definition, only represent a thing.

This is missing the lesson of the Yoneda Lemma: symbols are uniquely identified by their relationships with other symbols. If those relationships are represented in text, then in principle they can be inferred and navigated by an LLM.

Some relationships are not represented well in text: tacit knowledge like how hard to twist a bottle cap to get it to come off, etc. We aren't capturing those relationships between all your individual muscles and your brain well in language, so an LLM will miss them or have very approximate versions of them, but... that's always been the problem with tacit knowledge: it's the exact kind of knowledge that's hard to communicate!

> by encoding more and more responsibility in the type system, you're just pushing your business logic to a different language

Yes, this is 100% correct. Type systems are just another language

> The same propensity for human error exists there as well.

This is where I disagree. Sure you can make errors in types, but it's not the same because strong type systems are more like proof systems. They tell you when you've encoded something that doesnt make logical sense. And they help you figure out if your code can be made to adhere to them. It's a checker that you don't normally have.

> But I don't see much difference in putting that logic in the base language or the higher order type system language, except the base language is more expressive and flexible.

The type language encodes your assumptions, and the base language has to adhere to those assumptions. If your type language is expressive enough, you can encode pretty complex assumptions. There's value in having the two playing against each other.

Similar to tests: you could say tests are just re-stating what you've already written in your code. In reality, it's another check for consistency with your original intention.