391–400 of 731 posts
> We know the result isn’t idiomatic Rust, and there’s a lot that can be simplified once we’re comfortable retiring the C++ pipeline. That cleanup will come in time. Correct me if I’m wrong since I don’t know these two languages, but like some other languages, doing things the idiomatic way could be dramatically different. Is “cleanup” doing a lot of heavy lifting here? Could that also mean another complete rewrite f…
Earlier quoted context omitted.
Your argument is just as applicable on human code reviewers. Obviously having others review the code will catch issues you would never have thought of. This includes agents as well.
They’re not equal. Humans are capable of actually understanding and looking ahead at consequences of decisions made, whereas an LLM can’t. One is a review, one is mimicking the result of a hypothetical review without any of the actual reasoning. (And prompting itself in a loop is not real reasoning)
> This is not becoming the main focus of the project. We will continue developing the engine in C++, and porting subsystems to Rust will be a sidetrack that runs for a long time. I don't like this bit. Wouldn't it be better to decide on a memory-safe language, and then commit to it by writing all new code in Rust, or whatever. This looks like doing double the work.
it is totally possible to use some strict subset of C++, which will be memory safe.
Earlier quoted context omitted.
> Modern C++ pretty much solves the safety issues. The statistics from projects that have adopted Rust and measured the effect say otherwise. See https://security.googleblog.com/2025/11/rust-in-android-move... for example.
This article is not really specifying if Rust is compared against "Modern C++" or "Old School C++". The only thing we can assume is that at least part of it is "Google C++". Maybe we would see similar effects adopting Modern C++. Maybe not. The article doesn't tell us.
Earlier quoted context omitted.
Apple’s own marketing speak has Swift as a cross platform language. Just like, I suppose, C# is a cross platform language. Apple puts zero resources into making that claim reality, however.
Apple actually did put some resources behind it, the toolchain is reasonably pleasant to use outside macOS and Xcode, they have people building an ecosystem in the Swift Server Workgroup, and arguably some recent language design decisions don't seem to be purely motivated by desktop/mobile usage. But in the end I can't help but feel Swift has become an absolute beast of a multi-paradigm language with even worse compi…
> This is not becoming the main focus of the project. We will continue developing the engine in C++, and porting subsystems to Rust will be a sidetrack that runs for a long time. I don't like this bit. Wouldn't it be better to decide on a memory-safe language, and then commit to it by writing all new code in Rust, or whatever. This looks like doing double the work.
Earlier quoted context omitted.
> Rust is the final language. I honestly can't tell if this is a humorous attack or not. Poe's law is validated once again.
It's honest. If we can serialize our ideas to any language for durability, Rust is the way to go. It's not the best tool for the job for a lot of things, but if the LLMs make writing it as fast as anything else - whelp, I can't see any reason not to do it in Rust. If you get any language outputs "for free", Rust is the way to go. I've been using Claude to go ridiculously fast in Rust recently. In the pre-LLM years I…
I used to think that I would never write C code again, but when I decided recently to build something that would run on ESP32 chips, I realized there wasn't any good reason for me to use Rust yet. ESP-IDF is built on C and I can write C code just fine. C compiles quickly, it's a very simple language on the surface, and as long as you minimize the use of dynamic memory allocation and other pitfalls, it's reliable.
Interestingly editorialized title omits “with help from AI”.
That’s probably just the classic HackerNews title shortening algorithm at work.
There is an open PR (by simonw btw): https://github.com/minimaxir/hacker-news-undocumented/pull/4...
Earlier quoted context omitted.
> I guess more anti-hype, where Rust was the hype Yeah that is the thing I struggle with. I am really happy for people falling in love with Rust. It is a amazing language when used for the right use case. The problem is that had my Rust adventures a few years ago and I am over the hype cycle and able to see both the advantages and disadvantages. Plus being generally older and hopefully wiser I don't tie my identity t…
I'm contemplating diving into Rust for a smallish project, a daemon with super-basic UI intended for Linux, MacOS and Windows. Do you mind expanding on what disadvantages you encountered? Or use-cases that aren't appropriate for Rust?
1. build / compile times can be atrocious
2. crates.io inherits the npm philosophy, which means fairly unmoderated space of third party deps and because the Rust stdlib doesn't have a lot in it, extensive third party crate (lib) usage is strong in Rust. As a result most Rust projects have rather sprawling dependency trees, often with duplicated functionality (multiple Base64, rand, sha256, etc crates). I personally have a problem with this (auditability, accountability, security, complexity etc). Others don't.
3. Despite being nominally runtime agnostic, Rust async basically is tokio and it's almost impossible to use another runtime once you factor in third party deps. In many ways Rust is the language that tokio ate. In fact even if you opt out of async entirely, you often end up with tokio as a dependency simply because the community just seems to expect it.
4. Despite advertising itself as a "systems" language, some basic systems programming facilities I expect from my C++ background are still fundamentally not there. In particular, per-container/struct pluggable allocators still isn't a thing and the feature to add it (allocator-api) has sat unmerged in nightly for almost ten years at this point and it doesn't look good for it landing any time soon.
5. If you're working in the embedded space, there's still plenty of devices that will not have a workable Rust toolchain option yet.
I still choose it for new projects instead of its competitors C++ or Zig. But I think it's important to recognize there are compromises like any other tool.
As much as people might insist otherwise, there will in fact come a day when there are "multiple Rusts" by which I mean multiple styles and ways of doing things -- just like C++. For myself, for example... if it were my repository and my team and my hiring, and I was starting from scratch... I'd be extremely careful about third party crate adoption and have an extremely minimalistic approach there. And I don't use tokio. Though my paying jobs do.