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

201–210 of 259 posts

Re: How safe is Zig?

#201

Post by pjmlp »

vore wrote: post #193
3a2d29 wrote: post #183

Earlier quoted context omitted.

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.

While true, that depends pretty much on which libraries you depend on, and the npm like ecosystem doesn't help in that regard.

Re: How safe is Zig?

#202

Post by pjmlp »

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…

I am not big Go fan, yet its suited for embedded or drivers is a mindset question, as proven by USB hardware keys being shipped by F-Secure with Go firmware, goVisor, Android GPU debugger, ARM official support for TinyGo...

And since you speak of Java, companies like PTC, Aicas, microEJ, ExelsiorJET (now gone) have been happily doing business on embedded, with bare metal or RTOS based deployments.

And then there is Meadow/Netduino on .NET world, and Astrobe for Oberon as commercial products as well. Astrobe has been in business for 20 years now.

Re: How safe is Zig?

#203

Post by randyrand »

pjmlp wrote: post #200
randyrand wrote: post #197

Earlier quoted context omitted.

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.

IMO this is still simpler than automatic memory management, and the runtime costs are mostly fixed and predictable.

You also don't need to worry about ref cycles or GC pauses.

Re: How safe is Zig?

#204

Post by pjmlp »

longrod wrote: post #198
galangalalgol wrote: post #185

Earlier quoted context omitted.

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 y…

Just point people to F-Secure TamaGo unikernel for embedded firmware as one possible example,

https://www.withsecure.com/en/solutions/innovative-security-...

Re: How safe is Zig?

#205

Post by pjmlp »

MaxBarraclough wrote: post #100
afdbcreid wrote: post #24

Do compilers really can never call `free()`? Simple compiler probably can. Most complex probably cannot (I don't want to imagine a Rust compiler without freeing memory: it has 7 layers of lowering (source code->tokens->ast->HIR->THIR->MIR->monomorphized MIR, excluding the final LLVM IR) and also allocates a lot while type-checking or borrow-checking). What is most interesting to me is the average compiler. Does someb…

I imagine plenty of compilers do call free , but here's a 2013 article by Walter Bright on modifying the dmd compiler to never free, and to use a simple pointer-bump allocator (rather than a proper malloc) resulting in a tremendous improvement in performance. [0] (I can't speak to how many layers dmd has, or had at the time.) The never-free pattern isn't just for compilers of course, it's also been used in missile-gu…

Which is why dmd just dies on code that overdoes metaprogramming, after gobbling GB of data.

Re: How safe is Zig?

#206

Post by pjmlp »

randyrand wrote: post #203
pjmlp wrote: post #200

Earlier quoted context omitted.

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.

IMO this is still simpler than automatic memory management, and the runtime costs are mostly fixed and predictable. You also don't need to worry about ref cycles or GC pauses.

Assuming the mythical existence of the perfect developer that nevers does mistakes which handle to use, which certainly wasn't the case on Psion or Symbian projects.

Re: How safe is Zig?

#207

Post by flohofwoe »

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 that point it's better to use 'tagged index handles', but IMHO that's outside the scope of the language (but maybe an option for the stdlib):

https://floooh.github.io/2018/06/17/handles-vs-pointers.html

(but for this an "auto-decaying pointer" would be nice which cannot be stored outside the stack and cannot be "carried across" function calls.

Re: How safe is Zig?

#208

Post by flohofwoe »

nine_k wrote: post #187
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…

I would rather prefer the compiler to tell me: "Hey, this stack-allocated variable is escaping the function's scope, I can't do that! Allocate it somewhere outside the stack." Maybe the compiler could offer me a simple way to fix the declaration somehow. But being explicit and transparent here feels important to me; if I wanted to second-guess the compiler and meditate over disassembly, I could pick C++.

Since HN upvotes are invisible in the UI: +1. IMHO escaped locals should be an error, but not a hidden allocation.

Re: How safe is Zig?

#209

Post by gurjeet »

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…

> ... I am not willing to make the same wrong bet I did with C++. I sunk so much time into perfecting C++ skills ...

What are your top complaints about C++? What parts/patterns are wasteful, and must be avoided?

I have encountered C++ a couple of times in my career. And both those times I was barely able to survive in the short periods of time I spent in those jobs. I'm pretty good at C, but for the life of me, I just can't deal with the hidden behaviours of C++.

So far, I have seen only one example of well-written, understandable C++ code: LLVM. I dabbled in learning LLVM for a side project, and the tutorials on writing compiler passes, and the LLVM's own code, seems to use only the rudimentary features of C++ (primarily, single-inheritance). And this absence of complex C++ features made me feel comfortable looking at, reading, and understanding the LLVM code.

I am of the firm belief now that good code can be written in any bad language, and bad code can be written in any good language. Perhaps those couple of times that I encountered difficult C++ codebases, they were just instances of bad code, and should not be used as an indictment of the C++ language.

Good code => readable, understandable, maintainable, extensible, rewritable. Bad code => !Good code.

Re: How safe is Zig?

#210

Post by proto_lambda »

dilap wrote: post #138
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…

What Rust does is incredibly cool and impressive. But as someone that's dabbled a bit in both Zig and Rust, I think there's a lot of incidental complexity in Rust. For example, despite having used them and read the docs, I'm still not exactly sure how namespaces work in Rust. It takes 30s to understand exactly what is going on in Zig.

The module system is something that some people struggle with for a while, but every feedback I've heard so far is "it actually makes complete sense, I don't know why I didn't get it earlier". There just seems to be dead-end somewhere that people frequently think themselves into.
Post reply on HN