Do we apply a bar this high for any other company/job/business? Saving gov/tax money aka "billing NASA 1/20th what SLS does" doesn't count as worth it to you?
Reusing rockets reliably rather than "throwing them away" is a great achievement and I'm surprised people have to justify it on HN
I've read that New Zealand study and it's identifying an effect in a small group of heavy users who started using cannabis very young (a full third as teens) and continue to use it heavily (four times a week) three decades later. That's not a huge surprise.
They also state "cognitive functioning among midlife recreational cannabis users was similar to representative cohort norms". It's clearly shown in Figure 1 - midlife recreational cannabis users actually got smarter than people who quit cannabis according to their data.
There may well be some confounding factor in there. The study was done in New Zealand where cannabis was illegal for the majority of participants, and usage was self-reported so there's a basic issue there as well. One of the meta-analysis citing this (Crisafulli, 2026) and finding no effect criticizes the study design.
To be fair, if I wrote a book it would be because I saw a gap in current books' coverage or quality. I don't think anyone chooses to be a professor for the money.
It's "we support 4 JS backends, we don't have the capacity to support 5 currently". They're not dropping bun entirely, instead bumping the minimum bun version and not supporting "bunv2" because they don't want to be beta testers.
No, the team mislead people by claiming the rewrite was experimental only to merge 1M lines of unreviewed code merely days later. Responsible software developers don't operate on blind trust, and both the Bun code and the maintainers are highly unpredictable at this point. That's more than sufficient technical grounds to drop an optional and replaceable dependency, especially since there are no user-facing consequences beyond the bruised egos of a cult following that demands blind loyalty to its tech‑bro leaders.
Who did they mislead? A few days later it was no longer experimental and it became the main dev branch as they decided it would be the way forward for development (see the blog post on why). No stable release has been declared yet.
Here was the Bun team's message on merge:
> It passes Bun's pre-existing test suite on all platforms (and fixes several memory leaks and flaky tests), the binary size shrinks by 3 MB - 8 MB, the benchmarks are between neutral and faster - and most importantly, we now have compiler-assisted tools for catching & preventing memory bugs, which have costed the team an enormous amount of development & debugging time over the years.
>
> The codebase is otherwise largely the same. The same architecture, the same data structures. Bun still uses few 3rd party libraries. No async rust.
"Who did they mislead? They just changed their minds a few days later and words aren't what you think they mean. Here's the team's PR statement containing assertions about the 1M lines of code they never reviewed."
It's unfortunate that this is what some call "engineering" while labeling actual science and engineering as "politics."
yt-dlp is under no obligation to keep using a dependency from vendors that instantly flip flop and re-frame their own words and actions. That's what actual due diligence and responsible engineering looks like.
Feel free to point out where my logic is wrong. It sounds like you think they've made a stable release already? None of the new code is sent to users yet. It's a direct translation without relying on major AI decisions. I'm happy to call them cowboys if they make a release with lousy testing.
> It sounds like you think they've made a stable release already?
What's the point if you keep refusing to acknowledge the issue and tossing out theories about how I and others might be wrong, just to see what sticks?
> None of the new code is sent to users yet.
So? The decision to adopt was already made and the code was merged without planning, without considering downstream impacts, and without proper inspection. People who won't read their own code before merging won't read it after. But many of you don't even see this as an issue. So again, what's the point in trying to point all of this out?
Also you yourself said the experiment is over. You can't have it both ways.
> It's a direct translation without relying on major AI decisions.
Because the genie said so? That sounds lacking in scientific rigor, but
> I'm happy to call them cowboys if they make a release with lousy testing.
Oh right, that the test passes is proof that the new code is debuggable, maintainable, architecturally sound, semantically equivalent to the old code, and non-disruptive for downstream users. Apparently testing has leapt centuries ahead in the past two weeks or so.
Testing is a broader term covering multiple things, up to and including the decision of when you have enough confidence in the system to declare it stable. The test pass rate was an early bar for merging into dev, not release.
The translation did not change the architecture: it was a 1:1 translation with even the same internal data structures. Rust written in a zig-like way, with the original Zig still available as reference. AI can make an absolute mess when making architectural decisions, but translation like this plays to the strength of current AI, especially when moving to a stricter language.
The code being in the dev branch means that they now are open to community feedback and testing, and no date is set on it being declared stable. We'll see how the team handles it.
This might come down to when you expect plateau to happen. You could have said similar about transistor density many decades ago.
(I'm not denying it could happen next year for all we know. But we simply don't know, and from what I hear from researchers the breadth of ideas we've tried are still small)
Interesting, I read this series of posts and as someone who does not have a dog in this fight but does have a more than passing background in both audio engineering and datacenter engineering, the response Masley gives here to the very first criticism is fundamentally incorrect. I haven't read the rest of this, but his claim about sound intensity what it would imply about energy is on its face untrue.
When you take a measurement of a sound, you are measuring both its pressure and its intensity, that is what is implied by a measurement in decibels. The measurement is taken from the point of the measurement device/listener in relation to the source/generator. If the measured value is potentially harmful, there is no such implication about needing to redirect additional energy to make it harmful, it's already been measured as potentially harmful at the point of measurement.
It's basically nonsense. My most charitable interpretation of his very first responsive argument is he's saying that a datacenter would need to intentionally direct energy towards increasing the intensity of its sound output to make Jordan's original measurements meaningful. That's neither how measurement works, nor how sound works, nor even how datacenters work. Things like sound and heat are BYPRODUCTS and not the point of the datacenter, both have an intensity, and that intensity is measurable, and any energy which is expended towards that intensity is energy that was wasted away from doing computations.
I stopped reading after this. I don't know if Masley is out of his element or just practicing motivated reasoning and thinks his readers are stupid. Either way, his rebuttal already failed on the first point.
> Jordan is suspiciously lurching to the extremely high energy end of the light spectrum when we know that the low energy end (comparable to infrasound) doesn’t have negative impacts on us if we can’t detect its presence.
Masley spouts the falsifiable propaganda that any photon (light/emf) below ionizing radiation energy can only cause “heat” and can have no other possible harm effects.
Many science-minded people (though more accurately in this case, billiard-world materialists) have become quite militant defenders of this idea (ostensibly fighting off the hoardes of tinfoil hatters and quantum aquarians sensitive to 5g).
This point is very plausible military industrial propaganda. There were numerous studies with evidence (starting from the 60s) such as - non ionizing radiation (eg hv powerlines) might cause lots of cancer, and it’s weaponized (sub-thermal) usage can microwave the brains of enemy spies. THOSE studies have come out in declassified and leaked docs.
Now we have several plausible and serious theories of mechanism for low-f light disrupting biology that lean into quantum biology. While the iceberg of quantum biology understanding is still in its early decades, the mounting downstream evidence of health and medical issues are established public knowledge.
reply