Posted elsewhere but The default hello world stripped with one codegen unit and panic=abort was 342kB both nightly and stable. Adding lto dropped it 42kB in stable and 40kB in nightly. Adding build-std and only building core did not reduce it any further in size.
I agree, but if you use more of the std library it will contribute more to the final image. I can write a 100 line rust file that ends up being 1MiB (even after lto) because I maximize as much code from the standard library as possible. This is not a knock on rust, but your statements can be a misleading as well. In practice most folks ignore the majority of the standard library so only a few hundred kib of std library end up in their binary.
Oh come on, that was funny. It also highlights a problem with the way people write rust. If your app panics it has a bug. People throw panics in cases that can absolutely happen, a file isn't there or fails to parse, some set of inputs is mutually inconsistent these are things for error checking. Even if the correct way to handle an error you detect is to stop the app, do that instead of panicking. Panics are for things that should be impossible. Ideally they even get optimized out.
Did they say anywhere what they did? Rebuilding the stdlib as part of your build can shrink it a lot depending on how much of it you use, but that is still nightly only. Maybe they went no_std or created their own?
They didn't but keep in mind that the app is currently 170MiB. The standard library shouldn't have added more than a few hundred kilobytes. They already likely pay similar costs for c++, but it's more worthwhile as they have a lot more c++ code total.
Also note that if you statically link to the rust std library, lto will excise the majority of it anyways, no need to rebuild it.
The default hello world stripped with one codegen unit and panic=abort was 342kB both nightly and stable. Adding lto dropped it 42kB in stable and 40kB in nightly. Adding build-std and only building core did not reduce it any further in size.
That is what I was talking about. It didn't reduce it at all over just lto. If I'd set optimization to z it probably would have gotten some back, but that starts impacting performance
That isn't what I've seen. It seems to use every language in the way idiomatic for it, or more accurately, in the way it has een that language be ised. Rust written that way isn't present in it's training corpus so it doesn't do that. I would be more concerned about it getting creative and adding something a cool rustacean might add in the porting process that you don't actually want.
People work different than llms they fond things we don't and the reverse is also obviously true. As an example, a stavk ise after free was found in a large monolithic c++98 codebase at my megacorp. None of the static analyzers caught it, even after modernizing it and getting clang tidy modernize to pass, nothing found it. Asan would have found it if a unit test had covered that branch. As a human I found it but mostly because I knew there was a problem to find. An llm found and explained the bug succinctly. Having an llm be a reviewer for merge requests males a ton of sense.
It seems like they have something like differential fuzzing to guarantee identical behavior to the original, but they still are left with a codebase they cannot read...
Are there really any good reasons to start a brand new project in c++ though? No one who can write modern c++ has any trouble with rust in my experience, and all the other common options are even quicker to pick up. Creating bindings isn't hard anymore if your niche library doesn't have any yet. Syntactic preference I guess, but neither c++ or rust are generally considered elegant or aesthetic choices.
Because "brand new" doesn't mean devoid of context. Within your domain, there will still be common libraries, interfaces, and tools.
C++ is very flexible, with a lot of very mature tooling and incredibly broad platform support. If you're writing some web server to run on the hardware of your choosing, then sure, that doesn't matter. But if you're writing something deeply integrated with platform/OS interfaces, or graphics, or needs to support some less common platforms, then C++ is often your only practical option for combining expressiveness and performance.
This is the sort of info I was trolling for, but what are those platforms and os? Targets llvm doesn't handle yeah c++ makes sense, or c. A sibling mentions xcode, which makes sense. Graphics seems questionable, vulkan support is fine. Windows support has seemed finetoo, the same gui has worked as what we wrote for Linux.
Dependencies. There are billions of lines of C++ out there that have been optimized and production hardened over decades that you might want to reuse. Rust lang interoperability with anything but C sucks in practice.
Maybe, maybe not. But either way it's just plain rude to charge into a C++ thread to drop a comment saying how the language sucks and you should use (insert other language) instead.
C++ was the GUI king during the 1990's, and none of the Rust toolkits is half as good as the surviving frameworks, like C++ Builder, Qt, wxWidgets, heck even MFC has better tooling.
Trying to defer to native widget rendering per platform was a mistake, and every time I've touched wxWidgets in the past decade and a half I've regretted it.
FLTK on the other hand is ugly as sin, but I've found it reliable enough to not act in surprising ways, and it's also small enough to where you can vendor it and build it alongside your program.
Yes. If you're targeting Apple platforms and want to allow clients to use your product in Xcode (the common case) or even need Swift/ObjC interop yourself, using rust or anything not explicitly supported by Apple and Xcode is just too fiddly.
(Shrug) If I want Rust, I'll feed my C++ to an LLM and tell it to port it to Rust. Since we've been assured that Rust magically fixes everything that's wrong, bad, or unsafe about C++, this seems like a sound approach.
We probably aren't that far off actually. Even taking asm with no symbols back into rust works well. You have truth, just have the agent repeat until the asm matches. Doesn't work on giant codebases, but on a few functions it absolutely does. And while the llm may get the algorithm wrong, the type system does seem to help it generate useful code in rust for a starting place v
Yeah, but then just let the agent generate proper C++ code, contrary to an human it doesn't forget about best practices, or how ownership is supposed to be handled.
You missed the other take, with AI assisted coding, you can stay in C++, as it will take care everything is coded with enough care.
Or why bother with Rust, when the LLM gets to generate C++ code with best practices.
While I like Rust, I think AI as the next abstraction step in programming has kind of taken its relevance away, when computer assisted programming is part of the workflow.
Strange. I wouldn’t trust the output of a coding agent and I would want stronger review of its output. If it passes a strict compiler that gives me more confidence than if it passed a lax one.
But sure, if you trust it to have written C++ to a higher standard than the experts, then go for it.
It is what it is, I accept that’s where the industry is heading.
But if I have to produce reams of code I’d much rather have it be reviewed by rustc than clang. rustc may take longer to satisfy, but it’ll be worth it because I won’t be responsible for horrors in production.
You’re happy to be responsible for buffer overflows written by an LLM? I’m not, which is why I prefer a language where it’s not possible.
Even reviewing human written C++ is difficult. Android has had 20 years to figure it out and they couldn’t find a way to reduce the number of vulnerabilities they introduced in carefully crafted C++ code. I shudder to think how many more they would have introduced if they had vibe coded it.
Good analysis out there indicating sweden could beat Poland there. Finland and Germany also on the likely list. Then in the east Japan and sk. The npt is dead. The French government being completely gridlocked with a nonzero chance to go authoritarian itself, along with the us stepping away guarantee this.
reply