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

Zig → Rust porting guide

github.com

Post reply on HN
Print view View original

541–550 of 592 posts

Re: Zig → Rust porting guide

#541

Post by halJordan »

kelnos wrote: post #236
kgeist wrote: post #71

Interesting how times have changed. Back in 2015, the entire Go runtime (already a mature codebase) was rewritten from C to Go semi-automatically: one of the maintainers wrote a C-to-Go conversion tool (for a subset of C they used) so that it compiled and produced identical output, and then the resulting code was manually refactored to make the Go code more idiomatic and optimized. And now you can just ask a language…

The big difference here is that the C-to-Go tool was presumably deterministic: running it over and over again should produce the exact same result. You can trust that result because the human wrote the conversion tool, understood it, tested it, and worked the bugs out. The LLM is non-deterministic. You could have it independently do the conversion 10 times, and you'd get 10 different results, and some of them might e…

I'm not convinced by this argument. If you put 10 senior devs on a problem, you'd get ten solutions. Maybe even 12. If one engineer solves the same problem 10 times, you also will get 10 solutions.

The problem is not that we get 10 solutions, and I think you should draw out your implications and state them directly. Bc they're already either solved or being actively iterated on by industry. And we (well not me) can address them if you're willing to speak them

Re: Zig → Rust porting guide

#542

Post by pierrelgol »

satvikpendem wrote: post #474
pierrelgol wrote: post #464

Earlier quoted context omitted.

That's true, but then there's also the case of working on the zig compiler which is roughly a million loc, and with `--watch -fincremental` you can get 200ms recompile even if you change some of the most called function. Meanwhile even a 5k-10k rust project can take a 30s to recompile on minor changes. So the impact on velocity can be quite high, I love both languages, but the Zig compiler is undeniably faster than t…

Rust also has incremental compiling and is pretty fast, I haven't experienced 30 second compile times when using cargo watch. See also, cranelift, which is supposed to make compile times even faster.

from my own testing even their incremental on a codebase 10x smaller than the Zig compiler like Helix the text editor, on my machine almost all changes take 2/3s and with cranelift it's like 4/5s.

So it's definitely a faster feedback loop and honestly completely bearable, but it's not 200ms.

Re: Zig → Rust porting guide

#543

Post by brabel »

matt_kantor wrote: post #514
brabel wrote: post #373

Earlier quoted context omitted.

They are programmers when they write a prompt and get runnable code as a result, yes… but no if asking a human to write the code because if you have an intermediate, manual step between the text and the running code, you don’t have an automated process and hence it’s no longer even an application, let alone a “compiler”.

Why does it matter if a human or a machine is responsible for turning the prompt into code? If there's a black box which I can send C code into one side of and get faithful machine code out the other, I'd call that box a "compiler". I wouldn't rename it if I later find out that there are little elves inside doing the translation.

Sorry but that’s a childish take.

Re: Zig → Rust porting guide

#544

Post by pierrelgol »

satvikpendem wrote: post #474
pierrelgol wrote: post #464

Earlier quoted context omitted.

That's true, but then there's also the case of working on the zig compiler which is roughly a million loc, and with `--watch -fincremental` you can get 200ms recompile even if you change some of the most called function. Meanwhile even a 5k-10k rust project can take a 30s to recompile on minor changes. So the impact on velocity can be quite high, I love both languages, but the Zig compiler is undeniably faster than t…

Rust also has incremental compiling and is pretty fast, I haven't experienced 30 second compile times when using cargo watch. See also, cranelift, which is supposed to make compile times even faster.

The problem is not just that Rust takes a few seconds longer once. It compounds across the edit/debug cycle. If you make around 800 save/check iterations in a day, then a 2.5–3.5s feedback loop costs roughly 34–48 minutes of waiting per day. The same number of iterations at 200ms costs about 2.8 minutes.

So the practical delta is around half an hour to three quarters of an hour per day, or multiple hours per week. That directly affects flow state and experimentation speed. over the span of a month that's 2 full days worth of work waiting for the compiler. Or if you take my company's evaluation of the average engineer's hour cost it's roughly 2550 per month or almost 30k per year, obviously it's a bit exaggerated, you don't spend a full year refactoring and working like that, but even a tenth of that is still a big lump of money if you scale it to a few teams.

Now it needs to be taken with a huge pinch of salts because Rust provides other benefits that offsets the fact that it's painfully slow to compile, but still worth noting

Re: Zig → Rust porting guide

#545

Post by Tadpole9181 »

MisterTea wrote: post #513
Tadpole9181 wrote: post #488

Earlier quoted context omitted.

Or we can stop being toxic to open source maintainers and acting like we own them or they owe us anything. A commit message on a random branch is not an obligation. Not telling random internet users what side projects they're working on is not a blunder. It quite frankly doesn't matter what you think looks official, it doesn't give you the right to treat people like this. It's so embarrassing to be a programmer some…

> Or we can stop being toxic to open source maintainers and acting like we own them or they owe us anything. The majority of the community feels this way which says something. The author's reaction is to publicly display being upset and dismissive of the communities reaction. That is just making it worse. When you work on a project this big, more care is needed. The commit was an innocent mistake. The blunder is blow…

> The majority of the community feels this way which says something.

Yes, it says that those people are spoiled rotten brats and the community needs to start calling it out to improve itself.

They aren't contributors. They aren't employees. They aren't paying customers. Bun is not a web standard. They benefit from a free product that they chose to opt into over the standard ecosystem.

And for some reason they feel they have a right to know every decision and experiment everyone who does work on that project is making apriori. And, God forbid, if somebody even so much as starts working on something in an off branch that doesn't affect them in any way without getting their approval, they're going throw an absolute hissy fit.

And to criticize the person actually doing their job for feeling slighted that hundreds of people have verbally accosted them over it, because one feels they don't recognize an "implied responsibility" to those folk, is silly.

I'll also push back, though. The majority of the community doesn't seem to be doing anything.

Re: Zig → Rust porting guide

#546

Post by nailer »

Jtarii wrote: post #510
nailer wrote: post #447

Earlier quoted context omitted.

It’s the person that created the term’s definition.

Language and culture don't work like that. Inventing a term doesn't give you exclusive rights to provide the definition.

Yes but it's been a little over 14 months.

Re: Zig → Rust porting guide

#548

Post by bnolsen »

satvikpendem wrote: post #470
Imustaskforhelp wrote: post #455

Earlier quoted context omitted.

Do you know which project gets the most hate? Nodejs, so in that sense, Nodejs has made it and it is widely deployed but this hate was the reason that two seperate alternatives for Node have emerged as Deno and bun. Recently Bun's latest version had memory leaks which crashed production code from my understanding and their attitude[0] of saying OSS will have no human contribution allowed, now doing these ports of zig…

Well yeah, it's in Zig, not a memory-safe language, so of course I'd expect memory leaks. That's why I haven't seriously used bun and instead use a runtime that actually is in a memory-safe language, Deno in Rust. It's like wearing roller skates without brakes and wondering why you keep running into things.

Unit tests in zig will fail if the tested code leaks memory.

Re: Zig → Rust porting guide

#549

Post by ale »

mohsen1 wrote: post #360

I am also porting TypeScript to Rust. With a different design I managed to make it faster than tsgo port. I've made a lot of progress in the last 4 months but needs more work. Contributions are welcome! https://tsz.dev

The fact that tsz can compile to wasm might actually give you an even more interesting feature that tsgo can't (yet): using the type checker for data validation at runtime.

Re: Zig → Rust porting guide

#550

Post by matt_kantor »

brabel wrote: post #543
matt_kantor wrote: post #514

Earlier quoted context omitted.

Why does it matter if a human or a machine is responsible for turning the prompt into code? If there's a black box which I can send C code into one side of and get faithful machine code out the other, I'd call that box a "compiler". I wouldn't rename it if I later find out that there are little elves inside doing the translation.

Sorry but that’s a childish take.

Would you mind explaining why?
Post reply on HN