4 ms·

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 usi

by didibus 3mo ago

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 3mo ago
> 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.
- gpm 3mo ago
  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 3mo ago
    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 3mo ago
  > 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).
  - comex 3mo ago
    The forbidding of circular dependencies is exactly what makes it hard to achieve parallelism! It means you have to draw nice clean module boundaries and split your compilation units there. Clean boundaries sound nice, except… what if the module is getting large? Can you just take half the module, ctrl-x, ctrl-v into a new file, and get faster compilation times without having to do any massive refactors? In C, usually yes. In C++, sometimes yes. It depends on how template-heavy the code is, but if you have some discipline you can keep most logic out of headers and thus easily splittable. In Rust, almost always no, because of circular dependencies. You can try to work around it by adding `dyn Trait` everywhere, but that requires a lot of code changes and comes at big ergonomic costs (and a small runtime cost). Which is why in practice, Rust compilation units are almost always larger than C++ or C compilation units. Rust can sometimes be competitive with C++ on compilation speed anyway, thanks to a smarter build system and not having to re-parse headers a billion times, but usually it's slower.
    - FridgeSeal 3mo ago
      > Can you just take half the module, ctrl-x, ctrl-v into a new file, and get faster compilation times without having to do any massive refactors?…In Rust, almost always no, because of circular dependencies This feels like a strange, overly-specific complaint. It reads a bit like “When I write entangled code, it’s hard to untangle”. Like, yeah, the only thing that’ll save you from that is…not writing entangled code? I’m not of the opinion that the argument of “yeah but C lets me do whacky stuff” is a particularly strong line. FWIW, letting a module grow, and then splitting modules up by cut-and-pasting stuff out along natural domain lines generally _is_ how I write Rust. Largely due to how easy it makes it to construct modules and submodules.
- zamalek 3mo ago
  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 3mo ago
    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 3mo ago
      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.
      - hdjrudni 3mo ago
        Box3D just showcased some stuff including deterministic replays. If you wanted to port that, you could probably import the replay and make sure it plays back the same way in your new language. I think it captures the inputs and forces applied, not the pixels. I suppose rendering is a component of a game engine too though, not just physics. I don't know how to do that reliably. Even if you captured pixels, it'd be annoying. If you've ever tried doing screenshot based diffing on web you will know that slight changes in aliasing in Chrome bugger everything up. Things that should be equivalent randomly aren't but not in a way that any human would care.
- vlovich123 3mo ago
  For what it’s worth game devs often use C# or C++ engines which have even worse issues. Rust also has the early beginnings of hot reload which bevy adopted if I recall correctly [1]. I still think a higher level language is good for “business” logic to orchestrate how efficient low-level pieces connect, but Rust is holding its own even against those use cases IMHO. [1] https://docs.rs/hot-lib-reloader/latest/hot_lib_reloader/ https://docs.rs/hot-lib-reloader/latest/hot_lib_reloader/
  - Rohansi 3mo ago
    > For what it’s worth game devs often use C# or C++ engines which have even worse issues. Such as? You can't be referring to hot reload alone because you can already do that in both C++ and C#.
    - vlovich123 3mo ago
      Well for c++ memory safety and sharp abstractions and even worse compile times than Rust. I’m not aware of hot reload really being done in c++ at any scale but I’m not a game dev so I’m open to learning. C# AFAIK holds a minor place in gamedev and also has slow compile times maybe? I assume it has better support for hot reload times. But generally the performance profile isn’t there for the most demanding games even if the DX is.
      - Rohansi 3mo ago
        It's not specific to game dev but Visual Studio has hot reload for C++ that you should be able to make use of. C# compile times are fast. Performance is a lot better than you probably think, especially with modern .NET (not what Unity uses).
        vlovich123 3mo ago
        Visual Studio limitations around hot reload are quite unrealistic for any serious codebase and only work on Windows with Visual Studio when you started it under a debugger. Rust’s hot reload is cross platform if I recall correctly and is always available until you disable it from the build (eg debug on, release off). It also has a better story for working around the limitations that Visual Studio just throws up on. C++ hot reload is not a common experience in the ecosystem.
- stymaar 3mo ago
  > The rust compiler is very slow. It's not “very slow”, that's a tired meme. It's slower than it could/should, but complaining about rustc being “very slow” is a clear misrepresentation, especially when everybody seems to have been fine with tsc's historical performance for instance. It could be nice if it was faster indeed, but people claiming it's “very slow” are just showing they never worked with it. > The best way to speed it up appears to be organizing a codebase in many crates. This is not preferable ergonomics to many. In this context (where you don't plan on publishing you stuff on crates.io) a “crate” are just a directory at the root of your repo, the ergonomic impact is literally zero.
  - minraws 3mo ago
    As much as I like Rust, > In this context (where you don't plan on publishing you stuff on crates.io) a “crate” are just a directory at the root of your repo, the ergonomic impact is literally zero. Is not true, you can't have circular out of crate dependencies. This often means you now need a third crate that's a trait crate, but then you can't implement external traits on external types, so you need bridge crates, and so on. Rust's limitation of performance requiring lots of crates indeed has real impacts on projects beyond simple hello worlds or trivial cli apps. Considering it to be a zero impact issue is rather reductive, even in the context of the language's design principles itself. Rust for all it's good sides has had a lack of interest from core team and energy to drive real valuable changes beyond the nightly blockers into stable, or maybe they are working real hard and the boulders are so hard to move that we can't see any change looking outside in. Is it justified after the gargantuan effort that was merging Async and GATs? Yes. But acknowledging the problem doesn't help us solve it. This is to say, Rust is an amazing labour of love project that seems rather stuck in time due to lack of investment/time/effort or all of the above, I am not sure, but it's moving slower than I would like, at solving the problems Rust developers face everyday. And yes Rust compiler is slow (very slow is arguable, compared to modern C++ it isn't that bad, but compared to say Go without cgo, its horrid), Cargo is just bad, without proper hermetic builds and stuff, even when I setup sccache for our team and our cache hit rate remained below 20% and most of it was just C++ deps hitting the cache. Just to be clear Zig builds are quite slow too, especially on windows where debug builds also use llvm. TBH Zig debug builds on Linux also don't really feel that fast, C still compiles faster for me by a considerable margin. Either way as someone doing Rust everyday for last 8+ years, 5+ in small/large teams, I have lots of complaints and I am sad, it has been over years of me complaining without nearly enough progress, they have a survey declare ambitions, and then well... things just don't move much.. not nearly as much as I would have expected. Honestly given I have been a rust dev for over half a decade now, I should instead of commenting here probably be figuring out if I can contribute to Rust to help things along (faster?). But most meetings and discussions happen at very EU/US centric times, and number of non US/European core contributors in Rust is also rather small(I don't know of one but I hope there are a few) so as someone not in those circles, I don't have the energy to figure out my way in, with my day job. Tldr; Is Rust the language for the job here, likely. But the question should be why couldn't have been the language Bun was written from the very start. Why does Zig or C++ or C seem so much more productive. Sorry for ranting about this but this felt a little relevant since you claimed people complaining, are likely people who have never worked with Rust.
- psychoslave 3mo ago
  Hey thanks for teaching me a word today, and to be finicky myself, the convention seems to be to use a single n it. :)
- IshKebab 3mo ago
  > The rust compiler is very slow. It was very slow. It's gotten a lot faster over time (over 2x faster). It's still not exactly fast, but it's definitely faster than C++. Although C++'s slow compile times are often complained about they were never really enough to stop most people using it, including for games. > a garbage collector eliminates a large amount of defects (including the ones stated in the article) without any added friction I'd be careful about that "without any added friction". Rust's lifetime/borrowing system tends to lead to less buggy code because it encourages structuring code in a less spaghetti way. GC does eliminate memory errors but you also lose that non-spaghetti code structure.
  - pjmlp 3mo ago
    Because contrary to Rust, C and C++ have a culture of binary libraries. You are seldom compiling the world from scratch. Especially in the platforms dear to game devs.
    - IshKebab 3mo ago
      > You are seldom compiling the world from scratch. True in Rust too though - you're normally doing incremental compiles. And even though you're compiling the world, it's still on par with C++. For example I just tried compiling a hello world Bevy project, which has 462 crate dependencies - pretty big. It took 2m20. Totally reasonable to build an entire game engine and all it's dependencies. I wish they had reported the compile time of Bun before/after the Rust port - that would have been very interesting.
      - pjmlp 3mo ago
        Yeah but compiling full Unreal from scratch already requires going down the path of forking it for own purposes. Same applies to most commercial libraries, where code is usually provided for debugging purposes, not for building everything from scratch. Also incremental linking on Rust, or hot code reloading is still not something that works out of the box. How beefy is that machine to achieve 2m20? I started using C++ on MS-DOS, on a 20 MHz 386SX PC with 2MB RAM and 20 MB HDD. Especially relevant in current times.
- thayne 3mo ago
  > Beside that, for many problems, a garbage collector eliminates a large amount of defects (including the ones stated in the article) Languages with garbage collection are generally considered "memory safe". GP was talking about choosing a language that requires manual memory management, but doesn't have something like rust's lifetimes to catch things like use-after-free.
henry_bone 3mo ago
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 3mo ago
  > 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.
  - flohofwoe 3mo ago
    Rust-the-language may be medium-sized. Rust-the-stdlib though? The Rust stdlib has a lot of essential low-level types needed for adding a 'semantic layer' on top of the language so that the language user can exactly 'express intent' (types that arguably should be language features instead). Just look at all those detailed methods needed to make RefCell work, and what does 'into_inner' or 'undo_leak' even mean? https://doc.rust-lang.org/std/cell/struct.RefCell.html https://doc.rust-lang.org/std/cell/struct.RefCell.html E.g. what's a single concept in C (e.g. "the pointer") easily has a dozen specialized equivalents in Rust, just because Rust needs the additional information to do its memory safety magic correctly. The entirety of Rust and its stdlib has a huge 'semantic surface' compared to most other languages (even C++), and I think this difference in the semantic surface size to other languages is exactly the one thing that either attracts or repels people to/from Rust ;)
frizlab 3mo ago
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…
- pjmlp 3mo ago
  Sometimes we have no option, given the industry standards that expect C or C++. Khronos, Open Group, NVidia, Microsoft, Sony, Nintendo... aren't going to change their APIs and SDKs, just because of social media discussions on the merits of C, C++ vs other safer alternatives. I agree we should minimise their use, however not everyone accepts a dual language approach, nor there are alternatives in such domains, even if they technically exist, you still need to overcome the human and political factors. Hence why it is so relevant to fix C and C++ security flaws to some extent as well.
  - frizlab 3mo ago
    Obviously my comment of irresponsibility was “given that there is a choice.” Though that’s one nice thing about Swift: it has a very good interop’ with C now, and a “starting to get pretty good” interop’ with C++. So that can help, sometimes. (Obviously, I reiterate, I understand there are situations where the choice is just not possible, and enhancing C and C++ is indeed a good thing.)
    - pjmlp 3mo ago
      The nice thing about Swift, or Java/Kotlin on Android, is the platform owner attitude, either adopt it, or go elsewhere, that is the only way safety improvements are pushed into mainstream.
rvrb 3mo ago
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.
- remexre 3mo ago
  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 3mo ago
    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 3mo ago
      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.
Gigachad 3mo ago
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.
- sneak 3mo ago
  Agree 100%. Almost everything I have written with AI is in Go, and strong typing is really really nice (as is go vet and golangci-lint to keep the generated code in line). I imagine writing plain js or python with it would be much much riskier.
  - ubercore 3mo ago
    Well annotated code is fine in Python too.
sitzkrieg 3mo ago
rust is still a non starter in some niche embedded applications (way too big). i still write c and assembly constantly.
- steveklabnik 3mo ago
  > way too big https://github.com/tormol/tiny-rust-executable 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.
  - deleted 3mo ago
    [deleted]
  - whytevuhuni 3mo ago
    I tried to use Rust for a tiny microcontroller (GD32VF103, 128KB flash). First of all, I was amazed by how much I could do with Rust (safe Rust, even), and how well it was interfacing with my handwritten RISC-V assembly. I will definitely use Rust again for the next such project. But, every time my functions would get over a certain size, suddenly some optimizations stopped working, and Rust was trying to put the whole panic/fmt machinery into the thing, going above my linker's flash size limit. It was insanely frustrating, since there was no rhyme or reason to it. Simply adding another branch to a match made it do that. Or another if statement that was exactly the same as the 4 before it. The 137 binary thing does not scale.
    - steveklabnik 3mo ago
      I don't disagree that I think that the Rust project could do more to make this kind of development easier, and it is true that it doesn't come for free. That doesn't change the point that if you want to, you can do it, it is not a fundamental language limitation.
      - 3mo ago
josephg 3mo ago
> 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++.
- m00dy 3mo ago
  yeap, unfortunately, only few can see this.
  - lostglass 3mo ago
    It's not though. It's fast enough for many applications but if you need to write a hypervisor then suddenly bounds checks and atomic pointers become significant. Not to mention that rust dramatically reduces your ability to control where memory is allocated. I write in rust and c++, rust isn't as fast. Rust is easier to work with and, compared to the Java crap it's replacing at my work, it's a lot better but it's certainly not zero cost abstractions the way c++ can be, nor is it great for data oriented design because you're hoping the compiler will do the right thing, consistently.
  - flohofwoe 3mo ago
    It depends a lot on the coding style. The sort of Rust code that's heavy on Rc, Arc, Box, RefCell etc... (e.g. the typical band-aids to work around borrow checker restrictions) will be slower than typical C++ code (it's also possible to kill performance in C++ of course, just use std::shared_ptr for everything). E.g. I'd wager that performant Rust code is trickier to write than performant C++ code because you'll have to design your entire Rust codebase around borrow checker restrictions, while C++ lets you 'cheat' without having to fall back to helper types that incur runtime overhead.
- lionkor 3mo ago
  It depends just how fast you need it. C++ is much easier to get to zero abstraction code. In Rust you are constantly fighting the stdlib and other libraries, and you have to litter your hot code with unsafe blocks to get it to stop adding a branch to nearly every object access, be it for bounds checks or over/underflow checks. C++ does a much better job at giving you a zero abstraction API, and you can always drop down to raw pointers if you want, without(!!!!) unsafe blocks and weird tricks. Of course it's unsafe in C++ but the friction to writing a branchless hot loop is muuuuch smaller. When profiling and optimizing Rust code, I very often find myself poring over the generated code, making small changes, reading api docs, and trying again, much more than in C++. Lots of unsafe Rust APIs are not even nearly good enough, even with most checks turned off you will find branches that just branch to panic!(), which is, you guessed it, still more code and a branch than the code would suggest. I get why people think that most systems languages are the same "speed", but they really are not if you are hitting limits of the hardware in your hot loops.
flohofwoe 3mo ago
> and you decide to drop to down to C++ Going from Rust to C++ seems a strange choice, since you get most of the same problems just without memory safety. Zig, Odin, C3 or even plain old C though? At least those languages have things to offer that neither Rust nor C++ provide (and if it's just compilation speed).
- pjmlp 3mo ago
  Market share, IDE and graphics tooling, and industry standards. LLVM is not going to take PRs written in Rust to fix the Rust compiler backend, for example. Neither are OpenJDK, .NET, V8, JSCore going to take such PRs. By the way, LLVM and GCC would also not take PRs written in C.
  - flohofwoe 3mo ago
    'Industry standards' is where programming languages go to die ;) As for PRs: well yeah of course, when in Rome...
    - pjmlp 3mo ago
      C has been doing quite well with industry standards like UNIX/POSIX, OpenGL, Vulkan, VFX, OpenMP,.. Same applies to C++ with CUDA, SYSCL, HPC/HFT frameworks, LLVM/GCC, AI compilers,... They don't look dead to me, even if we as industry could be much better by now.
testdelacc1 3mo ago
> I can understand when you need the absolute best performance and you decide to drop to down to C++ Could you help me understand with an example or two? My understanding is that well written Rust and C++ are often identical in performance thanks to relying on the same compiler backend (both clang and rustc use LLVM).
- aldanor 3mo ago
  Even, possibly, the other way around in some cases. A seemingly identical program may (and it does occur) compile to a faster machine code in rust than in C++ due to extra markers (eg alignment) that rust compiler is able to provide to llvm.
rootlocus 3mo ago
Im constantly surprised by the disk size required by rust builds. It takes over 50G to compile zed IIRC.
OtomotO 3mo ago
> I can understand when you need the absolute best performance and you decide to drop to down to C++ What? Rust generally doesn't have worse performance to C++, so this argument makes no sense at all to me. > and I also relate with just personal preference, but beyond those it seems a no brainer to me. That's another argument altogether. It's totally fine to have preferences and decide to go with them of course.
fulafel 3mo ago
Fortunately there are also many other memory safe languages to choose from.
canbus 3mo ago
People get attached to things they've been using for decades. Also most of the world is still written in c/c++ so any critical mass has quite a lot to go up against. Rust isn't perfect but it solves a lot of the pitfalls of C++ (not just UB, package management, horrible cmake files, linker errors etc.)
egorfine 3mo ago
> and human involvement Isn't ironic for a project that successfully killed all past and future human involvement?
pjmlp 3mo ago
The main reason to use C++, and Rust compiler also falls into it, is existing infrastructure, SDKs and industry standards. I would love that Java and .NET would provide all layers like several managed languages in the 90's, However it has taken a quarter century to get back features we already had in Modula-3, Mesa, Oberon and co.
xiaoyu2006 3mo ago
Ownership is a very limiting coding constraint, and bypassing methods, when ultimately needed (e.g. cell), cannot be engineered to be ergonomical.
randypewick 3mo ago
Rust is C++ like language, with more safety. It makes no sense to say that to get performance one can drop down to C++. As far as I am aware, you can get as fast as C with Rust. Of course, that might mean to compromise on something, some bound checks, some code ergonomics, or something else. You can write ASM in Rust, so it really gets as low level as it gets. And what I find amazing is that, similarity to C++, you can get both low level and high level code in the same language. And this is intrinsic in the language complexity: if you take a simpler language with a less powerful type system (C-class languages), you lose this ability.
ryukoposting 3mo ago
tl;dr: my job requires me to do things where Rust's memory model can't save me. https://news.ycombinator.com/item?id=48833867 https://news.ycombinator.com/item?id=48833867
andrepd 3mo ago
This comment makes no sense. For one, "you need the absolute best performance and you decide to drop to down to C++", no, C++ and Rust are virtually equivalent in that they pretty much expose the underlying machine fully; if anything Rust makes it easier to write idiomatic performant code. For two, there are plenty of reasons to use C++ unfortunately: compatibility with existing code based and availability of developers to name two.

by didibus 3mo ago

leecommamichael 3mo ago

> 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.

gpm 3mo ago
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 3mo ago
  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 3mo ago
> 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).
- comex 3mo ago
  The forbidding of circular dependencies is exactly what makes it hard to achieve parallelism! It means you have to draw nice clean module boundaries and split your compilation units there. Clean boundaries sound nice, except… what if the module is getting large? Can you just take half the module, ctrl-x, ctrl-v into a new file, and get faster compilation times without having to do any massive refactors? In C, usually yes. In C++, sometimes yes. It depends on how template-heavy the code is, but if you have some discipline you can keep most logic out of headers and thus easily splittable. In Rust, almost always no, because of circular dependencies. You can try to work around it by adding `dyn Trait` everywhere, but that requires a lot of code changes and comes at big ergonomic costs (and a small runtime cost). Which is why in practice, Rust compilation units are almost always larger than C++ or C compilation units. Rust can sometimes be competitive with C++ on compilation speed anyway, thanks to a smarter build system and not having to re-parse headers a billion times, but usually it's slower.
  - FridgeSeal 3mo ago
    > Can you just take half the module, ctrl-x, ctrl-v into a new file, and get faster compilation times without having to do any massive refactors?…In Rust, almost always no, because of circular dependencies This feels like a strange, overly-specific complaint. It reads a bit like “When I write entangled code, it’s hard to untangle”. Like, yeah, the only thing that’ll save you from that is…not writing entangled code? I’m not of the opinion that the argument of “yeah but C lets me do whacky stuff” is a particularly strong line. FWIW, letting a module grow, and then splitting modules up by cut-and-pasting stuff out along natural domain lines generally _is_ how I write Rust. Largely due to how easy it makes it to construct modules and submodules.
zamalek 3mo ago
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 3mo ago
  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 3mo ago
    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.
    - hdjrudni 3mo ago
      Box3D just showcased some stuff including deterministic replays. If you wanted to port that, you could probably import the replay and make sure it plays back the same way in your new language. I think it captures the inputs and forces applied, not the pixels. I suppose rendering is a component of a game engine too though, not just physics. I don't know how to do that reliably. Even if you captured pixels, it'd be annoying. If you've ever tried doing screenshot based diffing on web you will know that slight changes in aliasing in Chrome bugger everything up. Things that should be equivalent randomly aren't but not in a way that any human would care.
vlovich123 3mo ago
For what it’s worth game devs often use C# or C++ engines which have even worse issues. Rust also has the early beginnings of hot reload which bevy adopted if I recall correctly [1]. I still think a higher level language is good for “business” logic to orchestrate how efficient low-level pieces connect, but Rust is holding its own even against those use cases IMHO. [1] https://docs.rs/hot-lib-reloader/latest/hot_lib_reloader/ https://docs.rs/hot-lib-reloader/latest/hot_lib_reloader/
- Rohansi 3mo ago
  > For what it’s worth game devs often use C# or C++ engines which have even worse issues. Such as? You can't be referring to hot reload alone because you can already do that in both C++ and C#.
  - vlovich123 3mo ago
    Well for c++ memory safety and sharp abstractions and even worse compile times than Rust. I’m not aware of hot reload really being done in c++ at any scale but I’m not a game dev so I’m open to learning. C# AFAIK holds a minor place in gamedev and also has slow compile times maybe? I assume it has better support for hot reload times. But generally the performance profile isn’t there for the most demanding games even if the DX is.
    - Rohansi 3mo ago
      It's not specific to game dev but Visual Studio has hot reload for C++ that you should be able to make use of. C# compile times are fast. Performance is a lot better than you probably think, especially with modern .NET (not what Unity uses).
      - vlovich123 3mo ago
        Visual Studio limitations around hot reload are quite unrealistic for any serious codebase and only work on Windows with Visual Studio when you started it under a debugger. Rust’s hot reload is cross platform if I recall correctly and is always available until you disable it from the build (eg debug on, release off). It also has a better story for working around the limitations that Visual Studio just throws up on. C++ hot reload is not a common experience in the ecosystem.
stymaar 3mo ago
> The rust compiler is very slow. It's not “very slow”, that's a tired meme. It's slower than it could/should, but complaining about rustc being “very slow” is a clear misrepresentation, especially when everybody seems to have been fine with tsc's historical performance for instance. It could be nice if it was faster indeed, but people claiming it's “very slow” are just showing they never worked with it. > The best way to speed it up appears to be organizing a codebase in many crates. This is not preferable ergonomics to many. In this context (where you don't plan on publishing you stuff on crates.io) a “crate” are just a directory at the root of your repo, the ergonomic impact is literally zero.
- minraws 3mo ago
  As much as I like Rust, > In this context (where you don't plan on publishing you stuff on crates.io) a “crate” are just a directory at the root of your repo, the ergonomic impact is literally zero. Is not true, you can't have circular out of crate dependencies. This often means you now need a third crate that's a trait crate, but then you can't implement external traits on external types, so you need bridge crates, and so on. Rust's limitation of performance requiring lots of crates indeed has real impacts on projects beyond simple hello worlds or trivial cli apps. Considering it to be a zero impact issue is rather reductive, even in the context of the language's design principles itself. Rust for all it's good sides has had a lack of interest from core team and energy to drive real valuable changes beyond the nightly blockers into stable, or maybe they are working real hard and the boulders are so hard to move that we can't see any change looking outside in. Is it justified after the gargantuan effort that was merging Async and GATs? Yes. But acknowledging the problem doesn't help us solve it. This is to say, Rust is an amazing labour of love project that seems rather stuck in time due to lack of investment/time/effort or all of the above, I am not sure, but it's moving slower than I would like, at solving the problems Rust developers face everyday. And yes Rust compiler is slow (very slow is arguable, compared to modern C++ it isn't that bad, but compared to say Go without cgo, its horrid), Cargo is just bad, without proper hermetic builds and stuff, even when I setup sccache for our team and our cache hit rate remained below 20% and most of it was just C++ deps hitting the cache. Just to be clear Zig builds are quite slow too, especially on windows where debug builds also use llvm. TBH Zig debug builds on Linux also don't really feel that fast, C still compiles faster for me by a considerable margin. Either way as someone doing Rust everyday for last 8+ years, 5+ in small/large teams, I have lots of complaints and I am sad, it has been over years of me complaining without nearly enough progress, they have a survey declare ambitions, and then well... things just don't move much.. not nearly as much as I would have expected. Honestly given I have been a rust dev for over half a decade now, I should instead of commenting here probably be figuring out if I can contribute to Rust to help things along (faster?). But most meetings and discussions happen at very EU/US centric times, and number of non US/European core contributors in Rust is also rather small(I don't know of one but I hope there are a few) so as someone not in those circles, I don't have the energy to figure out my way in, with my day job. Tldr; Is Rust the language for the job here, likely. But the question should be why couldn't have been the language Bun was written from the very start. Why does Zig or C++ or C seem so much more productive. Sorry for ranting about this but this felt a little relevant since you claimed people complaining, are likely people who have never worked with Rust.
psychoslave 3mo ago
Hey thanks for teaching me a word today, and to be finicky myself, the convention seems to be to use a single n it. :)
IshKebab 3mo ago
> The rust compiler is very slow. It was very slow. It's gotten a lot faster over time (over 2x faster). It's still not exactly fast, but it's definitely faster than C++. Although C++'s slow compile times are often complained about they were never really enough to stop most people using it, including for games. > a garbage collector eliminates a large amount of defects (including the ones stated in the article) without any added friction I'd be careful about that "without any added friction". Rust's lifetime/borrowing system tends to lead to less buggy code because it encourages structuring code in a less spaghetti way. GC does eliminate memory errors but you also lose that non-spaghetti code structure.
- pjmlp 3mo ago
  Because contrary to Rust, C and C++ have a culture of binary libraries. You are seldom compiling the world from scratch. Especially in the platforms dear to game devs.
  - IshKebab 3mo ago
    > You are seldom compiling the world from scratch. True in Rust too though - you're normally doing incremental compiles. And even though you're compiling the world, it's still on par with C++. For example I just tried compiling a hello world Bevy project, which has 462 crate dependencies - pretty big. It took 2m20. Totally reasonable to build an entire game engine and all it's dependencies. I wish they had reported the compile time of Bun before/after the Rust port - that would have been very interesting.
    - pjmlp 3mo ago
      Yeah but compiling full Unreal from scratch already requires going down the path of forking it for own purposes. Same applies to most commercial libraries, where code is usually provided for debugging purposes, not for building everything from scratch. Also incremental linking on Rust, or hot code reloading is still not something that works out of the box. How beefy is that machine to achieve 2m20? I started using C++ on MS-DOS, on a 20 MHz 386SX PC with 2MB RAM and 20 MB HDD. Especially relevant in current times.
thayne 3mo ago
> Beside that, for many problems, a garbage collector eliminates a large amount of defects (including the ones stated in the article) Languages with garbage collection are generally considered "memory safe". GP was talking about choosing a language that requires manual memory management, but doesn't have something like rust's lifetimes to catch things like use-after-free.

henry_bone 3mo ago

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 3mo ago
> 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.
- flohofwoe 3mo ago
  Rust-the-language may be medium-sized. Rust-the-stdlib though? The Rust stdlib has a lot of essential low-level types needed for adding a 'semantic layer' on top of the language so that the language user can exactly 'express intent' (types that arguably should be language features instead). Just look at all those detailed methods needed to make RefCell work, and what does 'into_inner' or 'undo_leak' even mean? https://doc.rust-lang.org/std/cell/struct.RefCell.html https://doc.rust-lang.org/std/cell/struct.RefCell.html E.g. what's a single concept in C (e.g. "the pointer") easily has a dozen specialized equivalents in Rust, just because Rust needs the additional information to do its memory safety magic correctly. The entirety of Rust and its stdlib has a huge 'semantic surface' compared to most other languages (even C++), and I think this difference in the semantic surface size to other languages is exactly the one thing that either attracts or repels people to/from Rust ;)

frizlab 3mo ago

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…

pjmlp 3mo ago
Sometimes we have no option, given the industry standards that expect C or C++. Khronos, Open Group, NVidia, Microsoft, Sony, Nintendo... aren't going to change their APIs and SDKs, just because of social media discussions on the merits of C, C++ vs other safer alternatives. I agree we should minimise their use, however not everyone accepts a dual language approach, nor there are alternatives in such domains, even if they technically exist, you still need to overcome the human and political factors. Hence why it is so relevant to fix C and C++ security flaws to some extent as well.
- frizlab 3mo ago
  Obviously my comment of irresponsibility was “given that there is a choice.” Though that’s one nice thing about Swift: it has a very good interop’ with C now, and a “starting to get pretty good” interop’ with C++. So that can help, sometimes. (Obviously, I reiterate, I understand there are situations where the choice is just not possible, and enhancing C and C++ is indeed a good thing.)
  - pjmlp 3mo ago
    The nice thing about Swift, or Java/Kotlin on Android, is the platform owner attitude, either adopt it, or go elsewhere, that is the only way safety improvements are pushed into mainstream.

rvrb 3mo ago

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.

remexre 3mo ago
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 3mo ago
  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 3mo ago
    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.

Gigachad 3mo ago

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.

sneak 3mo ago
Agree 100%. Almost everything I have written with AI is in Go, and strong typing is really really nice (as is go vet and golangci-lint to keep the generated code in line). I imagine writing plain js or python with it would be much much riskier.
- ubercore 3mo ago
  Well annotated code is fine in Python too.

sitzkrieg 3mo ago

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

steveklabnik 3mo ago
> way too big https://github.com/tormol/tiny-rust-executable 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.
- deleted 3mo ago
  [deleted]
- whytevuhuni 3mo ago
  I tried to use Rust for a tiny microcontroller (GD32VF103, 128KB flash). First of all, I was amazed by how much I could do with Rust (safe Rust, even), and how well it was interfacing with my handwritten RISC-V assembly. I will definitely use Rust again for the next such project. But, every time my functions would get over a certain size, suddenly some optimizations stopped working, and Rust was trying to put the whole panic/fmt machinery into the thing, going above my linker's flash size limit. It was insanely frustrating, since there was no rhyme or reason to it. Simply adding another branch to a match made it do that. Or another if statement that was exactly the same as the 4 before it. The 137 binary thing does not scale.
  - steveklabnik 3mo ago
    I don't disagree that I think that the Rust project could do more to make this kind of development easier, and it is true that it doesn't come for free. That doesn't change the point that if you want to, you can do it, it is not a fundamental language limitation.
    - 3mo ago

josephg 3mo ago

> 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++.

m00dy 3mo ago
yeap, unfortunately, only few can see this.
- lostglass 3mo ago
  It's not though. It's fast enough for many applications but if you need to write a hypervisor then suddenly bounds checks and atomic pointers become significant. Not to mention that rust dramatically reduces your ability to control where memory is allocated. I write in rust and c++, rust isn't as fast. Rust is easier to work with and, compared to the Java crap it's replacing at my work, it's a lot better but it's certainly not zero cost abstractions the way c++ can be, nor is it great for data oriented design because you're hoping the compiler will do the right thing, consistently.
- flohofwoe 3mo ago
  It depends a lot on the coding style. The sort of Rust code that's heavy on Rc, Arc, Box, RefCell etc... (e.g. the typical band-aids to work around borrow checker restrictions) will be slower than typical C++ code (it's also possible to kill performance in C++ of course, just use std::shared_ptr for everything). E.g. I'd wager that performant Rust code is trickier to write than performant C++ code because you'll have to design your entire Rust codebase around borrow checker restrictions, while C++ lets you 'cheat' without having to fall back to helper types that incur runtime overhead.
lionkor 3mo ago
It depends just how fast you need it. C++ is much easier to get to zero abstraction code. In Rust you are constantly fighting the stdlib and other libraries, and you have to litter your hot code with unsafe blocks to get it to stop adding a branch to nearly every object access, be it for bounds checks or over/underflow checks. C++ does a much better job at giving you a zero abstraction API, and you can always drop down to raw pointers if you want, without(!!!!) unsafe blocks and weird tricks. Of course it's unsafe in C++ but the friction to writing a branchless hot loop is muuuuch smaller. When profiling and optimizing Rust code, I very often find myself poring over the generated code, making small changes, reading api docs, and trying again, much more than in C++. Lots of unsafe Rust APIs are not even nearly good enough, even with most checks turned off you will find branches that just branch to panic!(), which is, you guessed it, still more code and a branch than the code would suggest. I get why people think that most systems languages are the same "speed", but they really are not if you are hitting limits of the hardware in your hot loops.

flohofwoe 3mo ago

> and you decide to drop to down to C++ Going from Rust to C++ seems a strange choice, since you get most of the same problems just without memory safety. Zig, Odin, C3 or even plain old C though? At least those languages have things to offer that neither Rust nor C++ provide (and if it's just compilation speed).

pjmlp 3mo ago
Market share, IDE and graphics tooling, and industry standards. LLVM is not going to take PRs written in Rust to fix the Rust compiler backend, for example. Neither are OpenJDK, .NET, V8, JSCore going to take such PRs. By the way, LLVM and GCC would also not take PRs written in C.
- flohofwoe 3mo ago
  'Industry standards' is where programming languages go to die ;) As for PRs: well yeah of course, when in Rome...
  - pjmlp 3mo ago
    C has been doing quite well with industry standards like UNIX/POSIX, OpenGL, Vulkan, VFX, OpenMP,.. Same applies to C++ with CUDA, SYSCL, HPC/HFT frameworks, LLVM/GCC, AI compilers,... They don't look dead to me, even if we as industry could be much better by now.

testdelacc1 3mo ago

> I can understand when you need the absolute best performance and you decide to drop to down to C++ Could you help me understand with an example or two? My understanding is that well written Rust and C++ are often identical in performance thanks to relying on the same compiler backend (both clang and rustc use LLVM).

aldanor 3mo ago
Even, possibly, the other way around in some cases. A seemingly identical program may (and it does occur) compile to a faster machine code in rust than in C++ due to extra markers (eg alignment) that rust compiler is able to provide to llvm.

rootlocus 3mo ago

Im constantly surprised by the disk size required by rust builds. It takes over 50G to compile zed IIRC.

OtomotO 3mo ago

> I can understand when you need the absolute best performance and you decide to drop to down to C++ What? Rust generally doesn't have worse performance to C++, so this argument makes no sense at all to me. > and I also relate with just personal preference, but beyond those it seems a no brainer to me. That's another argument altogether. It's totally fine to have preferences and decide to go with them of course.

fulafel 3mo ago

Fortunately there are also many other memory safe languages to choose from.

canbus 3mo ago

People get attached to things they've been using for decades. Also most of the world is still written in c/c++ so any critical mass has quite a lot to go up against. Rust isn't perfect but it solves a lot of the pitfalls of C++ (not just UB, package management, horrible cmake files, linker errors etc.)

egorfine 3mo ago

> and human involvement Isn't ironic for a project that successfully killed all past and future human involvement?

pjmlp 3mo ago

The main reason to use C++, and Rust compiler also falls into it, is existing infrastructure, SDKs and industry standards. I would love that Java and .NET would provide all layers like several managed languages in the 90's, However it has taken a quarter century to get back features we already had in Modula-3, Mesa, Oberon and co.

xiaoyu2006 3mo ago

Ownership is a very limiting coding constraint, and bypassing methods, when ultimately needed (e.g. cell), cannot be engineered to be ergonomical.

randypewick 3mo ago

Rust is C++ like language, with more safety. It makes no sense to say that to get performance one can drop down to C++. As far as I am aware, you can get as fast as C with Rust. Of course, that might mean to compromise on something, some bound checks, some code ergonomics, or something else. You can write ASM in Rust, so it really gets as low level as it gets. And what I find amazing is that, similarity to C++, you can get both low level and high level code in the same language. And this is intrinsic in the language complexity: if you take a simpler language with a less powerful type system (C-class languages), you lose this ability.

ryukoposting 3mo ago

tl;dr: my job requires me to do things where Rust's memory model can't save me. https://news.ycombinator.com/item?id=48833867 https://news.ycombinator.com/item?id=48833867

andrepd 3mo ago

This comment makes no sense. For one, "you need the absolute best performance and you decide to drop to down to C++", no, C++ and Rust are virtually equivalent in that they pretty much expose the underlying machine fully; if anything Rust makes it easier to write idiomatic performant code. For two, there are plenty of reasons to use C++ unfortunately: compatibility with existing code based and availability of developers to name two.