Zig 2024 roadmap

Posted Feb 3, 2024 10:01 UTC (Sat) by b7j0c (guest, #27559)
In reply to: Zig 2024 roadmap by rrolls
Parent article: Zig 2024 roadmap

I wish more Rust advocates committed to writing something non-trivial with it (10k lines or more) before bashing us over the heads with advocacy. Please be sure to introduce async into the mix too. I don't dispute that some Rust advocates have actually passed through the crucible, but most have only trivial experience with it.

I recall (and was sadly part of) the Haskell hype wave about ten years ago...screaming that shared mutable state was a grievous sin and the only path to redemption was through Haskell's purity. Then I actually tried writing a large project in Haskell and was instantly deprogrammed. Rust in 2024 feels like a do-over of the Church of Haskell.

Zig 2024 roadmap

Posted Feb 3, 2024 10:24 UTC (Sat) by mb (subscriber, #50428) [Link] (13 responses)

>Please be sure to introduce async into the mix too.

Could you please show us what Zig does better than Rust when it comes to async programming?

>that shared mutable state was a grievous sin

Well, shared mutable state is one of the biggest sources of memory safety bugs.

Zig 2024 roadmap

Posted Feb 3, 2024 14:39 UTC (Sat) by b7j0c (guest, #27559) [Link] (12 responses)

Zig rolled back async which is outlined in the article above.

Zig is years away from being stable so they have years to get it right

Rust on the other hand is stuck with its async approach forever

Zig 2024 roadmap

Posted Feb 3, 2024 21:17 UTC (Sat) by khim (subscriber, #9252) [Link] (10 responses)

Does it mean that we are comparing something that actually exist and works (however poorly) to something that doesn't even exist?

And if you think Rust async story is awful I recommend you to try C++ one. Then come back and talk.

> Rust in 2024 feels like a do-over of the Church of Haskell.

It's only half-truth. Haskell asked you to redesign all your code and write everything from scratch.

It's literally impossible to translate many idioms from other languages into Haskell, not even unsafe Haskell.

Rust offers unsafe that actually makes it possible to adapt practically any designs from any language. It may not be a good idea to do that in many cases, but it's mere availability separates Rust craze from Haskell one.

As for Zig… I actually hope it'll do well: we really need a target to send all these “we code for the hardware” guys and Zig looks like nice one.

It would even, probably, work, for some time, at least.

Zig 2024 roadmap

Posted Feb 4, 2024 2:20 UTC (Sun) by tialaramex (subscriber, #21167) [Link] (9 responses)

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.

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. Know your allocator will have put this new Goose at an address in memory sixteen more than this string you're about to free up? Just make a pointer to it by adding sixteen to the string pointer, no problem, it's not important when you do this, before you free it, after, either works. To deliver Sequential Consistency it would deliberately lack multi-threading. To deliver type safety it would eliminate new-fangled types like booleans, while underscoring that enums are just integers, strings are just arrays of bytes, etc. instead of "Make illegal states unrepresentable" instead this language would strive to "Make all representations legal states".

I think such a language could be made to deliver software that's maybe a thousand times slower than Python, while remaining no easier to learn than C today, and with no better tooling, this would be entirely safe (though it's probably important not to tell the beneficiaries that you've made their language safe, say instead that it's now "authentic" or something). 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.

Zig 2024 roadmap

Posted Feb 4, 2024 18:10 UTC (Sun) by khim (subscriber, #9252) [Link] (8 responses)

> 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

Posted Feb 5, 2024 14:53 UTC (Mon) by pbonzini (subscriber, #60935) [Link] (7 responses)

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

Posted Feb 5, 2024 15:01 UTC (Mon) by farnz (subscriber, #17727) [Link] (1 responses)

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

Posted Feb 5, 2024 15:17 UTC (Mon) by khim (subscriber, #9252) [Link]

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

Zig 2024 roadmap

Posted Feb 5, 2024 15:18 UTC (Mon) by khim (subscriber, #9252) [Link] (4 responses)

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

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

Zig 2024 roadmap

Posted Feb 5, 2024 15:24 UTC (Mon) by pbonzini (subscriber, #60935) [Link]

Oh, I would be happy to be wrong!

Zig 2024 roadmap

Posted Feb 6, 2024 9:02 UTC (Tue) by pbonzini (subscriber, #60935) [Link] (2 responses)

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

Posted Feb 6, 2024 10:13 UTC (Tue) by khim (subscriber, #9252) [Link] (1 responses)

> 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

Posted Feb 6, 2024 15:25 UTC (Tue) by pbonzini (subscriber, #60935) [Link]

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

Posted Feb 4, 2024 7:59 UTC (Sun) by pbonzini (subscriber, #60935) [Link]

If it's either async or portability (because they are not going to add LLVM support for it), it's dead on arrival. There are some good things about Zig but it has serious NIH problems.

Zig 2024 roadmap

Posted Feb 3, 2024 11:44 UTC (Sat) by kleptog (subscriber, #1183) [Link] (5 responses)

I'm not sure what your point is. There are several large Rust projects (firefox 2.3MLOC, rust-lang 1.8MLOC / redox 1.3MLOC / diem, tikv, servo 300KLOC / verloren 200KLOC). Are you trying to suggest that Rust is unsuitable for large projects? Because that's clearly not the case.

In my experience, I found Rust coding simpler than C++ for two main reasons: the error messages from the Rust compiler are more helpful, and you don't have the mental load of remembering what the lifetimes are are of all the variables, because it's all stated in the code.

What is true is that it's much harder building certain algorithms. That article tries to build a mark-sweep garbage collector, because it's something that a borrow-checker would have trouble with. And comes to the obvious conclusion it's much harder in Rust. But that's not representative of the majority of programs.

That it's harder to write such programs in Rust is not a downside in my eyes. Most applications do not need a mark/sweep garbage collector. A Rust program requires more planning up front to make sure the data structures are well defined, but that more than pays for itself later on as your application gets larger. In my experience, after junior developers get used to writing Rust, they become better C++ programmers because they understand that the concept of object lifetimes is very important for a correct program, even if the compiler can't check them.

Zig 2024 roadmap

Posted Feb 3, 2024 14:50 UTC (Sat) by b7j0c (guest, #27559) [Link] (1 responses)

Where did I say Rust was unsuitable for lage projects?

What I said was most advocacy for Rust is coming from people who likely aren't using it as such, but should.

Zig 2024 roadmap

Posted Feb 6, 2024 8:54 UTC (Tue) by LtWorf (subscriber, #124958) [Link]

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

Zig 2024 roadmap

Posted Feb 23, 2024 18:05 UTC (Fri) by pawel44 (guest, #162008) [Link] (2 responses)

> 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

Posted Feb 26, 2024 10:31 UTC (Mon) by kelvin (guest, #6694) [Link] (1 responses)

> 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

Posted Feb 26, 2024 10:33 UTC (Mon) by kelvin (guest, #6694) [Link]

> Firefox originates from the Mozilla organization

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

Zig 2024 roadmap

Posted Feb 3, 2024 13:06 UTC (Sat) by wtarreau (subscriber, #51152) [Link] (2 responses)

I'm sure there are plenty of good developers with good intents in the rust church, but I also think that a good part of the most vocal ones who constantly repeat the same buzzwords in the face of anyone have no clue about what a computer is, how memory works, how a CPU works, what an instruction is, and so on, and they're causing more harm than good to the group they claim to represent.

Zig 2024 roadmap

Posted Feb 3, 2024 13:19 UTC (Sat) by mb (subscriber, #50428) [Link]

Don't worry. Nobody is taking C or even Zig away. You can use them forever. I promise.
And you can ignore Rust or anything else. No problem at all.
Deal?

Zig 2024 roadmap

Posted Feb 4, 2024 1:37 UTC (Sun) by roc (subscriber, #30627) [Link]

What evidence do you have for this?

Almost all the Rust developers and advocates *I* know (mostly from Mozilla and Google) are like myself: veteran developers of large C and C++ projects who have been burned over and over again by severe bugs that Rust prevents, and want the pain to stop for ourselves and our users. People who know very well what a computer is and what an instruction is.

Zig 2024 roadmap

Posted Feb 4, 2024 19:51 UTC (Sun) by roc (subscriber, #30627) [Link]

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?"