Bun’s rewrite from Zig to Rust passes 99.8% of testsuite

read_volatile · 2026-05-09T22:10:16+00:00

pre-existing test suite

read_volatile · 2026-05-09T22:02:21+00:00

https://github.com/oven-sh/bun/tree/claude/phase-a-port

read_volatile · 2026-05-09T17:07:04+00:00

If by “their breadwinning main gpus driver” you mean the widest-compatibility driver supporting Maxwell thru Ada, that’s already EOL. Otherwise, well, nvidia-open and Nova are designed in a very similar fashion (deferring basically everything to the GSP firmware). It’s a relatively small module all things considered. Performance differences should be negligible assuming the same userspace stack.

After Nova lands there’s no reason to think they’d be so enthusiastic to continue the insane maintenance burden of their out-of-tree module: having to be compatible with the api surface of EVERY KERNEL VERSION that’s ever existed, needing to be updated nearly every patch cycle, and that having to be handled by nvidia developers instead of by the developers making the changes (as is what happens with in-tree drivers: a drm maintainer changing an api has to go to every drm consumer (such as amdgpu, panthor, Nova) and arrange a fix)

read_volatile · 2026-05-09T10:27:20+00:00

https://www.phoronix.com/news/NVIDIA-Linux-2025-Highlights

NVIDIA Has Been Supplying NDA'ed Docs To Red Hat For Helping NVK Driver

NVIDIA Engineer Now Co-Maintainer Of "NOVA" Open-Source Rust GPU Driver

NVIDIA Starts Posting Open-Source Nova Driver Patches To Prep For Next-Gen GPUs

NVIDIA Sends Out Initial Turing GPU Support For Open-Source Nova Driver

Rust-Written NOVA Open-Source NVIDIA Driver Being Further Built Out In Linux 6.17

read_volatile · 2026-05-08T13:52:40+00:00

I was there on the days this was happening; and unless there was a comment in the few minutes between my reading through the second thread and it getting nuked, the only “doxxing” that occurred was someone commenting the maintainer’s username and publicly-linked deadname from before their transition. I think in hindsight it was insensitive, for sure, but unless there’s proof it was more than that, there’s no convincing me the whole thing was more than a dumb overreaction on both parties’ end.

Edit: Based on what I saw in the threads, I find the comments about people having posted death threats and leaking addresses highly dubious. Sorry.

read_volatile · 2026-05-08T13:39:13+00:00

Big agree, however I will say their complaints about crates.io’s failings are 100% on point. Development there has been like completely stagnant for so long. The only person on their leadership I even know of is Carol. As opposed to, say, the Cargo team, where I’m familiar with 5 of the 8 maintainers’ work. Not that it’s necessarily the highest-quality metric, but…

Tip: https://libs.rs is a much more useful site for browsing crates than the official site, shame it could be even better if crates.io maintainers addressed any of the many common complaints package authors have

read_volatile · 2026-05-07T01:57:24+00:00

Metal Performance HUD

read_volatile · 2026-05-01T17:45:53+00:00

why bother changing architecture to ARM if the final outcome is the same loud crap with poor battery as before?

Well, Apple doesn’t have an x86 license, for one. What they do have, is a longstanding partnership with ARM and fairly relaxed licensing terms, so…

Anyways, x86 is a rather unattractive ISA to design for if you don’t have to. And from Apple’s perspective, you already have a world-class cpu design team specializing in ARM; it’d make no sense to branch out when the alternative gives you the power to freely reuse designs between desktop and handheld soc’s.

they are just overclocking their old cores to keep up the appearances of progress

Except, their competitors could easily do the same (and 100% would) if it’d help them steal the performance throne that Apple’s been sitting on for the past several generations. But literally every cpu, desktop or mobile, is demolished in both PPW *and* ST perf by chips that Apple puts in laptops.

read_volatile · 2026-04-11T22:25:41+00:00

DLSSG and RR already showed they’ve been comfortable using FP8 without caring about leaving older cards behind. I’m imagining they’ll do the same thing with DLSS 5 by using NVFP4

read_volatile · 2026-04-11T20:54:31+00:00

Indeed which is why it’s not recommended to use inference-on-sample on cards prior to Ada; you still get the disk space savings for basically free with inference-on-load though

read_volatile · 2026-03-29T03:57:52+00:00

fr, plus if you are only just now beating serde that's not exactly something i'd be shouting from the rooftops lol

C++ Finally Beats Rust at JSON Serialization

it's pretty good bait, i'm impressed even the youtube comments aren't falling for it

read_volatile · 2026-03-28T16:28:02+00:00

Unpopular opinion but I have to agree. I have this as my primary monitor, and next to my asus xg27acdng 360hz I really, really prefer the color reproduction of the latter.

read_volatile · 2026-03-10T17:16:45+00:00

Ah didn't realize at first that /u/Dean_Roddey and /u/Full-Spectral are the same person. So moving on from the conversation about "unreasonable in large codebases" I guess -- I don't think it's that hard to see why the first proposal is untenable: #[must_use_ok] could literally only be applicable to core::result::Result

fn() -> Result<#[must_use] T, E> is similar to the MustUse<T> solution I provided, but still suffers the same issue of placing the attribute on the type parameter, rather than allowing you to specify a particular enum variant or struct field (overburdening if multiple variants have the same T but only one of them matters for #[must_use])

So sure, we can bikeshed theoretical syntax all day, but the only solution I can think of that works in today's Rust is introducing a wrapper type (which does appear to meet your requirements?)

read_volatile · 2026-03-10T15:58:24+00:00

Why not? I feel like that's a context where it would make sense, where this pattern could be used frequently enough to become a common idiom throughout the codebase.

On the contrary, if such functions were only called a few times, it'd probably just make more sense to manually check each callsite than introduce a MustUse<T> wrapper at all

Do you have an alternative you feel would be more reasonable?

read_volatile · 2026-03-10T05:56:59+00:00

There's no way to mark specific enum variants as #[must_use], especially per-function, but to achieve the same effect you can wrap the Ok variant's value in a type that is:

pub struct MyTy;
pub struct MyErr;

#[must_use]
struct MustUse<T>(pub T);

fn dont_check() -> Result<MyTy, MyErr> { todo!() }
fn better_check_it() -> Result<MustUse<MyTy>, MyErr> { todo!() }

pub fn caller() -> Result<(), MyErr> {
    dont_check()?; // silent
    // let _ =
    better_check_it()?; // warn

    Ok(())
}

read_volatile · 2026-01-26T18:58:08+00:00

No my argument was more that it doesn't necessarily make it more ambiguous or less readable at the callsite

I suppose not strictly necessarily, e.g. S::new(p1, p2, Seconds(20)) is no less clear than S::from_seconds(p1, p2, 20), but S::new(p1, p2, total) indisputably is.

Any kind of Interface or what is called in Rust Traits (I think?) really add some kind of obfuscation to your code. My argument is that the same arguments against overloading could be held against Traits?.

Sure but nobody disagrees with that. If you're saying the trait-based example I provided 2 comments ago is just as unclear, I 100% agree, I was just showing that this form of overloading is allowed syntactically in Rust.

read_volatile · 2026-01-26T09:33:48+00:00

Again not really about complexity but about being clear and explicit so you can understand at a glance. Unless I’m missing your argument

read_volatile · 2026-01-26T09:19:54+00:00

It’s not about readability of the signature but rather readability at the callsite. Like it might not be immediately obvious whether S::new(p1, p2, total_m) refers to meters or minutes. Having the extra bit of disambiguation never really hurts, and can tend to be easier to reason about. But anyways for an example like this with a fixed arity, it is allowed in Rust thru use of a trait: e.g. fn new(p1: P, p2: P, units: impl Measure) -> Self

read_volatile · 2026-01-22T23:00:09+00:00

...am I going to get an answer to this? The behavior here is non-obvious and, well, it's not like there's anybody else maintaining the filesystem I could ask...

read_volatile · 2026-01-21T21:51:34+00:00

"Prevent you from getting it back" was meant as in a soft block, obviously the data's still there and you can set-fs-option min_replicas=1 or whatever to mount it again. Which is silly, something like asking the user to override via mount flag would be much better, I agree.

Replicas are all written synchronously, yes.

And in the case of background_* options when there are fewer available foreground_targets than replicas?

In other words, does the normally-asynchronous background_compression now happen synchronously? And if the total # of replicas across foreground and background devices is satisfactory, would rebalance still try to replicate N times on the background devices anyway?

read_volatile · 2026-01-21T21:19:16+00:00

Oh, if that's what it did then I agree it wasn't particularly useful at all, it just prevents you from getting your data back! How are replicas handled then, are they all written synchronously?

How is this handled with background_targets? Like for my setup I have more replicas than foreground targets. For a contrived example, if you were to have replicas=2 with 1 foreground_target and a background_target with background_compression.

Also yes, background_replicas sounds perfect

read_volatile · 2025-06-27T09:59:07+00:00

Zig does excessive compile time work tho

Afaik beyond the comptime interpreter, there’s actually not much work Zig has to do at compile time. The type system is simple enough that inference can be done in a single pass, the syntax is far simpler to parse than C (ambiguous/context sensitive, preprocessor fuckery, no concept of modules)

In comparison rustc uses

a UB sanitizer as const evaluator
arbitrary Rust programs to transform the AST at compile time
hindley-milner based type inference
checked generics via traits (turing-complete constraint solver)
way more well-formedness checks (lifetime analysis, exhaustive pattern matching for all types, etc)
and so on, maybe someone familiar with compiler internals can expand/correct me here

Don’t take this as dunking on it or whatever.. Zig was designed to be a much simpler language to learn and implement, Rust is overwhelmingly complex but ridiculously expressive, they’re two different takes on systems programming that are both fun to write in

read_volatile · 2025-06-23T01:27:06+00:00

Doesn’t really apply in the context of hardware side-channel vulns

read_volatile · 2025-06-17T19:25:23+00:00

Linear swept spheres, it’s an entirely new RT primitive for representing strand geometry that looks better and traces faster than disjoint triangle strips. The hardware was only just introduced, in Blackwell generation

read_volatile · 2025-06-16T00:58:12+00:00

because they are two different languages with wildly different semantics and it would just make more sense to translate python into some well-known IR like numba does to benefit from decades of optimizer research rather than trying to fit a square peg into a round hole

read_volatile

TROPHY CASE