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

How Our Rust-to-Zig Rewrite Is Going

rtfeldman.com

Post reply on HN
Print view View original

291–300 of 336 posts

Re: How Our Rust-to-Zig Rewrite Is Going

#291

Post by maleldil »

em-bee wrote: post #249
bsder wrote: post #188

Earlier quoted context omitted.

> languages ideally should not have breaking changes ever. I disagree MIGHTILY . This is how you wind up with C++ and Java. Languages need to be able to remove features to stay coherent. Occasionally, you get things wrong, it takes time to figure that out, and that's just the way life is.

different preferences i guess. i much prefer language stability. the idea that i should have to test my code with every python version out there for example is disturbing, but there are tools to do exactly that. they should not be needed.

The solution to this is editions/epochs, like Rust. You can set your project to the 2025 edition and be sure that, even if future versions introduce breaking changes, they will not affect your project; it will continue to compile as before.

Re: How Our Rust-to-Zig Rewrite Is Going

#292

Post by Peaches4Rent »

dnautics wrote: post #139
onlyrealcuzzo wrote: post #105

Earlier quoted context omitted.

I'm pretty sure Zig has no plans to ever become safe - by any sane sense of the word - so, yes, I would expect...

zig does have plans to give access to IRs when stable so adding a borrow checker to zig will be even easier than it is now

Apologies for the noob question, but what is an IR?

Re: How Our Rust-to-Zig Rewrite Is Going

#293

Post by [deleted] »

psychoslave wrote: post #280
rtfeldman wrote: post #38

Earlier quoted context omitted.

> I think that for the hot binary patching / code reloading features, yes, that is going to need unsafe. But for regular old "producing an executable" compilation? Emitting machine code isn't the part that requires unsafe. The language's runtime is a more likely site to find unsafe. Agreed! Emitting machine code is not unsafe, since it's just writing bytes down - it's only once you execute that machine code that ther…

Side concerne, but reading the post initially I thought it was about Rocq (formerly Coq). Maybe both team could coordinate and find a way that everybody agree on to avoid any confusion? https://en.wikipedia.org/wiki/Rocq

[deleted]

Re: How Our Rust-to-Zig Rewrite Is Going

#294

Post by lioeters »

rienbdj wrote: post #274
lioeters wrote: post #130

Earlier quoted context omitted.

Also OxCaml, from what I hear.

OCaml already starts form a memory safe base being GCd?

I'm not familiar but I think this paper describes how OxCaml works:

Oxidizing OCaml with Modal Memory Management - https://dl.acm.org/doi/10.1145/3674642

> We focus on three mode axes: affinity, uniqueness and locality. Modes are fully backwards compatible with existing OCaml code and can be completely inferred. Our work makes manual memory management in OCaml safe and convenient and charts a path towards bringing the benefits of Rust to OCaml.

https://github.com/oxcaml/oxcaml

Re: How Our Rust-to-Zig Rewrite Is Going

#296

Post by em-bee »

maleldil wrote: post #291
em-bee wrote: post #249

Earlier quoted context omitted.

different preferences i guess. i much prefer language stability. the idea that i should have to test my code with every python version out there for example is disturbing, but there are tools to do exactly that. they should not be needed.

The solution to this is editions/epochs, like Rust. You can set your project to the 2025 edition and be sure that, even if future versions introduce breaking changes, they will not affect your project; it will continue to compile as before.

pike has that. or had it. for two decades. inline in the code, in each file you could specify the version. they decided to drop it because of the maintenance overhead.

Re: How Our Rust-to-Zig Rewrite Is Going

#297

Post by never_inline »

Aurornis wrote: post #30
onlyrealcuzzo wrote: post #9

Earlier quoted context omitted.

It's literally the most sophisticated scheduling engine in the world. In practice, Go can typically outperform Rust in throughput (using more memory), despite having a mountain of disadvantages against it in theory. That's how good the Go scheduler/runtime is.

> n practice, Go can typically outperform Rust in throughput (using more memory), despite having a mountain of disadvantages against it in theory This is a huge claim that disagrees with both my real-world experience and everything I've seen from artificial comparisons. Every high performance Go system I've worked on has quickly reached the point where we're optimizing memory management and doing things that would ha…

Go has few issues with performance (lack of in-line union types, interface overuse, inefficient idioms reg. collections, some missed optimizations) but its seems plausible for a idiomatic Go program to outperform an idiomatic rust program in some situations.

Example: https://news.ycombinator.com/item?id=22336284

Re: How Our Rust-to-Zig Rewrite Is Going

#298

Post by guywithahat »

up2isomorphism wrote: post #18

I think there will be soon a wave of rewriting rust to language X coming up.

I've sort of thought this too. Rust adoption feels a lot like Haskell to me in that it's centered around ideological things that don't really improve the final product and arguably slow development. If your goal is to write a bunch of LLM code there are better languages than rust, and rust development is often regarded as too annoy for anyone not enthusiastic about the ideological improvements.

There are cool ideas in the language but I don't see it enduring over time.

Re: How Our Rust-to-Zig Rewrite Is Going

#299

Post by dnautics »

Peaches4Rent wrote: post #292
dnautics wrote: post #139

Earlier quoted context omitted.

zig does have plans to give access to IRs when stable so adding a borrow checker to zig will be even easier than it is now

Apologies for the noob question, but what is an IR?

intermediate representation. attempting to analyze zig code directly would be too hard (especially with comptime). on the way to the compiler backend, the compiler builds a simplified representation that only has "actually existing functions" and is very straightforward, e.g.

    function 10112:
    0: argument 0
    1: argument 1
    2: argument 2
    3: add 0, 1
    4: store 2
    5: call function 1342, (2, 4)
    6: return 5
you can see how building a data dependency graph from this would be easy.

Re: How Our Rust-to-Zig Rewrite Is Going

#300

Post by dnautics »

dnautics wrote: post #221
gpm wrote: post #184

Earlier quoted context omitted.

That's not sufficient - consider the following pseudocode x = malloc(); if (opaque_cond()) free(x); if (other_opaque_cond()) use(x); Conditions can be opaque and non-analyzable due to rices theorem - in any turing complete language. This code is correct (or at least not memory unsound) if opaque_cond and other_opaque_cond are never both true. Otherwise it isn't. And functionally compiler analyses of whether condition…

so yes it is possible to detect those patterns and ban them as unsafe, and have a"safety checked alternative. clr does this currently: https://github.com/ityonemo/clr#safety-oriented-architecture

i dont understand the downvotes here. the point of any safety checker is to flag and ban potentially unsafe code, and force the author to rewrite with existing language patterns that guarantee the desired safety parameters.

in this case, zig has a first class nullable syntax that the checker can use ti guarantee correctness for, so a checker can deterministically sidestep this turing completeness issue, by squeezing indeterminate code into the knowably safer language idiom.

Post reply on HN