I have to say, I actually disagree with most of this post. Many of these points come from Rust not being as old as C; for example, of course it won't have as many build targets, because Rust has...
I have to say, I actually disagree with most of this post. Many of these points come from Rust not being as old as C; for example, of course it won't have as many build targets, because Rust has only had a few years to support things rather than the 40 years C's head, nevermind that C was also designed very early in the computing industry, so a lot of work has gone into designing hardware specifically to optimize and work with the way C does.
I also think his argument on parallelism is flawed; parallelism is, for the moment at least, the only way that programs can continue to improve in speed. He's right, it is extraordinarily difficult; so rather than have end users try to stumble through it, creating a buggy mess that C can't check nearly as well as Rust can, doesn't it make more sense for the language designers to wrangle with it? Especially since both C and rust aim for the high-performance sector, where being able to effectively use all of the processing power that a machine has is important.
And his assertion that rewriting a program just introduces more bugs is patently false. Rust has the ability to automatically detect and flag many bugs that C can't by design. Even if you do a direct line by line translation, which is inefficient but wouldn't introduce any new bugs, Rust might catch some prexisting kinds. Rewriting a program also gives you the opportunity to reimplement or rethink a design decision that turned out to be a bad idea. For example, Firefox compeltely rewrote the backend code for managing tabs and extensions a few years ago, and in doing so, switched to a process isolation model; this greatly increases the browser's security and protection from bugs, since any errors can only crash a single tab, and not the whole browser.
And if I may, that the ability to prevent segfaults and buffer overflows, some of the most common sources of errors and security bugs, hold no value to them, while this person runs a consulting business where they apparently program device drivers, programs where a failure can potentially damage hardware, is appalling. I'm only a year 1 university student, but it's already drilled into us how important program correctness is. Failures don't just necessarily result in inconvenience, but can easily have hug financial repercussions or even endanger the safety of real people, depending on the application in question. :<
I second this, and want to add that your comment touches on something that's a more general problem in programming language development: All of the things that are being criticized about Rust,...
I second this, and want to add that your comment touches on something that's a more general problem in programming language development:
All of the things that are being criticized about Rust, that can be attributed simply to its young age, are also criticisms that get thrown upon every new language and really hamper innovation.
And I suppose that even more generally, this applies to more than just programming languages. Let's try not to criticize a new technology for failing to have decades-worth of support built up around it. It's like those entry-level jobs that require five years of experience.
This post would be better if it were titled "List of Rust Complaints". Rust isn't meant soley to replace C or C++. The people in charge have their own design goals. Besides that, you can't really...
This post would be better if it were titled "List of Rust Complaints". Rust isn't meant soley to replace C or C++. The people in charge have their own design goals. Besides that, you can't really take something as complicated as a programming language and it's ecosystem and drop-in replace it with something else. That makes this an extremely unfair comparison IMHO.
While I would say that these points are valid, I would argue that they are irrelevant for most intents and purposes. Who cares if there is only one implementation if that implementation is excellent and runs essentially anywhere you would want it? Who cares if there is no standard when you could simply run an older version of rustc when a change happens?
Except you can. That's what a lot of people did early on with C and C++. It's exactly what vlang is built to do. That's the point though. It runs in most places where you want to deploy, but it's...
Besides that, you can't really take something as complicated as a programming language and it's ecosystem and drop-in replace it with something else. That makes this an extremely unfair comparison IMHO.
Except you can. That's what a lot of people did early on with C and C++. It's exactly what vlang is built to do.
runs essentially anywhere you would want it?
That's the point though. It runs in most places where you want to deploy, but it's never going to usurp C/C++ (which is actually -- despite what you say -- the main goal of Rust, as per the proponents of Rust) since it cannot deploy most of the places where C can. C will firmly hold the embedded sector, and therefore most of the places where it would be more coherent to actually deploy Rust rather than C (Logistics, Aviation, Medicine, etc.), you can't because Rust doesn't support those platforms.
Who cares if there is no standard when you could simply run an older version of rustc when a change happens?
Until there are bugs in say, the allocator. Until those bugs are important and memory unsafe. I mean, it was only a year or two ago we heard news of a web server running on FreeBSD from before 1997, with all the included bugs from that era of software. Sure it's 'stable', but is it secure? Is it safe?
I don't think a language can declare itself to be memory safe if it doesn't have a standard and a stable ABI, given that those are pretty important semantics of defining exactly what "memory safe" means in any given context.
I think part of the point the author wants to make is that a language with the broader design goals of Rust will not be able to meaningfully displace C. I have seen some sentiment that Rust is...
Rust isn't meant soley to replace C or C++.
I think part of the point the author wants to make is that a language with the broader design goals of Rust will not be able to meaningfully displace C. I have seen some sentiment that Rust is just as capable in domains where C is widely used, though I couldn't tell you whether or not that's true in practice.
Who cares if there is no standard when you could simply run an older version of rustc when a change happens?
I could definitely see an application that is being designed for high reliability making it a point to avoid any technology without a well defined standard. If lives are on the line, it makes sense to me that you would want to work with a tool where you know as exactly as possible what it should do, even if that's not what it actually does in practice.
Yeah, I get that. I kind of regret that part of the comment. It was off the cuff and wasn't really thought out.
I could definitely see an application that is being designed for high reliability making it a point to avoid any technology without a well defined standard.
Yeah, I get that. I kind of regret that part of the comment. It was off the cuff and wasn't really thought out.
An interesting opinion piece I've found on HN. I agree with most points except for maybe their point that they “don't really care about safety”. I really think that newer languages could learn a...
An interesting opinion piece I've found on HN. I agree with most points except for maybe their point that they “don't really care about safety”. I really think that newer languages could learn a lot from Rust's rules for references and its usage of optionals and results.
https://news.ycombinator.com/item?id=19482669 Here's the other discussion. Notable sentiments (paraphrased): Rust team members disagree with the point about hostility toward other build systems...
Here's the other discussion. Notable sentiments (paraphrased):
Rust team members disagree with the point about hostility toward other build systems (and methodology the author used to arrive at his own conclusion)
People largely disagree with the author's sentiment of not caring about safety
A lot of the points in the article are explained by "Rust was released <4 years ago and C is ~45 years old" and therefore should fall under "wait and see" instead of "Rust cannot replace C because of [reason]"
Concurrency is not bad but is difficult, so using the language to wrangle it effectively is good
Just me, or is the attitude "I don't care about safety" really repulsive? Ok, alright, my homebrew data analysis pipeline for a pet project isn't really safety critical and isn't exposed much to...
Just me, or is the attitude "I don't care about safety" really repulsive? Ok, alright, my homebrew data analysis pipeline for a pet project isn't really safety critical and isn't exposed much to the webs, but if you're really looking at the kind of software written in C/++ and say "safety? meh".... keep in mind rust also enforces a lot more security through it's safety features.
Is this dude seriously saying that crashes and security breaches aren't that big a deal?
I mean, the entire article reeked of snobbery and snootiness. Especially the last paragraph. Especially the last two lines of the artice. I mean, sure, Rust is still young and is still a bit...
I mean, the entire article reeked of snobbery and snootiness. Especially the last paragraph. Especially the last two lines of the artice.
I mean, sure, Rust is still young and is still a bit immature. But the progress it had made towards concurrency and runtime safetiness is nothing to sniff at.
The way the author seems to write the article you'd think he was talking about Rust as if it was the next D Programming Language.
I think some of these complaints come from the fact that Rust is relatively new compared to C. It will have a stable ABI eventually - the addition of new features will slow down with time. But...
I think some of these complaints come from the fact that Rust is relatively new compared to C. It will have a stable ABI eventually - the addition of new features will slow down with time.
But fundamentally Rust is trying to do something different from C. So if you're used to C and good at it, then Rust can look like the wrong tool for the job.
I think that C is used in more places than it should be used, there's still a place for C - but many of the things you used to use it for could be done in rust now.
I think that C is used in more places than it should be used, there's still a place for C - but many of the things you used to use it for could be done in rust now.
I have to say, I actually disagree with most of this post. Many of these points come from Rust not being as old as C; for example, of course it won't have as many build targets, because Rust has only had a few years to support things rather than the 40 years C's head, nevermind that C was also designed very early in the computing industry, so a lot of work has gone into designing hardware specifically to optimize and work with the way C does.
I also think his argument on parallelism is flawed; parallelism is, for the moment at least, the only way that programs can continue to improve in speed. He's right, it is extraordinarily difficult; so rather than have end users try to stumble through it, creating a buggy mess that C can't check nearly as well as Rust can, doesn't it make more sense for the language designers to wrangle with it? Especially since both C and rust aim for the high-performance sector, where being able to effectively use all of the processing power that a machine has is important.
And his assertion that rewriting a program just introduces more bugs is patently false. Rust has the ability to automatically detect and flag many bugs that C can't by design. Even if you do a direct line by line translation, which is inefficient but wouldn't introduce any new bugs, Rust might catch some prexisting kinds. Rewriting a program also gives you the opportunity to reimplement or rethink a design decision that turned out to be a bad idea. For example, Firefox compeltely rewrote the backend code for managing tabs and extensions a few years ago, and in doing so, switched to a process isolation model; this greatly increases the browser's security and protection from bugs, since any errors can only crash a single tab, and not the whole browser.
And if I may, that the ability to prevent segfaults and buffer overflows, some of the most common sources of errors and security bugs, hold no value to them, while this person runs a consulting business where they apparently program device drivers, programs where a failure can potentially damage hardware, is appalling. I'm only a year 1 university student, but it's already drilled into us how important program correctness is. Failures don't just necessarily result in inconvenience, but can easily have hug financial repercussions or even endanger the safety of real people, depending on the application in question. :<
I second this, and want to add that your comment touches on something that's a more general problem in programming language development:
All of the things that are being criticized about Rust, that can be attributed simply to its young age, are also criticisms that get thrown upon every new language and really hamper innovation.
And I suppose that even more generally, this applies to more than just programming languages. Let's try not to criticize a new technology for failing to have decades-worth of support built up around it. It's like those entry-level jobs that require five years of experience.
This post would be better if it were titled "List of Rust Complaints". Rust isn't meant soley to replace C or C++. The people in charge have their own design goals. Besides that, you can't really take something as complicated as a programming language and it's ecosystem and drop-in replace it with something else. That makes this an extremely unfair comparison IMHO.
While I would say that these points are valid, I would argue that they are irrelevant for most intents and purposes. Who cares if there is only one implementation if that implementation is excellent and runs essentially anywhere you would want it? Who cares if there is no standard when you could simply run an older version of rustc when a change happens?
Except you can. That's what a lot of people did early on with C and C++. It's exactly what vlang is built to do.
That's the point though. It runs in most places where you want to deploy, but it's never going to usurp C/C++ (which is actually -- despite what you say -- the main goal of Rust, as per the proponents of Rust) since it cannot deploy most of the places where C can. C will firmly hold the embedded sector, and therefore most of the places where it would be more coherent to actually deploy Rust rather than C (Logistics, Aviation, Medicine, etc.), you can't because Rust doesn't support those platforms.
Until there are bugs in say, the allocator. Until those bugs are important and memory unsafe. I mean, it was only a year or two ago we heard news of a web server running on FreeBSD from before 1997, with all the included bugs from that era of software. Sure it's 'stable', but is it secure? Is it safe?
I don't think a language can declare itself to be memory safe if it doesn't have a standard and a stable ABI, given that those are pretty important semantics of defining exactly what "memory safe" means in any given context.
I think part of the point the author wants to make is that a language with the broader design goals of Rust will not be able to meaningfully displace C. I have seen some sentiment that Rust is just as capable in domains where C is widely used, though I couldn't tell you whether or not that's true in practice.
I could definitely see an application that is being designed for high reliability making it a point to avoid any technology without a well defined standard. If lives are on the line, it makes sense to me that you would want to work with a tool where you know as exactly as possible what it should do, even if that's not what it actually does in practice.
Yeah, I get that. I kind of regret that part of the comment. It was off the cuff and wasn't really thought out.
An interesting opinion piece I've found on HN. I agree with most points except for maybe their point that they “don't really care about safety”. I really think that newer languages could learn a lot from Rust's rules for references and its usage of optionals and results.
https://news.ycombinator.com/item?id=19482669
Here's the other discussion. Notable sentiments (paraphrased):
Just me, or is the attitude "I don't care about safety" really repulsive? Ok, alright, my homebrew data analysis pipeline for a pet project isn't really safety critical and isn't exposed much to the webs, but if you're really looking at the kind of software written in C/++ and say "safety? meh".... keep in mind rust also enforces a lot more security through it's safety features.
Is this dude seriously saying that crashes and security breaches aren't that big a deal?
I mean, the entire article reeked of snobbery and snootiness. Especially the last paragraph. Especially the last two lines of the artice.
I mean, sure, Rust is still young and is still a bit immature. But the progress it had made towards concurrency and runtime safetiness is nothing to sniff at.
The way the author seems to write the article you'd think he was talking about Rust as if it was the next D Programming Language.
I think some of these complaints come from the fact that Rust is relatively new compared to C. It will have a stable ABI eventually - the addition of new features will slow down with time.
But fundamentally Rust is trying to do something different from C. So if you're used to C and good at it, then Rust can look like the wrong tool for the job.
I think that C is used in more places than it should be used, there's still a place for C - but many of the things you used to use it for could be done in rust now.