Happy to answer any questions about Bun
If it really is a problem, then a binary lockfile might be worth it, but it's a pretty substantial hit to developer experience, I think. At least, I'm accustomed to checking the lockfile diff on PRs, and it's a shame to lose that.
To make serialization fast though, it would still need to do structure of arrays instead of an array of structures. Instead of each package being an object in the lockfile, arrays of package names, of version numbers, etc. it would need a tool to understand it
As for Rust and Zig, IMHO, programming in Zig is more fun, so if I was OP, I'd also have gone for Zig.
I have some criticism for the language itself around personal preferences, such as "concepts need to be finished ASAP", "don't depend on libc" (Zig is doing a much better job here) and some syntax pet-peeves.
Nim needs to be more popular IMO. Well, the same goes for D too. Sigh.
1. Support for cyclic imports 2. Official WASM support. I know nlvm exists. But those are two separate runtimes to be managed for long time.
I was writing a compiler I remember where I hit the 5k LOC mark in Nim. And then the errors and stuff. It was a terrible experience putting all the types into one file, the functions into others etc etc. The DevExp is bad that way.
Other than that, I don't see much issues with Nim to be fair. Its quite a good language that ticks all boxes
Some problems are - vibe.d does not look nearly as performant or supported as, say, Drogon, which is what I was seriously considering using (I love the idea of using C++ with modern move semantics and coroutines to make async code easy).
I know and love Java and Node a lot - just want to try not using a VM for a bit :)
Currently writing a small Zig project, I can totally see that. Although frankly I will probably stick to Go. Zig is a lot more work in my view as it os very low level. However that is also what helps you squeeze out performance.
With Zig you really get a fine grained control of memory management and it is a lot easier to push anything you can to be computed at compile time rather than runtime.
How much of this is due to Zig, vs using Webkit instead of v8?
Please take a look at #1169. This stopped me, and the issue got a couple agreements. Also asked around on Discord to no avail. I see you have #156, which seems to indicate you're able to bundle, just not optimally for prod. But it's not clear to me how to generate a bundle.js for a main entrypoint.
Maybe just a doc issue? Running ./node_modules.bun gets a loadable module, but unclear where to go from there and it's not drop-in compatible with my esbuild process.