Zig as an alternative to writing unsafe Rust • Hacker News Board

Re: Zig as an alternative to writing unsafe Rust

#121

Post by kaba0 » Tue, Mar 07, 2023, 9:13 PM UTC

j16sdiz wrote: post #16

satvikpendem wrote: post #10

Note, this is specifically talking about unsafe Rust versus Zig. Personally unsafe does have some rough edges, I'm looking forward to seeing how the Rust team manages to make it better in the future.

UB in unsafe rust sometimes "leaks" outside the unsafe scope and cause crashing elsewhere. If rust can pair with a proof checker and let user write some correctness proof, it can be way more useful than the current borrow checker.

Correctness proof? That’s like almost impossible, formal verification is just not scalable, insanely complex and it will never be done by your average developer.

The only way we can do proofs (on certain things) is restricting code, like non unsafe rust.

If it would be feasible, why wouldn’t we just continue to use C and be happy with our verified C codes?

Re: Zig as an alternative to writing unsafe Rust

#122

Post by tomtheelder » Tue, Mar 07, 2023, 9:15 PM UTC

infamouscow wrote: post #105

ksec wrote: post #12

>There are endless debates online about Rust vs. Zig I have never read anything that suggest or argued Zig as better than Rust, or "Rust vs Zig". Not on HN, not on Reddit, not on Twitter. In fact this link / title is the first one. ( I do wish the title was "Unsafe Rust" to better reflect on the content. ) There are however plenty who still prefer Zig over Rust, even knowing when Rust is better . I also want to note…

[flagged]

My experience is that I see a LOT more complaints about these sorts of behaviors than I see the actual behavior. I think it's honestly just a meme that's gotten out of hand at this point. Speaking as someone who is not part of the Rust community and knows comparatively little about the language.

Re: Zig as an alternative to writing unsafe Rust

#123

Post by jcranmer » Tue, Mar 07, 2023, 9:17 PM UTC

stouset wrote: post #37

ilrwbwrkhv wrote: post #24

Earlier quoted context omitted.

On top of that Rust might be the ugliest modern language.

People keep saying this and I just do not get it . It's just… not that bad?

I suspect the things that people are reacting to are a mixture of the following:

* Types in Rust use prefixing to create derived types whereas C family languages generally use postfixing. A pointer is i32, not int; an array [i32; 5], not int[5], etc. This makes special characters appear more heavily at the beginning of the scan line, and probably makes them slightly more noticeable as a result.

* Lifetimes have the form 'a, and that single quote is likely to bother a lot of people (I know it bothers me).

* Unqualified name lookup in Rust is a bit weaker than other languages, which makes the scope operator (::) more common.

* Passing in explicit generic type arguments for a function requires an extra :: for seemingly no reason.

* Similarly, macros require an explicit ! in the name to invoke. Given that println! (and formatting in general) is a macro and not a function, this means you get a lot of extra uses of ! that's unexpected for C family code.

* Again, the try operator (also decently common) is another random special character.

* Attributes also use #[] syntax, or sometimes #![]. While C++11 did use [[]] to designate its attributes, it's also something that always felt a bit ugly to me personally (I find the @Decorator() pattern from Java or Python to be a visually cleaner way to do attributes).

In short, Rust generally has a higher density of special characters than other C family languages, and I think that contributes to a sense of ugliness.

Re: Zig as an alternative to writing unsafe Rust

#124

Post by kaba0 » Tue, Mar 07, 2023, 9:17 PM UTC

chubot wrote: post #68

The way I would frame this is that Rust has static (compile-time) memory management, and that conflicts with dynamic memory management (garbage collection). The boundary is awkward and creates complexity. I wrote a post about problems writing a garbage collector in C++, e.g. annotating the root set, and having precise metadata for tracing. http://www.oilshell.org/blog/2023/01/garbage-collector.html https://news.ycomb…

Dynamic memory management is an entirely different axes from manual/automatic, though.

(Safe) Rust indeed limits the user to a compile-time deallocable subset of what’s expressible (RC being an escape hatch), which depending on the problem domain may be too limiting.

Re: Zig as an alternative to writing unsafe Rust

#125

Post by Asooka » Tue, Mar 07, 2023, 9:19 PM UTC

bpolverini wrote: post #5

I buy the premise that Zig is better if you know you will have lots of pointer arithmetic going on. Having written a fair amount of unsafe C interop code in Rust, I feel like these critiques of the ergonomics are valid. The new #![feature(strict_provenance)] adds a new layer of complexity, that, I hope, improves some of this experience while adding safety. Rust's benefits are not free. The benefits of Rust's (wonderf…

One big difference between unsafe Rust and C is that C compilers have flags to turn off the UB, so you have a lot less mental load when writing it. You go from e.g. "if this index calculation overflows, we may read from outside the array, because the bounds check was deleted" to "if this index calculation overflows, we may read from the wrong index, but never outside of the array bounds". UB is Damocles's sword and the speed gains are usually not worth it. With UB your program can enter a buggy state that you cannot detect, because "it cannot happen". Without UB, your program can still enter a buggy state, but you can detect it and potentially recover or crash immediately before even more things go wrong.

Re: Zig as an alternative to writing unsafe Rust

#126

Post by kaba0 » Tue, Mar 07, 2023, 9:19 PM UTC

tomtheelder wrote: post #122

infamouscow wrote: post #105

Earlier quoted context omitted.

[flagged]

My experience is that I see a LOT more complaints about these sorts of behaviors than I see the actual behavior. I think it's honestly just a meme that's gotten out of hand at this point. Speaking as someone who is not part of the Rust community and knows comparatively little about the language.

In my surface-level interactions with the community I have found it to be absolutely kind and helpful.

Re: Zig as an alternative to writing unsafe Rust

#127

Post by lll-o-lll » Tue, Mar 07, 2023, 9:27 PM UTC

hn92726819 wrote: post #101

indymike wrote: post #93

Earlier quoted context omitted.

> we keep finding serious bugs in code that is decades-old I'm sure of one thing: we will find many and different bugs in decades old rust code one day, too. The problem with software is that it has code in it ;-)

Difference of course being that zero of these bugs will be due to buffer overflows or use after free or other memory bugs in safe rust, which is a huge source of bugs in C[1]. I don't understand why this argument keeps coming up. Not all bugs are the same and when you make entire classes of bugs unrepresentable, that's a massive win, especially when they happen to be the class containing >60% of the highest severity…

It’s not that simple. Rust is used in the system’s programming space and as a result it will be used in many places where unsafe ends up required to solve problems. There won’t be memory safety bugs in safe Rust, but there will be in the interop/unsafe layers.

I think there is a strong argument to be made that if you need a lot of unsafe, Zig is going to be the safer language.

Re: Zig as an alternative to writing unsafe Rust

#128

Post by Animats » Tue, Mar 07, 2023, 9:31 PM UTC

If you're writing much unsafe code in Rust, you're doing it wrong.

OK, for a garbage collector, maybe you have to, because you're taking over memory management yourself. But very, very rarely do you need to do that. And when you do, you need very thorough testing, test tools, and documentation.

I just got done chasing someone else's pointer bugs with valgrind and gdb, in C code from a public crate three levels down from my code. Valgrind was useful in locating the area of trouble. The code there had too much unnecessary pointer manipulation, and offsets obtained from input which might be un-initialized memory. This never happens in safe Rust. Which is the whole point.

Most things for which C programmers use pointer arithmetic can be expressed as slices. Slices are pointer arithmetic, but with size information and sound rules.

(I'm a bit cranky this week. I've spent the last few weeks finding bugs in Rust crates that ought to Just Work.)

Re: Zig as an alternative to writing unsafe Rust

#129

Post by Asooka » Tue, Mar 07, 2023, 9:36 PM UTC

stouset wrote: post #37

ilrwbwrkhv wrote: post #24

Earlier quoted context omitted.

On top of that Rust might be the ugliest modern language.

People keep saying this and I just do not get it . It's just… not that bad?

My biggest peeve is types on the right. I would say that C is "humanistic" in its type declarations, while Rust and the rest of Pascal's lineage are "mechanistic". Concretely, look at this:

    int foo(int a, float b);

vs

    fn foo(a: i32, b: f32) -> i32;

In Rust's case you're specifying to the machine what the thing is, i.e. "I am declaring a function called foo. The function has a first parameter called a, of type i32, ... The function returns an int". Whereas in C you have a "declaration follows usage" idiom, such that what you're saying is "typing foo(a, b) produces an int on the left side, within foo a produces an int lvalue, ...". The function arguments flow from right to left and the result emerges on the left with the given type. The order of tokens in declaring foo matches the order of tokens when calling foo. It also matches the order of importance - first is the return type, then the function name, then each parameter type followed (optionally) by the parameter name.

Or look at an array declaration:

    int arr[5];

"You get an int when you type arr[N] where N is less than 5".

This kind of argument of course goes all the way back to AT&T vs Intel assembly syntax and I am firmly on Intel's side.

Re: Zig as an alternative to writing unsafe Rust

#130

Post by lll-o-lll » Tue, Mar 07, 2023, 9:37 PM UTC

slaymaker1907 wrote: post #85

I think most of the difficulty people experience is when they try to naïvely use references anywhere they would normally use a pointer. That mostly works for functions, but this ends up getting really confusing and difficult for data objects. Instead, people should really be using things like Rc which makes certain patterns much simpler. People seem to have this ridiculous notion that using Rc or heaven forbid Rc > i…

People do say that Swift is slow though, and it has a whole bunch of optimisations to ensure the RC is elided whenever possible.