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

How safe is Zig?

scattered-thoughts.net

Post reply on HN
Print view View original

191–200 of 259 posts

Re: How safe is Zig?

#191

Post by socialdemocrat »

avgcorrection wrote: post #118

A meta point to make here but I don’t quite understand the pushback that Rust has gotten. How often does a language come around that flat out eliminates certain errors statically, and at the same time manages to stay in that low-level-capable pocket? And doesn’t require a PhD (or heck, a scholarly stipend) to use? Honestly that might be a once in a lifetime kind of thing. But not requiring a PhD (hyperbole) is not en…

I think you are too dismissive of the importance of simplicity. Programming is hard. That Rust takes away certain problems doesn’t change that. A lot of coding is just reading and understanding some code. If you have problems understanding some code then I hat is also code you are. Or likely to not catch bugs in.

A compiler cannot be a substitute for your brian. The ability to read code and think clearly about it is a massively important feature because humans at the end of the day are the ones who have to understand code and fix it.

It depends on the person. Programmers are different. Rust works great for some. To me it looks too much like C++ which is something I want to put behind. I know it is a different language but it has a lot of that same focus as C++ that leads to slow compilers and complex looking code.

If I was younger I might have put in the effort, but I am not willing to make the same wrong bet I did with C++. I sunk so much time into perfecting C++ skills and realizing afterwards when using other languages that it was a huge waste.

Re: How safe is Zig?

#192

Post by [deleted] »

3a2d29 wrote: post #183
avgcorrection wrote: post #134

Earlier quoted context omitted.

> But if Option A has 20 defects and takes a lot of effort to go down to 15 defects, yet Option B has 25 defects and offers a quick path to go down to 10 defects, then which option is superior? Yes. If you change the entire premise of my example then things are indeed different. Rust eliminates some defects entirely. Most other low-level languages do not. You would have to use a language like ATS to even compete. Tha…

Rust does no eliminate memory errors. 200+ memory safety errors were found in rust crates: https://www.infoq.com/news/2021/11/rudra-rust-safety/ I love rust, I think there's a good chance zig in its current state isn't the answer, but saying rust is totally memory safe is wrong. You drop into unsafe and people make the same errors C/C++ devs make.

[deleted]

Re: How safe is Zig?

#193

Post by vore »

3a2d29 wrote: post #183
avgcorrection wrote: post #134

Earlier quoted context omitted.

> But if Option A has 20 defects and takes a lot of effort to go down to 15 defects, yet Option B has 25 defects and offers a quick path to go down to 10 defects, then which option is superior? Yes. If you change the entire premise of my example then things are indeed different. Rust eliminates some defects entirely. Most other low-level languages do not. You would have to use a language like ATS to even compete. Tha…

Rust does no eliminate memory errors. 200+ memory safety errors were found in rust crates: https://www.infoq.com/news/2021/11/rudra-rust-safety/ I love rust, I think there's a good chance zig in its current state isn't the answer, but saying rust is totally memory safe is wrong. You drop into unsafe and people make the same errors C/C++ devs make.

The surface of exposure is much lower in Rust than in C/C++ however. It is unlikely you are writing your entire program in unsafe Rust, so you can still get a significant benefit from memory-safe safe Rust.

In C/C++ world, _everything_ is unsafe, so you can't even limit your exposure in the safer parts because you can do unsafe operations anywhere.

Re: How safe is Zig?

#194

Post by adwn »

messe wrote: post #133
kristoff_it wrote: post #114

Earlier quoted context omitted.

I don't know the precise details of what Andrew has in mind but the compiler can know how much memory is required for this kind of operation at compile time. This is different from normal heap allocation where you only know how much memory is needed at the last minute. At least in simple cases, this means that the memory for escaped variables could be allocated all at once at the beginning of the program not too diff…

Static allocation at the beginning of the program like that can only work for single threaded programs with non-recursive functions though, right? I’d hazard a guess that the implementation will rely on use-after-free faulting, meaning that the use of any escaped variable will fault rather than corrupting the stack.

No need for recursion or multi-threading: If you call the function in a loop and don't release the escaped local unter after the loop, and if the number of loop iterations isn't statically known, then it's impossible to pre-allocate heap storage for that local variable.

Re: How safe is Zig?

#195

Post by modeless »

crabbygrabby wrote: post #186
modeless wrote: post #155

Earlier quoted context omitted.

It's pretty simple. Rust's safety features (and other language choices) have a productivity cost. For me I found the cost surprisingly high, and I'm not alone (though I'm sure I'll get replies from people who say the borrow checker never bothers them anymore and made them a better programmer, let's just agree there's room to disagree). Although I'm a big fan of safety, since experiencing Rust my opinion is that low-p…

After having seeing GC after GC fail to live up to expectations... I'm still voting for Rust. So much more control over wether you even want to allocate or not. I know where you are coming from but, I see it differently I guess.

Whether you allocate or not is a property of the language, not the GC. A lot of GC'd languages encourage or even force allocations all over the place. But maybe we could do better in a new language.

Re: How safe is Zig?

#196

Post by haberman »

avgcorrection wrote: post #118

A meta point to make here but I don’t quite understand the pushback that Rust has gotten. How often does a language come around that flat out eliminates certain errors statically, and at the same time manages to stay in that low-level-capable pocket? And doesn’t require a PhD (or heck, a scholarly stipend) to use? Honestly that might be a once in a lifetime kind of thing. But not requiring a PhD (hyperbole) is not en…

I invested a lot of time porting some parsing code I had written to Rust, with the vision that Rust is the memory-safe future. The code I was porting from used arenas, so I tried to use arenas in Rust also.

Using arenas required a bunch of lifetime annotations everywhere, but I was happy to do it if I could get provable memory safety.

I got everything working, but the moment I tried to wrap it in Python, it failed. The lifetime annotation on my struct was a problem. I tried to work around this by using ouroboros and the self-referencing struct pattern. But then I ran into another problem: the Rust arena I was using (Bumpalo) is not Sync, which means references to the arena are not Send. All of my arena-aware containers were storing references to the Arena and therefore were not Send, but wrapping in Python requires it to be Send. I wrote more about these challenges here: https://blog.reverberate.org/2021/12/19/arenas-and-rust.html

You might say "well don't use an arena, use Box, Rc, etc." But now you're telling me to write more complicated and less efficient code, just to make it work with Rust. That is a hard pill to swallow for what is supposed to be a systems language.

Re: How safe is Zig?

#197

Post by randyrand »

AndyKelley wrote: post #81

I have one trick up my sleeve for memory safety of locals. I'm looking forward to experimenting with it during an upcoming release cycle of Zig. However, this release cycle (0.10.0) is all about polishing the self-hosted compiler and shipping it. I'll be sure to make a blog post about it exploring the tradeoffs - it won't be a silver bullet - and I'm sure it will be a lively discussion. The idea is (1) escape analysi…

Just another idea for use after free:

What If we combined the 'non-repeating' malloc idea with 128-bit uuids?

malloc would just return a 128-bit uuid, and to get to the data ptr you'd need to consult a hash table.

  dataPtrArr[hash(uuid)].dataPtr = dataPtr
We'd check if it's been freed by checking:

  dataPtrArr[hash(uuid)].uuid == uuid

Re: How safe is Zig?

#198

Post by longrod »

galangalalgol wrote: post #185
longrod wrote: post #182

I think Zig has a lot more footguns due to it's explicit nature. When you don't hide away the details from the human, you are increasing the risk of writing bad code and it becomes increasingly harder to make the compiler detect each potentially bad decision. Rust did it but they had to rethink the whole problem from the ground up. Rust is safe but that safety had quite the learning cost as compared to, say, Zig or G…

why does go always get brought up when talking about rust or nim or now zig? Its got gc, a large std lib, less latency than java but noticably slower, and its not suited for embedded or drivers. Its a completely different language for a completely different niche than zig or rist, though maybe I could see a comparison to nim... Maybe. I do like go for what it is, batteries included back end language with syntax nicer…

Go is a compiled language with comparable performance to Zig/Rust/C in a lot of use cases. It's heavily ergonomic for network/server side programming, it's safe, easy to use with a tiny footprint.

Rust is not only or even primarily used in embedded or driver programming. Indeed, I see more user space software built in rust than in embedded nowadays. As for Zig, it's so new and alpha that it didn't even find a niche yet. Rust also hasn't yet found a specific niche. It's all over the place in GUI, networking, embedded etc. which isn't a bad thing, to be clear.

It might be harder to do embedded in Go but that's not the point here, is it? It's about safety. Go has a special place in that it is compiled, easy to learn, quite performant for most tasks, and safe to boot.

> I can believe that abstractions prevent errors, but can't a language allow footguns but have syntax that makes them easy to detect?

What would be the point though? If a language can detect footguns, it's time to prevent them which is what Rust does, essentially. Footguns are rarely useful and there's always an alternative way. For these rare cases, Rust includes the unsafe escape hatch but then all bets are off. Don't expect the compiler to help you if you are intent on going down that road.

Re: How safe is Zig?

#199

Post by avgcorrection »

socialdemocrat wrote: post #191
avgcorrection wrote: post #118

A meta point to make here but I don’t quite understand the pushback that Rust has gotten. How often does a language come around that flat out eliminates certain errors statically, and at the same time manages to stay in that low-level-capable pocket? And doesn’t require a PhD (or heck, a scholarly stipend) to use? Honestly that might be a once in a lifetime kind of thing. But not requiring a PhD (hyperbole) is not en…

I think you are too dismissive of the importance of simplicity. Programming is hard. That Rust takes away certain problems doesn’t change that. A lot of coding is just reading and understanding some code. If you have problems understanding some code then I hat is also code you are. Or likely to not catch bugs in. A compiler cannot be a substitute for your brian. The ability to read code and think clearly about it is…

Readable code is important? Then keep in mind the context: low-level programming and writing Safe Rust or writing in some not-quite-memory-safe language because one would rather be bitten by undefined behavior now and again rather than have to learn the borrow checker.

Knowing for sure that the code you write is at least memory safe is a certain kind of readability win and I don’t see how anyone can claim that it’s not.

Re: How safe is Zig?

#200

Post by pjmlp »

randyrand wrote: post #197
AndyKelley wrote: post #81

I have one trick up my sleeve for memory safety of locals. I'm looking forward to experimenting with it during an upcoming release cycle of Zig. However, this release cycle (0.10.0) is all about polishing the self-hosted compiler and shipping it. I'll be sure to make a blog post about it exploring the tradeoffs - it won't be a silver bullet - and I'm sure it will be a lively discussion. The idea is (1) escape analysi…

Just another idea for use after free: What If we combined the 'non-repeating' malloc idea with 128-bit uuids? malloc would just return a 128-bit uuid, and to get to the data ptr you'd need to consult a hash table. dataPtrArr[hash(uuid)].dataPtr = dataPtr We'd check if it's been freed by checking: dataPtrArr[hash(uuid)].uuid == uuid

At which point is much simpler to introduce automatic memory management in some form.

That solution is basically how platforms like Psion or Symbian used handles due to memory constraints.

Post reply on HN