> honestly thats the biggest problem with rust, they come up with a lot of useful changes but then take ages to stabilize because the core team is overworked
On the contrary, that has been one of Rust's biggest strengths. My impression when reading through stdlib was that they got so many things right, and for that to happen, things need to be thought out properly.
Case in point, it'd be such a shame if they stabilized the allocator API, only for us to forever regret never getting the storage API [1] instead, or vice-versa, depending on which one turns out to be more pragmatic.
> they also have a kind of perfectionist culture as a reaction to all the half baked features shipping in C++.
And that's a good thing! Some people really dislike the constant influx of new features due to the overwhelming complexity it leads to. So if we do have new features, they better be worth it.
GP is referring to the article's title, as in "safe Rust", as in "Rust with no unsafe keyword", as in whether it has undefined behavior or not.
Granted the premise is rather brittle, since all Cpp2Rust does is to convert UB to runtime crashes, which can be undecidable, and cannot be used to prove anything about the original C++ code.
It is a fundamental language limitation, unless you want to claim that the core library (or rather what's left when using no_std) is not part of the language.
The problem comes from a combination of three things:
1. Rust's standard library (including core) likes to panic a lot, e.g. for code that is genuinely unreachable (and this is fine)
2. Rust/LLVM cannot always optimize unreachable code away (and this is also fine)
3. The presence of at least one panic causes Rust to also include the error string format machinery, which is HUGE (and this is completely unavoidable)
Because of #2, there is no way to prevent this for larger code. I can define my own panic handler, but I can't prevent panic!() calls from inside core from constructing the format message using core::fmt before they call my panic handler.
And so any non-trivial code sometimes just randomly becomes 3x larger, and I can no longer fit it on my MCU, despite never actually printing or caring about any panic messages.
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.
Languages, no. But for language-agnostic package managers, Nix/Guix and Gentoo are similar.
Sadly, Gentoo is not great for managing per-project dependencies in the same way as is done by npm, pipenv, etc. Nix however works great (if you can stomach its stdlib).
Ah, okay. In that case I feel like the only sane way to approach this is to completely abolish null-terminated strings, and reimplement everything (including stuff like printf's format and arguments) in terms of strv. Otherwise if there has to be a 2cstr function, it should be an allocating one.
> The concept of "a garbage-collected language" is not well-defined. There are languages, like Java, Rust, and Python that depend on a garbage collection mechanism, and languages like C, C++ and Zig, which don't. C++ happens to offer a GC in its standard library, however.
How does Rust differ from C++ in this regard?
As far as I know, both use RAII, and offer something RC-like in their stdlib that is optional to use.
The list of features and anti-features looks amazing, that's just want I want from a simple systems language.
However, the list of examples has... basically nothing. So it hasn't really proved that its set of features is enough to do anything with it.
The syntax is... off-putting. Regardless of how superficial it might seem, most systems programmers will want curly braces, and going against that is a really bad idea.
I'm a really big fan of Rust, but I have to challenge this, GP was clearly talking about the complexity of the language itself, and that one is high.
Extra features and extra static checking add complexity. Extra complexity in the language can make simple programs harder, and they make complex programs easier to code and maintain, like you said.
However, nobody will ever be able to make a Rust equivalent of TinyCC, the language's rules are insanely complex, especially for things like GATs and the other tricky concepts it's trying to tackle.
Moral of the story: A truly secure website would be a continuously morphing one where an LLM keeps rewriting and redeploying large parts of its code every minute, so that no attacker can keep up.
Very surprised to hear that, since editions are exactly the kind of mechanism Rust is using to make sure software will keep working unchanged for decades.
The Rust compiler can build a 2024 edition application which depends on a 2015 edition library, which in turn depends on a 2018 edition library.
Every crate can upgrade at their own pace, or even never at all.
Maybe this was a genius move made precisely to be ambiguous on whether it was April Fools or not... so that the author can later read the room and clarify whether it was or was not April Fools, without much repercussion either way.
That's not much different than other distros, because the way auto-update usually works, is it can't use root permissions or the system package manager (in any distro), so it has to install the newer version in $HOME. Once the update is installed, the system package becomes a trampoline to that.
I tried Discord, and this one seems to download some updates on first run, but the version sticks to the one from the system (0.0.127, latest is 0.0.129). So I assume it just doesn't update, or it tries to and fails.
On the contrary, that has been one of Rust's biggest strengths. My impression when reading through stdlib was that they got so many things right, and for that to happen, things need to be thought out properly.
Case in point, it'd be such a shame if they stabilized the allocator API, only for us to forever regret never getting the storage API [1] instead, or vice-versa, depending on which one turns out to be more pragmatic.
> they also have a kind of perfectionist culture as a reaction to all the half baked features shipping in C++.
And that's a good thing! Some people really dislike the constant influx of new features due to the overwhelming complexity it leads to. So if we do have new features, they better be worth it.
[1] https://github.com/rust-lang/rfcs/pull/3446