[grumpyprole]

Zig is not memory safe and therefore at risk, just like C/C++, of future government legislation that outlaws the use of memory unsafe languages for some or all projects. The risk of such legislation is not insignificant: https://www.itpro.com/development/programming-languages/3694...

Personally I do not see the point of building an entirely new language and ecosystem that does not fully address this issue.

[jmull]

Well, technically, Rust is unsafe, unless they remove “unsafe”.

We’re really talking about safety on a continuum, not as a binary switch. Zig has some strong safety features, and some gaps. Well, one notable big gap, UAF. (Perhaps they’ll figure out a way to plug thisin the future? Perhaps by 1.0?)

Actually, safety has multiple axes as well.

> Personally I do not see the point of building an entirely new language and ecosystem that does not fully address this issue

The more safe languages make significant tradeoffs to achieve their level of safety. The promise of zig (I don’t know if it will ultimately achieve this, but it’s plausible, IMO), is “a better C”, including much more safety. For one thing, it has a great C interop/incremental adoption story, which increases the chance it will actually be used to improve existing codebases. The “RIIR” meme is a joke because, of course, there is no feasible way to do so for so many of the useful and widely used vulnerable codebases.

[ksec]

>Well, technically, Rust is unsafe, unless they remove “unsafe”.

I am somewhat surprised this is being mentioned. And the whole thread is without the usual people complaining it about unsafe.

Interesting changes happening on HN.

[justin66]

I'm sure the federal government's advocacy will aid Rust adoption massively. I mean, look at how Ada's adoption skyrocketed when it received DoD's stamp of approval.

[BaculumMeumEst]

the united states government is not going to outlaw the use of memory unsafe languages. that is an absurd idea. nothing in your links suggests they would even consider it. "moving the culture of software development" to memory safe language does not mean "we want to put you in jail for writing C".

[grumpyprole]

Where did you get the idea that jails are involved? Governments are clearly forming a position, if they fund new projects, they are quite likely to enforce that position. That's a significant market already.

[BaculumMeumEst]

they can enforce that position by funding projects that are written in languages that they believe are memory safe. they do not need, or want, to legislate that.

[pjmlp]

Funny that you mention that, EU does sponsor Rust development.

"Logical Foundations for the Future of Safe Systems Programming"

https://cordis.europa.eu/project/id/683289

As for US,

https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...

"NSA advises organizations to consider making a strategic shift from programming languages that provide little or no inherent memory protection, such as C/C++, to a memory safe language when possible. Some examples of memory safe languages are C#, Go, Java, Ruby™, and Swift®. Memory safe languages provide differing degrees of memory usage protections, so available code hardening defenses, such as compiler options, tool analysis, and operating system configurations, should be used for their protections as well. By using memory safe languages and available code hardening defenses, many memory vulnerabilities can be prevented, mitigated, or made very difficult for cyber actors to exploit."

[pjmlp]

No, however it may require that like with other kinds of dangerous chemicals, or hazourds goods, their use must follow strict requirements, like they already have to for high integrity computing.

[dakom]

Agreed, it's absurd. Jail time for writing javascript otoh...

[Borborygymus]

I guffawed, and I'm not afraid to admit it.

[grumpyprole]

And this attitude is why it's a serious issue in our industry. You clearly don't take security seriously, to the point that it's a laughing matter for you.

[dbalatero]

If you can't see why jailing people for writing JS is a comically absurd concept…

[grumpyprole]

Why is JS even relevant to this discussion?

[dgb23]

At some level you need languages that are not “memory safe”.

Memory safety comes with a cost. Either you pay for a GC runtime (Java) or for reference counting (Swift) or by not being able to express a correct program (Rust).

There are plenty of use cases where none of these tradeoffs are feasible.

To add, Zig comes with its own story around memory safety. Not at the static type system level and it’s not as comprehensive as other languages.

[aldanor]

"Express a correct program" that might end up being incorrect due to programmer's fault.

The difference is, you can use unsafe blocks/fns in Rust, in which case it becomes equivalent to C expressiveness-wise; but you can also do the opposite and forbid(unsafe_code) altogether.

[memefrog]

All programs can be incorrect. You cannot forbid unsafe code. Its use is necessary to implement basic functionality.

[aldanor]

You absolutely can forbid unsafe code (within a scope of a particular codebases) and some projects happily do it.

"The use is necessary" = absolutely not. Lots (most) of projects wouldn't ever need to dip into unsafe code. And then there's another category where authors think they do because "that's how they would do it in C++", but in reality they don't.

[memefrog]

> You absolutely can forbid unsafe code (within a scope of a particular codebases) and some projects happily do it.

No, you can't. The standard library contains 'unsafe', all over the place. Even if you discount that, large swathes of the library 'ecosystem' contain 'unsafe' and those that don't? They depend on libraries that do.

>"The use is necessary" = absolutely not.

Relying on some unsafe code that someone else has written is still using unsafe. The code in your dependencies is code that you use, that you depend on, and that affects you. It is meaningless to say you 'don't use unsafe code' if your code is just plumbing together a bunch of libraries that contain 'unsafe' code.

>And then there's another category where authors think they do because "that's how they would do it in C++", but in reality they don't.

This common sentiment from Rust developers is, just like all their other claims, totally unfounded. 'Oh you don't really need unsafe'. Then you explain why actually, yes, you do need unsafe and you're told that you're describing a 'special case'. Well guess what, every project is a special case in some respect. Every nontrivial project is going to have something that requires unsafe code, whether it's interfacing with hardware or using a system call that hasn't been wrapped or using a third party library or implementing a complex data structure or one of many many other various things that require 'unsafe'.

And even if you don't use 'unsafe' anywhere in your code and you somehow magically know that all of your dependencies are perfectly written and all the soundness bugs in the Rust compiler are fixed (at which point you might well ask: if you can assume all your Rust dependencies are perfect, why can't you assume all your C dependencies are perfect? And also, how can you be confident in any 'unsafe' code being safe if the rules for what is 'safe' to do in unsafe aren't even written down anywhere?), then what do you get? Almost nothing. 'Memory safety' is a very narrow category. As I said above, it means 'things Rust protects against'. It wasn't a term that was popularly used before Rust became known in the way Rust means it. Even to most Rust developers and contributors, right up until release it was widely assumed that it included leak freedom. And then a couple of weeks before release that was quietly dropped and memory-holed when it was shown that you could introduce memory leaks trivially. Large amounts of supposedly 'safe' unsafe code had to be rewritten and redesigned.

Rust just doesn't give you any the guarantees that Rust evangelists love to claim. Even in memory safety. In fact, almost every language out there is MORE safe than Rust, in the sense in which Rust claims to be memory-safe! The only ones that aren't are those without garbage collection.

[grumpyprole]

> At some level you need languages that are not “memory safe”.

Perhaps as an escape hatch (unsafe Rust) or a compiler target, but ideally not as a "general purpose language" as Zig is marketed as.

[Klonoar]

...that's like, completely ignoring the escape hatch in Rust of unsafe {}.

You're not limited by anything there, period.

[dgb23]

Rust is optimized for minimal _unsafe_ usage. That's the reason you choose it over C or Zig.

https://zackoverflow.dev/writing/unsafe-rust-vs-zig/

[anonymoushn]

Why would the legislature permit the use of unsafe Rust?

[quic5]

That totally misses the point of quality software. What good is memory safety if you medical device crashes because of an out of memory error?

What I'm trying to say: There are use cases where areas of safety are required other than memory safety.

[nevi-me]

It sounds like you'd be worrying about n-1 types of safety errors instead of n, which is arguably better.

[lmm]

There are use cases where safety beyond memory safety is required. But there are no use cases where memory unsafety is desirable, yet alone required.

[memefrog]

>there are no use cases where memory unsafety is desirable, yet alone required.

There are plenty of 'use cases' where Rust's guarantees (some vague but unenforceable promises around memory) are not worth the cost of using Rust (a very high cost). This is doubly true if you want to, say, not use any third-party libraries. If you use third-party libraries, you get essentially zero guarantees. And if you don't, you have to reinvent the world - and writing new data structures in Rust is a series of research projects, whereas doing so in C is trivial.

There are many situations where guaranteed 'memory safety' (a Rust propaganda term for 'having the guarantees we can provide but not the ones we can't provide') is not very important.

[quic5]

That is absolutely true. But but you can write memory-bug-free code in Zig but you cannot prevent heap allocations in most of the languages listed in the article, making it outright impossible to write certain software in them.

[grumpyprole]

Sure one can write memory-bug-free code in x86 assembly too. But how can you prove it? ATS is an example of a low-level systems language where you can prove it.

[ObscureScience]

As Zig promises "not hidden allocation", I assume you can build your allocator in Rust and then use it for all memory allocation in Zig.

[lmm]

A function that doesn't allocate doesn't mean it's safe. (Indeed if anything the opposite is more likely - copying is safe, if slow, writing to something that was passed in tends to be what breaks).

[memefrog]

You can't prove it in Rust either.

[ArtixFox]

formalized subsets of x86 assembly exist. Coq can be used as a macro assembler. tools to work with llvm ir exist, x86 can be raised up to llvm ir and proved, kinda bad way tho.

[jdrek1]

While that is true, there might be other requirements that prevent memory safe languages from being used. For example not having a heap available instantly disqualifies most of them. Or when you have simulations running where having constant OOB and other checks would be a massive slowdown. Now obviously your code should still be memory safe (because otherwise it's not correct anyway and you should fix the code), but not at the cost of runtime checks.

[throwawaymaths]

> But there are no use cases where memory unsafety is desirable, yet alone required.

Operating system bootstraps?

DMA management/volatile driver access?

Doubly linked lists?

[grumpyprole]

Memory safety is one aspect of quality yes, but is there any evidence Zig is a good fit for other quality aspects, e.g. static analysis tooling and correctness proofs? ATS is a low-level language that allows embedded proofs of correctness in the type system.

[johnisgood]

That article does not even mention Ada/SPARK... So much for safety. :P Yup, there is static analysis with Ada/SPARK and it is great. It is much more general-purpose than ATS, and there are other things in Ada/SPARK that increases safety in general, not only memory safety.

For what it is worth, Ada/SPARK has a strong presence in safety-critical domains like aerospace and medical devices, while Rust is gaining popularity in system programming and web development. ^^ I'm surprised that it is not as widespread. That, or lots of misconceptions.

[grumpyprole]

Yes Ada/SPARK is a great example.

[TheFragenTaken]

Not to be snarky, but you argument works both ways :). What good is a medical device if it leaks sensitive data, because it had been exploited by a use-after-free?

[Ygg2]

Memory errors are much, much less likely to occur with more memory than use after free.

[flohofwoe]

Zig enforces much more correctness than C or C++, which also results in much more memory safety, it's just not as extremist as Rust.

[TheRoque]

What would happen with existing codebases, sometimes built upon 2 decades of C or C++? Will the we "rewrite everything in Rust" ? lol

[pjmlp]

No, we will Rewrite in ChatGPT (or similar), and only architect jobs and the few AI druids that write the tooling will be safe.

[grumpyprole]

Maybe doing it for new projects is better than doing nothing?

[31tor]

AI will probably find all bugs or re-write all the software in minutes soon enough.

[templix]

I ditched Rust a year ago in favor of Zig and have not regretted since

Number of memory bugs in several fairly huge projects: 0

Zig is way more maintainable, leads to less code which translates to fewer bugs

How about that?

[throwawaymaths]

Someone will eventually build a static safety checker for zig. No reason memory safety has to be in the compiler.

[al_be_back]

IF a Gov subcontracts a company to design + impl a system, they as Customer (if you like) have the right to request specifics; maintenance & integration with the wider ecosystem is a massive concern in this case. That's not "legislation" though.

[bachback]

seriously?

"The National Security Agency (NSA) has recommended only using 'memory safe' languages, like C#, Go, Java, Ruby, Rust, and Swift, in order to avoid exploitable memory-based vulnerabilities."

[grumpyprole]

Yes seriously. The west is getting hacked and owned on a daily basis. The NSA recommendation shows that governments are starting to identify where the problem is.

[ArtixFox]

ah yes the east! The lovers of memory safety. West is getting hacked daily because every country is getting hacked daily.

[DrBazza]

log4shell enters the chat.

https://en.wikipedia.org/wiki/Log4Shell

[pjmlp]

Yes, it belongs to the remaining 30% of exploits, when we remove the 70% ones caused by memory corruption.

[johnisgood]

And they have not even mentioned Ada/SPARK... right.