8 ms·

How Our Rust-to-Zig Rewrite Is Going

531 points by jorangreef 2mo ago

overgard 2mo ago
Compile times are a really underrated thing. My #1 gripe with C++ is waiting 10 minutes on a build, it absolutely kills flow.
- AlienRobot 2mo ago
  I currently have a problem with Rust that I use Rust-Analyzer for syntax and autocomplete in VS Code and it has to run the compiler when you save a file to "refresh" things. As you may imagine, this is insanely slow. So slow that when I switch from a .rs file to a .ts file I feel like I switched computers.
- jolt42 2mo ago
  My realization first time with Eclipse/Java.
coffeeindex 2mo ago
Didn’t know Roc was still being worked on. I think it’s an interesting concept for a language that I personally haven’t seen elsewhere
- sarchertech 2mo ago
  What made you think it was no longer being worked on?
- denismenace 2mo ago
  What concepts do you find interesting, compared to other FP languages?
onlyrealcuzzo 2mo ago
Zig's incremental builds are DEFINITELY a killer feature. In the short term, I could see why you'd make a switch to get it. But, in the medium term, can we really not expect to see this in Rust in the somewhat near future? I want to go fast, but I don't want to go fast just to shoot my foot off. If only somehow we could get Rust's safety with all of Zig's features and Go's runtime without GC... That's what I'm working on building [=
- Hinrik 2mo ago
  Layperson here: what is special about Go's runtime, aside from the GC?
  - onlyrealcuzzo 2mo ago
    It's literally the most sophisticated scheduling engine in the world. In practice, Go can typically outperform Rust in throughput (using more memory), despite having a mountain of disadvantages against it in theory. That's how good the Go scheduler/runtime is.
    - jcgl 2mo ago
      This is the first I've heard anyone claim higher throughput for Go than Rust. Any articles you'd point to to learn more?
      - insanitybit 2mo ago
        I think one of the few performance benefits with a GC is that you can defer allocations. You can do that in Rust too though.
    - deleted 2mo ago
      [deleted]
    - Aurornis 2mo ago
      > n practice, Go can typically outperform Rust in throughput (using more memory), despite having a mountain of disadvantages against it in theory This is a huge claim that disagrees with both my real-world experience and everything I've seen from artificial comparisons. Every high performance Go system I've worked on has quickly reached the point where we're optimizing memory management and doing things that would have been explicit in a non-GC language like Rust anyway. The Go runtime is amazingly optimized, but it comes with overhead over doing the same work directly in a lower level language.
      - 2mo ago
KoleSeise1277 2mo ago
The 35ms incremental rebuild is the part that sold me. I'd be curious to see the same benchmark on ARM once -fincremental gets there.
- mlugg 2mo ago
  Zig team member here---obviously I can't say for sure yet, but I'm pretty confident the number will be basically identical. In the Zig compiler, incremental updates (rebuilds) have a small amount of overhead which is roughly proportional to the total size of the codebase (rather than just the amount of code which was changed). This comes from a) detecting which source files changed, and b) traversing a graph to figure out which declarations are referenced (necessary due to Zig's "lazy analysis" feature). But performance analysis reveals that for small updates, this overhead actually dominates the update time, by a lot. Of the 35ms, I would guess that under 5ms are actually spent rebuilding the function(s) that changed. Of that 5ms, code generation---the only thing which would really be different on AArch64---is an even smaller slice of the pie (it often doesn't even impact the overall time, since it runs in parallel with other parts of the pipeline, and those other parts are usually the bottleneck there). So even if the AArch64 backend was significantly slower (which, right now, is the opposite of what we expect---instruction selection and encoding for x86_64 is unusually complicated!), I wouldn't expect the number to change from 35ms.
throwaway613746 2mo ago
[dead]
steveklabnik 2mo ago
I think this is a fine post. But one comment: > remember that for compilers which emit machine code, like roc and rustc, doing memory-unsafe things is a big part of the job I don't really think that this is true, in the way that it's written. I think that for the hot binary patching / code reloading features, yes, that is going to need unsafe. But for regular old "producing an executable" compilation? Emitting machine code isn't the part that requires unsafe. The language's runtime is a more likely site to find unsafe.
- paulddraper 2mo ago
  Agreed, that’s disturbingly incorrect. If anything, compilers are perfect models of trees and well formed programs.
  - benj111 2mo ago
    Maybe in theory. In practise you have thing like super optimisers. You have side effects that the compiler needs to understand etc. That said I'm struggling to think of something that would need to be unsafe.
- Aurornis 2mo ago
  That line confused me, too. What parts of their compiler require memory-unsafe operations to produce machine code?
  - skybrian 2mo ago
    They are saying that running the compiled code is memory-unsafe when there is a compiler bug, and that’s what developers do next. The memory corruption happens in a different process. In this respect, effectively all the compiler should be treated sort of like an unsafe region because it requires extra care to avoid memory corruption bugs.
    - Aurornis 2mo ago
      That's not what it says at all. The section we're talking about is for the compiler and emitting machine code > we ended up with about 1,200 uses of unsafe > remember that for compilers which emit machine code, like roc and rustc, doing memory-unsafe things is a big part of the job Anywhere talking about the `unsafe` keyword is within the Rust code.
landr0id 2mo ago
>ReleaseSafe catches use-after-free errors through runtime checks which panic if the program tries to use freed memory. I don't know Zig so maybe they know something I don't, but I have seen no evidence that it catches any type of use-after-free including double-free? While writing a blog post (below) I went through the documentation to figure out the possible runtime memory safety checks Zig can insert. The term "use-after-free" or "UaF" never occurs on that documentation page. Searching for "safety-checked" doesn't yield any related hits either. Unless maybe they're using the DebugAllocator in release builds? Even that does not reliably surface UaF. https://landaire.net/memory-safety-by-default-is-non-negotiable/ https://landaire.net/memory-safety-by-default-is-non-negotia...
- veber-alex 2mo ago
  I believe you are correct. I think ReleaseSafe just adds bound checking and panics on unreachable code. I don't think Zig offers any temporal memory safety.
  - flohofwoe 2mo ago
    The DebugAllocator catches use-after-free (at least on page-level), but at the cost of never recycling memory addresses (e.g. it eats through the virtual address space). https://ziglang.org/documentation/master/std/#src/std/heap/debug_allocator.zig https://ziglang.org/documentation/master/std/#src/std/heap/d... For higher level code, "generation-counted index handles" might be the better solution to provide temporal runtime memory safety, not part of Zig the stdlib though. Or even better: never use dynamic memory allocation and make all lifetimes 'static' :)
    - landr0id 2mo ago
      >The DebugAllocator catches use-after-free (at least on page-level) To clarify, is that to say that you have to use the `std.heap.page_allocator` as its backing allocator?
      - deleted 2mo ago
nntlol 2mo ago
[dead]
arthurbrown 2mo ago
Interesting that OCaml was flexible and expressive enough to be used as a prototype testbed but not chosen as the implementation language, especially given the maturity of both. I would be surprised if Zigs incremental builds could be meaningfully faster than dune's. Cross compilation is great, but not mentioned in the "why Zig" section. Is memory control that crucial for a compiler? Rust itself was originally written in OCaml, same with WASM. I'm curious about what milestone gets reached where the maintainers collectively decide to transition away.
- steveklabnik 2mo ago
  Rust moved away from OCaml when it decided to be re-written in Rust. The post alludes to this as being a usual time for a wholesale re-write, and I'd agree.
  - arthurbrown 2mo ago
    I appreciate the insight, and on closer reading the post clearly states that realistically only Zig and Rust were ever considered anyway. Since you're here, could you comment on the approach Rust took in their rewrite? Was it more of a straight translation like Go did when they self hosted -- similar to the recent Bun transliteration? Or were there architectural changes made along the way like this article describes with Roc?
    - steveklabnik 2mo ago
      The Rust re-write happened before I got involved. If pcwalton is around and sees this comment, maybe he can provide a more first-class account. > Was it more of a straight translation like Go did when they self hosted -- similar to the recent Bun transliteration? Or were there architectural changes made along the way like this article describes with Roc? From what I remember, it was a whole-sale re-write from scratch, not a transliteration. While Rust took a lot of inspiration from OCaml, especially in those days, it was different enough that I'm not sure that a more direct transliteration would have been particularly possible, though again, see above, I wasn't there, so I don't know for sure.
up2isomorphism 2mo ago
I think there will be soon a wave of rewriting rust to language X coming up.
- echelon 2mo ago
  The other way around. Rust is also one of the best languages to use with AI.
  - skhameneh 2mo ago
    I like Rust and I'm an advocate of Rust, but this really isn't true (at least it hasn't been and I doubt much has significantly changed). The syntax complexity and the ecosystem haven't been ideal for LLM development. And there have been publications on findings of LLM efficacy with different languages. Rust is most often towards the lower end of efficiency/correctness when benchmarked. https://arxiv.org/html/2508.09101v1 https://arxiv.org/html/2508.09101v1
    - steveklabnik 2mo ago
      This paper uses models that are over a year old at this point. Many people didn't believe that LLMs were worth using for programming until 6 months after that, and now again this week we've had another huge leap in abilities. This is beyond the other issues with the methodology of this study. For example, their Rust code was created by asking Deepseek to port their C++ code, not having it try and write Rust itself.
      - pjmlp 2mo ago
        From what I am seeing in big corp, with low code/no code tooling, coupled with agentic orchestration, for many scenarios the actual programming language will become irrelevant. Sure the programming platform still needs to be programming in something, but everything else on top will migrate to such tools. This might not come to all corners of programming, but in the domain of orchestrating SaaS products, with MCP tools replacing classical microservices, it is getting there already in 2026.
dev_l1x_be 2mo ago
Zig is a pre-1.0 language while Rust is post-1.0. This alone is settles which one to pick for may developers. The library support is probably favours Rust too. Rust build times are much slower than Zig, I get that, but I rarely optimize software for build times.
- drdexebtjl 2mo ago
  Zig is not pre-1.0 because it’s not ready for production (bugs or missing features), it’s pre-1.0 because they want to be able to make breaking language changes. Nowadays when you can just point an agent at release notes and have it update everything, I actually prefer not having to wait through rare major releases to get new language features.
  - afdbcreid 2mo ago
    > Nowadays when you can just point an agent at release notes and have it update everything Except that means that not only you lose compiler bugfixes, you also pretty much has no access to the ecosystem. For most production codebases, this is a deal breaker.
  - rwz 2mo ago
    > they want to be able to make breaking language changes That sounds like it's not ready for production to me.
    - drdexebtjl 2mo ago
      I invite you to read the release notes and see for yourself the types of breaking changes we’re talking about. To me it is not much different from Lua, which despite being on 5.x for decades, makes breaking changes on minor releases (because it predates SemVer). I also don’t see it being much different from any other language or language runtime that has a major release every year. It’s fine to update at your own pace.
      - uaksom 2mo ago
satyambnsal 2mo ago
is this uno reverse for bun post of zig to rust port ?
giancarlostoro 2mo ago
One thing I wish Rust would improve over time is the builds. Its one of the biggest sources of wasted storage space on all my computers, builds a ton of libraries can take tens of gigs, it adds up very quickly. Not sure what the best solution is, one I found is to set the global build folder so dependencies get reused across projects, but imho it should be an OOTB default behavior whatever the real solution should be.
- c-hendricks 2mo ago
  I always got a kick out of that, coming from a JavaScript background where people constantly harp on the size of node modules. My Tauri project, where the backend is much smaller code-wise than the frontend, has 9gb of rust artifacts (node_modules is 550mb for comparison)
  - tredre3 2mo ago
    Rust isn't great, and it shouldn't be a surprised since it's designed after npm. However one metric where nodes_modules is still worse for me is the sheer number of small files in it. Having nearly one million files in nodes_modules isn't that unusual. The problem is that on most common file systems the minimum allocation is usually at least 4KB. So even if the actual data is less than 500MB, you end up with 4GB disk space used/wasted.
    - inigyou 2mo ago
      I wish ext4 had a feature to mark a file as "atomic" where it would allocate all atomic files in a long run, without room for expansion, and I suppose with very inefficient compaction upon deletion, but without any padding bytes.
      - giancarlostoro 2mo ago
        A file “pointer” for byte exact files, pointer gets ditched for files that get updated or the pointer gets adjusted to another common file.
jdw64 2mo ago
[dead]
pjmlp 2mo ago
Quite interesting the hand waving of security issues with Zig, oh well. If I want to use allocator debuggers I already have the production ready tools that exist for C and C++ for at least 30 years.
- afdbcreid 2mo ago
  Compilers are not security sensitive, usually. And while UB could theoretically poison the generated code, this isn't a bigger risk than logic bugs.
  - pjmlp 2mo ago
    Of course they are, anything can be a gateway to inject backdoors, if security is not taken into account. And as mentioned, if what Zig offers is already in Purify, there is hardly any added value over C and C++, without the headaches of a niche language.
    - afdbcreid 2mo ago
      Considering that you often run the code after you compile it, it might not matter. Anyway, like it or not, most compilers don't consider themselves security sensitive and will not consider malicious code that is able to hijack the compiler a security vulnerability.
      - pjmlp 2mo ago
        Ken Thompson won the award for nothing, yeah.
        afdbcreid 2mo ago
        Totally unrelated; The trusting trust attack was about downloading a malicious compiler because malicious code was injected into it in some early version. (And if you ask me, it was indeed overrated, but that's unrelated).
royal__ 2mo ago
I don't even know what Zig is but I've seen this topic come up so many times on this site that I'm starting to think the people who are actually doing this are unsure themselves whether it's a good idea or not.
- pjmlp 2mo ago
  Basically the security model of Modula-2 or Object Pascal, with a curly brackets syntax, and compile time execution. Some folks embrace it as some kind of novelty.
- uaksom 2mo ago
  It does seem like they're trying to convince themselves. If you like Zig, that's a good enough reason to use it. Why waste time on language tribalism? I have the same issue with "use the right tool" rhetoric. The right tool is the one that does the job and that you know best.
dminik 2mo ago
While I'm a rust enthusiast, I do agree that certain languages lend themselves well to particular domains. So a rewrite from Rust to something better suited is fine by me. In fact, while I do work on a rust project, I would not have and still would not recommend it as the choice for that particular project. That being said, I had to do some double takes while reading this. > https://rtfeldman.com/rust-to-zig#memory-safety-post-rewrite https://rtfeldman.com/rust-to-zig#memory-safety-post-rewrite I feel that it's a bit weird to compare a rather well tested 7 (?) year old rust implementation with a brand new not yet released less than a year old Zig implementation. Without that context, this looks like a bad comparison for rust, when it is in fact the complete opposite. > https://rtfeldman.com/rust-to-zig#build-times https://rtfeldman.com/rust-to-zig#build-times The swiftness of the Zig compilere here is insane, and would would very much shift my recommendation of Rust if it got to similar speeds. That being said, I do find it funny that currently, the compilation speed is actually worse on Zig than Rust, despite Zig (anonymous commenters at least tbf) claiming the opposite for years. How did you eventually discover the 35 ms figure for Roc? Did you have to temporarily update the codebase to 0.17? > https://rtfeldman.com/rust-to-zig#memory-control-zero-parse-deserialization https://rtfeldman.com/rust-to-zig#memory-control-zero-parse-... Nothing negative here. I did play around with implementing a scripting language in this DOD-ish, index-based paradigm and yeah, it is neat. I was thinking that it might be possible to do resumable computation across the network like this (in the context of frontend frameworks "resuming" UIs), but ultimately I have no use for this so just the experience itself was enough. One note here is that it does tend to break completely if non-pointer-free data is introduced. It seems like it's either all or nothing. > https://rtfeldman.com/rust-to-zig#ecosystem-relevance https://rtfeldman.com/rust-to-zig#ecosystem-relevance This is more of an LLVM thing, which is fair, but I find it funny that "LLVM unstable bad" while "Zig unstable whatever". Overall though, this was an interesting read. And if the folks contributing to roc like zig then more power to them. Last thing, the link here is broken (points to a TODO): > Zig's compiler itself is another
- andriy_koval 2mo ago
  > In fact, while I do work on a rust project, I would not have and still would not recommend it as the choice for that particular project. wondering what type of project is that? I think besides some very embedded projects with very little memory where you need C/assembly, rust is good enough for all kind of projects..
maybebug 2mo ago
Nitpicking ahead: I am not sure, but there might be a bug in their pattern matching example. What happens if 'verb' is "GET" and 'path' is "/users/1234/posts/1234/extra_path/and/more/"? Will 'post_id' become "extra_path/and/more/"? I tried running it in the sandbox, and it does indeed seem to buggily result in: "Post ID: 1234/extra_path/and/more" I suspect that the reason it is behaving like it is, is due to how it handles characters in the string literal. The example program exploits that only the slashes present in the string literal pattern are matched, to enable matching on 'page' having slashes. But then in the nested 'match', it forgot to account for any possible extra slashes. Nitpicking end. I have not read the whole post yet, but the pattern matching not requiring any allocations, seems very nice. The string literal patterns also seem interesting, though I am not completely sold on them, also as per the above possible bug. It seems really clean in some ways, but the specific semantics, I am not fully sure about. Maybe it is excellent, and is so clean and concise that it is overall less bug-prone than alternatives in other programming languages. I do not know.
stymaar 2mo ago
Irrespective to the technical merits of both language, moving from a stable language to a pre-1.0 one that just lost his most popular open source project is a wild move.
- estebank 2mo ago
  > that just lost his most popular open source project As they state in the article, they started the migration a year and a half ago, something that happened a few weeks back would never come into the decision making process.
norir 2mo ago
This piece would have been a lot more compelling if they had actually done science on selecting a language for compiler development. From what I can tell, they had an untested hypothesis that a low level systems language is necessary for a high performance compiler https://www.roc-lang.org/faq#self-hosted-compiler https://www.roc-lang.org/faq#self-hosted-compiler and from that concluded that their only choice besides rust was zig. I know from experience that this initial assumption is wrong. Compiler performance is dominated by algorithms. The fastes managed languages tend to be at worst within a factor of two for wall time on any given algorithm. Algorithmic differences can be unbounded in their performance gaps. Zig itself is a perfect counterexample to the theory that writing a compiler in a low level systems language will lead to a fast compiler. Roc seems to compile at around 15k lines per second. That is not fast. There were evidently compilers written in ml that did 3k likes per second in 1998 https://flint.cs.yale.edu/cs421/case-for-ml.html https://flint.cs.yale.edu/cs421/case-for-ml.html The zig rewrite of roc looks like the author's second compiler. Compiler and language design is a skill like any other and from my vantage point, they appear to have overcommitted to an initial design at the expense of developing their higher level design skills. In my opinion, the best thing they could do for the future of roc is stop working on their current compiler and use it to write a self hosting compiler for a much smaller subset of roc. They should be able to do that in less than 10k lines of code. They might even find that their self hosting compiler is faster than their zig based bootstrap compiler for the self hosted subset of roc. If the self hosting compiler is inadequate. Now they at least have identified a smaller useful subset of roc and can experiment with different compiler implementations in 10k likes of code rather than 300k lines of code. Then they could actually test the theory of whether or not a low level language is necessary to meet whatever arbitrary compiler performance goals they have. By self hosting, they would also discover what roc features actually matter and they would spend much more time actually writing roc code. The features that are needed to write a self hosted compiler are all features that are generally useful. By improving the self hosted compiler, they also improve downstream programs.
- munificent 2mo ago
  Your comment is very assertive, but also doesn't offer much in the way of science. Being able to compile ML quickly in the 90s tells you little about being able to compile Roc or some other language today because the language design enforces hard constraints on the algorithms necessary to compile it and the hardware today is much more complex. It's not hard to write a fast Pascal compiler that targets a 1980s chip with shallow pipelines. But that's not the problem being solved here. I don't know much about Roc but it looks like it's got some amount of overloading and the linked article alludes to sophisticated algorithms to avoid heap allocating closures. Those can enforce algorithmic complexity in the compiler that is essential and can't be eliminated. Once you're at the limits of algorithmic optimization, all that's left is reducing constant factors. I've written code in many languages in different performance regimes over the years and it's certainly the case that higher level languages, especially managed memory ones, put a hard floor in terms of how low you can go when optimizing to improve those constant factors. I have seen in real-world code where explicit control over memory layout improved performance by more than an order of magnitude. I have friends in the game industry where much of their career is this kind of work. Those people would love to live in the luxurious world you describe where all they need to do is find a sufficiently clever algorithm and all of their performance problems will disappear.
christkv 2mo ago
Can anybody explain to me why anthropic bought bun in the first place ?
- steveklabnik 2mo ago
  Claude Code uses bun.
  - christkv 2mo ago
    Yeah I get they use it but I don't understand why you would buy it. it's just the runtime for code that makes up the agent.
    - steveklabnik 2mo ago
      Bun was a startup. Startups can go out of business, and then you are now scrambling to move your code to something else. They could also be bought by someone who has different priorities regarding future development than you, and that's also a risk. The simplest solution to these problems, if you have the capital, is to buy them.
      - christkv 2mo ago
        I get that but there is always node.js
        steveklabnik 2mo ago
        They aren't exactly the same thing, moving to node would be possible but bun does more than node, so you need to replace the whole thing.
        christkv 2mo ago
        Oh for sure. I guess its just as much a Acqui-hire as well as for the tech.
rienbdj 2mo ago
Seems like Rust unsafe could be improved without changing the language design.
dbacar 2mo ago
why not rewrite in ROC?? Would be much more cooler. I think precious cognitive time should be spent more on the language itself rather than wasting it on rewrites.
- steveklabnik 2mo ago
  The article links to https://www.roc-lang.org/faq#self-hosted-compiler https://www.roc-lang.org/faq#self-hosted-compiler to discuss this.
g42gregory 2mo ago
Does this mean every time you find yourself using lots of “unsafe” Rust blocks, it’s not the right tool for the job? I suspect it’s not that simple, but what are people’s experience?
- steveklabnik 2mo ago
  It really depends. For example, it might mean that you do not know the way to do the same thing, but in a safe manner. It might mean that you could refactor your code to do things more safely. Of course, reasonable people may also believe that it is easier to use an unsafe language directly rather than change the ways that you code. In my experience doing embedded, operating systems work, compiler work, and others, you never need a large amount of unsafe code. 1%/4% is really about it.
  - g42gregory 2mo ago
    Makes sense. Thanks!
baerbelblue 2mo ago
[dead]
bbkane 2mo ago
Tangentially relates, but if any Roc devs are around I'm curious about the use cases for Roc. It's supposed to be a scripting language right you embed into your C ABI right? Do you see it competing with WASM for the plugin use case (i.e. a really large Roc platform)? Why would an app author prefer to expose a Roc layer to their app rather than a WASM layer? With a WASM layer, plugin devs can write in any language. Another use case I've heard from it is as a more app-level language (i.e. a really small Roc platform). Do you see it competing with Gleam for server side http code? Do you see it competing with Elm for client side code?
- SoftTalker 2mo ago
  Same question. I always like learning about languages I had not heard of, especially functional languages, so I was immediately curious what sorts of applications this might have. But after looking over the roc-lang.org website and the FAQ, I still don't know.
- grayrest 2mo ago
  > If any Roc devs are around I'm curious about the use cases for Roc. It's a general functional programming language that's interested in the constraints and state control properties but not really in the dogma/traditions. As a specific example, it has a for loop statement that doesn't return anything just because sometimes the algorithm is easier to express imperatively. That said, it really is functional, mutating functions/methods require a `!` suffix and `->` (pure) vs `=>` (not) is distinguished in the type system and enforced. The language is fully decidable so type annotations are optional with the arguable exception of the built-in Serde which needs a concrete type to encode/decode. It's also pretty fast, like in the Go range. I think it has the best error handling of any language in the ~3 dozen I've tried. It's Rust style in general with `Result` renamed to `Try` but the error side of `Try` is an open tag set and can just aggregate so you get the nice parts of the Rust error experience without the downsides. As an example, a coeffect (effectful input) from an example on my server platform: book! = |req| { body : { id : I64 } body = Req.json_body!(req)? rows = Sql.query!(req.ctx, db_path, "SELECT id, title, author, year FROM books WHERE id = ?", [Integer(body.id)])? row = Sql.first(rows) ? |_| NotFound("book ${body.id.to_str()} not found") book = decode_book(row)? Ok(book) } The full set of errors covers malformed utf8, missing/wrong type for id, db errors, the custom NotFound with message, and missing/changed db columns and these plus all the other errors across the app get rolled up and handled in one spot by the error mapping function which rolls the input errors to 400, a 404 for the NotFound, 500s in general in a big match. I have more compact ways to express this in the platform (sqlx) but those don't show off the error handling as nicely. All in all, it's pretty much just a nice hosted language for doing things. > Do you see it competing with WASM for the plugin use case? It's mostly competing with Lua and friends but the host is a platform and not an embedder so the Roc goes on the outside and produces the binary. Roc is particularly well suited for compiling to wasm because all the effects coming from the host is shared. This is actually one of my primary interests in Roc but I haven't really harassed the Roc team about it because they've been busy with the rewrite and wasm module specs have been WIP. > Why would an app author prefer to expose a Roc layer to their app rather than a WASM layer? No need for the relatively large WASM runtime would be one of the first ones but Roc isn't really designed to be embedded. I expect to mainly use Roc for app level code on top of Rust for systems level code. I could write app-level Rust but I like functional programming, GC (refcount) is convenient, the error handling is nice, no annotations are nice, super fast compiles are nice, etc. > Do you see it competing with Gleam for server side http code? Do you see it competing with Elm for client side code? Sure. As mentioned, I'm experimenting with a server platform that uses pure handlers plus an effect system. I have a RealWorld implementation and in casual benchmarking on my M1 laptop I get 69k req/s for the article endpoint (serialization bound) and 10k going through the article_list endpoint (sqlite bound, 4 table join). The framework also has full and automatic cache invalidation so if I turn on caching I hit 120-140k req/s on both endpoints with no other code changes. As for GUI stuff, I'm working on a platform (Clay+Solid2) but I don't see any particular reason it wouldn't work.
Fervicus 2mo ago
Roc seems interesting. But for some reason I find it very grating to have the type definition on a separate line. Very much prefer F# syntax for that.
kotberg 2mo ago
[dead]
deleted 2mo ago
[deleted]
deleted 2mo ago
[deleted]
dzonga 2mo ago
even though I don't use Zig - a few things make me excited. such as new games that are gonna come - written in Zig - since its more ergonomic than C. the other side is on the distributed software side of things - we have already seen it with TigerBeetle. on my own end - probably robotics side.
kyo5uke 2mo ago
[dead]
LAC-Tech 2mo ago
> I enjoy Rust, I've taught a course on it, and I happily use it daily for my work at Zed. Despite what Internet comments might have us believe, it's extremely normal for one language to be the best fit for one project, while a different language turns out to be the best fit for a different project. One size does not actually fit all! Amen. I like both Zig and Rust, and if I praise/criticise one of them, people act like I'm "switching", as if they were two exclusionary religions (though I think some people may indeed view them that way). The stuff on memory safety written in the article is well worth reading, because in a lot of programmer discourse it's talked of as if it's some binary, that Rust Is Memory Safe, and Zig Is Not Memory safe. That's simply not the case.
feelamee 2mo ago
> As discussed earlier, having full control over allocations and deallocations is what I want in our compiler's implementation. And in tests, I also appreciate the testing allocators detecting leaks—it can even detect leaks in compiled Roc code! Unfortunately, to get that benefit requires a lot of "init this, defer deinit" code in tests that has to be correct or else the test fails on a memory leak. None of that is necessary in Rust. I care more about the compiler's implementation being the way I want it than the tests looking nicer, but in a perfect world I could somehow have both. haha, just for fun... do you want a C++ in your perfect world :D?
arikrahman 2mo ago
Saw Zig in the headline and worried they were going the way of Bun. Turned out it was the opposite and made for a good read.
lowbloodsugar 2mo ago
> though (more on this later) and we ended up with about 1,200 uses of unsafe (out of our 300K lines of Rust code Vs >Rust code has a different source of memory-safety gaps: the unsafe sections that nearly every Rust program has somewhere in its dependencies. Unsafe Rust has all the memory unsafety risk of ReleaseFast Zig code, but none of the runtime checks to catch issues during development Well if ReleaseFast would work for you then just write that in rust. The unsafe keyword can be used to write a shitshow, or it can be used to write small pieces of functionality, such as ArcUnion, that are safe to use. I don’t agree that every application has to have any unsafe code. If you find yourself needing it, then you go build the abstraction you need in another crate, miri the fuck out of that, and then just consume it in your application. If you’re fine with the shitshow, then use zig, because that’ll improve rusts stats. If you think you’re in the magical “I know what I’m doing and I need the extra performance” then you probably don’t know what you’re doing. You’re young. Knock yourself out. I’ve written assembly language hackery for video games you wouldn’t believe. Would I use any of that for a language others are going to use? You’re not that smart. And if you are, someone else on your project isn’t. Just a matter of time.
deleted 2mo ago
[deleted]
xiaodai 2mo ago
Why? Zig is clearly not memory safe like Rust.
ycombarepedos 2mo ago
[flagged]
- pjmlp 2mo ago
  Not at all, my buddy, my original point stands. Do you think personal attacks affect me? Grow up, I have cut my scars in the bloody discussions from BBS and Usenet days, not the woke friendly discussions of modern Internet.
Havoc 2mo ago
Nice. I like this - adds a different perspective without adding drama
ksec 2mo ago
Just reading the HN comments I found most interesting is that Rust and Zig have future improvement that related to each other's strong point. Rust will be getting faster Build time in 2026 and 2027+. This post shows incremental build went from 10s to 3s in 18 months. And lots of improvement coming as well. While it may not be 35ms in Zig but it is not too far to imagine Rust could have 1s or even sub second incremental build in next 2-3 years. On the other hand Zig is getting more tooling for memory safety. Opening Access to IR and even other ( although non official ) side project to have borrow checking implemented. That is on top of the subject languages ROC, which for whatever reason really hit the "friendly" part for a functional language.

531 points by jorangreef 2mo ago

Compile times are a really underrated thing. My #1 gripe with C++ is waiting 10 minutes on a build, it absolutely kills flow.

AlienRobot 2mo ago
I currently have a problem with Rust that I use Rust-Analyzer for syntax and autocomplete in VS Code and it has to run the compiler when you save a file to "refresh" things. As you may imagine, this is insanely slow. So slow that when I switch from a .rs file to a .ts file I feel like I switched computers.
jolt42 2mo ago
My realization first time with Eclipse/Java.

coffeeindex 2mo ago

Didn’t know Roc was still being worked on. I think it’s an interesting concept for a language that I personally haven’t seen elsewhere

sarchertech 2mo ago
What made you think it was no longer being worked on?
denismenace 2mo ago
What concepts do you find interesting, compared to other FP languages?

onlyrealcuzzo 2mo ago

Zig's incremental builds are DEFINITELY a killer feature. In the short term, I could see why you'd make a switch to get it. But, in the medium term, can we really not expect to see this in Rust in the somewhat near future? I want to go fast, but I don't want to go fast just to shoot my foot off. If only somehow we could get Rust's safety with all of Zig's features and Go's runtime without GC... That's what I'm working on building [=

Hinrik 2mo ago
Layperson here: what is special about Go's runtime, aside from the GC?
- onlyrealcuzzo 2mo ago
  It's literally the most sophisticated scheduling engine in the world. In practice, Go can typically outperform Rust in throughput (using more memory), despite having a mountain of disadvantages against it in theory. That's how good the Go scheduler/runtime is.
  - jcgl 2mo ago
    This is the first I've heard anyone claim higher throughput for Go than Rust. Any articles you'd point to to learn more?
    - insanitybit 2mo ago
      I think one of the few performance benefits with a GC is that you can defer allocations. You can do that in Rust too though.
  - deleted 2mo ago
    [deleted]
  - Aurornis 2mo ago
    > n practice, Go can typically outperform Rust in throughput (using more memory), despite having a mountain of disadvantages against it in theory This is a huge claim that disagrees with both my real-world experience and everything I've seen from artificial comparisons. Every high performance Go system I've worked on has quickly reached the point where we're optimizing memory management and doing things that would have been explicit in a non-GC language like Rust anyway. The Go runtime is amazingly optimized, but it comes with overhead over doing the same work directly in a lower level language.
    - 2mo ago

KoleSeise1277 2mo ago

The 35ms incremental rebuild is the part that sold me. I'd be curious to see the same benchmark on ARM once -fincremental gets there.

mlugg 2mo ago
Zig team member here---obviously I can't say for sure yet, but I'm pretty confident the number will be basically identical. In the Zig compiler, incremental updates (rebuilds) have a small amount of overhead which is roughly proportional to the total size of the codebase (rather than just the amount of code which was changed). This comes from a) detecting which source files changed, and b) traversing a graph to figure out which declarations are referenced (necessary due to Zig's "lazy analysis" feature). But performance analysis reveals that for small updates, this overhead actually dominates the update time, by a lot. Of the 35ms, I would guess that under 5ms are actually spent rebuilding the function(s) that changed. Of that 5ms, code generation---the only thing which would really be different on AArch64---is an even smaller slice of the pie (it often doesn't even impact the overall time, since it runs in parallel with other parts of the pipeline, and those other parts are usually the bottleneck there). So even if the AArch64 backend was significantly slower (which, right now, is the opposite of what we expect---instruction selection and encoding for x86_64 is unusually complicated!), I wouldn't expect the number to change from 35ms.

throwaway613746 2mo ago

[dead]

steveklabnik 2mo ago

I think this is a fine post. But one comment: > remember that for compilers which emit machine code, like roc and rustc, doing memory-unsafe things is a big part of the job I don't really think that this is true, in the way that it's written. I think that for the hot binary patching / code reloading features, yes, that is going to need unsafe. But for regular old "producing an executable" compilation? Emitting machine code isn't the part that requires unsafe. The language's runtime is a more likely site to find unsafe.

paulddraper 2mo ago
Agreed, that’s disturbingly incorrect. If anything, compilers are perfect models of trees and well formed programs.
- benj111 2mo ago
  Maybe in theory. In practise you have thing like super optimisers. You have side effects that the compiler needs to understand etc. That said I'm struggling to think of something that would need to be unsafe.
Aurornis 2mo ago
That line confused me, too. What parts of their compiler require memory-unsafe operations to produce machine code?
- skybrian 2mo ago
  They are saying that running the compiled code is memory-unsafe when there is a compiler bug, and that’s what developers do next. The memory corruption happens in a different process. In this respect, effectively all the compiler should be treated sort of like an unsafe region because it requires extra care to avoid memory corruption bugs.
  - Aurornis 2mo ago
    That's not what it says at all. The section we're talking about is for the compiler and emitting machine code > we ended up with about 1,200 uses of unsafe > remember that for compilers which emit machine code, like roc and rustc, doing memory-unsafe things is a big part of the job Anywhere talking about the `unsafe` keyword is within the Rust code.

landr0id 2mo ago

>ReleaseSafe catches use-after-free errors through runtime checks which panic if the program tries to use freed memory. I don't know Zig so maybe they know something I don't, but I have seen no evidence that it catches any type of use-after-free including double-free? While writing a blog post (below) I went through the documentation to figure out the possible runtime memory safety checks Zig can insert. The term "use-after-free" or "UaF" never occurs on that documentation page. Searching for "safety-checked" doesn't yield any related hits either. Unless maybe they're using the DebugAllocator in release builds? Even that does not reliably surface UaF. https://landaire.net/memory-safety-by-default-is-non-negotiable/ https://landaire.net/memory-safety-by-default-is-non-negotia...

veber-alex 2mo ago
I believe you are correct. I think ReleaseSafe just adds bound checking and panics on unreachable code. I don't think Zig offers any temporal memory safety.
- flohofwoe 2mo ago
  The DebugAllocator catches use-after-free (at least on page-level), but at the cost of never recycling memory addresses (e.g. it eats through the virtual address space). https://ziglang.org/documentation/master/std/#src/std/heap/debug_allocator.zig https://ziglang.org/documentation/master/std/#src/std/heap/d... For higher level code, "generation-counted index handles" might be the better solution to provide temporal runtime memory safety, not part of Zig the stdlib though. Or even better: never use dynamic memory allocation and make all lifetimes 'static' :)
  - landr0id 2mo ago
    >The DebugAllocator catches use-after-free (at least on page-level) To clarify, is that to say that you have to use the `std.heap.page_allocator` as its backing allocator?
    - deleted 2mo ago

nntlol 2mo ago

[dead]

arthurbrown 2mo ago

Interesting that OCaml was flexible and expressive enough to be used as a prototype testbed but not chosen as the implementation language, especially given the maturity of both. I would be surprised if Zigs incremental builds could be meaningfully faster than dune's. Cross compilation is great, but not mentioned in the "why Zig" section. Is memory control that crucial for a compiler? Rust itself was originally written in OCaml, same with WASM. I'm curious about what milestone gets reached where the maintainers collectively decide to transition away.

steveklabnik 2mo ago
Rust moved away from OCaml when it decided to be re-written in Rust. The post alludes to this as being a usual time for a wholesale re-write, and I'd agree.
- arthurbrown 2mo ago
  I appreciate the insight, and on closer reading the post clearly states that realistically only Zig and Rust were ever considered anyway. Since you're here, could you comment on the approach Rust took in their rewrite? Was it more of a straight translation like Go did when they self hosted -- similar to the recent Bun transliteration? Or were there architectural changes made along the way like this article describes with Roc?
  - steveklabnik 2mo ago
    The Rust re-write happened before I got involved. If pcwalton is around and sees this comment, maybe he can provide a more first-class account. > Was it more of a straight translation like Go did when they self hosted -- similar to the recent Bun transliteration? Or were there architectural changes made along the way like this article describes with Roc? From what I remember, it was a whole-sale re-write from scratch, not a transliteration. While Rust took a lot of inspiration from OCaml, especially in those days, it was different enough that I'm not sure that a more direct transliteration would have been particularly possible, though again, see above, I wasn't there, so I don't know for sure.

up2isomorphism 2mo ago

I think there will be soon a wave of rewriting rust to language X coming up.

echelon 2mo ago
The other way around. Rust is also one of the best languages to use with AI.
- skhameneh 2mo ago
  I like Rust and I'm an advocate of Rust, but this really isn't true (at least it hasn't been and I doubt much has significantly changed). The syntax complexity and the ecosystem haven't been ideal for LLM development. And there have been publications on findings of LLM efficacy with different languages. Rust is most often towards the lower end of efficiency/correctness when benchmarked. https://arxiv.org/html/2508.09101v1 https://arxiv.org/html/2508.09101v1
  - steveklabnik 2mo ago
    This paper uses models that are over a year old at this point. Many people didn't believe that LLMs were worth using for programming until 6 months after that, and now again this week we've had another huge leap in abilities. This is beyond the other issues with the methodology of this study. For example, their Rust code was created by asking Deepseek to port their C++ code, not having it try and write Rust itself.
    - pjmlp 2mo ago
      From what I am seeing in big corp, with low code/no code tooling, coupled with agentic orchestration, for many scenarios the actual programming language will become irrelevant. Sure the programming platform still needs to be programming in something, but everything else on top will migrate to such tools. This might not come to all corners of programming, but in the domain of orchestrating SaaS products, with MCP tools replacing classical microservices, it is getting there already in 2026.

dev_l1x_be 2mo ago

Zig is a pre-1.0 language while Rust is post-1.0. This alone is settles which one to pick for may developers. The library support is probably favours Rust too. Rust build times are much slower than Zig, I get that, but I rarely optimize software for build times.

drdexebtjl 2mo ago
Zig is not pre-1.0 because it’s not ready for production (bugs or missing features), it’s pre-1.0 because they want to be able to make breaking language changes. Nowadays when you can just point an agent at release notes and have it update everything, I actually prefer not having to wait through rare major releases to get new language features.
- afdbcreid 2mo ago
  > Nowadays when you can just point an agent at release notes and have it update everything Except that means that not only you lose compiler bugfixes, you also pretty much has no access to the ecosystem. For most production codebases, this is a deal breaker.
- rwz 2mo ago
  > they want to be able to make breaking language changes That sounds like it's not ready for production to me.
  - drdexebtjl 2mo ago
    I invite you to read the release notes and see for yourself the types of breaking changes we’re talking about. To me it is not much different from Lua, which despite being on 5.x for decades, makes breaking changes on minor releases (because it predates SemVer). I also don’t see it being much different from any other language or language runtime that has a major release every year. It’s fine to update at your own pace.
    - uaksom 2mo ago

satyambnsal 2mo ago

is this uno reverse for bun post of zig to rust port ?

giancarlostoro 2mo ago

One thing I wish Rust would improve over time is the builds. Its one of the biggest sources of wasted storage space on all my computers, builds a ton of libraries can take tens of gigs, it adds up very quickly. Not sure what the best solution is, one I found is to set the global build folder so dependencies get reused across projects, but imho it should be an OOTB default behavior whatever the real solution should be.

c-hendricks 2mo ago
I always got a kick out of that, coming from a JavaScript background where people constantly harp on the size of node modules. My Tauri project, where the backend is much smaller code-wise than the frontend, has 9gb of rust artifacts (node_modules is 550mb for comparison)
- tredre3 2mo ago
  Rust isn't great, and it shouldn't be a surprised since it's designed after npm. However one metric where nodes_modules is still worse for me is the sheer number of small files in it. Having nearly one million files in nodes_modules isn't that unusual. The problem is that on most common file systems the minimum allocation is usually at least 4KB. So even if the actual data is less than 500MB, you end up with 4GB disk space used/wasted.
  - inigyou 2mo ago
    I wish ext4 had a feature to mark a file as "atomic" where it would allocate all atomic files in a long run, without room for expansion, and I suppose with very inefficient compaction upon deletion, but without any padding bytes.
    - giancarlostoro 2mo ago
      A file “pointer” for byte exact files, pointer gets ditched for files that get updated or the pointer gets adjusted to another common file.

jdw64 2mo ago

[dead]

pjmlp 2mo ago

Quite interesting the hand waving of security issues with Zig, oh well. If I want to use allocator debuggers I already have the production ready tools that exist for C and C++ for at least 30 years.

afdbcreid 2mo ago
Compilers are not security sensitive, usually. And while UB could theoretically poison the generated code, this isn't a bigger risk than logic bugs.
- pjmlp 2mo ago
  Of course they are, anything can be a gateway to inject backdoors, if security is not taken into account. And as mentioned, if what Zig offers is already in Purify, there is hardly any added value over C and C++, without the headaches of a niche language.
  - afdbcreid 2mo ago
    Considering that you often run the code after you compile it, it might not matter. Anyway, like it or not, most compilers don't consider themselves security sensitive and will not consider malicious code that is able to hijack the compiler a security vulnerability.
    - pjmlp 2mo ago
      Ken Thompson won the award for nothing, yeah.
      - afdbcreid 2mo ago
        Totally unrelated; The trusting trust attack was about downloading a malicious compiler because malicious code was injected into it in some early version. (And if you ask me, it was indeed overrated, but that's unrelated).

royal__ 2mo ago

I don't even know what Zig is but I've seen this topic come up so many times on this site that I'm starting to think the people who are actually doing this are unsure themselves whether it's a good idea or not.

pjmlp 2mo ago
Basically the security model of Modula-2 or Object Pascal, with a curly brackets syntax, and compile time execution. Some folks embrace it as some kind of novelty.
uaksom 2mo ago
It does seem like they're trying to convince themselves. If you like Zig, that's a good enough reason to use it. Why waste time on language tribalism? I have the same issue with "use the right tool" rhetoric. The right tool is the one that does the job and that you know best.

dminik 2mo ago

While I'm a rust enthusiast, I do agree that certain languages lend themselves well to particular domains. So a rewrite from Rust to something better suited is fine by me. In fact, while I do work on a rust project, I would not have and still would not recommend it as the choice for that particular project. That being said, I had to do some double takes while reading this. > https://rtfeldman.com/rust-to-zig#memory-safety-post-rewrite https://rtfeldman.com/rust-to-zig#memory-safety-post-rewrite I feel that it's a bit weird to compare a rather well tested 7 (?) year old rust implementation with a brand new not yet released less than a year old Zig implementation. Without that context, this looks like a bad comparison for rust, when it is in fact the complete opposite. > https://rtfeldman.com/rust-to-zig#build-times https://rtfeldman.com/rust-to-zig#build-times The swiftness of the Zig compilere here is insane, and would would very much shift my recommendation of Rust if it got to similar speeds. That being said, I do find it funny that currently, the compilation speed is actually worse on Zig than Rust, despite Zig (anonymous commenters at least tbf) claiming the opposite for years. How did you eventually discover the 35 ms figure for Roc? Did you have to temporarily update the codebase to 0.17? > https://rtfeldman.com/rust-to-zig#memory-control-zero-parse-deserialization https://rtfeldman.com/rust-to-zig#memory-control-zero-parse-... Nothing negative here. I did play around with implementing a scripting language in this DOD-ish, index-based paradigm and yeah, it is neat. I was thinking that it might be possible to do resumable computation across the network like this (in the context of frontend frameworks "resuming" UIs), but ultimately I have no use for this so just the experience itself was enough. One note here is that it does tend to break completely if non-pointer-free data is introduced. It seems like it's either all or nothing. > https://rtfeldman.com/rust-to-zig#ecosystem-relevance https://rtfeldman.com/rust-to-zig#ecosystem-relevance This is more of an LLVM thing, which is fair, but I find it funny that "LLVM unstable bad" while "Zig unstable whatever". Overall though, this was an interesting read. And if the folks contributing to roc like zig then more power to them. Last thing, the link here is broken (points to a TODO): > Zig's compiler itself is another

andriy_koval 2mo ago
> In fact, while I do work on a rust project, I would not have and still would not recommend it as the choice for that particular project. wondering what type of project is that? I think besides some very embedded projects with very little memory where you need C/assembly, rust is good enough for all kind of projects..

maybebug 2mo ago

Nitpicking ahead: I am not sure, but there might be a bug in their pattern matching example. What happens if 'verb' is "GET" and 'path' is "/users/1234/posts/1234/extra_path/and/more/"? Will 'post_id' become "extra_path/and/more/"? I tried running it in the sandbox, and it does indeed seem to buggily result in: "Post ID: 1234/extra_path/and/more" I suspect that the reason it is behaving like it is, is due to how it handles characters in the string literal. The example program exploits that only the slashes present in the string literal pattern are matched, to enable matching on 'page' having slashes. But then in the nested 'match', it forgot to account for any possible extra slashes. Nitpicking end. I have not read the whole post yet, but the pattern matching not requiring any allocations, seems very nice. The string literal patterns also seem interesting, though I am not completely sold on them, also as per the above possible bug. It seems really clean in some ways, but the specific semantics, I am not fully sure about. Maybe it is excellent, and is so clean and concise that it is overall less bug-prone than alternatives in other programming languages. I do not know.

stymaar 2mo ago

Irrespective to the technical merits of both language, moving from a stable language to a pre-1.0 one that just lost his most popular open source project is a wild move.

estebank 2mo ago
> that just lost his most popular open source project As they state in the article, they started the migration a year and a half ago, something that happened a few weeks back would never come into the decision making process.

norir 2mo ago

This piece would have been a lot more compelling if they had actually done science on selecting a language for compiler development. From what I can tell, they had an untested hypothesis that a low level systems language is necessary for a high performance compiler https://www.roc-lang.org/faq#self-hosted-compiler https://www.roc-lang.org/faq#self-hosted-compiler and from that concluded that their only choice besides rust was zig. I know from experience that this initial assumption is wrong. Compiler performance is dominated by algorithms. The fastes managed languages tend to be at worst within a factor of two for wall time on any given algorithm. Algorithmic differences can be unbounded in their performance gaps. Zig itself is a perfect counterexample to the theory that writing a compiler in a low level systems language will lead to a fast compiler. Roc seems to compile at around 15k lines per second. That is not fast. There were evidently compilers written in ml that did 3k likes per second in 1998 https://flint.cs.yale.edu/cs421/case-for-ml.html https://flint.cs.yale.edu/cs421/case-for-ml.html The zig rewrite of roc looks like the author's second compiler. Compiler and language design is a skill like any other and from my vantage point, they appear to have overcommitted to an initial design at the expense of developing their higher level design skills. In my opinion, the best thing they could do for the future of roc is stop working on their current compiler and use it to write a self hosting compiler for a much smaller subset of roc. They should be able to do that in less than 10k lines of code. They might even find that their self hosting compiler is faster than their zig based bootstrap compiler for the self hosted subset of roc. If the self hosting compiler is inadequate. Now they at least have identified a smaller useful subset of roc and can experiment with different compiler implementations in 10k likes of code rather than 300k lines of code. Then they could actually test the theory of whether or not a low level language is necessary to meet whatever arbitrary compiler performance goals they have. By self hosting, they would also discover what roc features actually matter and they would spend much more time actually writing roc code. The features that are needed to write a self hosted compiler are all features that are generally useful. By improving the self hosted compiler, they also improve downstream programs.

munificent 2mo ago
Your comment is very assertive, but also doesn't offer much in the way of science. Being able to compile ML quickly in the 90s tells you little about being able to compile Roc or some other language today because the language design enforces hard constraints on the algorithms necessary to compile it and the hardware today is much more complex. It's not hard to write a fast Pascal compiler that targets a 1980s chip with shallow pipelines. But that's not the problem being solved here. I don't know much about Roc but it looks like it's got some amount of overloading and the linked article alludes to sophisticated algorithms to avoid heap allocating closures. Those can enforce algorithmic complexity in the compiler that is essential and can't be eliminated. Once you're at the limits of algorithmic optimization, all that's left is reducing constant factors. I've written code in many languages in different performance regimes over the years and it's certainly the case that higher level languages, especially managed memory ones, put a hard floor in terms of how low you can go when optimizing to improve those constant factors. I have seen in real-world code where explicit control over memory layout improved performance by more than an order of magnitude. I have friends in the game industry where much of their career is this kind of work. Those people would love to live in the luxurious world you describe where all they need to do is find a sufficiently clever algorithm and all of their performance problems will disappear.

christkv 2mo ago

Can anybody explain to me why anthropic bought bun in the first place ?

steveklabnik 2mo ago
Claude Code uses bun.
- christkv 2mo ago
  Yeah I get they use it but I don't understand why you would buy it. it's just the runtime for code that makes up the agent.
  - steveklabnik 2mo ago
    Bun was a startup. Startups can go out of business, and then you are now scrambling to move your code to something else. They could also be bought by someone who has different priorities regarding future development than you, and that's also a risk. The simplest solution to these problems, if you have the capital, is to buy them.
    - christkv 2mo ago
      I get that but there is always node.js
      - steveklabnik 2mo ago
        They aren't exactly the same thing, moving to node would be possible but bun does more than node, so you need to replace the whole thing.
        christkv 2mo ago
        Oh for sure. I guess its just as much a Acqui-hire as well as for the tech.

rienbdj 2mo ago

Seems like Rust unsafe could be improved without changing the language design.

dbacar 2mo ago

why not rewrite in ROC?? Would be much more cooler. I think precious cognitive time should be spent more on the language itself rather than wasting it on rewrites.

steveklabnik 2mo ago
The article links to https://www.roc-lang.org/faq#self-hosted-compiler https://www.roc-lang.org/faq#self-hosted-compiler to discuss this.

g42gregory 2mo ago

Does this mean every time you find yourself using lots of “unsafe” Rust blocks, it’s not the right tool for the job? I suspect it’s not that simple, but what are people’s experience?

steveklabnik 2mo ago
It really depends. For example, it might mean that you do not know the way to do the same thing, but in a safe manner. It might mean that you could refactor your code to do things more safely. Of course, reasonable people may also believe that it is easier to use an unsafe language directly rather than change the ways that you code. In my experience doing embedded, operating systems work, compiler work, and others, you never need a large amount of unsafe code. 1%/4% is really about it.
- g42gregory 2mo ago
  Makes sense. Thanks!

baerbelblue 2mo ago

[dead]

bbkane 2mo ago

Tangentially relates, but if any Roc devs are around I'm curious about the use cases for Roc. It's supposed to be a scripting language right you embed into your C ABI right? Do you see it competing with WASM for the plugin use case (i.e. a really large Roc platform)? Why would an app author prefer to expose a Roc layer to their app rather than a WASM layer? With a WASM layer, plugin devs can write in any language. Another use case I've heard from it is as a more app-level language (i.e. a really small Roc platform). Do you see it competing with Gleam for server side http code? Do you see it competing with Elm for client side code?

SoftTalker 2mo ago
Same question. I always like learning about languages I had not heard of, especially functional languages, so I was immediately curious what sorts of applications this might have. But after looking over the roc-lang.org website and the FAQ, I still don't know.
grayrest 2mo ago
> If any Roc devs are around I'm curious about the use cases for Roc. It's a general functional programming language that's interested in the constraints and state control properties but not really in the dogma/traditions. As a specific example, it has a for loop statement that doesn't return anything just because sometimes the algorithm is easier to express imperatively. That said, it really is functional, mutating functions/methods require a `!` suffix and `->` (pure) vs `=>` (not) is distinguished in the type system and enforced. The language is fully decidable so type annotations are optional with the arguable exception of the built-in Serde which needs a concrete type to encode/decode. It's also pretty fast, like in the Go range. I think it has the best error handling of any language in the ~3 dozen I've tried. It's Rust style in general with `Result` renamed to `Try` but the error side of `Try` is an open tag set and can just aggregate so you get the nice parts of the Rust error experience without the downsides. As an example, a coeffect (effectful input) from an example on my server platform: book! = |req| { body : { id : I64 } body = Req.json_body!(req)? rows = Sql.query!(req.ctx, db_path, "SELECT id, title, author, year FROM books WHERE id = ?", [Integer(body.id)])? row = Sql.first(rows) ? |_| NotFound("book ${body.id.to_str()} not found") book = decode_book(row)? Ok(book) } The full set of errors covers malformed utf8, missing/wrong type for id, db errors, the custom NotFound with message, and missing/changed db columns and these plus all the other errors across the app get rolled up and handled in one spot by the error mapping function which rolls the input errors to 400, a 404 for the NotFound, 500s in general in a big match. I have more compact ways to express this in the platform (sqlx) but those don't show off the error handling as nicely. All in all, it's pretty much just a nice hosted language for doing things. > Do you see it competing with WASM for the plugin use case? It's mostly competing with Lua and friends but the host is a platform and not an embedder so the Roc goes on the outside and produces the binary. Roc is particularly well suited for compiling to wasm because all the effects coming from the host is shared. This is actually one of my primary interests in Roc but I haven't really harassed the Roc team about it because they've been busy with the rewrite and wasm module specs have been WIP. > Why would an app author prefer to expose a Roc layer to their app rather than a WASM layer? No need for the relatively large WASM runtime would be one of the first ones but Roc isn't really designed to be embedded. I expect to mainly use Roc for app level code on top of Rust for systems level code. I could write app-level Rust but I like functional programming, GC (refcount) is convenient, the error handling is nice, no annotations are nice, super fast compiles are nice, etc. > Do you see it competing with Gleam for server side http code? Do you see it competing with Elm for client side code? Sure. As mentioned, I'm experimenting with a server platform that uses pure handlers plus an effect system. I have a RealWorld implementation and in casual benchmarking on my M1 laptop I get 69k req/s for the article endpoint (serialization bound) and 10k going through the article_list endpoint (sqlite bound, 4 table join). The framework also has full and automatic cache invalidation so if I turn on caching I hit 120-140k req/s on both endpoints with no other code changes. As for GUI stuff, I'm working on a platform (Clay+Solid2) but I don't see any particular reason it wouldn't work.

Fervicus 2mo ago

Roc seems interesting. But for some reason I find it very grating to have the type definition on a separate line. Very much prefer F# syntax for that.

kotberg 2mo ago

[dead]

deleted 2mo ago

[deleted]

deleted 2mo ago

[deleted]

dzonga 2mo ago

even though I don't use Zig - a few things make me excited. such as new games that are gonna come - written in Zig - since its more ergonomic than C. the other side is on the distributed software side of things - we have already seen it with TigerBeetle. on my own end - probably robotics side.

kyo5uke 2mo ago

[dead]

LAC-Tech 2mo ago

> I enjoy Rust, I've taught a course on it, and I happily use it daily for my work at Zed. Despite what Internet comments might have us believe, it's extremely normal for one language to be the best fit for one project, while a different language turns out to be the best fit for a different project. One size does not actually fit all! Amen. I like both Zig and Rust, and if I praise/criticise one of them, people act like I'm "switching", as if they were two exclusionary religions (though I think some people may indeed view them that way). The stuff on memory safety written in the article is well worth reading, because in a lot of programmer discourse it's talked of as if it's some binary, that Rust Is Memory Safe, and Zig Is Not Memory safe. That's simply not the case.

feelamee 2mo ago

> As discussed earlier, having full control over allocations and deallocations is what I want in our compiler's implementation. And in tests, I also appreciate the testing allocators detecting leaks—it can even detect leaks in compiled Roc code! Unfortunately, to get that benefit requires a lot of "init this, defer deinit" code in tests that has to be correct or else the test fails on a memory leak. None of that is necessary in Rust. I care more about the compiler's implementation being the way I want it than the tests looking nicer, but in a perfect world I could somehow have both. haha, just for fun... do you want a C++ in your perfect world :D?

arikrahman 2mo ago

Saw Zig in the headline and worried they were going the way of Bun. Turned out it was the opposite and made for a good read.

lowbloodsugar 2mo ago

> though (more on this later) and we ended up with about 1,200 uses of unsafe (out of our 300K lines of Rust code Vs >Rust code has a different source of memory-safety gaps: the unsafe sections that nearly every Rust program has somewhere in its dependencies. Unsafe Rust has all the memory unsafety risk of ReleaseFast Zig code, but none of the runtime checks to catch issues during development Well if ReleaseFast would work for you then just write that in rust. The unsafe keyword can be used to write a shitshow, or it can be used to write small pieces of functionality, such as ArcUnion, that are safe to use. I don’t agree that every application has to have any unsafe code. If you find yourself needing it, then you go build the abstraction you need in another crate, miri the fuck out of that, and then just consume it in your application. If you’re fine with the shitshow, then use zig, because that’ll improve rusts stats. If you think you’re in the magical “I know what I’m doing and I need the extra performance” then you probably don’t know what you’re doing. You’re young. Knock yourself out. I’ve written assembly language hackery for video games you wouldn’t believe. Would I use any of that for a language others are going to use? You’re not that smart. And if you are, someone else on your project isn’t. Just a matter of time.

deleted 2mo ago

[deleted]

xiaodai 2mo ago

Why? Zig is clearly not memory safe like Rust.

ycombarepedos 2mo ago

[flagged]

pjmlp 2mo ago
Not at all, my buddy, my original point stands. Do you think personal attacks affect me? Grow up, I have cut my scars in the bloody discussions from BBS and Usenet days, not the woke friendly discussions of modern Internet.

Havoc 2mo ago

Nice. I like this - adds a different perspective without adding drama

ksec 2mo ago

Just reading the HN comments I found most interesting is that Rust and Zig have future improvement that related to each other's strong point. Rust will be getting faster Build time in 2026 and 2027+. This post shows incremental build went from 10s to 3s in 18 months. And lots of improvement coming as well. While it may not be 35ms in Zig but it is not too far to imagine Rust could have 1s or even sub second incremental build in next 2-3 years. On the other hand Zig is getting more tooling for memory safety. Opening Access to IR and even other ( although non official ) side project to have borrow checking implemented. That is on top of the subject languages ROC, which for whatever reason really hit the "friendly" part for a functional language.