LWN: Comments on "Zig 2024 roadmap"

Zig 2024 roadmap

kelvin — Mon, 26 Feb 2024 10:33:21 +0000

> Firefox originates from the Mozilla organization

that was supposed to be "Rust originates from the Mozilla organization"

Zig 2024 roadmap

kelvin — Mon, 26 Feb 2024 10:31:32 +0000

> I didn't know Firefox is written in Rust. I thought it's mainly C++.

Firefox originates from the Mozilla organization, and while C++ is still the most used language in Firefox as measured by lines of code, significant parts of Firefox are now written in Rust.

Here's a project which tracks the language stats of Firefox: https://4e6.github.io/firefox-lang-stats/

C++ ~9.9 MLOC
JavaScript ~9.5 MLOC
C ~5.3 MLOC
Rust ~4.3 MLOC

Zig 2024 roadmap

pawel44 — Fri, 23 Feb 2024 18:05:30 +0000

> There are several large Rust projects (firefox 2.3MLOC[...]).

I didn't know Firefox is written in Rust. I thought it's mainly C++.

Zig 2024 roadmap

rghetta — Wed, 07 Feb 2024 12:59:13 +0000

Multithreaded yes. Fuzzed only on import interfaces, not on the complete codebase.

Zig 2024 roadmap

pbonzini — Tue, 06 Feb 2024 15:25:37 +0000

GCC and clang have promised for over 10 years to not use that latitude (not sure if left shift overflow is undefined, but anyway negative numbers can be shifted left and right with no other worries). So yeah it should be a no brainer.

Zig 2024 roadmap

kentonv — Tue, 06 Feb 2024 14:30:24 +0000

From: https://en.wikipedia.org/wiki/Memory_safety

> Memory safety is the state of being protected from various software bugs and security vulnerabilities when dealing with memory access, such as buffer overflows and dangling pointers.[1] For example, Java is said to be memory-safe because its runtime error detection checks array bounds and pointer dereferences.[1] In contrast, C and C++ allow arbitrary pointer arithmetic with pointers implemented as direct memory addresses with no provision for bounds checking,[2] and thus are potentially memory-unsafe.[3]

Zig 2024 roadmap

khim — Tue, 06 Feb 2024 10:13:31 +0000

> Nope:

Ugh. I think someone should propose to fix it, then. C++ have finally removed “undefined behavior” from there (crazy values still trigger undefined behavior when E2, the right operand is “strange”, but anything is accepted as E1, the left operand — starting from C++20), thus in practice compilers already have code to handle everything properly

Zig 2024 roadmap

pbonzini — Tue, 06 Feb 2024 09:02:03 +0000

Nope:

> 6.5.7 Bitwise shift operators
>
> [...] 4 The result of E1 << E2 is E1 left-shifted E2 bit positions [...] if E1 has a signed type and nonnegative value, and E1 * 2^E2 is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined
>
> 5 The result of E1 >> E2 is E1 right-shifted E2 bit positions [...] If E1 has a signed type and a negative value, the resulting value is implementation-defined

Zig 2024 roadmap

LtWorf — Tue, 06 Feb 2024 08:54:38 +0000

Most people believe that their project (however simple it might be) is the apex of difficulty.

Zig 2024 roadmap

LtWorf — Tue, 06 Feb 2024 08:50:57 +0000

Changing the definition to have the definition apply… classic!

Zig 2024 roadmap

atnot — Mon, 05 Feb 2024 20:35:19 +0000

C++ templates are probably actually a good example in multiple ways here. Anyone really into their types would sneer at someone calling templates generics, they aren't really generics for similar reasons as comptime isn't dependent typing. But they're still extraordinarily popular and helpful, and they make it very easy to sell people on proper generics by pointing at them and saying "they're like that, but better".

Zig 2024 roadmap

atnot — Mon, 05 Feb 2024 20:16:33 +0000

Yes, for anyone curious, one reason is that comptime isn't statically typed, it's dynamically typed but at compile time. For example, there is no way to write things like "comptime function that returns a function that returns either int or float", you can only write "comptime function that returns a function that returns some mystery surprise type". Like C++ templates, there's no type checking going on until after things have already been evaluated.

That said, you can do a lot of similar constructions and I think it faces a lot of similar issues regarding ergonomics when used in a non-fp language. Plus I think it does also demonstrate some of the benefits of having a single unified type system nicely without having to teach someone to read haskell-like syntax.

Zig 2024 roadmap

roc — Mon, 05 Feb 2024 19:02:17 +0000

What Zig does is not "dependent types" as in academia.

Zig 2024 roadmap

roc — Mon, 05 Feb 2024 19:00:23 +0000

Is it multithreaded and being fuzzed by experts?

Zig 2024 roadmap

atnot — Mon, 05 Feb 2024 16:26:59 +0000

> Nothing would have been avoided because Rust would have been just ignored.

You're just making my own arguments back at me now, but snarkier. I said this two messages ago.

Look, I like Rust too, it's my personal language of choice. There's no need for this level of aggressive defensiveness over someone on the internet thinking it would be useful to make some pretty marginal tradeoff differently. With the data we have, I'm convinced it makes sense today and I've explained why. You're welcome to disagree.

Zig 2024 roadmap

mb — Mon, 05 Feb 2024 16:14:45 +0000

>10x or more slowdown is not that uncommon if you enable these checks and then process
>large arrays of integers, which is definitely easily measurable in real world programs.

You do not have to decide globally, if you want overflow checks or not.

You can enable overflow checks in release builds and for the performance critical code you can use https://doc.rust-lang.org/std/num/struct.Wrapping.html
With that you get fast code and safe code where it matters.

Zig 2024 roadmap

khim — Mon, 05 Feb 2024 15:36:03 +0000

> In a hypothetical world where overflow checking was enabled by default

…Rust would have played the role of “new Haskell”: something which people talk about but don't use, except for a few eggheads and then rarely.

> And millions of mysterious production bugs and a hundred CVEs would have been avoided, at barely any cost to most programmers and one extra profiling iteration of a thousand for a few people writing heavily integer math code.

Nothing would have been avoided because Rust would have been just ignored. Rust, quite consciously, used up it's weirdness budget for other, more important, things.

Perhaps Rust with slow-integers-by-default would have saved someone from themselves, but chances are high that it would have hindered adoption of Rust too much: people are notoriously finicky about simple things and seeing these dozens of checks in the program which should be, by their understanding, two or three machine instructions long would have gave Rust a bad reputation for sure.

> This is just based on just testing my own programs.

If you are happy with that mode then why couldn't you just enable it in your code? -Z force-overflow-checks exists precisely because some people like these overflow checks.

I'm not big fun of them because in my experience for hundreds of bugs where some kind of buffer is too small and range checks are catching the issue there exist maybe one or two cases where simple integer overflow check is capable of catching the issue which is not also caught by these range checks. Certainly not enough to warrant these tales about millions of mysterious production bugs (why not trillions if you go for imaginary unjustified numbers, BTW?)

Zig 2024 roadmap

pbonzini — Mon, 05 Feb 2024 15:24:24 +0000

Oh, I would be happy to be wrong!

Zig 2024 roadmap

khim — Mon, 05 Feb 2024 15:18:59 +0000

P1236R1 changed definition to precisely what you say in C++20.

Are you sure C23 haven't picked up that change?

Zig 2024 roadmap

khim — Mon, 05 Feb 2024 15:17:38 +0000

You are talking about right argument, pbonzini talks about left one.

Zig 2024 roadmap

atnot — Mon, 05 Feb 2024 15:09:00 +0000

> 10x slowdown is “barely measurable”? What world do you live in?

This is just based on just testing my own programs. Which are generally bottlenecked on memory not integer math, as most programs are. Even then, 10x is a ridiculous number, I can't find anyone reporting anything even close to 2x in real world programs.

But here, let's look at some actual data, someone running specint:

> On the other hand, signed integer overflow checking slows down SPEC CINT 2006 by 11.8% overall, with slowdown ranging from negligible (GCC, Perl, OMNeT++) to about 20% (Sjeng, H264Ref) to about 40% (HMMER). [...]
> Looking at HMMER, for example, we see that it spends >95% of its execution time in a function called P7Viterbi(). This function can be partially vectorized, but the version with integer overflow checks doesn’t get vectorized at all. [...]
> Sanjoy Das has a couple of patches that, together, solve [some missed optimizations]. Their overall effect on SPEC is to reduce the overhead of signed integer overflow checking to 8.7%.
https://blog.regehr.org/archives/1384

Specint is a bit biased towards HPC but we see, even there most normal business logic style code doesn't lose out at all. The losses are dominated by a few, very hot functions that are presumably heavily optimized already.

As you note, overflow checks interfere with vectorization, but so do millions of other things, it's notoriously finicky. Rust regularly misses autovectorization because of bounds checks too. It's very hard to write non-trivial code that vectorizes perfectly and reliably across platforms by accident.

Which gets me to the actual point I was getting at you ignored: In a hypothetical world where overflow checking was enabled by default, here's how this would have gone in a profiling session:

"why is hmmer::P7Viterbi() so slow now?"
"oh, it's not vectorizing because of overflow"
"let me replace it with a wrapping add, or trap outside of the loop body, or use iterators since I'm using Rust"
"that's better"

And millions of mysterious production bugs and a hundred CVEs would have been avoided, at barely any cost to most programmers and one extra profiling iteration of a thousand for a few people writing heavily integer math code.

Zig 2024 roadmap

farnz — Mon, 05 Feb 2024 15:01:15 +0000

That then makes x >> y and x << y a multiple instruction sequence, not a single instruction sequence. On AArch64, for example, LSL x1, x2, x3 is defined as "take the bottom 6 bits of x3, shift x2 left by that amount"; this ignores the sign bit completely, and to implement the behaviour you're suggesting, I'd have to check the sign bit of x3, then choose whether to do an LSL, LSR, or ASR instruction based on signedness of x2's current contents and sign bit of x3.

Zig 2024 roadmap

pbonzini — Mon, 05 Feb 2024 14:53:57 +0000

I never quite understood why shifts of negative values are still an issue now that C23 mandates twos complement representation. They should be changed to be equal to x*2^n for left shift, and x/2^n rounded towards negative infinity for right shift.

Zig 2024 roadmap

khim — Mon, 05 Feb 2024 13:49:25 +0000

> But it's usually barely measurable in real world programs.

10x slowdown is “barely measurable”? What world do you live in?

> I should say Rust has this issue a bit too, thanks to the regrettable decision to disable overflow checks in release mode by default.

If you are talking about arithmetic (which is wrapping in Rust when not in debug mode) then they really had no choice: while trying to vectorize code with these checks is not impossible infrastructure is just not there. And they really had no resources to add custom passes to LLVM which would make the whole thing usable from Rust with non-wrapping arithmetic.

10x or more slowdown is not that uncommon if you enable these checks and then process large arrays of integers, which is definitely easily measurable in real world programs.

And having different rules for integers in arrays and standalone integers would be just too weird (although it may be interesting optional mode of compilation, now that I think about it).

Zig 2024 roadmap

atnot — Mon, 05 Feb 2024 13:44:36 +0000

> comptime instead of generics is a non-starter, I suspect, since generics in Rust lay out data differently, not just change the code

You totally can do that! Zig and other languages with dependent-ish types generally have a unified type system for all types, including types themselves. In practical Zig terms, this means that you can't only return an integer from a comptime function, but the integer type itself, or a different type _depending_ on the arguments (that's where the term comes from), or an arbitrary struct type you just made, or a function, or anything really.

So in mathematical terms it's actually far more powerful than anything Rust has. Rust can do a few of these things as bespoke features but it's not a generalized system in the same way it is in dependently typed languages. This has its advantages and disadvantages, with dedicated syntax generally being more compact, readable and debuggable but also leaving weird incongruences between various parts of the language that are hard to solve, as Rust is experiencing.

It's been a pretty hip thing to experiment with somewhat recently (at least before effect systems really hit the scene) so I'm looking forward to seeing how Zig fares with it in a non-academic setting.

Zig 2024 roadmap

farnz — Mon, 05 Feb 2024 10:22:54 +0000

comptime instead of generics is a non-starter, I suspect, since generics in Rust lay out data differently, not just change the code. But comptime instead of macros and some uses of traits would be extremely interesting to see; I suspect that there's a lot of cases where people currently have to write procmacros in Rust where comptime would be a good fit.

Zig 2024 roadmap

ballombe — Mon, 05 Feb 2024 10:13:17 +0000

> The program might not do what you want, but this is not what memory safety means.

This is my point. rust defines memory safety, not the other way round.

Zig 2024 roadmap

rghetta — Mon, 05 Feb 2024 07:02:55 +0000

I don't know for C, but I work on a 5MLOC C++ very active project, and in my experience memory errors are not so frequent, especially after C++/11. Each year we have *some* memory bugs (and none in production) but hundreds of logic errors. RAII, smart pointers, references, even templates can make a huge difference in preventing resource bugs, imho.

Zig 2024 roadmap

roc — Sun, 04 Feb 2024 20:28:19 +0000

I think the question is misplaced because we're not actually pouring resources into Zig. Even advocates agree that it's years away from stabilization, and it's not going to get used much until after that happens. In the meantime, there are some interesting ideas like comptime that will get some testing.

We might even discover at some point in the future that "Rust, but comptime instead of generics and macros" would be an improvement on Rust.

Zig 2024 roadmap

Wol — Sun, 04 Feb 2024 20:18:11 +0000

Yup. I got the impression the LLVM people were quite happy to fix the problems, but if it's pervasive right through the IT and implementation, I can understand it being a long and painful process.

Certainly I've seen a fair few complaints that "C/C++ isn't strict, so the LLVM isn't strict. Rust is strict and it breaks".

Cheers,
Wol

Zig 2024 roadmap

roc — Sun, 04 Feb 2024 19:51:14 +0000

FWIW I wrote about half of a 250K-ish line system (Pernosco) in Rust, using async for parts of it. It was a great experience and I'll use Rust for new production systems whenever I possibly can. It's not just about reliability and safety but also easy parallelism and maintainability. And FWIW I've been coding in C++ for over 30 years including stints at Mozilla and Google.

*My* wish is that more advocates of less safe languages such as C, C++ and Zig had experience working on multi-million line multithreaded programs that are constantly scrutinized by malicious experts. Then we'd hear less of "have you tried just not writing memory safety bugs?"

Zig 2024 roadmap

ojeda — Sun, 04 Feb 2024 19:39:30 +0000

So, you are saying we can avoid temporal memory safety mistakes by "thinking carefully". But somehow, the same argument would not apply to spatial memory safety mistakes, and in fact, we would "constantly" make them.

Well, according to the Chromium project (and other projects), some of those issues you say we would not "run into in practice" are, in fact, quite prevalent sources of vulnerabilities: "Around 70% of our high severity security bugs are memory unsafety problems (that is, mistakes with C/C++ pointers). Half of those are use-after-free bugs."

> If that was Zig code, using a slice for that buffer would have given me a panic

...unless the safety checks are disabled, e.g. via -OReleaseFast.

> Rust would not let code with those bugs compile, it would also make it a lot harder to write anything in the first place

I mean, you state this as a fact, but you also recognize you have almost no experience with Rust. If you already think in terms of lifetimes anyway as you said, then writing safe Rust should be a very nice experience.

> I hope I have at least demonstrated that the dismissive, rhetorical question of "Why are we, as an industry, pouring resources into non-memory-safe languages [like Zig]?" is equally misplaced :)

It is not misplaced. The point is that nowadays we know how to do better. The industry (and other entities) is interested in getting away from memory unsafety as much as possible. Thus introducing a new language that essentially works like C (especially if you consider existing tooling for C) is not a good proposition.

Zig 2024 roadmap

roc — Sun, 04 Feb 2024 19:19:29 +0000

I don't think LLVM is a lost cause there --- John Regehr and others are doing heroic work in this area --- but it sure is a problem.

Zig 2024 roadmap

khim — Sun, 04 Feb 2024 18:10:42 +0000

> My thinking for those "Portable assembler" people is a revision of C which eliminates all the Undefined Behaviour and in the process also removes any semblance of modern convenience or decent performance.

It wouldn't work. Because they are after efficiency, just feel that compiler have to provide it if possible and leave their low-level tricks alone if it doesn't understand something.

Usually they even realize that some unlimited undefined behaviors are needed (look on their semi-serious proposals… Loosening the basic model part is precisely about that), they just couldn't accept the fact that it's either fully defined behavior, or fully undefined behavior, their dreams of, somehow, pulling ~~the rabbit out of the hat~~ what-the-hardware-does behavior into high-level languages just wouldn't work.

> This hypothetical language would have wrapping overflow for all its integer types, it would define all bounds misses to result in a zero value, and its memory model would be an idealized vast array of raw bytes, thus enabling Provenance Via Integers.

And even if you would invent a way to define show right shift is supposed to work… they would immediately turn around and ask why compiler doesn't do the sensible thing and doesn't put local variables in registers (which is impossible in such a language).

> I think such a language could be made to deliver software that's maybe a thousand times slower than Python

No, it wouldn't be even that much slower if you would use it as “portable assembler” and would write code like you are writing assembler and compiler (that may usually do some optimizations, but not if you “code for the hardware”) just doesn't do anything. The problem is that they wouldn't be satisfied, anyway.

> They wouldn't necessarily _write_ software in this revised C, but they could spend their days arguing with each other about the definitions, which keeps them off the streets.

They don't really spend that much time arguing about things. They actually produce code and their rants are usually limited to complains about how this or that compiler misunderstands their genious ideas and instead of producing optimized code breaks their valuable programs.

When asked about what compiler should do instead they usually either provide random incompatible answers or just say that “compiler should preserve hardware semantics” without elaborating what that phrase even means.

Zig 2024 roadmap

kentonv — Sun, 04 Feb 2024 17:56:18 +0000

What do you mean by "bypass refcounting"? JavaScript doesn't use refcounting.

Also "memory safety" isn't really about collecting garbage / leaks, it's about preventing memory access errors like out-of-bounds access or use-after-free. A garbage collector which never actually collects anything would technically be "memory safe".

Are you saying that e.g. JavaScript in Node.js doesn't sufficiently prevent such memory errors? Can you give a specific example?

Zig 2024 roadmap

IntrusionCM — Sun, 04 Feb 2024 17:18:34 +0000

In theory, thanks to Garbage collection, yes.

In practice, especially given its (ab-)use in backends, no.

Pure JavaScript as a browserspecific, client side only language has become niche.

Most complex frameworks have the need to bypass refcounting and thus make the GC collector useless.

Same goes for example for Java.

Memory safety isn't perfect in Rust, either - just far better as it was integrated into the core design of the language.

Zig 2024 roadmap

mb — Sun, 04 Feb 2024 17:18:22 +0000

>you could build this type of allocator using only safe code

Certainly.

But note that the allocator traits are unsafe. That means if an allocator implements these traits, it promises to not violate memory safety rules. Therefore, an allocator can't reduce Rust's 100%-safe guarantee, unless it is unsound. An unsound allocator is a bug.

And if you don't register the allocator to Rust by implementing the unsafe trait and your allocator is 100% safe Rust, then it's just a normal piece of code that is also 100% memory safe. Doesn't reduce Rust's guarantees either.

Rust's safety guarantees assume and depend on all unsafe code and the operating environment (all linked libraries, the operating system and the hardware) to be sound and not violate Rust's memory model.

Of course that means in practice one will probably find bugs in unsafe or foreign language code that breaks Rust's safety guarantees. A CVE in libc, for example (https://lwn.net/Articles/960289/). But that is an argument for pushing Rust code even further down the chain of dependencies, into the operating system.

Zig 2024 roadmap

mpr22 — Sun, 04 Feb 2024 16:40:16 +0000

There kind of is "compile-time checking" for a hammer; the manufacturer calls it "quality control", and it's there to make sure that the carpenter, if they do their job properly, won't get injured in a way that attracts an unacceptable financial liability to the manufacturer or tool supplier.

Zig 2024 roadmap

matthias — Sun, 04 Feb 2024 16:39:09 +0000

> Sound Rust does not provide 100% memory safety, only the illusion of 100% memory safety.

Rust is quite precise in what memory safety means. First and foremost it means that it is impossible to invoke undefined behavior, e.g. data races. It certainly does not mean that the owner of a portion of memory cannot write data to the memory.

> I work on a C software that use a custom memory manager. It works this way:
> Use mmap to allocate a large ( 1GB to 1TB) array of virtual memory.
> The custom memory allocator will give you a range of indices that you can use in this array.

The question is: Who owns the array? If it is owned by the allocator, then all reads and writes must go through the allocator. Only the function/struct that owns this array is allowed to access it. Of course you can give away mutable access to the array, but again, there can be only a single owner of the mutable reference.

> From the point of view of rust (and valgrind!), all the memory is owned by main(), there is no pointers, all accesses are checked to be within the bound of the allocation, all memory is initialized etc.

Why should the memory be owned by main()? It should be owned by your custom allocator (which is transitively owned by main()).

> But really, there is nothing that prevent the code to write outside the allocated range of indices as long as it is inside the array. So buffer overflow are still possible, even though the memory manager is safer than malloc.

It depends how you give access to the memory. If you really only give indices and have a functions in the allocator for reads and writes, then yes, you have a function that can write to arbitrary locations in the array. It is perfectly safe to do so and this will not invoke undefined behavior. The program might not do what you want, but this is not what memory safety means.

If you you give slices of the array, then each receiver of a slice can only write to that slice and you have bounds checking etc. This is the only way different parts of the program can modify parts of the array independent of each other. However, rust will make sure that they only write to the parts of the array, the custom allocator has reserved for them. Writing such an allocator certainly requires some unsafe code to split up the one array into several smaller pieces that have independent lifetimes. There is at least split_at_mut() as a safe abstraction, so you could build this type of allocator using only safe code, but you certainly will need a bit more fine grained control if you really write an allocator yourself.

Valgrind will only see individual allocations, but rusts ownership tracking can be much more fine grained than a single allocation from the system allocator. And clearly it will ensure that you cannot overwrite the stack and that there are no data races and much more.

Zig 2024 roadmap

kentonv — Sun, 04 Feb 2024 15:55:53 +0000

What do you mean? JavaScript is memory-safe.