aystatic

That's a hell of a lot more than "basic extrapolation." You're misrepresenting the original claim to fight against one that's trivially easy to dispute. "Bun has had an extremely high amount of crashes/memory bugs due to them using Zig" (which unlike Rust, doesn't prevent you from writing them) is a completely different statement than your "using Zig results in an extremely high amount of crashes/bugs." Implying that such a generalization was even on the table is insulting.

Yes, obviously you can write high-quality software in Zig. But does Zig categorically reject the kind of bugs Bun was suffering from? Rust does.

> Is your claim that using Zig ends in an "extremely high amount of crashes/memory bugs?" Wouldn't that mean that it isn't even feasible to make high-quality software with such a tool?

What caused you to hallucinate such a broad blanket statement? The point is the memory unsafety issues they ran into would be categorically impossible in safe Rust, which is why they're doing this in the first place.

i don't think it's that "wild". sure, i'm not so cynical as to feel hn's become a nazi bar or anything, but i am willing to recognize that some of the incidents i've witnessed could be reason enough for a trans person to want to avoid this site.

> It's neutral to this topic, it's about tech.

this thread began by xe bringing up failures in moderation affecting trans people

you are literally on hackernews

don't see why they would care to put out docs on it considering macos doesn't even permit kexts anymore, there'd be no gpu drivers anyways. i figured it was obvious we're talking in the context of running linux on these things, given the parent topic.

> There's also an Apple VP saying unified memory on AS doesn't leave room for DGPUs and separate VRAM

can you link to this? my intuition is that they're speaking on whether apple would include dgpus inside AS systems like they used to with nvidia and amd chips in macbooks, which i agree wouldn't make much sense atp

name 3 things using tinygrad that's not openpilot

> You cannot even use Nvidia/AMD/Intel DGPUs with AS Macs

afaik you technically can, except that m1/m2 force pcie bars to be mapped as device memory (forbids unaligned r/w), so most gpu software (and drivers) that just issue memcpys to vram and expect the fabric to behave sanely will sigbus. it's possible to work around this, and some people indeed have with amdgpu, but it'd absolutely destroy performance to fix in the general case

so it doesn't really have anything to do with apple themselves blocking it but rather a niche implementation detail of the AS platform that's essentially an erratum

> Runtime borrow checking: RefCell<T> and Rc<T>. Can give other examples, but admittedly they need `unsafe` blocks.

Where are the “subtle linguistic distinctions”? These types do two completely different things. And neither are even capable of being used in a multithreaded context due to `!Sync` (and `!Send` for Rc and refguards)

imo if you're sprinkling around `unsafe` in your codebase "liberally", you're holding it wrong. In general it's really not that hard to encapsulate most unsafety into a wide-contract abstraction; I’d argue where Rust really shines is when you take advantage of the type system and static analyzer to automatically uphold invariants for you

Glancing at the Cargo.toml, the package doesn't define any features anyways. `cargo b --no-default-features` only applies to the packages you're building, not their dependencies -- that would lead to very unpredictable behavior

You've managed to miss the entire point of using a union: the value is either a success payload or an error value, never both.

You can't encode that mutual exclusivity if you return a std::pair or std::tuple. That's exactly why std::expected, std::variant, or Rust enums exist, to make that constraint explicit in the type system.