Without any ::prelude and some void* arguments.
Maybe you have thoughts about it.
The URL is just a sample of “why” but not “because”.
I have my own preference but will keep it inside my mind to not burn a tornado that will erase me from the matrix of the world.
P.S.: I think C is faster, more powerful, and more elegant. I like it more than Rust.
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.
Thank you for your answer. There are a lot of startups and good open repos in Rust nowadays and it seems this intention will only grow. Finally, only community and business preferences define how much cool staff will be made with programming language. I do not like the hype around Rust and like the simplicity of the C syntax. And I think we need to use languages for their appointments. Learn Rust, learn C, and use them in different projects. Switching between technologies helps avoid burnout and learn new things to keep your interest fresh.
I very much understand thinking that Rust has too much hype, but the differences between C and Rust are so fundamental that “switching between” them just to “keep your interest fresh” seems ill-advised to me. To be honest, your statements about both C and Rust so far seem pretty superficial; have you actually used Rust for anything nontrivial?
C syntax is simple, yes, but C semantics are not; there have been numerous attempts to quantify what percentage of C and C++ software bugs and/or security vulnerabilities are due to the lack of memory safety in these languages, and although the results have varied widely, the most conservative estimate (this blog post about curl; see the section “C is unsafe and always will be”) ended up with an estimate of 40%, or 50% if you only count critical bugs. If I recall correctly, Microsoft did a similar study on one of their projects and declared a rate closer to 70%.
This means that the choice of language is not just about personal preference. Bugs aren’t just extra work for software developers; they affect all users of software, which means they affect pretty much everyone. And, crucially, they’re not just annoyances; cyberattacks of various kinds are extremely prevalent and can have a huge impact on people. So if 50% or more of critical software vulnerabilities are due to the choice of language, then that is a very good reason to pick a safer language.
Rust is not the only choice for memory-safe languages. If you like the simplicity of C, you should definitely learn Go (it’s explicitly designed to be as simple as possible to learn). But I would also strongly recommend looking into Zig, which hews much closer to C than Rust does; in fact, it has probably the best interoperability with C of any modern language.
C syntax is simple, yes, but C semantics are not; there have been numerous attempts to quantify what percentage of C and C++ software bugs and/or security vulnerabilities are due to the lack of memory safety in these languages, and (…)
…and the bulk of these attempts don’t even consider onboarding basic static analysis tools to projects.
I think this comparison is disingenuous. Rust has static code analysis checks built into the compiler, while C compilers don’t. Yet, you can still add static code analysis checks to projects, and from my experience they do a pretty good job flagging everything ranging from Critical double-frees to newlines showing up where they shouldn’t. How come these tools are kept out of the equation?
This is an old post and a lot has changed since then. Many of the points in that article are no longer true. Drew himself started a language - hare, for which he is considering Rust style borrow checker to ensure safety. It’s a bit wrong to bash anything based on a half a decade old opinion.
Oh another Rust vs C discussion.
I bet the comparisons totally won’t be controversial on both sides at all. That never happens.
Did you try to add an image and remove the URL to the article im the process?
