[zozbot234]

Even Rust has an unsafe subset. There's a meaningful question about how to make such an unsafe language as easy and comfortable to use as possible, and Zig is a decent answer to that particular question. The libraries Zig ships with are especially relevant here, rather than the core language per se: Rust's library facilities are outright terrible to write unsafe code with, because the usual requirements of safe code are assumed throughout and the whole point of unsafe code is to break those. (You can selectively relax those requirements, e.g. take &Cell<T> not &mut T, to allow for benign aliasing - but most stdlib code doesn't bother to!)

[kibwen]

Rust's library facilities are excellent for writing unsafe code with. Rust is very precise about which safety invariants must be upheld by which APIs, and does an excellent job documenting these, an excellent job at linting against improper usage of these APIs, and an excellent job leveraging the type system to reduce the need for unsafety in the first place. Writing unsafe Rust does indeed require its own degree of expertise compared to writing safe Rust, but fortunately it's trivial to just not write unsafe Rust; most Rust programmers only rarely have any cause to write unsafe code.

[zozbot234]

> but fortunately it's trivial to just not write unsafe Rust

The point of unsafe Rust is to "leave no room for a lower-level language". When writing lower-level facilities it's not uncommon at all to have to resort to unsafe. In practice, relying on the idiomatic standard library support within an unsafe block that might be breaking Safe Rust invariants is almost a sure way of shooting oneself in the foot as soon as the library function is doing anything more complicated than taking a pure value as input and returning a value as output.

[oytis]

"Like unsafe Rust, but more convenient to use" is basically every imperative language around there, I still don't understand the specific niche that Zig intended to fill

[applfanboysbgon]

It's weird to talk about "basically every" language, when you have exactly three mature systems languages: C, C++, Rust. C is from the 70s, C++ is an incoherent kludge on top of it, and Rust has a miserable DX (especially when actually used as a systems language instead of relying on pulling in 500 cargo dependencies that handle the unsafe code for you). Nothing else is used for serious systems programming. You don't need to do anything innovative, simply developing C-but-with-some-lessons-learned-since-1972 to a mature enough point would be more than sufficient to add value to the pitiful array of language options available. It is the language projects that try too hard to be novel and innovative and do brand new things that don't fill a real niche; they are academic experiments that will be use at most recreationally, never for real projects. If Zig doesn't seem interesting or unique enough to you, that's a good sign for it, because a new systems language doesn't need to be interesting or revolutionary.

[oytis]

C, C++ and Rust are the only ones that stuck, but programming languages graveyard is full of C++ killers. Rust is around because it offered something new.

[applfanboysbgon]

> but programming languages graveyard is full of C++ killers.

Literally just D? I'm not really aware of other serious efforts to modernise C/C++. Other than Rust, the world became completely fixated on GC languages that were inherently meant for higher-level purposes. Full-fledged attempts at memory unsafe languages in this century have been few and far between.