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

491–500 of 592 posts

Re: Zig → Rust porting guide

#491

Post by [deleted] »

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.

[deleted]

Re: Zig → Rust porting guide

#492

Post by philwelch »

kelnos wrote: post #247
philwelch wrote: post #50

Earlier quoted context omitted.

Normal, emotionally stable people don’t care if the creators of a programming language disagree with them about tariffs.

I can't find any evidence that the creators of Zig hold the views GP seems to suggest, but I think your assertion is wrong. Normal, emotionally stable people do sometimes make decisions about what businesses to patronize based on the political leanings of the business owners. Same thing happens with art appreciation, movie/TV watching, and plenty of other things. Zig might not be a business, but the same rules apply.…

> Normal, emotionally stable people do sometimes make decisions about what businesses to patronize based on the political leanings of the business owners.

Maybe with issues like abortion or racial discrimination, but not tariffs.

Re: Zig → Rust porting guide

#493

Post by zapnuk »

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…

You could also use the LLM create a program to do the conversion and then review and use the program to deterministicly perform the actual conversion.

Have the best of both worlds.

Re: Zig → Rust porting guide

#494

Post by Klonoar »

MisterTea wrote: post #483
Jarred wrote: post #319

I work on Bun and this is my branch This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely. I’m curious to see what a working version of this looks, what it feels like, how it performs and if/how hard it’d be to get it to pass Bun’s test suite and be maintainable. I’d like to be able to co…

Advice for the future: experiments should be explicitly tagged as such. The commit message "docs: add Phase-A porting guide" says nothing about the experimental and looks like a planned move to rust. That message certainly looks very official to me. > This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets throw…

Or the community at large could stop acting deranged over language wars like it’s 2001.

It’s their repo, let them do what they want lol

Re: Zig → Rust porting guide

#495

Post by desdenova »

sarreph wrote: post #349
Jarred wrote: post #319

I work on Bun and this is my branch This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely. I’m curious to see what a working version of this looks, what it feels like, how it performs and if/how hard it’d be to get it to pass Bun’s test suite and be maintainable. I’d like to be able to co…

It is a pity that you can't make an experimental commit on an experimental branch without igniting a fire of delirium through some people who -- if they were able to put their emotional response aside for a minute and could weigh this up on the basis of merit -- would probably agree with the motivations for researching this approach. > if/how hard it’d be to get it to pass Bun’s test suite and be maintainable Every m…

The fact someone who works on Bun is willing to create and even push a branch generated by a stochastic parrot is very telling of the direction the project is going.

Doesn't matter if it's "experimental", it's a dumb experiment that shouldn't exist.

Re: Zig → Rust porting guide

#497

Post by delfinom »

desdenova wrote: post #495
sarreph wrote: post #349

Earlier quoted context omitted.

It is a pity that you can't make an experimental commit on an experimental branch without igniting a fire of delirium through some people who -- if they were able to put their emotional response aside for a minute and could weigh this up on the basis of merit -- would probably agree with the motivations for researching this approach. > if/how hard it’d be to get it to pass Bun’s test suite and be maintainable Every m…

The fact someone who works on Bun is willing to create and even push a branch generated by a stochastic parrot is very telling of the direction the project is going. Doesn't matter if it's "experimental", it's a dumb experiment that shouldn't exist.

Why are you treating branches as if they are holy? This is all OSS, people work on this in their free time, git is got and people can use branches as they like to experiment and share their experiments with others. If you don't like the code, don't use it you damn leech.

Re: Zig → Rust porting guide

#498

Post by unethical_ban »

desdenova wrote: post #495
sarreph wrote: post #349

Earlier quoted context omitted.

It is a pity that you can't make an experimental commit on an experimental branch without igniting a fire of delirium through some people who -- if they were able to put their emotional response aside for a minute and could weigh this up on the basis of merit -- would probably agree with the motivations for researching this approach. > if/how hard it’d be to get it to pass Bun’s test suite and be maintainable Every m…

The fact someone who works on Bun is willing to create and even push a branch generated by a stochastic parrot is very telling of the direction the project is going. Doesn't matter if it's "experimental", it's a dumb experiment that shouldn't exist.

Underplaying AI, overselling what an experimental branch is, and suggesting it's representative of the entire project, all while suggesting people shouldn't even consider new tools and methodologies. Where to start.

Re: Zig → Rust porting guide

#499

Post by hiccuphippo »

I wonder if something like Haxe, a language that was able to transpile to several languages would be the best target for LLMs. They could always generate haxe and then transpile it to whatever language the user wants. Probably not for an already ongoing project like this but for a greenfield one.
Post reply on HN