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

331–336 of 336 posts

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

#331

Post by bbkane »

niclas-ahden wrote: post #328
bbkane wrote: post #168

Tangentially relates, but if any Roc devs are around I'm curious about the use cases for Roc. It's supposed to be a scripting language right you embed into your C ABI right? Do you see it competing with WASM for the plugin use case (i.e. a really large Roc platform)? Why would an app author prefer to expose a Roc layer to their app rather than a WASM layer? With a WASM layer, plugin devs can write in any language. An…

>Another use case I've heard from it is as a more app-level language (i.e. a really small Roc platform). Do you see it competing with Gleam for server side http code? Do you see it competing with Elm for client side code? For sure! I've been using Roc for work exclusively for the past year and a half, writing mostly full-stack web apps, and it's been great. I wrote a small framework/platform ( https://github.com/nicl…

Thanks, I've starred your repo and I'll come back to it once Roc is more mature!

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

#332

Post by onlyrealcuzzo »

dnautics wrote: post #330
onlyrealcuzzo wrote: post #327

Earlier quoted context omitted.

By all means - reach out when it's ready and I'll give it a test. I'm highly skeptical you can get it to work. If it was easy and optional and non-invasive and actually worked - the Zig team would almost certainly build it. But, even if it just mostly works - that would still be very useful if it's non invasive.

> the Zig team would almost certainly build it 1. It's a small team. 2. The zig team is parsimonious about what they do and don't build. For example, they did not work on the language server, rather punting it to the community. 3. That you can do this with the zig compiler is a happy accident. The team was not designing towards this possibility, it's not really a part of the core zig ethos (and that's fine). 4. You c…

You either do it with Linear Types, Affine Types, or you have holes...

Or you've invented a novel new system and should be publishing white papers immediately.

You can do virtually everything Zig comptime does in Brute Force in C++23. If this was possible - completely, it would already be done for C++. You need to point out exactly what you can do in Zig that you can't in C that somehow magically makes this completely possible and bulletproof in Zig - otherwise, you have a "concept of a plan".

The reason Rust sucked the air out of the room is that people are much more interested in systems without holes than systems that mostly work, or partially solve small parts of the problem and/or rely on the developer getting it right.

I hope you're right, but hope is a bad strategy.

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

#333

Post by dnautics »

onlyrealcuzzo wrote: post #332
dnautics wrote: post #330

Earlier quoted context omitted.

> the Zig team would almost certainly build it 1. It's a small team. 2. The zig team is parsimonious about what they do and don't build. For example, they did not work on the language server, rather punting it to the community. 3. That you can do this with the zig compiler is a happy accident. The team was not designing towards this possibility, it's not really a part of the core zig ethos (and that's fine). 4. You c…

You either do it with Linear Types, Affine Types, or you have holes... Or you've invented a novel new system and should be publishing white papers immediately. You can do virtually everything Zig comptime does in Brute Force in C++23. If this was possible - completely, it would already be done for C++. You need to point out exactly what you can do in Zig that you can't in C that somehow magically makes this completel…

its refinement types which are a "superset of affine types" iiuc (you can construct a refinement type system that can represent affine types, plus more).

there is nothing special about zig that makes it fundamentally possible in zig and impossible in C.

the difference is that compiler architecture, some language decisions, well-designed stdlib, not having to contend with past decisions of a committee that overweighted backwards compatibility, take it from "jesus christ this is too much of a pain in the ass to bother" to "oh theres actually a path forward for one person and an llm".

As a concrete example. In C there is no "anointed allocator", sure, most people use malloc/free, but a broadly useful analyzer needs to be able to contend with any of a billion different patterns, and "oops I forgot jemalloc's mallocx" is not really okay (plus you gotta deal with weird things like errno, etc, and maybe some program uses jemalloc's free in some places and stdlib free in other places, how do you track that). In zig, sure, you could build a function that allocates off the stdlib path, but it's not unreasonable to "ban" that and force people to use the stdlib interface, and most dependencies will be compliant. Hopefully you can see how this "jesus christ i don't want to deal with all that" vs "a clean path forward".

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

#334

Post by Ar-Curunir »

dnautics wrote: post #305
Ar-Curunir wrote: post #156

Earlier quoted context omitted.

the architecture doesn't make sense. MIRI doesn't perform static analysis on MIR. It is, as the name says, an interpreter. The borrow checker is entirely different from miri. Rust's borrow checker requires lifetime annotations. Zig code doesn't contain any such annotations. How does your design handle this?

1. it is possible to do code annotations in zig even though i havent implemented it in this iteration of clr (the first poc demonstrated this). i want to see how far i can get without them. 2. let's take double free (easiest to explain). you dont have to tag ownership, you can be agnostic about who should free, and merely report if two nondisjoint code paths attempt to free the same memory.

Re 1: that doesn't help with Zig code that doesn't use your annotations. In contrast, Rust forces all code to use annotations.

Re 2: that still looks to me to be a runtime check.

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

#335

Post by niclas-ahden »

bbkane wrote: post #331
niclas-ahden wrote: post #328

Earlier quoted context omitted.

>Another use case I've heard from it is as a more app-level language (i.e. a really small Roc platform). Do you see it competing with Gleam for server side http code? Do you see it competing with Elm for client side code? For sure! I've been using Roc for work exclusively for the past year and a half, writing mostly full-stack web apps, and it's been great. I wrote a small framework/platform ( https://github.com/nicl…

Thanks, I've starred your repo and I'll come back to it once Roc is more mature!

Good move! I'm porting it to the new compiler now and that'll enable nicer APIs and fewer workarounds. Roc v0.1 (later this year probably?) will be a great time to jump in!

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

#336

Post by vips7L »

silisili wrote: post #131
vips7L wrote: post #119

Earlier quoted context omitted.

Is the Go GC that special? Is it even generational yet?

I'm not sure it would ever make sense to be. That makes the assumption tons of allocations get made that don't live long, which was(maybe is still?) more common in some languages. Go is more aggressive about not heap allocating, and has tools to help you avoid them.

It makes plenty sense to be. There aren’t many negatives and there are plenty of workloads that would benefit.
Post reply on HN