Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig, the Small Language

zserge.com

Post reply on HN
Print view View original

151–160 of 429 posts

Re: Zig, the Small Language

#151

Post by pcwalton »

verdagon wrote: post #121
cercatrova wrote: post #83

Why should I use Zig coming from Rust? It doesn't seem that Zig actually solves the memory problems that Rust does.

I think there's three reasons one might use Zig instead of Rust. These are just opinions, and I would love yall's thoughts. First: there's only a certain amount of effort that one is willing to put into accomplishing one's goals, effort that will be spent on learning tools and building a project. It's not unlimited. If I just want to make a game where a character walks around the world, and I only have 20 or so hours…

> Third: There are a lot of cases where the cost of memory safety just isn't that high, and Zig's mitigations are more than sufficient.

But then why not just use a GC'd language? It isn't 1995 anymore; most apps are written in GC'd languages. C++ makes sense when you already have a lot of C++ code, but if you're talking about new code, I don't see a lot of room for a language without memory safety.

Re: Zig, the Small Language

#152

Post by pid-1 »

amelius wrote: post #94
10000truths wrote: post #46

Earlier quoted context omitted.

It's usually not the disk space that's the bottleneck, but rather, the CPU instruction cache. On modern Intel and AMD CPUs, the jump from L1 -> L2 alone can triple the latency of a memory fetch. For a "hello world" application, that doesn't really mater, but for, say, an OS kernel, it becomes really important to keep as much of your hot-path code in i-cache as possible.

It requires a special kind of programming. Maybe they should just release the benchmarks instead of saying "small". By the way, I wouldn't be surprised if Rust 2.0 will feature a typechecker that guarantees that everything fits in the L1 cache.

I don't think most CPUs expose caches in any way. You can only hope a variable will be cached.

Re: Zig, the Small Language

#154

Post by oconnor663 »

beltsazar wrote: post #124

Why would anyone use a new systems programming language that is not safe? Zig might be better than C in some aspects, but is it worth it to switch to Zig when you realize that it's not much safer than C? [0] [0]: https://www.scattered-thoughts.net/writing/how-safe-is-zig/

The simple answer to your question (if you really meant it as a question) is that memory safety comes with ergonomic and performance costs. The Rust project is an experiment in hammering those costs down as small as possible, and sometimes maybe even turning those costs into benefits. But the costs do exist, and of course not every project in the whole world will want to pay them.

Re: Zig, the Small Language

#155

Post by pcwalton »

ok123456 wrote: post #110
cercatrova wrote: post #100

Earlier quoted context omitted.

But the problems still remain? The borrow checker is an automated way of what one would normally check by hand, or in their mind. Removing it means that, just as one does in C, one must still check for memory errors and will more likely miss such errors more than the borrow checker does.

They have a build in arena allocator. That would cover a lot of manual frees. Also they have the defer syntax to defer your call to free. 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. There are many memory related CVE on common rust libraries.

> 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.

This is completely untrue. Anyone who has maintained a large Rust project and a large C++ project knows that, empirically, Rust projects have far fewer memory safety problems than C++ projects do.

Re: Zig, the Small Language

#156

Post by littlestymaar »

ok123456 wrote: post #92
cercatrova wrote: post #83

Why should I use Zig coming from Rust? It doesn't seem that Zig actually solves the memory problems that Rust does.

Not fighting the borrow checker or making gratuitous copies of data to satisfy the borrow checker. Zig's scope is just to be a better C that's free to add modern features like optional types, compile time expressions instead of string-macros, source level modules, packages, a more expressive syntax for writing bit-packed structures, a standard testing framework, deferred function calls, and so on. You can also direct…

> Not fighting the borrow checker

This isn't going to be appealing to Rust current users though, because “fighting the borrow checker” is a learning curve issue, you don't fight the borrow checker anymore once you've internalized its rules.

> or making gratuitous copies of data to satisfy the borrow checker.

You get it backward. In Rust there's less gratuitous copies, not more, because the ownership rules and the borrow checker gives you compile-time guarantees, while “defensive copies” are common in C++ for instance, “to be safe”.

Re: Zig, the Small Language

#157

Post by ferdowsi »

rtev wrote: post #144
beltsazar wrote: post #124

Why would anyone use a new systems programming language that is not safe? Zig might be better than C in some aspects, but is it worth it to switch to Zig when you realize that it's not much safer than C? [0] [0]: https://www.scattered-thoughts.net/writing/how-safe-is-zig/

It does seem confusing to me why someone would choose Zig. If you’re looking for a low-level language, Rust is safer with a better ecosystem. If you want a high-level language, Nim binaries are smaller and the Go ecosystem is better. When is Zig the best choice?

I would choose Zig because Zig has a much more approachable learning curve and Zig code is eminently legible compared to Rust code and it's overly complex type system.

Re: Zig, the Small Language

#158

Post by WalterBright »

oconnor663 wrote: post #140
WalterBright wrote: post #37

Earlier quoted context omitted.

There's a push-and-pull on this in D, too. For example, sometimes I want a backtrace at a certain point, so I'll add an `assert(0);` there. The compiler complains that the rest of the code is unreachable. I then have to block out the code with a `static if (0) { ... }`, or comment it out, which is annoying. But most everyone else likes this, so it stays in. There are no real right answers here. Adding a switch for it…

> every compiler switch is a bug I totally get where this is coming from, but on the other hand it seems like Rust and Zig both get a lot of value from having the compiler understand the difference between debug and release modes, and it seems like modern C++ suffers somewhat from not having any built-in way to do something similar. The optimal number of compiler switches might not be zero.

D literally has the switches `-release` and `-debug`.

Re: Zig, the Small Language

#159

Post by pcwalton »

ok123456 wrote: post #120
davidatbu wrote: post #115

Earlier quoted context omitted.

"The borrow checker stops only easy memory errors" is not the impression I have of Rust, and I would love to learn more about this claim. For example, I'd love to see examples of CVEs on common rust libraries that you mention, if they are caused by safe code (ie, not using `unsafe`, which means the borrow checker is in effect).

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

You realize that these are notable because they're so rare, right? The vast majority of these would never even be filed as CVEs in C++.

Like, consider https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4569...: "An issue was discovered in the mopa crate through 2021-06-01 for Rust. It incorrectly relies on Trait memory layout, possibly leading to future occurrences of arbitrary code execution or ASLR bypass." In C++ this would never have been filed, because it didn't actually cause any problems. It was only filed for Rust because Rust has much higher standards around even the possibility of potential memory safety problems than C++ does.

Re: Zig, the Small Language

#160

Post by flohofwoe »

beltsazar wrote: post #124

Why would anyone use a new systems programming language that is not safe? Zig might be better than C in some aspects, but is it worth it to switch to Zig when you realize that it's not much safer than C? [0] [0]: https://www.scattered-thoughts.net/writing/how-safe-is-zig/

The world isn't just black and white, as is demonstrated by Rust's unsafe keyword (and Rust would be pretty much useless as systems programming language without unsafe).
Post reply on HN