How do you know it was built irresponsibly without reading the code, which is something you should be doing when adopting a dependency anyway?

Looks like pretty nice dx. Will keep an eye out

I'm using it locally, with models my existing computer can handle. I think, but I'm not sure, that it's better for the environment than buying into some massive model hosted in a data centre. And I don't want to lose my skills so I still try to do as much as I can without calling on it.

Not everyone uses big data center powered LLM inference though. Running some models locally uses less power than playing a video game.

you got me at "responsibly" burning resources.

localhost(2026-07-19|14:57:51) ~/rust$ rustup update stable
info: syncing channel updates for stable-x86_64-unknown-linux-gnu
info: latest update on 2026-07-16 for version 1.97.1 (8bab26f4f 2026-07-14)
info: removing previous version of component cargo
info: removing previous version of component clippy
info: removing previous version of component rust-docs
info: removing previous version of component rust-std
info: removing previous version of component rustc
info: removing previous version of component rustfmt
info: downloading 6 components
        cargo installed                       10.63 MiB
       clippy installed                        4.71 MiB
    rust-docs installed                       22.73 MiB
     rust-std installed                       28.71 MiB
        rustc installed                       77.30 MiB
      rustfmt installed                        2.06 MiB                                                                                                      
  stable-x86_64-unknown-linux-gnu updated - rustc 1.97.1 (8bab26f4f 2026-07-14) (from rustc 1.96.0 (ac68faa20 2026-05-25))

info: checking for self-update (current version: 1.29.0)
localhost(2026-07-19|15:01:20) ~/rust$

I think that it should do backups first and remove only in the end. Or do parallel installs.

translates to assembly code with a very predictable pattern.

the portable assembly meme

🤣🤣🤣🤣🤣🤣🤣

Don't worry, you might make it to the start of the bell curve one day.

Well I guess not everyone learns at the same rate.

I've been programming for 35 years, and professionally for over 20, so I'm pretty far along the curve, thanks.

Yes. It's not as easy and reliable as Zig.

There are definitely some cases where memory safety isn't especially important:

• Single player games
• Apps that don't process external data (e.g. a simple calculator).
• Lots of things running on microcontrollers, where the form of input could never possibly cause any security issues. E.g. a motor controller or a basic syringe pump or a (non-smart) washing machine or something.
• Tests, e.g. I've considered writing RISC-V tests in Zig. They're traditionally written in C or assembly.

In cases like those, memory unsafety mainly leads to non-security bugs and annoying debugging sessions. But I wouldn't say it's as much of a deal breaker compared to e.g. writing a video codec or font renderer or web browser or DNS server or whatever.

I still think Rust is a better choice than Zig in most cases anyway, even ignoring memory safety. But in these cases it's at least a defensible choice.

C won’t surprise you...

Lol... I'm sure there's a meme or graph for where you are in learning C to believe this.

then translates to assembly code with a very predictable pattern.

Even this is a stretch. Modern C compilers can do some wild transformations. I assume you've seen the classic one where UB makes it jump to a function that you never actually call.

bash scripting is well-defined

Yeah I mean Bash's problem isn't that it's poorly defined - it's that the definition is awful!

These days we have to expect many projects will have them. It's really a question of how responsibly and carefully AI is used. Some people just throw in their requirements, have the AI spit out code, do a cursory check to see if it seems to work, and that's it. Other people take responsibility for the architecture and the code quality, using AI in a focused way and reviewing the results carefully. I'd look at the quality of the architecture and code before judging. I confess I have not done that yet with this one; I just thought it sounded potentially interesting.

There are quite a few ways to write web applications with Rust these days, and while this sounds like it has potential, I'd still pick frameworks that are a little more mature for my own projects.

⚠TRIGGER WARNING⚠ two tokio-rs repos (this and toasty) have AGENTS.md files.

exposed ABI

ABI is not something that gets "exposed" or not.

it will always be ambiguous as implementations are hard to compare across languages

Correct.

in the transition for x86_64 they were seeing up to 70% increase in compile speeds

And that was a part of what I was hinting at, because you get >>70% speed-up with Cranelift in most Rust projects. But in either case, faster code generation is not free lunch, hence the mention of comparable runtime performance of generated binaries.

I'm not sure what you're talking about then, in zigs case you don't need an exposed ABI to use existing c code?

in terms of performance it will always be ambiguous as implementations are hard to compare across languages, however they use llvm as an alternative to support architectures as they build out their native compiler. in the transition for x86_64 they were seeing up to 70% increase in compile speeds. its still ambiguous as its dependent on their implementation of llvm, though its such a large increase it is still meaningful.

but i say all this as a rust and zig advocate where i would happily choose either over the the majority of alternatives.

in c code you will see malloc, alloc, free w/e scattered through the code base, most static tools lack because they don't control the memory and just analyze address spaces or do static code analysis. they look top down and try to catch errors.

zig's design forces you to create a memory allocator before any object initializations (alloc/free) and is typically constructed at the top level and passed through to functions. this allows you to swap implementation easily and use the allocator to claim memory or return an error to the caller if it can't.

you can do some simple static allocator, general purpose allocator (can grow memory space as you allocate more objects) or in this case to test memory safety a debug allocator which you use in your tests. This moves the memory inspection inside of where your program allocates memory. this is more of an inside out approach where the analysis is produced by controlling the memory allocations and frees through a standard interface.

We all have different definitions of "fun." C won't surprise you when you try to add a string and an array; it'll do exactly what you told it to do, which then translates to assembly code with a very predictable pattern.

On a different note, bash scripting is well-defined and mostly consists of understanding that common tools can be chained together to provide useful output; combined with the very well-defined string operations, I've found that bash scripts can address over 99% of cases people try to throw sed and awk at. It's almost surprisingly powerful.

JavaScript is just a hot fucking mess.

working on a project where memory safety isn’t that important

I can't really imagine anything where this is not the case, unless you're doing like... I dunno, small scripts for personal use or something? But why would you use Zig or C or even Rust for that, just do Python or even bash at that point? Python is memory safe and perfectly suitable for very small programs where static analysis gives little benefit.

You know bindgen exists, right?

That has nothing to do with what we were talking about. And in any case:

insanely fast

Needs qualification vs. other languages for binaries with comparable runtime performance.

(Hint: you will be surprised.)

with incremental rebuilds

Not special or unique.

and can watch files for changes

Not only not special, but literally exists in all workable build tools. bindgen+build.rs is the Rust version of this.

C is firmly in the "not fun" camp with PHP, JavaScript and Bash. I'd say even assembly is more fun, in a puzzle challenge sort of way.

The most fun language I've used is QuakeC, because the only thing you can do with it is write Quake mods. It was a pretty neat language too from what I remember. It even automatically detected infinite loops!

Zig is way better than C in many other respects, so if you want a modern sane language and you're either a Rust luddite or working on a project where memory safety isn't that important, it might be attractive.

Like, if the choice is C or Zig, then Zig is pretty much a no-brainer (or it will be when it hits 1.0). It just fixes so many insane things about C that have been broken for literal decades.