Article did a decent job of showing discipline and care and human involvement to assert the automated rewrite was done diligently, as best as it can be when using AI for it. I does make me feel a bit more comfortable about it.

As an aside, I don't know why anyone would not want to use a memory-safe (and possibly race-safe) language in 2026. Rust gives you that in a performant package, so if you are turned off by GCs and immutability for performance reasons, you still have the option to use Rust.

I can understand when you need the absolute best performance and you decide to drop to down to C++, and I also relate with just personal preference, but beyond those it seems a no brainer to me.

▲

leecommamichael 4 hours ago | parent | next [-]

> As an aside, I don't know why anyone would not want to use a memory-safe (and possibly race-safe) language in 2026.

The rust compiler is very slow. The best way to speed it up appears to be organizing a codebase in many crates. This is not preferable ergonomics to many. Beside that, for many problems, a garbage collector eliminates a large amount of defects (including the ones stated in the article) without any added friction, whereas Rust asks that you think in terms of ownership. This is not preferable ergonomics to many.

I realize what I'm saying above, while true, doesn't give a clear example. Many gamedevs would rather iterate with a language that is lower friction, not only because game code is finnicky (like frontend UI code) but because the build process can be unique. Many gamedevs prefer to iterate with hot-reloading, and asking them to use a slower compiler is asking them to accept greater latency in that cycle.

I do not claim that these reasons apply to everyone.

▲

zamalek 4 hours ago | parent | next [-]

Game engines are typically in two languages, one for the engine itself and one for scripting. That even goes for Unity: in Unity, C# is a significantly more powerful than average scripting language (for lack of a better term), but the engine itself is still C++.

That's not to say that you couldn't write a commercial game engine with something like C# that stands shoulder-to-shoulder with unity and unreal, but it doesn't seem like anyone has attempted to do so. Maybe it's the decompilation fear.

Also, it would continue to make sense to use a scripting language alongside Rust.

▲

atrevbot 3 hours ago | parent [-]

As someone who has almost no familiarity with game engines, it seems the success of this port was largely possible due to a comprehensive test suite written in a runtime agnostic way. What might be the equivalent test suite implementation required to successfully port a game engine to another language?

	▲	zamalek 2 hours ago \| parent \| next [-]
		One option would be to have an input replay alongside captured outputs (audio visual), at some fixed framerate. Capturing intermediates (scene graph etc.) would probably also be valuable, as that could help nail down why something is failing. Or you could do it [as I recall the project being called] the scientist way. You still have the old code, so you could replay inputs against each and compare. Probably more realistic because uncompressed video would be a ridiculously huge dataset. This would be more resilient in the face of testing hardware and driver drift. Historically game engines are the worst offenders when it comes to unit testing. I'm not sure if that's still the case - but that's why I erred on the side of integration tests.
	▲	jamesfinlayson 2 hours ago \| parent \| prev [-]
		Gosh, I don't think any game engines have particularly good test suites at all. GoldSource and Source are the only ones that I have any real experience with and neither seems to have anything (Source may have a handful of things but nothing approaching baseline let alone comprehensive). I have no idea how game devs handle big refactors other than lots of manual testing.

▲

gpm 4 hours ago | parent | prev | next [-]

The comment you're replying to wasn't arguing rust > GCed languages (e.g. C# or whatever game dev language you are thinking of). It was arguing rust > non-GC non-safe languages (e.g. zig).

	▲	leecommamichael 4 hours ago \| parent [-]
		I see that now, thanks. There's a lot to say here, especially with other approaches to memory management. My overall goal was to give them some context that wasn't their own.

▲

kibwen 4 hours ago | parent | prev [-]

> The best way to speed it up appears to be organizing a codebase in many crates.

A "crate" in Rust is the unit of compilation. In C, a file is the unit of compilation. Rust just lets you have a compilation unit that's composed of more than one file (without having to resort to C-style textual inclusion). But if you want, you can certainly have one-file-per-crate, just like you would in C. And what's nice about having many crates is that crates forbid circular dependencies, which trivially enables coarse-grained parallelism in the build system. So yes, organizing a large codebase into crates is the best way to achieve parallelism, but that isn't something to be deplored (and strictly controlling circular dependencies is useful for comprehending large codebases in general).

▲

rvrb 3 hours ago | parent | prev | next [-]

that you understand and think dropping down to C++ is what you need to do when you "need the best performance" is quite enough of a tell to invalidate the rest of your opinion here. if you "need the best performance", you need to ditch OOP and RAII, and you're probably reaching for C. Zig wants to be the better choice there. that's a perfectly reasonable niche for a language to exist in.

if you read the article carefully, jarred is pretty clear about how their specific requirements with Bun cause friction when bridging the manual memory management of Zig with a garbage collected JS runtime. at face value, that makes quite a lot of sense to me, and it's a pretty specific scenario that is not the full on condemnation of memory unsafe languages that your comment is.

▲

gmadsen an hour ago | parent | next [-]

It is widely accepted that you can get better performance with c++ far easier than C. Outside of custom rolling assembly , a large aspect of performance tuning is compile time optimization, which is extremely non trivial in C, while being supported in language with C++. All the things people associate with C performance can be done in C++, the converse is not true

▲

remexre 3 hours ago | parent | prev [-]

the point of c++ when you need max perf is to be able to maintain the compile-time abstractions you need w/ templates instead of macros and undocumented optimizer behavior, not oop or raii

▲

rvrb 3 hours ago | parent [-]

you're right that that is a weak argument against C++ in that use case (biased by my own dislike of the language); but it is also a niche that Zig fits into quite well. so it's weird for the OP to claim it's ok to drop down to C++ when needed while kind of suggesting they don't get why anyone would use Zig

	▲	galangalalgol an hour ago \| parent [-]
		If you are willing to hand code intrinsics it doesn't really matter what language you pick from a performance perspective. Rust consistently shows it has better performance than c++ in code that does not hand code intrinsics. If cpu(not gpu) based performance is all you care about there is no reason to pick anything but rust. Modern c++ devs have no trouble with the borrow checker either they are already doing all the things that keep it from complaining. The reasons someone might not pick rust involve integration with existing code, the complexity of the language, and the depth of it's dependency trees. The complexity argument certainly doesn't lean you towards c++ or probably anything with an llvm back end. The openbsd approach to c is probably as simple as you can get these days short of forth or something equally obscure. Dependency trees are deceptive. We all have deeper trees than we think we do, but the rust front end itself has well over 100 crates in its tree... All that said, I use rust for everything.

▲

josephg an hour ago | parent | prev | next [-]

> I can understand when you need the absolute best performance and you decide to drop to down to C++

Rust is just as fast as C++.

▲

frizlab 3 hours ago | parent | prev | next [-]

My personal memory and concurrent-safe option is Swift. And I agree, choosing a non-memory safe language for a new project is close to irresponsible today…

▲

Gigachad 2 hours ago | parent | prev | next [-]

I've observed that dumber models are able to vibecode in safe languages a lot easier since the compiler errors can self correct the models hallucinations, while they end up marking a task as complete in dynamic languages despite it not actually working.

If I'm vibe coding something I'm always just going to do it in Rust.

▲

henry_bone 3 hours ago | parent | prev | next [-]

I'll bite. The first language I could "just write" in was C. I had internalised the language and its standard lib and didn't need the internet to work with it.

Rust is pushed by many as the replacement to C, because of the memory safety guarantees. I'm sympathetic. I worked with Haskell for a time, so I get it. But Rust seems quite complex. There are so many language features that there's memes about it. There's also the friction and learning curve.

So, for fun, I choose zig because, like C, I can hold most of the language in my head and "just write." I choose zig because it does a great deal to help me write correct and highly performant code. I can use arena allocators and defer and cure my code of many memory issues. Then there's the various language rules around pointers (optionals, slices, etc) that help me write correct code. There's the built in testing and the test allocator. I love that comptime and the build system are not special cases, but rather are just garden variety zig. I love the simplicity and elegance of it all.

I also choose zig because I prefer the liberty it affords me. I am responsible for each and every allocation. It appeals to my libertarian sensiblities.

	▲	kibwen 3 hours ago \| parent [-]
		> There are so many language features that there's memes about it. Like many memes, these are misleading. Rust is a solidly medium-sized language; smaller than Python, certainly, though with a perilously steeper learning curve than Python.

▲

sitzkrieg 2 hours ago | parent | prev [-]

rust is still a non starter in some niche embedded applications (way too big). i still write c and assembly constantly.

▲

steveklabnik 2 hours ago | parent [-]

> way too big

https://github.com/tormol/tiny-rust-executable

This produces a 137 byte binary. Obviously AMD64 isn't used in embedded, but I've seen ARM ones that are in the ~256 range.

It's all in how you use it. Of course, if you don't care about binary sizes, they can get large, but that's very different than actually paying attention to what you're doing.

	▲	an hour ago \| parent [-]
		[deleted]