Rust is wildly fast. Learning that it is being used for a program is good to know if you care about speed. If you read the article, it even addresses your exact critiques:
Moreover, Rust has demonstrated superior performance compared to JavaScript add-ons, resulting in a quicker and more responsive Thunderbird. Furthermore, the integration of Rust into Thunderbird will be facilitated by the fact that it is already utilized in Firefox, enabling Thunderbird to leverage existing infrastructure for testing and continuous integration.
So not only with thunderbird be faster because Rust is faster than JavaScript, but it eliminates 3rd party addons by being native which also further increases speed. Lastly, development time for new features and improvements is faster because they can now use using the mature tooling that Mozilla has for Rust.
Not the person you wrote to, but TB has native code in C++, so I don’t really think the speed will change. The official website also doesn’t advertise speed improvements. It argued that Rust is (almost) as fast as the current native C++ part in TB, and that’s about it.
I wrote a simple commandline program in Rust to read mailbox file from Thunderbird and to output count of unread mails. The speed is insanity! Measuring the execution time with command timeCMD outputs execution time of total 0m0,001s! While also providing all the features and checks from Rust (plus Clippy with pedantic options enabled), so I am confident it is not a buggy mess. I would need at least 10 years of professional experience in C to have this feeling of confidence.
The improvement here is switching from interpreted to compiled. It could have been C, Zig, Odin, or even C++ (but thank Satan it isn’t C++)
I’m not sure I understand why people like Rust over C, although I don’t have that much experience in enterprise coding. I’m generally distrustful of languages without a standardized specification, and I don’t really like that Rust has been added to the Linux Kernel. Torvalds giving in to public opinion isn’t something I thought I’d live to see…
I get the segmentation fault thing, but to be blunt, that sounds like a skill issue more than an actual computer science problem.
Maybe if things were less rushed and quality control was regarded more highly, we wouldn’t have such insanities as an email client (or an anything client) written in JavaScript in the first place.
Rust is likely going to suffer the same problem as JS, where people indirectly include 6,000 crates and end up with 30 critical CVEs in their email client that they can’t even fix because the affected crate was abandoned 5 years ago…
This “skills issue” thing just sounds so stupid in my ears. I am sick of reading it.
So, I am choosing a language that I hope will ensure fast, secure, and sophisticated code for my project. It has to do this for code I write, my team writes, and all future maintainers and contributors will write as well. If I choose a language that makes it easy to write unstable, fragile, and insecure code then “the skills issue” applies more to my lack of capability as an architect than it does the coders that come after me.
Stop saying, “well ya, it is super easy to make these mistakes in this language but that would never happen if you are as awesome as I am” and thinking that sounds like an intelligent argument for your language choice. There are better options. Consider them.
Why do you want sophisticated code ? That word seems out of place from the other two to me.
Rust doesn’t introduce the same problems as C, but it sure does introduce a lot of other problems in making code overly complicated. Lifetimes and async are both leaky abstractions (and don’t even work as advertised, as rust-cve recently demonstrated), macros can hide control flow…
C is unsafe, sure, but also doesn’t pretend to be safe. C is also stupid simple, and that’s a good thing : you can’t just slap ArcMutexes around, because by the time you know how to code them yourself you also know why you shouldn’t do that.
I hope Rust can reach a point where its safety model can be formally proven, and we have a formal specification and a stable ABI so we don’t have to hard-compile every crate into the binary.
But I personally expect something with some of Rust’s ideas, but cleaned up, to do that instead. Actually, I wouldn’t be surprised if C itself ends up absorbing some of Rust’s core ideas in an upcoming standard.
Obviously it’s a skill issue but don’t you ever make mistakes? If Rust prevents some bugs and makes you more productive, what is not to like? It’s a new language and takes time to learn but the benefits seem to outweigh the downsides now and certainly in the long run (compared to C at least).
Maybe Torvalds didn’t give in to public opinion but made an informed choice?
The crates are a bit of a problem and I think Rust is a bit overhyped for high-level problems (it still requires manual memory management after all) but those are not principal roadblockers, especially in the kernel.
It’s not “the segmentation fault thing”. It’s that C allows you to shoot yourself in the foot in many various ways, part of which will immediately show itself in the form of a segfault, part of which may show itself in the form of a segfault minutes, days, or years later depending on how the users use the software, and part of which will not show itself in the form of a segfault ever but make the program unstable in other ways.
Yeah, sure, you can say that it’s “a skill issue”, but maybe that’s not the attitude of the year if you want more contributors in the project, which is a useful goal if you don’t want it’s developer community to die out or otherwise disintegrate.
where people indirectly include 6,000 crates and
That’s why the maintainers shouldn’t allow anyone to just add any new dependencies without a proper consideration. I don’t think this is an unsolvable problem.
I admit to not knowing how running an open source project goes, but wanting more contributors seems like the wrong metric compared to better contributors.
I understand the pitfalls of C are not limited to segmentation faults, but I suspect it would be more productive to fix C by including some of Rust’s better ideas than to throw it away, as seems to be the current trend.
I don’t think Rust is wholly bad, to be clear, but it seems over-engineered to me, and the fact its useful new features don’t even completely work (see rust-cve) isn’t very encouraging.
I would recommend listening to Jonathan Blow’s opinion on Rust, which I tend to agree with. I personally think I’m just going to stick with C until Rust either becomes the standard, or I retire and let the next generation worry about that.
I don’t have much experience in C, but I’m not sure if bringing Rust’s ideas over to C would help.
As I understand, a lot of problems come from either that arrays are actually just pointers and if you don’t enforce it’s length for yourself then no one will, and in practice they span the entire area of process memory dorwards and backwards too. Or from that you free memory at the wrong time, or you never do that at all.
You can’t make mistakes with the first thing in Rust because the compiler takes note of the array’s length, and you just can’t abuse it as it won’t compile then. The second is a nonissue too, as memory management is automatic (kind of).
Fixing C sounds to me like patching up a sieve. That language was designed with those features in mind that make it error prone, and changing them would result in a different language. You would have to change your program anyway, and that probably wouldn’t be a small renovation. Also, you often can’t afford to not use pointers, because that’s how you pass things by reference in C, and besides passing by reference being important for performance reasons (to avoid copies) that’s the only option if so you have is a pointer to something, and when it’s stored in the heap.
including some of Rust’s better ideas than to throw it away
The problem is that you can’t just tack Rust’s ideas onto an existing language. Generics, traits, lifetimes, borrowing, sum types, and match are key Rust features, but took considerable design time before Rust even reached 1.0. They interlock to produce a pleasant development experience. You can’t just attached them to C and call it a day.
I don’t think Rust is wholly bad, to be clear, but it seems over-engineered to me, and the fact its useful new features don’t even completely work (see rust-cve) isn’t very encouraging.
Most of the CVE’s listed there are in unsafe code in the standard library. At some point, some code is going to have to have to implement the tricky cases. In C, this code is common place, ready for any coder to run into problems. In Rust, these are bizarre edge cases that most people would never trigger.
I haven’t heard Jonathan Blow’s take yet, but one thing a person pointed out is that he tends to prefer a style that uses a lot of shared state. Rust explicitly discourages that style, considering it a source of bugs.
I encourage you to give Rust a try. It never hurts to have another language in your arsenal. Who knows, you might even find it fun.
I’m not sure I understand why people like Rust over C, although I don’t have that much experience in enterprise coding.
I’d actually say that Rust is more popular in open-source projects. The reason people like it is because it’s WAY safer than C or C++ while being literally just as fast if not faster. I’m still in the process of learning it though so I can’t speak to your other points.
It is worth mentioning that the White House recommends Rust over C/C++ due to its very notable safety advantage over classic languages.
Somehow it sounds quite weird that the white house has such a recommendation. NIST, or the NSA? That would be easier to understand because they deal with code and algorithms but the white house?
Rust is wildly fast. Learning that it is being used for a program is good to know if you care about speed. If you read the article, it even addresses your exact critiques:
So not only with thunderbird be faster because Rust is faster than JavaScript, but it eliminates 3rd party addons by being native which also further increases speed. Lastly, development time for new features and improvements is faster because they can now use using the mature tooling that Mozilla has for Rust.
So yeah, good to know its using Rust now.
Not the person you wrote to, but TB has native code in C++, so I don’t really think the speed will change. The official website also doesn’t advertise speed improvements. It argued that Rust is (almost) as fast as the current native C++ part in TB, and that’s about it.
I wrote a simple commandline program in Rust to read mailbox file from Thunderbird and to output count of unread mails. The speed is insanity! Measuring the execution time with command
time CMDoutputs execution time of total0m0,001s! While also providing all the features and checks from Rust (plus Clippy with pedantic options enabled), so I am confident it is not a buggy mess. I would need at least 10 years of professional experience in C to have this feeling of confidence.The improvement here is switching from interpreted to compiled. It could have been C, Zig, Odin, or even C++ (but thank Satan it isn’t C++)
I’m not sure I understand why people like Rust over C, although I don’t have that much experience in enterprise coding. I’m generally distrustful of languages without a standardized specification, and I don’t really like that Rust has been added to the Linux Kernel. Torvalds giving in to public opinion isn’t something I thought I’d live to see…
I get the segmentation fault thing, but to be blunt, that sounds like a skill issue more than an actual computer science problem.
Maybe if things were less rushed and quality control was regarded more highly, we wouldn’t have such insanities as an email client (or an anything client) written in JavaScript in the first place.
Rust is likely going to suffer the same problem as JS, where people indirectly include 6,000 crates and end up with 30 critical CVEs in their email client that they can’t even fix because the affected crate was abandoned 5 years ago…
This “skills issue” thing just sounds so stupid in my ears. I am sick of reading it.
So, I am choosing a language that I hope will ensure fast, secure, and sophisticated code for my project. It has to do this for code I write, my team writes, and all future maintainers and contributors will write as well. If I choose a language that makes it easy to write unstable, fragile, and insecure code then “the skills issue” applies more to my lack of capability as an architect than it does the coders that come after me.
Stop saying, “well ya, it is super easy to make these mistakes in this language but that would never happen if you are as awesome as I am” and thinking that sounds like an intelligent argument for your language choice. There are better options. Consider them.
Why do you want sophisticated code ? That word seems out of place from the other two to me.
Rust doesn’t introduce the same problems as C, but it sure does introduce a lot of other problems in making code overly complicated. Lifetimes and async are both leaky abstractions (and don’t even work as advertised, as rust-cve recently demonstrated), macros can hide control flow…
C is unsafe, sure, but also doesn’t pretend to be safe. C is also stupid simple, and that’s a good thing : you can’t just slap ArcMutexes around, because by the time you know how to code them yourself you also know why you shouldn’t do that.
I hope Rust can reach a point where its safety model can be formally proven, and we have a formal specification and a stable ABI so we don’t have to hard-compile every crate into the binary.
But I personally expect something with some of Rust’s ideas, but cleaned up, to do that instead. Actually, I wouldn’t be surprised if C itself ends up absorbing some of Rust’s core ideas in an upcoming standard.
Isn’t rust-cve based on a single error of the borrow checker?
Obviously it’s a skill issue but don’t you ever make mistakes? If Rust prevents some bugs and makes you more productive, what is not to like? It’s a new language and takes time to learn but the benefits seem to outweigh the downsides now and certainly in the long run (compared to C at least).
Maybe Torvalds didn’t give in to public opinion but made an informed choice?
The crates are a bit of a problem and I think Rust is a bit overhyped for high-level problems (it still requires manual memory management after all) but those are not principal roadblockers, especially in the kernel.
I do wonder why rust is used in high-level time to time, then I realize the most high-level langs are sht.
Do you really think Torvalds is the one who would cave in to public opinion only? Really?
Also how much of C programming did you do
It’s not “the segmentation fault thing”. It’s that C allows you to shoot yourself in the foot in many various ways, part of which will immediately show itself in the form of a segfault, part of which may show itself in the form of a segfault minutes, days, or years later depending on how the users use the software, and part of which will not show itself in the form of a segfault ever but make the program unstable in other ways.
Yeah, sure, you can say that it’s “a skill issue”, but maybe that’s not the attitude of the year if you want more contributors in the project, which is a useful goal if you don’t want it’s developer community to die out or otherwise disintegrate.
That’s why the maintainers shouldn’t allow anyone to just add any new dependencies without a proper consideration. I don’t think this is an unsolvable problem.
I admit to not knowing how running an open source project goes, but wanting more contributors seems like the wrong metric compared to better contributors.
I understand the pitfalls of C are not limited to segmentation faults, but I suspect it would be more productive to fix C by including some of Rust’s better ideas than to throw it away, as seems to be the current trend.
I don’t think Rust is wholly bad, to be clear, but it seems over-engineered to me, and the fact its useful new features don’t even completely work (see rust-cve) isn’t very encouraging.
I would recommend listening to Jonathan Blow’s opinion on Rust, which I tend to agree with. I personally think I’m just going to stick with C until Rust either becomes the standard, or I retire and let the next generation worry about that.
I don’t have much experience in C, but I’m not sure if bringing Rust’s ideas over to C would help.
As I understand, a lot of problems come from either that arrays are actually just pointers and if you don’t enforce it’s length for yourself then no one will, and in practice they span the entire area of process memory dorwards and backwards too. Or from that you free memory at the wrong time, or you never do that at all.
You can’t make mistakes with the first thing in Rust because the compiler takes note of the array’s length, and you just can’t abuse it as it won’t compile then. The second is a nonissue too, as memory management is automatic (kind of).
Fixing C sounds to me like patching up a sieve. That language was designed with those features in mind that make it error prone, and changing them would result in a different language. You would have to change your program anyway, and that probably wouldn’t be a small renovation. Also, you often can’t afford to not use pointers, because that’s how you pass things by reference in C, and besides passing by reference being important for performance reasons (to avoid copies) that’s the only option if so you have is a pointer to something, and when it’s stored in the heap.
The problem is that you can’t just tack Rust’s ideas onto an existing language. Generics, traits, lifetimes, borrowing, sum types, and match are key Rust features, but took considerable design time before Rust even reached 1.0. They interlock to produce a pleasant development experience. You can’t just attached them to C and call it a day.
Most of the CVE’s listed there are in unsafe code in the standard library. At some point, some code is going to have to have to implement the tricky cases. In C, this code is common place, ready for any coder to run into problems. In Rust, these are bizarre edge cases that most people would never trigger.
I haven’t heard Jonathan Blow’s take yet, but one thing a person pointed out is that he tends to prefer a style that uses a lot of shared state. Rust explicitly discourages that style, considering it a source of bugs.
I encourage you to give Rust a try. It never hurts to have another language in your arsenal. Who knows, you might even find it fun.
I’d actually say that Rust is more popular in open-source projects. The reason people like it is because it’s WAY safer than C or C++ while being literally just as fast if not faster. I’m still in the process of learning it though so I can’t speak to your other points.
It is worth mentioning that the White House recommends Rust over C/C++ due to its very notable safety advantage over classic languages.
How can Rust be faster than C? What is faster than unabstracted direct memory management?
Somehow it sounds quite weird that the white house has such a recommendation. NIST, or the NSA? That would be easier to understand because they deal with code and algorithms but the white house?
I don’t know, I’m not american, I just read the news about it.
A few hours later I have read it too, possibly the same website. Still weird.
Any bug is a skill issue. There’s literally 0.001% of programmers who are dealing with computer science problems and they are all compiler writers