@dang: is this the kind of curious conversation that you're cultivating?
Zig → Rust porting guide
511–520 of 592 posts
Re: Zig → Rust porting guide
#512Just curious, why Go was not an option. TS compiler was rewritten in Go.
Re: Zig → Rust porting guide
#513Earlier quoted context omitted.
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 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 blowing off the communities response as overblown which it would be had the commit been tagged experimental. But it wasn't. And the author did themselves no favor blowing it off.
If the author was smart, their reply would simply have been:
Hello, To clarify, this is an experimental branch only. There are no plans to port, only experiment. I will tag the repo as such to ensure people understand its intention and avoid future misunderstandings.
Nothing difficult to understand here.
Re: Zig → Rust porting guide
#514Earlier quoted context omitted.
So by your logic all the PMs, managers and customers are programmers, right? After all, there’s a human compiler that takes their input and produces a program?
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.
Re: Zig → Rust porting guide
#515Interesting to see this when the current top post on HN is someone worrying about Bun as it was acquired by Anthropic. The top comment there describes “Anthropic does experiments on their own codebase, the Bun team is not gonna do the same vibe coding experiments”. Yet here we are, what looks like a massive undertaking for vibe coding. Time will tell how this will turn out. Would be nice if the Bun maintainers could…
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.
Not only that but Zig was working on a similar improvement to their change already
Re: Zig → Rust porting guide
#516Earlier 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…
I am a topic starter, and I had no emotional response, was just being curious. Never expected it will land at HN #1. I specifically posted the link to the first commit and not to the whole branch, because currently the prompt is the most interesting part.
An original topic starter? I'm pretty sure that this was originally posted on X by someone else, as I commented there, and minutes after, it was copied and put here on HN with the twisted title; the original was more of a "question, surprise tone"
Re: Zig → Rust porting guide
#517So far the wonders of claude/codex have been mostly constrained to applications that are built within the boundary conditions of existing libraries -- the models make direct use of the good work that humans have done to date to build Python, `requests`, `ffmpeg`, you name it.
But I'm excited for the (I think inevitable) stage where the shoggoth starts to reach outside those constraints -- rewriting, patching, renaming, rebuilding libraries, DLLs, binaries -- and we move into a regime where the libraries dissolve, the application floats on top of the shifting sands of an ever more efficient, secure, unified and totally inhuman technology stack.
Obviously this is a horrifying idea in some ways (interpretability, security etc), but it's also not obvious to me that it can't work, especially if there are dedicated, centralized efforts to do this. it's also not clear that interpretability is necessarily mutually exclusive with full slopification/machine rewrite of decades of foundational, incremental development
Re: Zig → Rust porting guide
#518this makes me so scared to work on OOS. If people saw every random draft PR, branch, design doc I ever made, no doubt the community would be furious
Re: Zig → Rust porting guide
#519Earlier quoted context omitted.
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.
> But now they are dependent on Zig which [...] is hostile to them because not accepting their contributions
I'm struggling to figure out how to even start interrogating this notion. What does this mean?
Re: Zig → Rust porting guide
#520you can use both zig and rust in a single project, duh
multi-language codebase are a nightmare to work with