[gabrieledarrigo]

Bah.

Personally my take on the entire affair is quite negative, whatever Jarred or Simonw says about it.

I think Bun owned by Anthropic and the entire rewrite with AI is not the real point (even if it's quite interesting, though).

My take is that Jarred, and Bun,didn't demonstrate a serious, adult approach, from "this is my branch, you are overreacting" message to just proceeding with a 1mil+ PR merged in less than month.

The communication is the issue, and it was handled very badly, in a way that impacted trust and divisions.

Was it so difficult to adopt the approach that the TS team adopted for 7.0?

[ozozozd]

Serious adults?

They are in extremely short supply right now.

It’s a mix of serious-wanna be, quasi religious, quasi-technical people running the show right now.

I am so happy to I got to read about the 90s-2000s tech culture, and experienced the post-2008 startup culture.

Just about 10 years ago people were really serious, but chill-looking. Somehow that got flipped.

[randysalami]

Sometimes being unserious is actually very serious. See current US administration.

[kzrdude]

Mario Zechner's talk "Building Pi in a World of Slop" is a good listen, on the topic of adults in a "world of slop". https://www.youtube.com/watch?v=RjfbvDXpFls

[polynomial]

The wig-vs-grok periodic cycle.

[baq]

I guess the point is none of it matters, CC users didn't notice or don't care except an exceptionally small minority.

[snemvalts]

The lowest of the bars

[drodgers]

But the only one that matters?

Seems like this is delivering business value.

[randysalami]

There was a recent post on here with a Claude Code issue I and others responses to. Specifically, the person from Anthropic who caused the issue replied on HackerNews. In it, he claimed he was the sole contributor and reviewer of the code into production, that he would “do better” in the future. Commenters were confused how a company like Anthropic could allow something like this occur and for an engineer to publicly admit a complete failure and negligence of build processes.

It’s clear seeing your post here a couple days later what’s going on. It’s deliberate. I can only speculate on their reasons why but it seems to be an intentional form of disrespect on the engineering culture. “Your norms, your work, your principles” mean nothing. We can spend money and invalidate your life’s work. We don’t need your consent or support. That’s my personal guess at a surface level.

[NewsaHackO]

I don't know, I feel as though Bun went about it much more maturely than zig at any point in the process, from the initial attempted zig compiler commit by the Bun team to the Zig dev team member response to the Bun Rust blog post. Also, I think that fallout over this whole event will definitely favor Bun versus Zig.

[raincole]

It's a weird way to frame the event. Yeah, Andrew (Zig)'s responses were astonishingly immature, but it doesn't matter. Even if Andrew literally ate baby seals for breakfast and kicked puppies as a hobby, it wouldn't make Bun look better. You'd notice that the parent comment didn't even mention zig at all.

[NewsaHackO]

Saying Bun's communication was an issue here is clutching pearls. There is no evidence that Bun ever acted in bad faith, Jared definitely seemed to initally think it was just a trial, until he realized that it was actually something feasible. He isn't clairvoyant; there is no way he would have known it was going to be successful when he initially made the post.

[simondotau]

Bun isn't Bun, it's a (notionally) trillion dollar AI company famous for ruthlessness and engineering controversy for marketing purposes. Zig just happens to be a language led by someone with an AI-skeptic philosophy. Are you saying I should just believe that their strategically deniable negative insinuations about Zig are not bad faith?

Sorry, but I'm calling bullshit. I know there's no absolute smoking gun here, but it's all a bit too cute to be unintentional. They are very very smart people. They knew what they were doing.

[foldr]

The simplest explanation is that the Bun team decided to try rewriting Bun in Rust because they had some frustrations with Zig. I haven't seen any evidence that there's more to it than that. It's easy to get sucked into all the internet drama, but that only exists because Zig's author lost his cool and wrote a salty blog post, not because of any conniving on Athropic's part.

[simondotau]

I agree that that's the surface-level, superficial, zero-thinking description of what happened.

[NewsaHackO]

>I know there's no absolute smoking gun here

Wow, so you can't even find circumferential evidence of circumferential evidence? I guess you can believe whatever you want, evidence be damned

[conartist6]

Haha TS7 is the next biggest example of, "Let's just do a line by line port to another language instead of seriously examining our architecture"

[raincole]

This is the correct approach (I dare to say the only correct approach) when porting to another language. You can examining the architecture later.

[dirtbag__dad]

If you can lock down a test suite that ensures parity, then who cares what shape the lift ultimately looks like.

A full rewrite in different language that fails to be idiomatic is a step backward operationally, even if you stand to gain on issues the new language just eats for free

[yathaid]

I like your fair-mindedness but for folks who are anti-LLM-anything, your argument is not the point.

Evidence: see the amount of nonsense in the postgres rewritten in Rust story - https://news.ycombinator.com/item?id=48841676 where there are two contradictory claims made:

"postgres is so stable I will never trust a rewrite."

"covering 100% of postgres regression suite doesn't guarantee you have replicated every behavior."

Folks who are okay with LLMs think the regression test suite is the spec and is the guarantee of stability. How else can it be? If you are depending on some behavior not covered in the regression tests, how do you know the next minor release won't break you?

Folks who are against seem to imagine a platonic ideal of PG which conveniently is the original PG implementation by tautological definition. So no rewrite can ever meet their bar.

[rtpg]

> Folks who are okay with LLMs think the regression test suite is the spec and is the guarantee of stability. How else can it be? If you are depending on some behavior not covered in the regression tests, how do you know the next minor release won't break you?

I think this deserves a real response.

First, an analogy. I drive along a cliff with no guardrail. How do I not drive off the cliff? By knowing how to drive. Sometimes people mess up and drive off the cliff

In practice people are operating Postgres as a machine, more than an abstract spec. Minor releases exist, but the changes are made by people operating the machine and who have a fear of making the machine break.

There are also performance characteristics that are part of an informal spec. While you can definitely write regression tests on performance, theres loads of value in stability of internals because people who have problems look into the machine and discuss it.

The internals might change, but there’s a lot of friction. So… you can have a lot of informal knowledge about.

If everyone working on a software stack is bathing in this informal knowledge, then the decision making is based on that. Things like what is meant to be in a minor or major release is understood. And people make those judgement calls.

After all, even if you have regression tests if you’re making changes you’ll need to write new tests! How do you know your new tests are right? That the new behavior is right?

PG is the entire machine. Fortunately we have version numbers, migration strategies, etc. But “here’s a new binary that passes the test suite and… maybe changes everything not covered by tests maybe doesn’t”. Why bother suffering when there are totally reasonable gradual rewrite strategies?

And of course… every bug in the world… got through despite a test suite! What software out there doesn’t have bugs?

And if the behavioral difference in the rewrite does affect people… I guess that’s something right? “Oh this isn’t a bug because it wasn’t covered in regression tests” is not that tenable.

[yathaid]

>> There are also performance characteristics that are part of an informal spec.

They are not informal AFAIK - https://github.com/PGPerfFarm. A lot of these heavy duty OS projects have explicit Perf testing/nighlites (see Lucene's at https://benchmarks.mikemccandless.com/)

If you are saying the PG regression suite doesn't cover these perf tests - that is fair. I consider perf to be part of the "regression framework" generally.

>> How do you know your new tests are right? That the new behavior is right?

This is a more generic question in the LLM world. Reliable verifiers is what drives LLM loops. If you don't have these, you have no idea if you are actually making progress or you just generated code that returns 42 for every question. You needs something to actually ground the LLM output against. For existing features, the reliable verification is the existing regression/perf suites. For new features, the regression/perf suites should expand to fit. There are ways to go at this that range from ad-hoc (line/branch coverage) to fully formalized (verification-aware languages like Dafny).

[consp]

> If you are depending on some behavior not covered in the regression tests, how do you know the next minor release won't break you?

Decades of intrinsic knowledge. Which a rewrite lacks.

imho the issue is the language used. AI rewrites are cheap and cheap exercises require a great deal of scrutiny and proof of correctness. Simply using regressions test lacks the intrinsic knowledge of a decades old codebase stuck in developers minds.

Claiming a rewrite is better because it passes all tests is a flex, a new version requires a boatload of evidence for people to accept it as an improvement and not just "passes tests, written in rust via LLM so it must be better". Run it in production for a year in a sufficiently large system and you might be somewhere.

[yathaid]

>> Decades of intrinsic knowledge. Which a rewrite lacks.

You mean the ones encoded in the regression suite? I think your argument is valid in many medium-to-faang firms where the application is going to have encoded business logic that isn't explicitly tested for. If anything, projects like PG are the exact opposite: no business context and regression suites that test every possible scenario due to the accumulation of bug fixes and context over many years.

>> Run it in production for a year in a sufficiently large system and you might be somewhere.

How do you know every release of PG doesn't break in the setting of "a year in a sufficiently large system"?

[frio]

I think what folks want, but aren't quite able to articulate, is an ongoing community and effort that indicate a project will be healthy and maintained. We want to be able to rely upon the software that we are choosing to use.

Regardless of the technical choices, whether Rust is better or worse, whatever -- pgrust popped into existence thanks to one person driving an LLM through 7000 commits in ~2 weeks. It produced something that passes the regression tests. Even as an LLM-sceptic, I think that's amazing.

From that point, though, it appears to have been completely abandoned. There hasn't been a commit in a month, other than a brief tweak and a note that an as-yet unpublished version that's even betterer is in the works. IDK. I don't think we've acclimated to the shock of the change LLMs create, but if the outcome is a forest of exciting new projects that have a bus factor of 1 and little to no collaboration, I think that's a disservice to this profession.

[yathaid]

I am not saying anything about the viability of that particular project; just that one argument that was repeatedly made in that thread which I think is frankly nuts.

[zarzavat]

Indeed as much I dislike the approach Bun took, at least the port appears to be working. TS7 is going to cause problems for downstream users because Go is the wrong language to use for something that has to run in WASM.

[nicce]

> TS7 is going to cause problems for downstream users because Go is the wrong language to use for something that has to run in WASM.

Is there a huge need to run that typechecking on browsers?

[conartist6]

First, yes, the demand to be able to code natively in a browser is, I have reason to suspect, very large. It's just difficult to measure demand when nobody has ever offered a really compelling product. In engineering terms it's like getting a full-scale reading. The real level could be 1% above a full-scale reading, or the real level could be 100x higher than the full-scale reading.

Secondly, WASM isn't the right target for the browser anyway, JS and the DOM have to be what you consider "native", for the most rigorous UI projects at least (which building an IDE is). If you want to build a cross-platform UI product that doesn't require installation and has Emacs-like levels of extensibility, JS is the end of the line in terms of language selection. There are no other candidates.

[skydhash]

> If you want to build a cross-platform UI product that doesn't require installation and has Emacs-like levels of extensibility, JS is the end of the line in terms of language selection. There are no other candidates.

calibre (with python+Qt) begs to differ. And I believe VLC runs on every current platforms. There's also Code::Blocks and Blender. Cross-platform UI is not rocket-science.

[conartist6]

All great examples, but ones that do require installation. Their website is just where you download the product, I'm talking about making the website the product.

[zarzavat]

Yes, in the Monaco editor (https://microsoft.github.io/monaco-editor/).

It's not just typechecking, the typescript library is also the reference parser for TypeScript and reference emit. Emitting JS from TypeScript is non-trivial and non-local.

It's not just in browsers, you might want to run the typescript library on the edge or in some restricted environment where JS/WASM is OK but native code is not.

You may want to use the typescript library as a dependency in your own package. TypeScript becoming non-pure JS means that your library also becomes non-pure JS.

[anon7000]

NodeJS can strip types internally without a straight TS dependency. I don’t think this matters, TS was a huge bottleneck for many build pipelines because it never parallelized well

[zarzavat]

Type stripping is not the same as emit, it only gets you a subset of TypeScript. Fine if you're running your own code, not fine if you want to run arbitrary TypeScript.

[egeozcan]

I think running a typechecker on its target platforms has huge benefits.

[shepherdjerred]

It is incredibly useful

[norman784]

Didn't WASM got a GC proposal that Go and other managed languages can use it? So it might be an issue in most browsers right now, but soon it might not.

[pier25]

This is the exact reason I stopped using Bun for new projects.

Terrible project governance.

TS 7 is a good example of what a responsible team that cares about their users should have done.

[mlsu]

It really does seem like they should have been able to do an incremental rewrite with FFI. Could have easily done it with AI too.

[classicposter]

Yes, they probably don't know C ABI.

[cush]

There's literally nothing stopping anyone from continuing the Zig version if they want to

[pier25]

You mean except the bugs in the zig version and any future CVEs?

[cush]

I meant continuing to develop it

[pier25]

why would anybody invest all that time to understand and maintain a mess (according to the creator of zig) of 500k lines of zig code?

[cush]

Because they’re complaining about it moving to Rust. I don’t know. I’m just saying, they can do something about it instead of complain