Zig, the Small Language • Hacker News Board

Re: Zig, the Small Language

#311

Post by gautamdivgi » Thu, Sep 08, 2022, 1:18 AM UTC

brundolf wrote: post #297

It just occurred to me, Zig could be a great learning-language for CS When I was in college we mostly used C++, which exposed (and thereby taught) a lot of core concepts around how computers and low-level languages work. But it was also a bit of a nightmare for... unrelated, obvious reasons. Rust is great for building software, but as a learning language I think it introduces too many additional concepts, has too man…

I think it’s supposed to be C without all the pain and misery. C++ without pain and misery is allegedly Rust :).

But we were thrown into C and UNIX when I was at university. I think I’ll have Bus Error and Segmentation Fault core dump messages etched on my gravestone and may be request that the flower vases be labeled gdb (I forget the native debugger that came with the UNIX flavor I was using).

Either way we did data structures and algorithms with Pascal. But I think c should be essential learning from a systems perspective. Maybe I’m too old though.

Re: Zig, the Small Language

#312

Post by dundarious » Thu, Sep 08, 2022, 1:24 AM UTC

davidatbu wrote: post #181

ok123456 wrote: post #120

Earlier quoted context omitted.

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=RUST+Memory

Out of the 10 top ones in that list about Rust (there's one about C code in GCC), 1. 6 are because of unsafe code. 2. 3 are because of ouf-of-memory (OOM) errors. 3. 1 is due to unsafe code in `tokio`, but I think it's fair to consider unsoundness in tokio's safe abstractions (over unsafe code) as unsoundness in "safe Rust" because the crate is so foundational, even if its third party. Regardless, I don't think any o…

The original claim was:

> The borrow checker doesn't stop most memory errors, just the easy ones at the cost of making it painful to write basic data structures

I'm not the OP but I think the point here is that the borrow checker is only applicable for the "easy" code (which does make up an awful lot of code), but even "basic data structures" very often require abandoning the borrow checker. In such a case, it's perfectly accurate to say "the borrow checker doesn't stop most memory errors" since you must turn it off when you write the code responsible for "most memory errors" -- at least that is the case in my experience.

So in this type of discussion, consider arguments about the capabilities of "the borrow checker" as analogous to arguments about "the memory safety of Rust in general", rather than taking it so literally.

If you want to make a sensible argument on this front, it should be about unsafe belonging mostly in crates that have been thoroughly looked over and battle-tested by the community. That is after all, a major reason why the number of such errors is still impressively small. But unsafe errors are still Rust errors, and while the borrow checker is wonderful, it and Rust should still be held accountable for problems in necessary code that requires disabling the borrow checker.

I think Zig does pretty well on this front, with there being pros and cons to not having a clearly demarcated "unsafe" boundary built into the language. Lacking an unsafe keyword does make it more unsafe, but in my experience, not very much.

Re: Zig, the Small Language

#313

Post by sarchertech » Thu, Sep 08, 2022, 1:37 AM UTC

Jarred wrote: post #142

If you want to build stuff using Zig full-time, Oven ( https://oven.sh ) is hiring Zig engineers. Email jarred@oven.sh to apply

I noticed you deleted the tweet where you said employees would need to grind for the first 9 months, and that if you're looking for somewhere with a good work life balance this job isn't for you.

Does that mean you've rethought that position?

https://news.ycombinator.com/item?id=32584211

Re: Zig, the Small Language

#314

Post by dtolnay » Thu, Sep 08, 2022, 1:38 AM UTC

hsn915 wrote: post #305

stephc_int13 wrote: post #300

Earlier quoted context omitted.

As far as I am concerned, the alleged "memory safety" benefits of Rust do not have much more value or weight than wishful thinking, this kind of claim can only gain strength by standing the test of time. Computer security is a real problem that must be fully addressed at every step of the design of a system, language and tooling can help, a bit, not much. Rust is not a "safe" language. It might be -safer- than C/C++,…

Here's a hypothesis I'd like to see Rust advocate attack: In any serious system written in Rust, significant portions of it will have to be written in "Unsafe Rust".

https://github.com/diem/diem is 387,952 lines of Rust code across 169 crates. In total there are 3 lines of unsafe code, which is less then 0.001% (1 thousandth of 1%).

Re: Zig, the Small Language

#315

Post by steveklabnik » Thu, Sep 08, 2022, 1:41 AM UTC

hsn915 wrote: post #305

stephc_int13 wrote: post #300

Earlier quoted context omitted.

As far as I am concerned, the alleged "memory safety" benefits of Rust do not have much more value or weight than wishful thinking, this kind of claim can only gain strength by standing the test of time. Computer security is a real problem that must be fully addressed at every step of the design of a system, language and tooling can help, a bit, not much. Rust is not a "safe" language. It might be -safer- than C/C++,…

Here's a hypothesis I'd like to see Rust advocate attack: In any serious system written in Rust, significant portions of it will have to be written in "Unsafe Rust".

You’d have to demonstrate that this is the case before it’d be worthy of “attacking.”

You’d also have to define “serious system” and “significant portion” and if you really do mean “any,” that is, is a single counter example enough, and if not, what percentage of them would need to be so for this to be true. You’d also have to say what’s in bound or not, is it just the code you wrote for the system, is it any dependencies, etc etc etc. Does “significant” mean “large amount” or does it mean “most important”?

Re: Zig, the Small Language

#316

Post by skohan » Thu, Sep 08, 2022, 1:50 AM UTC

gautamdivgi wrote: post #311

brundolf wrote: post #297

It just occurred to me, Zig could be a great learning-language for CS When I was in college we mostly used C++, which exposed (and thereby taught) a lot of core concepts around how computers and low-level languages work. But it was also a bit of a nightmare for... unrelated, obvious reasons. Rust is great for building software, but as a learning language I think it introduces too many additional concepts, has too man…

I think it’s supposed to be C without all the pain and misery. C++ without pain and misery is allegedly Rust :). But we were thrown into C and UNIX when I was at university. I think I’ll have Bus Error and Segmentation Fault core dump messages etched on my gravestone and may be request that the flower vases be labeled gdb (I forget the native debugger that came with the UNIX flavor I was using). Either way we did dat…

Zig might be a good alternative as it matures. As far as I understand, zig makes a lot of things explicit which are not in C, like explicitly passing the allocator when it’s needed. This might be even more edifying than C which has a little bit of magic going on.

Re: Zig, the Small Language

#317

Post by tialaramex » Thu, Sep 08, 2022, 1:50 AM UTC

brundolf wrote: post #297

It just occurred to me, Zig could be a great learning-language for CS When I was in college we mostly used C++, which exposed (and thereby taught) a lot of core concepts around how computers and low-level languages work. But it was also a bit of a nightmare for... unrelated, obvious reasons. Rust is great for building software, but as a learning language I think it introduces too many additional concepts, has too man…

I still think the first language when I was an undergraduate (so, last century) was the correct choice: an ML in our case SML/NJ

The stuff about how this actually works can come later, we're not teaching electronics students here (or are we? Zig as first language for electronics students makes some sense)

I agree that (safe) Rust has too much stuff for a first language for Computer Scientists. Lifetimes! Polymorphism! Two entire Macro systems! although it's simpler than C++, surely nobody should teach that as first language.

Zig has a compelling case as a second language if you learned something less practical like ML as first language. Apparently a colleague now teaches Haskell to the equivalent undergraduate classes as a second (or maybe third?) language, and I think Rust would also fit in there for the same purpose but given how practical the current first language is (now Java) he probably doesn't want more practicality.

One thing I'd say for Rust is that we need to start teaching Safety and Correctness early. There's a reason the Medics don't wait until year four to do Ethics and Consent. If we want to stop writing software which is crap we need to start teaching the next generation of CS graduates that's not OK up front, not just in some Friday afternoon class about the Therac-25 which has maybe 40% attendance.

Re: Zig, the Small Language

#318

Post by AndyKelley » Thu, Sep 08, 2022, 2:05 AM UTC

ptato wrote: post #82

synergy20 wrote: post #76

is zig still one man's work and has a hit-by-a-bus risk factor? checked it a few weeks ago for a few hours, looks good, but I don't feel I need switch from c to zig yet. will re-try after 1.0 is out.

The "People" section on the right on their github organization[0] shows members of the core team. It's also free software and surrounded by a passionate community, so it's pretty hard that it would die out. Andrew is irreplaceable though. [0] https://github.com/ziglang

Legally I am extremely replaceable because Zig Software Foundation is a 501(c)(3) non-profit, and I am only one of three board members who can make legally enforceable decisions.

As a software engineering lead I am becoming more replaceable every year as others learn to maintain various components of the project. Recently, I am proud to have dropped to having fewer than 50% of total commits in the Git repository for the compiler.

Re: Zig, the Small Language

#319

Post by burntsushi » Thu, Sep 08, 2022, 2:18 AM UTC

azakai wrote: post #291

pcwalton wrote: post #281

Earlier quoted context omitted.

> Rust has the same thing. In Rust all of those features are delineated by unsafe. For one, you can disable unsafe with a compiler switch; Zig has no such equivalent feature. Moreover, we shouldn't assume that Zig pointers are the only feature that breaks spatial memory safety. It was simply the first one I found after like 2 minutes of looking through the docs. After like 5 more minutes I found another: extern union…

> Moreover, we shouldn't assume that Zig pointers are the only feature that breaks spatial memory safety. It was simply the first one I found after like 2 minutes of looking through the docs. After like 5 more minutes I found another: extern unions. Just now I found another: sentinel-terminated pointers, since you could delete the sentinel. You're right on each of those points. But (AFAIK) all those types are explici…

I do think the 'unsafe' notation is the crucial bit here. Rust has stuff that is heavily (although not completely) motivated by C interop. For example, 'union' in Rust is something that is rarely used outside of C interop. (With some notable exceptions in the standard library.) But, crucially, in order to actually use a Rust 'union', you do have to utter the 'unsafe' notation.

I'm not sure I have an opinion as strong as pcwalton here, but I do think that you can't call yourself memory safe (even on a particular dimension) if you have to delineate all of the various language features that are unsafe without having to somehow explicitly annotate it as such in the source. Or at the very least, I don't think you can say that Zig's spatial memory safety is on even footing with Rust's (assuming pcwalton's characterization of Zig's unsafe features is correct).

The annotation really is the point here, because you can pin everything (modulo bugs and OS features that permit subversion) with regard to memory safety down to an unsafe annotation somewhere. That's a powerful tool that crystalizes what it means to be a "safe API."

As I said, I don't necessarily share pcwalton's strong opinion (although I do weakly agree with him) that having an annotation like 'unsafe' is the only way to go. I do think it's possible to go the Zig route and reduce memory safety bugs. But we should be very clear eyed about the claims being made and how comparisons are drawn.

Re: Zig, the Small Language

#320

Post by burntsushi » Thu, Sep 08, 2022, 2:21 AM UTC

azakai wrote: post #304

pcwalton wrote: post #292

Earlier quoted context omitted.

Well, let's turn this around. Is C++ spatially memory safe? C++20 has slices (ranges). They're bounds checked, via the .at() method. You can get the integer overflow semantics of Zig with "-fsanitize=signed-integer-overflow -fsanitize=unsigned-integer-overflow -fsanitize=float-cast-overflow". You could write a checker that enforces that only these features are used (in fact, this checker basically exists--ISO Core C+…

Yes, technically there might exist a subset of C++ as safe as idiomatic Zig. But in practice inertia and legacy code and lack of ergonomics etc. work against that subset of C++ becoming popular - does anyone constantly type .at()? Zig can do better, if it doesn't squander the opportunity. In other words, this isn't about theoretical subsets of a language. It's that there is an opportunity when designing a new languag…

I think it's worthwhile to point out that there are two threads of argument here. One is what it means to be spatially memory safe. Another is whether and how effective various mitigations are.