7 ms·

cargo check reported over 16,000 compiler errors when I wrote that message. It could not print a version number or run JavaScript. I didn’t expect it to work th

• sysguest 4mo ago
  > I am so tired of worrying about & spending lots of time fixing memory leaks and crashes and stability issues. it would be so nice if the language provided more powerful tools for preventing these things. haven't used zig...(only used rust) but zig doesn't solve those problems?
  • josephg 4mo ago
    Nope! Zig is like C in this regard. There’s no borrow checker. Managing memory is your responsibility. It gives you a few more tools than C - like a debug allocator, bounds checked array slices and so on. But it’s not a memory safe language like rust.
    • dnautics 4mo ago
      It's not.. but im pretty sure it could be. could probably even take this (WIP) idea and bolt on a formal verifier pretty easily. https://github.com/ityonemo/clr https://github.com/ityonemo/clr
      • josephg 4mo ago
        It'd take more than that to match rust's borrow checker. Rust's borrow checker tracks lifetimes, and sometimes needs annotations in code to help it understand what you're actually trying to do. I suppose you could work around that by adding lifetime annotations in zig comments. Then you've have a language that's a lot like rust, but without an ecosystem of borrowck-safe libraries. And with worse ergonomics (rust knows when it can Drop). And rust can put noalias everywhere in emitted code. And you'd probably have worse error messages than the rust compiler emits. Its an interesting idea. But if you want static memory safety in a low level systems language, its probably much easier to just use rust.
        • dnautics 4mo ago
          > I suppose you could work around that by adding lifetime annotations in zig comments. you can make a no-op function that gets compiled out but survives AIR > rust knows when it can Drop. and its possible to cause problems if you aren't aware where rust picks to dropp. > And rust can put noalias everywhere in emitted code. zig has noalias and it should be posssible to do alias tracking as a refinement. > But if you want static memory safety in a low level systems language, its probably much easier to just use rust. don't use that attitude to suck oxygen out of the air. rust comes with its own baggage, so "just using rust because its the only choice" keeps you in a local minimum.
          • josephg 4mo ago
            > and its possible to cause problems if you aren't aware where rust picks to drop. Can you give some examples? I've never ran into problems due to this. > don't use that attitude to suck oxygen out of the air. rust comes with its own baggage Yeah, that's a totally fair argument. One nice aspect of the approach you're proposing is it'd give you the opportunity to explore more of the borrow checker design space. I'm convinced there's a giant forest of different ways we could do compile time memory safety. Rust has gone down one particular road in that forest. But there's probably loads of other options that nobody has tried yet. Some of them will probably be better than rust - but nobody has thought them through yet. I wish you luck in your project! If you land somewhere interesting, I hope you write it up.
            • dnautics 4mo ago
              > 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
              • josephg 4mo ago
                > 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 essential tool for optimisation. The solution to this "unexpected performance regression" in rust is the same as it is in C, C++ and Zig: Stop heap allocating so much. Use primitive types, SSO types (SmartString and friends in rust) or memory arenas. Drop isn't the problem.
    • pjmlp 4mo ago
      Those tools exit in C tooling as well, now that many ignore them is another matter. MSVC has a debug allocator since at least Visual Studio 5.
  • efficax 4mo ago
    zig is unmanaged memory. But rust also allows memory leaks, and they're not uncommon in large, complex programs. So this rewrite will not necessarily control for that.
    • X0Refraction 4mo ago
      What language doesn't allow memory leaks?
      • dmytrish 4mo ago
        There are two kinds of memory leaks: forgotten manual freeing (all references are gone, but allocation is not) and forgetting to get rid of references that keeps an allocation alive. Both are a kind of logical error, but the first is mostly possible in languages with manual memory management. The second one is a universal logical error (only programmer knows which live references are really needed).
        • tardedmeme 4mo ago
          Rust allows reference-counting cycles, right?
        • ethanpailes 4mo ago
          In the Haskell community I’ve seen the second kind called “space leaks.” I don’t see it used much outside that community but I like the term and use it when talking about other languages as well.
      • efficax 4mo ago
        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, but leaks are not considered a correctness or safety issue (oom is a panic and panic is safe!). Not only explicitly possible (through Box::leak) but also possible by mistake (again, usually through reference cycles).
  • nyrikki 4mo ago
    Zig is a middle ground. It solves some of the common foot-guns in C, Without the costs of affine substructural typing that offers Rust its super powers. I am of the opinion that it is horses for courses and not a universal better proposition. Because my needs don’t fit in with Rust’s decisions very well I will use zig for personal projects when needed. I just need linked lists, graphs etc… While hopefully someone can provide a more comprehensive explanation here are the two huge wins for my use case. 1) In Zig, accessing an array or slice out of bounds is considered detectable illegal behavior. 2) defer[0] allows you to collocate the the freeing of resources with code. That at least ‘feels’ safer to me than a bunch of ‘unsafe’ rust that is required for my very specific use case. I was working on some eBPF code in C and did really miss zig. For me it fits the Pareto principle but zig is also just a sometimes food for me, so take that for what it is worth. [0] https://zig.guide/language-basics/defer/ https://zig.guide/language-basics/defer/
    • IshKebab 4mo ago
      Fwiw you don't need unsafe for graphs or linked lists in Rust. At least not directly - these things can be abstracted. The petgraph crate is the most popular for graphs. I'm not sure about linked lists because linked lists are the wrong choice 99.9% of the time. I've written hundreds of thousands of lines of Rust and outside of FFI, I've written I think one line of unsafe Rust.
      • fao_ 4mo ago
        [flagged]
        • IshKebab 4mo ago
          It's not as simple as that. All software is abstraction and with any software if you go deep enough you'll find unsafe code. E.g. look at a Python list. Is it safe? In Python sure, but that's abstracting a C implementation which definitely isn't safe. If you look at Rust's std::Vec you'll find a very similar story - safe interface over an unsafe implementation. It isn't as binary as you think.
        • 4mo ago
  • SuperV1234 4mo ago
    Zig doesn't even have RAII...
    • reactordev 4mo ago
      which is a good thing. C++'s RAII is magic-sauce that does a lot for you when you can simply use `defer` in zig. A constructor is just a function call. A destructor is just a function call.
      • shakow 4mo ago
        And a function call is just a fancy JMP, still it's generally acknowledged to be better to have all the bookkeeping automated.
      • fooker 4mo ago
        How is defer not magic sauce?
        • zephen 4mo ago
          Whether you consider it magic is up to you, but, unlike a destructor in RAII, there is nothing automatic going on. If you don't explicitly invoke a destructor, you won't get a destructor. The fact that you can explicitly invoke the destructor to happen later is simply syntactic sugar, just like if/else/while, or any other control construct more powerful than a conditional jump instruction.
          • drysine 4mo ago
            > If you don't explicitly invoke a destructor, you won't get a destructor. When you explicitly invoke a "destructor", you do it on many code paths (and miss one or two) >The fact that you can explicitly invoke the destructor to happen later You don't specify where the `defer`-red "destructor" will be invoked.
            • zephen 4mo ago
  • baranul 4mo ago
    It is quite obvious that Zig is pre 1.0 with thousands of stranded unsolved issues (per their GitHub repo). A review of Zig hype gives the strong impression it was created by being relentlessly and suspiciously pushed on HN, beyond logic or its language rankings (per TIOBE or GitHub stats), so that many were under the illusion that the language was something more or other than what it really is. Zig is still under development and beta. Stability, crashes, and leaks should not be surprising, and even expected. To stick with a beta language, usually companies and developers are philosophically and/or financially aligned with the language. An example is JangaFX and Odin, where they not only have committed to using the language (despite being beta) in their products, but have directly hired GingerBill. Team Bun appears to have "alignment and relationship issues" with Zig, to the point they have decided to extensively explore their options. Now Bun is rewritten in Rust. They are seeing if Rust solves their requirements. As with any relationship, if one ignores or takes a partner for granted, don't be surprised if they want a divorce or jump to someone else.
    • smj-edison 4mo ago
      You might want to check their Codeberg then, because they've moved all their development over there...
      • baranul 4mo ago
        Zig very much could of moved all of their GitHub issues over to Codeberg, to be resolved, but chose not to do so. Thus left thousands of issues unsolved and stranded. This maneuver was arguably obfuscated by the anti-LLM stance and finger pointing at Microsoft, but nevertheless, many still have noticed. Zig, for a long time, had been falling behind and doing poorly on their open to close ratio for resolving issues. It should be embarrassing to leave so many issues open. Even if not accepting new GitHub issues, they have demonstrated an inability to resolve existing issues, except at an extremely slow pace. Considering there are just about no new issues on their GitHub repo, it is understandable if there are those that find the pace to close and amount of issues unacceptable or questionable, in addition to the clearly bad open to close ratio.
• inglor 4mo ago
  Rust is really fun to work with and the compiler is great, just make sure the rewrite takes compile times into account since larger projects often have to be organized in a way that makes compilation reasonably fast.
  • ignoramous 4mo ago
    how long does it take to compile? @jarredsumner: It's basically the same as in zig using our faster zig compiler. If we were using the upstream zig compiler, rust port would compile faster. https://x.com/jarredsumner/status/2053050239423312035 https://x.com/jarredsumner/status/2053050239423312035
    • jorams 4mo ago
      This is at least partially disingenuous. Zig is working on, and has already shipped for some situations, a faster compiler. Bun runs on an outdated version of Zig that doesn't include it.
  • deleted 4mo ago
    [deleted]
  • laurencerowe 4mo ago
    In my experience Bun in Zig compiles more slowly than Deno in Rust.
    • hiccuphippo 4mo ago
      Single compiles for sure. Where Zig is optimizing compilation is in the incremental compiler, which I've seen compile the compiler itself in an instant after a single line change. Of course, that kind of speed is probably not interesting to some people if the AI is writing tons of lines of code before they go to the compilation step.
      • laurencerowe 4mo ago
        I found making single line changes in Bun’s zig code led to very long compiles compared to doing the same in Rust code. It was a while ago though and maybe I was doing something wrong.
• lelanthran 4mo ago
  Peter Naur: Programming as Theory Building Bun: Hold my beer
• nhatcher 4mo ago
  That's a post I am eagerly waiting to read. Basically we are seeing now an "inverse Hofstadter's Law" where doing something with an LLM takes less time thanexpected even when you take into account this law. I am a Rust developper myself but I really love Zig and Bun. I am just overly curious of all this.
  • nextaccountic 4mo ago
    > Basically we are seeing now an "inverse Hofstadter's Law" where doing something with an LLM takes less time thanexpected even when you take into account this law. Even LLMs themselves can't accurately estimate this (though this may be out of distribution stuff)
    • yen223 4mo ago
      LLMs have no conception of time, unless you explicitly feed in timestamps to the context
      • 0x457 4mo ago
        It doesn't stop LLMs provide "this feature set will require 4 months to finish" (and then finishing it one hour)
        • yen223 4mo ago
          Sorry yeah, I meant to say LLMs have no concept of time, so time estimates they give are almost always hallucinations
        • bw86 4mo ago
          Scotty from Star Trek does approve!
• gobdovan 4mo ago
  If this experiment ends up resulting in a real migration path, I think that would be completely awesome. Maybe it means we have a chance to revive older projects such as ngspice [0], but with modern affordances and better safety properties. From your post, though, it sounds like Bun may have been a pretty direct rewrite, without too many hard choices along the way. Is that fair? [0] https://ngspice.sourceforge.io/ https://ngspice.sourceforge.io/
  • bsder 4mo ago
    [flagged]
    • eqvinox 4mo ago
      +1, a project presenting at FOSDEM certainly does not need a "revive".
      • etimberg 4mo ago
        The spice core that ngspice is built off is terrible code. It has a long history going back to 1970s era fortran. Starting fresh is probably preferable
        • eqvinox 4mo ago
          That's not a revive though, revive (at least to me) implies it's dead.
        • bsder 4mo ago
          > The spice core that ngspice is built off is terrible code. It has a long history going back to 1970s era fortran. Starting fresh is probably preferable That code is also hyper-optimized for performance. I sincerely doubt you are going to match the performance easily with any random rewrite. Now, if you had a very clear idea of why the code was making assumptions from the 1990s that are no longer valid, then you might stand a chance of producing something that would outperform it. Or, perhaps, if you had particular knowledge of modern high-performance numerical libraries that you could apply to the problem, then you might be able to beat it. However, circuit simulation is remarkably difficult to get right (stiff systems with multiple time constants are not uncommon) and generally resistant to parallelization (each device can have its own model which are a unique set of linear differential equations). If, however, the legacy of ngspice bugs you that much, go look at Xyce and see if that is more to your taste.
• Eufrat 4mo ago
  I think given the current mood of things, it would be prudent to not make such strong assertions on anything. Trust is in increasingly short supply these days.
  • minimaxir 4mo ago
    Nothing Jarred said is an assertion other than "There’ll be a blog post with more details."
    • dakj12iH 4mo ago
      "I didn’t expect it to work this quickly and I also didn’t expect the performance to be as competitive." These are two assertions. There could have been a prior secret rewrite that took much longer than six days and this is a marketing stunt for Anthropic. In case people still don't get it, Jarred works for Anthropic and Bun belongs to Anthropic.
      • preommr 4mo ago
        Those are not assertions of anything meaningful. We have no idea what his expectations were. Maybe he expected it to be absolute crap, and it was only kind of crap. None of it means that it's actually viable. My fat uncle trying to beat Bolt's time could exceed my expectations by improving from 30s to 20s, doesn't mean it's ever going to be a reality. > In case people still don't get it, Jarred works for Anthropic and Bun belongs to Anthropic. In case people still don't get it, Jarred works for Anthropic and Bun belongs to Antrhopic. This means that people that have an ax to grind against anthropic (admittedly a reasonable position), will take the most antagonistic position they possibly can because of personal bias.
        • thrwaway55 4mo ago
          I disagree. This is the same sort of marketing strategy as Mythos.Wow it out performed so much we have to tell you in the future. If he wasn't aligned financially with the outcome I'd agree but he's not
• deleted 4mo ago
  [deleted]
• Aeolun 4mo ago
  This does not surprise me in the least. Several Claudes are very good at splitting up and working through them all.
• cpeterso 4mo ago
  What coding model are you using for the rewrite? Opus for everything? A prerelease model like Mythos?
• folderquestion 4mo ago
  Just an aside, is there any way to know how many of those 16,000 compiler errors are independent. I mean, could it be that just by changing say 500 lines of code all those errors disappear? Perhaps 16,000 could just measure cascade breakage, for example one lifetime mismatch can cause errors in every function that tries to use that reference. Rust reference lifetime bookkeeping is a difficult task for LLMs. The LLM has to maintain, across multiple functions and structs, which references outlive which. Furthermore compiler messages are highly contextual and lifetime patterns are sparse in the training set.
• sheepscreek 4mo ago
  UPDATE: This would make for an excellent case study if you don’t mind sharing the details. I am very curious about the number of agents, hours it took, and models used (did you use Mythos?). This would not have been possible 5 years ago. LLMs are going to push us into the space age. Both Anthropic and OpenAI have committed to spending 10s of billions of dollars on training alone for the year. I am equally excited and terrified at the pace of progress!