What Zig felt like, coming from Rust

What Zig felt like, coming from Rust besok.github.io

What Zig felt like, coming from Rust Intro I’ve spent the last 7 years as a Rust developer, working mostly on open source projects, and I’d like to think I’ve built a solid feel for the language and its ecosystem along…

282 points•ksec•11 days ago•351 comments•

#like #rust #zig #felt #zig felt #felt like #zig felt like #intro

351 comments

drpython2 days ago

My prediction for 2027 is that the world will be powered by two kinds of languages: low-level language(s) that implement the deterministic compute layer (i.e., tools) for agents, and high-level language(s) that implement agents and orchestration. Based on my observations, the strongest choice for each tier is Rust and TypeScript. You may also count Golang and Python.

In 2027, other languages will become increasingly irrelevant.

torginus11 days ago

Personally while I'm somewhat pragmatic about Rust, I do have to admit it fills a niche that no other language does currently: that of a high-performance, zero runtime memory-safe language.

By memory-safety I mean the basic 'no crashes and corruption' version, that's fulfilled by Java, Go etc., but not by C++ and Zig.

I'm a C++ dev among other things, and I have enough experience to know, you really can't hand C++ to a novice dev (even one who uses smart pointers correctly), and expect an app with no memory related crashes/issues.

For this reason only, I generally thing C/C++/Zig is a language for typical professional projects/applications (which are written usually in GC languages nowadays).

I think it's a hard cutoff criteria. Most programmers/orgs simply cannot work with memory unsafe software. Most commerical C++ codebases leak.

This is basically the most important and common 'niche' of SW dev, which for some reason has been somewhat neglected, and I don't really consider Rust a great fit here either, but it doesn't lack anything that would disqualify it.

Swift would be another good choice, but it seems that language is very tied to the Apple ecosystem.

The only (non-Apple) language that understood EXACTLY what these people wanted imo was Object Pascal/Delphi in the 90s to early 2000s but seem to have died out unfortunately.

andsoitis11 days ago

> Personally while I'm somewhat pragmatic about Rust, I do have to admit it fills a niche that no other language does currently: that of a high-performance, zero runtime memory-safe language.

Ada/SPARK comes close: memory safety is very strong, formally provable. Has no GC. Excellent performance. Very mature.

tgv10 days ago

SPARK is quite hard, harder than Rust, I would say (based on limited experience, though), and Ada isn't that memory safe, IIRC. They are, however, much more readable than Rust.

zumtrotz9 days ago

Ada does not get enough love.

strideashort9 days ago

I started my career with turbo pascal, then Delphi… great language, great tooling. Tbh everything since then felt like a huge step back, especially for UI.

smallmouth8 days ago

Absolutely my feeling as well. I'll never understand why more activity and innovation didn't coalesce around object pascal...save for FreePascal and Lazarus which are terrific.

hn_submit10 days ago

Swift is basically C++ with shared_ptr (i.e. using reference counting for smart pointers). You need to be aware of its limitations just as you would with shared_ptr.

MBCook10 days ago

Swift is not heavily tied to the Apple ecosystem anymore, and it’s getting better every year.

However that perception tends to mean it’s only heavily used there.

bigyabai10 days ago

Foundation and SwiftUI definitely are, which makes porting Swift applications very difficult.

Syzygies11 days ago

For various purposes I work on a language comparison project that includes C and candidate successors such as Go, Zig. One question is the language to use for an archival port of a 1980's computer algebra system written in 32-bit K&R C. While Zig is a great debugging compiler, it's not yet stable enough to be the best target language for archival purposes.

https://github.com/Syzygies/Compare

So you're in a restaurant where you don't speak the language, you can't read the menu, but you see three price points for set meals featuring the house specialty. (Say, "Crossing the Bridge" noodles in Yunnan.) Which do you choose? My tour guide, the author Fuchsia Dunlop, later agreed with me this is obvious: The middle choice.

So you're choosing between Go and C23 as candidate successors to K&R C. They both have "royal blood". One got the name. Knowing nothing more, which do you choose?

The answer is equally obvious. The one that got the name also got the warts.

pjmlp11 days ago

Despite my usual rants, naturally C23.

Minimal rewrite due to the breaking changes introduced in C23 versus K&R C, while the others are a complete rewrite.

Even if the syntax is a bit of a kludge there are now ways to indicate bounds on function arguments.

dharmatech11 days ago

You mention there that you like Ruby and that you wanted Ruby with types (and that you looked at Crystal).

I've been messing around with a language that I summarize as:

ALOE = Scheme + Smalltalk + Types

https://github.com/dharmatech/2026-09-02-aloe-racket

One of the examples is a very basic computer algebra simplifier:

https://github.com/dharmatech/2026-09-02-aloe-racket/blob/ma...

That simplifier is based on a computer algebra library in Scheme:

https://github.com/dharmatech/mpl

ksec11 days ago

>https://github.com/Syzygies/Compare

You might want to take a look at Odin as well.

d0mine11 days ago

Middle may be wrong (it is a marketing trick to add 3rd outragesly expensive option, to make 2nd option look reasonable). The correct answer is “it depends” (even how long you should spend on choosing may depend on context too).

For example, write in whatever language you know best, then translate to a more appropriate language using LLMs once the desired behavior can be checked automatically. It is a tactic that works in some cases.

kelipso11 days ago

It can be used as a marketing trick, possibly because of the logic in GP post. Marketing people use this to trick people, which is different from it being a marketing trick in and of itself.

Shorel11 days ago

No D-lang? It seems quite incomplete without it.

weinzierl11 days ago

Two additional points:

1. Tooling (as an extension to the mentioned IDE support point). Zig and Rust are both praised for their tooling and I think rightfully so. The C/C++ interop story and the cross-compiling story in Zig are great. From the standpoint of a working practitioner though I think Rust is way ahead. Not surprising given that Zig is much younger, but something to keep in mind.

2. Compile Time Stuff: Here Zig is praised and Rust not so much. I think this is undeserved. Rust has much higher aspirations for their compile time features, namely that outcome must be identical regardless when the code runs. This is a very useful property but makes the task much harder and fundamentally incomparable with Zig comptime.

LoganDark11 days ago

Zig comptime feels easier and more effective in practice. I've had some fun const evaluating some stuff in Rust, but I needed to use a bunch of annoying imperative hacks because so much of the functional stuff wasn't supported in const context back then. It's probably a bit better these days.

For one of my crates I needed to have a build script make a bunch of lookup tables as separate files for me to `include_bytes!` because at the time I couldn't generate a bunch of floating point conversions in const.

tialaramex11 days ago

Certainly every new Rust release tends to have either new things which were stabilized as const on day one, or things which already existed but now have stable const.

The biggest constraint today on Rust's constant evaluation compared to where you'd expect is that trait implementations can't ever be constant, this obviously means you can't call SomeTrait::function in your constant, even if you can see the implementation of SomeTrait::function and if it were not a trait it'd obviously be constant -- but it also means sugar like Rust's for loop, which de-sugars into trait invocations, can never be constant today.

I think we can expect that to get fixed in the relatively near future, but I'd have said that last year too so what do I know.

If you have C++ experience you'd probably want a lot more. C++ is allowed to allocate inside constant evaluation, and I believe in C++ 26 it's now even allowed to persist the allocation to runtime rather than being required to always clean up during compilation, so that's a much bigger set of crazy things you can do at compile time.

vlovich12311 days ago

There’s a few comptime crates out there. Crabtime is iirc the most mature and popular

chaz7211 days ago

Are you saying that you think that Zig does not produce identical outcomes for comptime code regardless of when the code runs? What do you mean?

weinzierl11 days ago

Yes. For example in Rust it took a long time for floating point operations to be available at compile time and even now only a subset is. The reason is that a lot of energy and thought went into the issue of producing identical output (and what identical precisely means ) even when compilation is on a different processor than where the target runs.

As far as I know this is not a concern for Zig comptime.

bruckie11 days ago

I assumed that it meant that if you ran code at compile time or at runtime, the results should be exactly the same given the same inputs.

csense11 days ago

One of the section headings says "Mutation vs. immutable monad is the core difference" but this is not true.

The code in that section is clear in its purpose and broad outline: "Give me a function and data; if the data is bare apply the function to it; if the data is a container apply the function to each item inside it."

You can absolutely do that with immutable data structures in Zig. You just have to pass an allocator to the function (i.e. instead of calling data.flat_map(f), you call data.flat_map(a, f) where a is your allocator).

That the Zig version of the code does mutation is a matter of programmer choice, not something imposed by the language.

(Also, what do monads have to do with it?)

bunderbunder11 days ago

Further up he discusses that using a functional paradigm is possible, but concludes that it doesn’t feel like a practical choice because of how Zig does memory management:

> But the language quickly forces you to diverge from the functional style, mostly because you’re now dealing with allocators directly, and a genuinely pure functional approach means constantly constructing new structures. That’s either expensive in memory or expensive in the manual bookkeeping needed to avoid it.

So I don’t think he’s trying to say that it’s literally impossible. It felt more like the result of a good faith attempt to understand how Zig itself actually wants to be used, and to compare that to how he’s used to using Rust.

I actually liked that he did it. So many other comparisons want to evaluate one language against the other language’s values. But I don’t want to know how well Zig can do Rust; I want to know how well Zig accomplishes its own goals, and what those goals are.

tialaramex11 days ago

So, what you're not seeing is that even though the Rust doesn't announce mutation the implementation may be mutation anyway if that's probably faster/ cheaper.

    unsafe impl<I, U, F> InPlaceIterable for FlatMap<I, U, F> where
    I: InPlaceIterable,
    U: BoundedSize + IntoIterator,

What you're seeing is the graceful goose on the water moving forward at pace. Beneath there is frantic action to make that happen. The Rust surface was more a maintainable immutable operations, but the implementation is a frantic whirling mutation like the Zig.

In Zig you end up spending a lot of time writing How to do a thing, where in Rust you only wrote What the thing is and the machine did it. There are edge cases where Zig's explicitness wins for the best programmers, but there just aren't enough of those cases or those programmers for this to net out IMNSHO.

slopinthebag11 days ago

yes people don't understand that there is often a runtime performance cost to explictness as well

kccqzy11 days ago

Monads are where flat_map came from. A monadic programming style is where flat_map is used pervasively eschewing other APIs.

Read the full thread on Hacker News →

351 comments

Related stories