[deleted]
Rust’s 1.0 release (i.e. the date on which the language received any sort of stability guarantee) was in 2015, and this article was written in 2019. Measuring the pace of feature development of a four-year-old language by its release notes, and comparing against a 50-year-old language by counting bullet points in Wikipedia articles, is absolutely ridiculous.
Yes, younger languages adopt features more quickly, and Rust was stabilized in a “minimal viable product” state, with many planned features not yet ready for stabilization. So of course the pace of new features in Rust is high compared to older languages. But Wikipedia articles are in no way comparable to release notes as a measure of feature adoption.
I think C is faster, more powerful, and more elegant.
“More elegant” is a matter of opinion. But “faster” and “more powerful” should be measurable in some way. I’m not aware of any evidence that C is “faster” than Rust, and in fact this would be extremely surprising since they can both be optimized with LLVM, and several of the features Rust has that C doesn’t, such as generics and ubiquitous strict aliasing, tend to improve performance.
“Powerful” can mean many things, but the most useful meaning I’ve encountered is essentially “flexibility of application” : that is, a more powerful language can be used in more niches, such as obscure embedded hardware platforms. It’s really hard to compete with C in this regard, but that’s largely a matter of momentum and historical lock-in: hardware vendors support C because it’s currently the lowest common denominator for all hardware and software. There’s nothing about Rust the language that makes it inappropriate for hardware vendors to support at a low level. Additionally, GCC is probably the toolchain with the broadest hardware support (even hardware vendors that use a bespoke compiler often do so by forking GCC), and Rust currently has two projects (mrustc and gccrs) working to provide a way to use GCC with Rust. So even the advantage C has in terms of hardware support is narrowing.
But note that there are also niches for which C is widely considered less appropriate than Rust! The most obvious example is probably use in a front-end web application. Yes, C should in theory be usable on the front-end using emscripten, but Rust has had decent support for compiling to WebAssembly almost as long as it’s been stabilized.
LPThinker@lemmy.world 9 months ago
There are several things I disagree with in this article, although I see where the author is coming from. I will never be onboard with “I’ll take my segfaults and buffer overflows.”, and I fundamentally disagree about concurrency. I also think that cargo is fantastic, and a lack of standard build tools is one thing that holds rust’s predecessors back.
However, a majority of the authors points can be boiled down to “C is more mature”, which doesn’t tell us much about the long-term viability and value of these languages. For example, in the author’s metric of stability and complexity, they use C99 as the baseline, but C99 is the state of a language that had already had almost 3 decades of development, whereas Rust has been stable for less than a decade. Talking about superior portability, stability, and even spec, implementations, and ABI is in some real sense just saying “C is older”.
That’s not to say those things aren’t valuable, but rather they aren’t immutable characteristics of either language. And given that safety is playing an ever more important role in software, especially systems software, I think Rust will catch up in all the ways that are meaningful for real projects more quickly than most of us realize. I certainly don’t think it’s going anywhere anytime soon.
randy@lemmy.ca 9 months ago
Also worth noting this article is nearly five years old. Rust’s first stable release was nearly nine years ago, so its (stable) age has more than doubled since then. I expect Rust would look a lot more mature if the article was written today.
Turun@feddit.de 9 months ago
In terms of changes, probably.
The kitchen sink feature creep is continuing though. You can consider that good or bad, but it’s a fact that it is happening.
BehindTheBarrier@programming.dev 9 months ago
Brushing off safety in a single small paragraph sure makes me feel like its not trying to make a serious argument. Sure a handyman likes the simplicity and freedom, but considering this:
From Wikipedia, it’s pretty clear memory security is a pretty substantial topic in the programming world. Brushing that off because you do not care makes for a bad argument.