[pron]

Yes, we know how to offer memory safety; we just don't know how to offer it without exacting a price that, in some situations, may not be worth it. Memory safety always has cost.

Rust exists because the cost of safety, offered in other languages, is sometimes too high to pay, and likewise, the cost Rust exacts for its memory safety is sometimes too high to pay (and may even adversely affect correctness).

I completely agree with you that we reach for low-level languages like C, C++, Rust, or Zig, in "special" circumstances - those that, for various reasons, require precise control over hardware resource, and or focuses more on the worst case rather than average case - and most software has increasingly been written in high-level languages (and there's no reversal in this trend). But just as different factors may affect your decisions on whether to use a low-level language, different factors may affect your decision on which low-level language to choose (many of those factors may be subjective, and some are extrinsic to the language's design). Of course, if, like the vast majority of programmers, you don't do low-level programming, then none of these languages are for you.

As a long-time low-level programmer, I can tell you that all of these low-level languages suffer from very serious problems, but they suffer from different problems and require making different tradeoffs. Different projects and different people may reasonably want different tradeoffs, and just as we don't have one high-level language that all programmers like, we also don't have one low-level language that all programmers like. However, preferences are not necessarily evenly distributed, and so some languages, or language-design approaches, end up more popular than others. Which languages or approaches end up more popular in the low-level space remains to be seen.

Memory safety is clearly not "table stakes" for new software written in a low level language for the simple reason that most new software written in low level languages uses languages with significantly less memory safety than Zig offers (Zig offers spatial memory safety, but not temporal memory safety; C and C++ offer neither, and most new low level software written in 2025 is written in C or C++).

I can't see a strong similarity between Go, a high-level language, and Zig, a low-level language, other than that both - each in its own separate domain - values language simplicity. Also, I don't see Zig as being "a better C", because Zig is as different (or as similar) from C as it is from C++ or Rust, albeit on different axes. I find Zig so different from any existing language that it's hard to compare it to anything. As far as I know, it is the first "industry language" that's designed almost entirely around the concept of partial evaluation.

[hawk_]

Would you say writing something like a database (storage and query engine) from scratch is better done in Rust or Zig?

[jandrewrogers]

It depends on the purpose. If the objective is maximum scale and performance then Zig. The low-level mechanics of userspace I/O and execution scheduling in top-end database architectures strongly recommends a language comfortable expressing complex relationships in contexts where ownership and lifetimes are unavoidably ambiguous. Zig is designed to enable precise and concise control in these contexts with minimal overhead.

If performance/scale-maxxing isn't on the agenda and you are just trying to crank out features then Rust probably brings more to the table.

The best choice is quite arguably C++20 or later. It has a deep set of somewhat unique safety features among systems languages that are well-suited to this specific use case.

[pron]

First, I would avoid using any low-level language if at all possible, because no matter what you pick, the maintenance and evolution costs are going to be significantly higher than for a high-level language. It's a very costly commitment, so I'd want to be sure it's worth it. But let's suppose I decided that I must use a low-level language (perhaps because worst-case behaviour is really important or I may want to run in a low-memory device or the DB was a "pure overhead" software that aims to minimise memory consumption that's needed for a co-located resource heavy application).

Then, if this were an actual product that people would depend on for a long time, the obvious choice would be C++, because of its maturity and good prospects. But say this is hypothetical or something more adventurous that allows for more risk, then I would say it entirely depends on the aesthetic preferences of the team, as neither language has some clear intrinsic advantage over the other. Personally, I would prefer Zig, because it more closely aligns with my subjective aesthetic preferences, but others may like different things and prefer Rust. It's just a matter of taste.

[hawk_]

> the DB was a "pure overhead" software that aims to minimise memory consumption that's needed for a co-located resource heavy application)

Thanks pron for the reply. This describes it the best. To minimize resource consumption in a "pure overhead" software. It's currently written in Java and we are planning a rewrite in a systems PL.

[pron]

I would first spend a good amount of time figuring out if you can't just keep it in Java, because it's not just the rewrite in C++ that's expensive, but a low-level language would make maintenance and evolution costlier forever.

If memory footprint is the issue, I would recommend watching this: https://youtu.be/mLNFVNXbw7I. A lot of people misunderstand memory consumption, and even in Java there are many options to try. There could definitely still be situations where a low-level language is the only choice, but it's not a decision to be taken lightly.