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

421–430 of 592 posts

Re: Zig → Rust porting guide

#421

Post by latexr »

jaapz wrote: post #407
latexr wrote: post #385

Earlier quoted context omitted.

This is getting stupid. Now one can’t even make a reasonable polite question with praise without being asked if they pay. Bun raised millions of dollars and was acquired by a commercial entity which bragged in the same blog post of reaching $1B. They’re not a guy with an eyepatch and a tin can out on the street. Open-source developers should be compensated, but they don’t have to be. You can’t reasonably offer your w…

Come on, whenever a project is discussed on hackernews, there is always one comment of "why are you working on X, when you should be fixing bug Y?!". We are all software engineers on here (or at least many of us are), we all know how project management and prioritisation works right? We can't work on everything all at once.

> Come on, whenever a project is discussed on hackernews, there is always one comment of "why are you working on X, when you should be fixing bug Y?!".

That is not what the question is about, which you’ll see if you engage with it properly in good faith. There is a single question in the comment (indicated, as one does in English, by a question mark):

> How do you feel about all the constant concerns being raised about the quality of the project lately?

Everything else is context and opinion to explain the question.

Re: Zig → Rust porting guide

#422

Post by newswasboring »

xigoi wrote: post #277
brabel wrote: post #273

Earlier quoted context omitted.

That’s funny because it’s exactly, literally the same. The difference is it’s not deterministic. That may be a problem but it’s still a higher level language, just a much higher level language than anything before.

The main difference is that the input to an LLM is in an ambiguous language.

So is JavaScript haha.

Re: Zig → Rust porting guide

#424

Post by [deleted] »

jeroenhd wrote: post #361
alethic wrote: post #320

Earlier quoted context omitted.

In the context of this post, that's absolutely hilarious they're vibe-porting their Zig codebase to Rust . I love Rust, but you couldn't pick a language with slower compile times... XD

Compiling Rust is actually quite fast in my experience. The problem with many Rust projects is that they pull in dependencies left, right, and center. Pulling in Tokio makes your project compile an entire thread management system even if you're just compiling Hello World, and simple oneliners containing macros can easily spread out into dozens of lines of code each. Linking is also slow, and the extreme amounts of me…

[deleted]

Re: Zig → Rust porting guide

#425

Post by padjo »

xigoi wrote: post #333
padjo wrote: post #239

Picking a pre 1.0 language to build your product always seemed like a bad choice to me. Purely on that basis and ignoring the recent drama this seems like a reasonable idea for tech debt pay down to me. Assuming automated conversion can work without making things worse, which is not exactly a given.

> Picking a pre 1.0 language to build your product always seemed like a bad choice to me. Such as React Native? :D

React Native is only an application framework. Using a tool with an unstable API a level down the stack seems much worse. Foundations of sand is the phrase that springs to mind.

Re: Zig → Rust porting guide

#426

Post by conartist6 »

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…

Hoping that an AI rewrite is thrown out.

You may even be an OK programmer, but IF YOU AREN'T ABLE TO DO THE WORK I DON'T WANT TO USE IT.

Not worth your time? Not worth my time.

Re: Zig → Rust porting guide

#427

Post by elktown »

stingraycharles wrote: post #396
elktown wrote: post #370

Earlier quoted context omitted.

"Show me the incentive and I'll show you the outcome" is usually the overarching law of software dev/design/arch.

What do you mean with that in this context?

That the incentives have changed after being bought by Anthropic. So don't be surprised by a sudden change of heart.

Re: Zig → Rust porting guide

#428

Post by dolmen »

epolanski wrote: post #301
TheRoque wrote: post #62

Earlier quoted context omitted.

Why didn't they use Rust in the first place then ? All this was true before AI

Zig has some advantages for such projects, especially in the beginning. Among them: - much easier to iterate on (due to the language being simpler and compilation much faster) - native C/C++ interops (Zig can compile C and C++ and mix it with Zig) which is crucial for a node-replacement runtime that runs an open source JS engine - fewer dependencies and trivial static linking I guess that now that they've been acquir…

Also: Anthropic bought Bun to not depend on node.js. But now they are dependent on Zig which is a moving target and is hostile to them because not accepting their contributions.

Re: Zig → Rust porting guide

#429

Post by chrisweekly »

majormajor wrote: post #87
chrisweekly wrote: post #31

Earlier quoted context omitted.

100%. For many people, Bun is the only reason they've even heard of Zig. I'm not in a position to comment intelligently on comparative language features per se, but when it comes to mindshare and community size, Rust is a clear winner.

fwiw before today I'd heard of Zig and not Bun :D something JS-adjacent could certainly be more known than an obscure language but are that many people using drop-in node replacements?

alt runtimes are still pretty niche, but deno and bun do have some degree of adoption. For Bun, the runtime is actually sometimes perceived as unwanted baggage, (eg a consulting client of mine wanted to pursue bun for its build tooling but had no interest in changing the runtime). IMHO, node (with Vite and PNPM) is the right call for the vast majority.

Re: Zig → Rust porting guide

#430

Post by naasking »

jeltz wrote: post #293
andkenneth wrote: post #100

Earlier quoted context omitted.

They recently tried to upstream an improvement to zig, but were prevented from doing so because zig has a hard and fast "no AI code" rule. Whether you think this response is trying to put pressure on zig or whether they're just moving for practical reasons is up to you. It's probably a bit of both.

I don't see why they think it would work when the reason their patch set was rejected was because it was not correct, did not go in a direction the Zig authors were interested in and is also in an area where they are already working hard on improvements. It would have been much better if the bun team joined forces and helped out instead of vibe coding a broken PoC patch that never can get merged. Compilation speed is…

> It would have been much better if the bun team joined forces and helped out

Submitting patches is joining forces and helping out.

Post reply on HN