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

221–230 of 259 posts

Re: How safe is Zig?

#221

Post by avgcorrection »

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.

Yeah, it was quite mind-bending when I tried to learn it. I still don’t understand why they went in that direction.

Re: How safe is Zig?

#222

Post by coldtea »

notriddle wrote: post #157
coldtea wrote: post #140

Earlier quoted context omitted.

> If option A has 20 defects and option B has the superset of 25 defects then option A is better Only if "defect count" is what you care for. What if you don't give a fuck about defect count, but prefer simplicity to explore/experiment quickly, ease of use, time to market, and so on?

Then you don't want Zig or Rust. Use a language with a GC. Exploratory programming is a lot more pleasant when you don't have to worry about calling free() at the right time. I've had success with PHP and Elixir for productive, exploratory programming, not just because of their GCs, but also because they both support REPL-driven development and hot code reloading.

>Then you don't want Zig or Rust.

I might still want Zig just fine. E.g. because I know C well, and it's a better C. Or because of the ease of interfacing with C/native libs. And several other reasons.

Re: How safe is Zig?

#223

Post by coldtea »

qzw wrote: post #161
coldtea wrote: post #140

Earlier quoted context omitted.

> If option A has 20 defects and option B has the superset of 25 defects then option A is better Only if "defect count" is what you care for. What if you don't give a fuck about defect count, but prefer simplicity to explore/experiment quickly, ease of use, time to market, and so on?

Then just use C? Heck, if you really don't give a fuck about defects, you can just have all your code in main(). You really can't beat that in terms of simplicity to explore/experiment quickly, ease of use, and time to market.

>Heck, if you really don't give a fuck about defects, you can just have all your code in main(). You really can't beat that in terms of simplicity to explore/experiment quickly, ease of use, and time to market.

I probably can "beat that", because e.g. breaking things into functions increases simplicity and being able to explore/experiment quickly.

Whereas eliminating defects with a type/lifetime checker you need to hand-wrestle, not so much.

Re: How safe is Zig?

#224

Post by randyrand »

flohofwoe wrote: post #207
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 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.

Nice article. Similar idea ofc. Yes, that design could work tho all objects per pool must be the same size. Not sure how that would be better.

Re: How safe is Zig?

#225

Post by SubjectToChange »

gurjeet wrote: post #209
socialdemocrat wrote: post #191

Earlier quoted context omitted.

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

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

Uh, what parts of LLVM were you reading? Because LLVM uses pretty much every C++14 feature allowed by their coding standard. The fact that you felt like no complex machinery was being used is actually a testament of the powers of abstraction in C++.

Re: How safe is Zig?

#226

Post by Measter »

Klonoar wrote: post #147
LAC-Tech wrote: post #141

Safe enough. You can use `std.testing.allocator` and it will report leaks etc in your test cases. What rust does sounds like a good idea in theory. In practice it rejects too many valid programs, over-complicates the language, and makes me feel like a circus animal being trained to jump through hoops. Zigs solution is hands down better for actually getting work done, plus it's so dead simple to use arena allocation a…

>Zigs solution is hands down better for actually getting work done Rust has seen significant usage in large companies; they wouldn't be using it unless it was usable for "real work". >Full disclaimer, I'm pretty bad at systems programming. Zig is the only one I've used where I didn't feel like memory management was a massive headache. I'd say this about Rust, though. Rust's mental model is very straightforward if you…

> Can you show me a "valid program" that Rust rejects?

    #[derive(Debug)]
    struct Foo {
        a: i32
    }
    
    fn thing(foo: &mut Foo) {
        match foo {
            f @ Foo { a } if *a > 5 => {
                println!("{:?}", f)
            }
            _ => {}
        }
    }
There's no reason it should reject that, as the use of the `a` reference doesn't interleave with the use of `f`.

Re: How safe is Zig?

#227

Post by kaba0 »

randyrand wrote: post #159
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 feel like the most user friendly solution for Use After Free is to just use Reference Counting. Basically, just copy Objective-C's "weak_ptr" design. For every allocation, also store on the heap a "reference object", that keeps track of this new reference. struct reference_t { // the ptr returned by malloc void* ptr; // the stack/heap location that ptr was written to. // i.e the reference location. void* referenceA…

Reference counting is an incomplete solution it itself - it leaks circular references, and on multithreaded programs it is quite slow. Though some optimizations could be done statically to improve on that.

All in all, a mark-and-sweep will likely be faster (in throughput at least) let alone a good GC.

Re: How safe is Zig?

#228

Post by pornel »

notriddle wrote: post #160
pornel wrote: post #156

Earlier quoted context omitted.

This error is possible in Rust, but not easy to cause. Uninitialised memory is considered unsafe. There aren't any loopholes even for "just bytes". You can't accidentally make an uninitialised buffer, and you can't expose one without explicit `unsafe{}`. Sych unsafe code is typically wrapped in safe interfaces, so the risk is limited to implementation side, and not spread to every usage site. For filling buffers the…

It's actually not very hard to cause. It would happen if your system reuses buffers without actually going through the allocator. Something like this: let mut buf = vec![0; DEFAULT_BUFFER_SIZE]; let database_frame_len = database_socket.read(&mut buf)?; // use 1 let database_result = Database::parse(&buf[..database_frame_len])?; let html_template = HtmlTemplate::new(database_result); let html_len = html_template.write…

This is why I've mentioned io::Write, because people don't chop buffers like that with C-style separately tracked length when they can have zero-copy:

   html_template.pipe_to(socket);
and there's a foolproof io::BufWriter adapter if you need these writes buffered.

Re: How safe is Zig?

#229

Post by kaba0 »

haberman wrote: post #196
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. T…

I’ve written a JVM in Rust where I was pretty much unable to work without unsafe, and while I know the general consensus is that it is a sin to use, I managed to get away with a few usages wrapped tightly inside a safe API. Sure, I had memory problems during writing, but with MIRI and some debug assertions they were not hard to hunt down and I really only had to get that few lines of code inside unsafe blocks right.

What I’m trying to say with all that, do not be afraid to use unsafes in Rust. It is part of the language for a reason. Sure, do use ARC for some non-performance critical whatever, because it frankly doesn’t really matter. But where it matters, and you decided to use a low-level language, then go for unsafe if that’s the only reasonable way. The result will still be much safer than the other low-level languages. I believe the problem here is the same what C++ tried to achieve: making people believe it is a high level language. That is just dishonest, and really should not be the goal of Rust.

Re: How safe is Zig?

#230

Post by crabbygrabby »

modeless wrote: post #195
crabbygrabby wrote: post #186

Earlier quoted context omitted.

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.

I see a lot of people put rust down for what it is today, and then in the next breathe wistfully wonder about the future of zig, or some other language, etc. It's just not fair.

Rust today let's you avoid allocations, if you want smart pointers you can have them today, I'd you want a GC inside rust, you can have that today as well. Don't need to wait for another language lol.

Post reply on HN