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

91–100 of 336 posts

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

#91

Post by pjmlp »

steveklabnik wrote: post #72
grayrest wrote: post #23

Earlier quoted context omitted.

One of the primary goals for the Roc project is compiler speed. I presume OCaml is out of the running because it's not a systems language.

OCaml has often historically been considered a language that's been appropriate to write systems tooling like compilers, runtimes, and unikernels in, even though GC'd languages were/are not often considered for such projects.

They are considered in many research labs since Xerox, unfortunately there are still too much anti-GC religion among mainstream devs.

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

#92

Post by pjmlp »

onlyrealcuzzo wrote: post #9
Hinrik wrote: post #5

Earlier quoted context omitted.

Layperson here: what is special about Go's runtime, aside from the GC?

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.

What a joke, ignoring Erlang, and the custom schedulers from JVM and CLR runtimes.

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

#93

Post by minraws »

rtfeldman wrote: post #74
steveklabnik wrote: post #55

Earlier quoted context omitted.

I am disappointed you're downvoted, Richard. This is a fine reply, and I hope you know that a minor quibble with a single line in the post doesn't mean that I think it's a bad one overall. (EDIT: a few minutes later, the parent comment is no longer grey.) I also think it's a good thing that you wrote the post in general, when I saw it pop up I was like "oh, of course, this post should exist!" I'm surprised I didn't t…

Also a good point! TIL that Rust and C++ use interpreters for const, although of course that wouldn't work for running tests. Then again, in the specific case of Rust I believe rustc only compiles the tests and then something else like Cargo executes them. Of course, as I noted elsewhere, if rustc emits machine code and then cargo immediately executes it, there's the same opportunity for end user memory being corrupt…

I would like to understand this more,

> rustc emits machine code and then cargo immediately executes it, there's the same opportunity for end user memory being corrupted (due to miscompilation) as if rustc and cargo shared a code base.

Cause this hasn't been true for me or for anyone maybe your definition of memory being corrupted is the not same as mine.

I am not even sure what you are trying to prove with this.

I appreciate the time and effort in building stuff like Roc I don't use it but this comment and the article feel like...

Oh some guy said Zig not nice because memory safety so here, a post why memory safety doesn't exist because we have to do memory unsafe things sometimes and so everything is memory unsafe already, so maybe it doesn't matter.

I get the energy that we are going for seeing useless claims and wanting to push back but I think the article deserves a clearer part 2 where you elaborate on your thoughts about stuff maybe even get it peer reviewed a bit before posting or maybe don't I guess we could use more raw thoughts in the post AI age.

Either way I appreciate someone trying to put forward their own thoughts and explain problems with a different perspective.

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

#94

Post by steveklabnik »

rtfeldman wrote: post #74
steveklabnik wrote: post #55

Earlier quoted context omitted.

I am disappointed you're downvoted, Richard. This is a fine reply, and I hope you know that a minor quibble with a single line in the post doesn't mean that I think it's a bad one overall. (EDIT: a few minutes later, the parent comment is no longer grey.) I also think it's a good thing that you wrote the post in general, when I saw it pop up I was like "oh, of course, this post should exist!" I'm surprised I didn't t…

Also a good point! TIL that Rust and C++ use interpreters for const, although of course that wouldn't work for running tests. Then again, in the specific case of Rust I believe rustc only compiles the tests and then something else like Cargo executes them. Of course, as I noted elsewhere, if rustc emits machine code and then cargo immediately executes it, there's the same opportunity for end user memory being corrupt…

Cool, I'm not sure that people know that we know each other and have some deeper mutual understanding. :)

> although of course that wouldn't work for running tests.

Why not? Unless you mean in the cross-compilation case, in which yeah, to run the compiled tests you'd need an emulator.

> in the specific case of Rust I believe rustc only compiles the tests and then something else like Cargo executes them.

It doesn't have to be Cargo, but yes, rustc produces executables for the tests, and you have to then run them.

> there's the same opportunity for end user memory being corrupted (due to miscompilation)

I agree for sure that the safety of the outputted binary is completely distinct from the safety of the compiler itself.

I think the reason that this framing specifically (in the post and in this comment) strikes me as odd is that "requires unsafe code" sort of implies that you need to use unsafe to fix the unsafety of the outputted binary. That just isn't the case. Of course, this is a serious bug that needs to be fixed, but there's just something about "doing memory unsafe things" in this area that like, I think can be a little mis-leading, even if that's not intentional. But I am going to sit with this and think about it, regardless, because I am not sure that my gut reaction here is completely accurate.

(And, hilariously, looking over some work my agents did on my compiler last night, they fixed some mis-compilations that occurred, entirely in safe code. I bet that's also part of why I'm in this headspace at the moment, it's not like those fixes required dropping down into unsafe to fix either!)

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

#95

Post by pjmlp »

veber-alex wrote: post #37
lioeters wrote: post #7

Earlier quoted context omitted.

Instead of waiting for faster compiler in Rust, how about from the other direction, adding some kind of borrow checker to Zig? That sounds more within reach and practically achievable, possibly even in userland.

It's impossible to add a borrow checker to any existing language. The reason Rust has a working borrow checker is because every part of the language from structs, enum, traits, generics and all the way to the syntax itself has been designed to support lifetimes and borrow checking. It's is not something you can just tack on to an existing language without fundamentally changing it.

Swift, Linear Haskell, Chapel, Ada/SPARK are all counter examples from such claim.

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

#96

Post by pjmlp »

royal__ wrote: post #54

I don't even know what Zig is but I've seen this topic come up so many times on this site that I'm starting to think the people who are actually doing this are unsure themselves whether it's a good idea or not.

Basically the security model of Modula-2 or Object Pascal, with a curly brackets syntax, and compile time execution.

Some folks embrace it as some kind of novelty.

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

#97

Post by drdexebtjl »

rwz wrote: post #71
drdexebtjl wrote: post #44

Earlier quoted context omitted.

Zig is not pre-1.0 because it’s not ready for production (bugs or missing features), it’s pre-1.0 because they want to be able to make breaking language changes. Nowadays when you can just point an agent at release notes and have it update everything, I actually prefer not having to wait through rare major releases to get new language features.

> they want to be able to make breaking language changes That sounds like it's not ready for production to me.

I invite you to read the release notes and see for yourself the types of breaking changes we’re talking about.

To me it is not much different from Lua, which despite being on 5.x for decades, makes breaking changes on minor releases (because it predates SemVer).

I also don’t see it being much different from any other language or language runtime that has a major release every year.

It’s fine to update at your own pace.

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

#98

Post by estebank »

stymaar wrote: post #83

Irrespective to the technical merits of both language, moving from a stable language to a pre-1.0 one that just lost his most popular open source project is a wild move.

> that just lost his most popular open source project

As they state in the article, they started the migration a year and a half ago, something that happened a few weeks back would never come into the decision making process.

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

#99

Post by minraws »

djha-skin wrote: post #51
Hinrik wrote: post #5

Earlier quoted context omitted.

Layperson here: what is special about Go's runtime, aside from the GC?

Chief design goals were radically easy concurrency and speed of compilation.

Speed of compilation feels like a distant second in terms of goals given the weird new generic features they keep adding..

I was fine with basic generics they complicated it quite a bit much for my liking.

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

#100

Post by andriy_koval »

dminik wrote: post #64

While I'm a rust enthusiast, I do agree that certain languages lend themselves well to particular domains. So a rewrite from Rust to something better suited is fine by me. In fact, while I do work on a rust project, I would not have and still would not recommend it as the choice for that particular project. That being said, I had to do some double takes while reading this. > https://rtfeldman.com/rust-to-zig#memory-s…

> In fact, while I do work on a rust project, I would not have and still would not recommend it as the choice for that particular project.

wondering what type of project is that? I think besides some very embedded projects with very little memory where you need C/assembly, rust is good enough for all kind of projects..

Post reply on HN