711–720 of 754 posts
Earlier quoted context omitted.
> It's the whole damn point. Believe it or not, for some of us it’s not “the whole damn point”.
The purpose of a system is what it does. If people constantly use your device to turn kittens into pulp, you have built a kitten grinder, even if the label you slapped on the side says "coffee beans only".
Earlier quoted context omitted.
> It's the whole damn point. Believe it or not, for some of us it’s not “the whole damn point”.
Whether or not you want to admit that is up to you. If you're selling automation or efficiency gains, you're removing human labor.
Earlier quoted context omitted.
Running an experiment, the experiment being more successful than you thought, and then deciding to put more effort into a bigger experiment is not hypocrisy. It’s engineering. If you think some of the objective facts they’re putting out (like test coverage and performance) are lies, go and prove it instead of appealing to emotion.
Running an experiment and deciding based on the results is not hypocrisy, it's engineering, 100%. Saying you have no intention of doing something then doing it is not engineering, it's being dishonest. He could have said "well decide when we see the results", why didn't he?
Very impressive that they could do this so quickly because I have been on a similar project (porting TypeScript to Rust) for 5 months. But I guess I don't have access to Mythos and unlimited tokens. I'm also close to 100% pass rate. 99.6% at the time of writing. https://tsz.dev Rust is perfect for writing all of code using LLM. It's strict type system makes is less likely to make very dumb mistakes that other languag…
> Rust is perfect for writing all of code using LLM. It's strict type system makes is less likely to make very dumb mistakes that other languages might allow. I question this. Yes, strong enforcement of invariants at compile time helps the LLM generate functional code since it gets rapid feedback and retraces as opposed to generating buggy code that fails at runtime in edge cases. On the other hand, Rust is a complex…
Serious question… Who’s going to want to run a vibe coded runtime in production? I don’t see how this is a good look for Bun?
One should care about tests more than how code was coded. If I had a codebase with lots of tests and asked someone else to rewrite it to another language passing the same test suite, I honestly wouldn't expect a great quality job. I say this because it happened 3 times in the company I work for: we conducted experiments by tasking different companies to rewrite the same code in another language. All of them passed (m…
All tests overspecialize and easy to cheat, there is no "program works" test.
Earlier quoted context omitted.
>I don't agree that them actually doing an entire draft rewrite can just be characterized as them considering a rewrite. You're right, a rewrite is in existence, and whether it is good enough to be used or expand upon is what is being considered. I don't think that changes the fact that languages don't live or die by whether or not 1 large project using them continues using them. Especially a language like Zig which…
>It's not like Jarred has been begging the Zig devs to implement language changes to make Bun development easier. Zig was always upfront that you will have to manage memory manually, and that allows for operator error. Huh? The patch that Bun submitted was for Zig was about compilation times, and making Zig's type resolution faster. I am sure the Bun developer who is submitting patches to Zig is well aware that manua…
You're right, other things constant, this would not make sense. But this is a strawman. Zig has fast compilation on average compared to systems languages with more automatic memory management, like Rust. In addition, Bun's fork is based on 0.14 Zig, while 0.16 has become much faster.
Take a look at this post by one of Zig's core maintainers explaining why Zig doesn't want to upstream any changes from the Bun fork: https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio....
In short, the Bun fork introduces non-deterministic compilation errors, a terrible problem for a language and its compiler to have. Zig just made changes to type resolution in 0.16 specifically to allow them to implement parallel semantic analysis, but properly without the bug the Bun fork has.
In addition, they have chosen to spend their time building the self-hosted backend and perfecting incremental compilation, which will have orders of magnitude more benefits to compile times than. Matthew already demonstrates a 4x speedup, what Bun claims to achieve, using the self-hosted backend, and 300x speedups with incremental compilation on a large project (Zig itself).
I am sure it is frustrating for Jarred to not get his patch in, but he was rebuffed for good reason. Bun's fork may have worked for them but many people, including the Zig team, would rather Zig do things properly than introduce bugs and tech debt to make flashy headlines.
Earlier quoted context omitted.
I disagree with a lot of what you said, but I don't feel authorative enough to say you're wrong. > Which is really not that many places, it's a fast but rather niche optimization. There's not a whole lot of scenarios where lots of temporary memory is needed for one well defined scope. Arena allocators are not niche optimizations, or not something picked first for optimization. Contrary to what you said, arenas are us…
> Zig doesn't have explicit annotations for it, but the concept of ownership and lifetime doesn't go away. It's not enforced by the compiler, which is an intentional tradeoff to let the programmer have more control and freedom. Right, it's exactly like C, and we kinda all know how that worked out in practice already... Hence why I called Zig a "love letter to C". If all you want is C with a dash of zest, that's Zig.…
Production operating systems have been written in C, along the with the countless tooling, libraries and game engines (which you said are a poor fit for manual memory management) that modern systems depend on. I say it worked out it pretty well.
And zig did learn from the hard lessons from the industry and fixes a lot of problems with C. It also has a lot of affordances that makes it more than suitable for general purpose use.
> Arenas are not good for that because the arena as a whole has to outlive all of those poorly defined scopes & lifetimes, which is hard to do.
I don't what else to tell you, arenas outliving temporary allocations is exactly what it is made for, they go poof as soon as the arena owner is done. That's not hard, it makes it easier if anything. To give concrete examples, arenas are used on HTTP requests that are clean up in one go as soon as the request is done. They are also used on (possibly deep) recursive functions that are cleaned up as soon as the root function returns. Of course, you don't store arena-allocated memory elsewhere that outlives the arena, that would be dumb.
That's why you have to be consciously aware of the ownership and lifetimes that a piece of memory has. Ownership and lifetimes are just one part of the API contract of a function or module. You break it, that's on you. Having a compiler help with ownership model would be nice, but it's a not substitute for having a good mental model of your programs. It's not that different from the tradeoff of a having a less strict type system. Not every sanity check can or has to be performed at compile time. Zig also has debug allocators that catches a lot of memory mismanagement during testing. Hard to debug double-frees, use-after-frees and other things are a symptom of poor cavalier YOLO programming.
That all said, I do agree that manual memory management is really hard to do if you are used to just sweeping gigabytes of memory under rug, hoping the GC vacuum cleaner slurps it afterwards. It takes a mindset and a set of practice. But once you internalized it, it becomes second nature.
(Not to sound like a zig fanboy, I do think it's still rough around the edge and there are a lot of things I don't like. But manual memory management is not that big of a problem).
Earlier quoted context omitted.
> Can you give some examples? I've never ran into problems due to this. If it's doing a drop in the hot loop that may be an unexpected performance regression that could be carefully lifted. thank you. Unfortunately in the last few weeks i've been too busy with my startup to put as much work into it. We'll see =D
> If it's doing a drop in the hot loop that may be an unexpected performance regression that could be carefully lifted. Yeah, I've heard of people being surprised that when they make massive collections of Box'ed entries, then get surprised that it takes a long time to Drop the whole thing. But this would be the same in C or Zig too. Malloc and free are really complex functions. Reducing heap allocations is an essent…
Earlier quoted context omitted.
The purpose of a system is what it does. If people constantly use your device to turn kittens into pulp, you have built a kitten grinder, even if the label you slapped on the side says "coffee beans only".
Nonsense. By your logic anything pointy is a killer machine, because people constantly use them to kill.
Earlier quoted context omitted.
What language doesn't allow memory leaks?
I suppose all languages allow them, depending on how you define a memory leak. Garbage collected languages generally prevent them, since you never have to explicitly free memory, but if there are reference cycles, that memory can never be freed automatically. Rust has the same problem, but since rust uses lifetimes to understand when to drop things, many people expect that this will mean there can be no memory leaks,…
Many garbage collection algorithms can deal with cycles.