There is only one language (as far as I know) in the following niche:
* compiles to native code with no GC or runtime overhead
* Facilities for high-level abstraction well beyond those offered by C
* Widely used in the mainstream.
That language is C++. If Rust becomes mainstream, it will be the second language in that set.
Thus, in my opinion, talking about the value proposition of Rust makes the most sense when comparing it to C++. I find it much easier to write and understand Rust than modern C++, and that’s what makes it valuable, for me.
Pretty much that. Safety gimmick aside, Rust is (mostly) what C++ would have been if designed with modern knowledge of programming languages theory and compiler practice in mind. It’s not like Rust brings that much novel things to the table, it is has its roots in ML and friends that have been around for decades. It’s just that we didn’t know how to make ML-type languages fast in the 80-ties. So C++ designers did the best they could given the time period and the circumstances.
For me Rust and C++ have similar complexity in terms of learning curve and the main difference is where you spend your time. Rust programs have a tendency to work on the first or second try provided you can get them to compile. In C++ it’s easier to rig something up that technically meets the portion of the language spec that the compiler enforces, but who knows if it actually does what you expect and the debug cycle is much longer. Debugging is generally more frustrating and time consuming than simply conceptually massaging your implementation strategy until it fits Rust’s model, at least for me.
* Microsoft's VS Code uses ripgrep for searching through code which is coded in Rust.
* npm is using Rust
* Cloudflare (I believe for their serverless platform)
* Figma (unsure how)
* And I'm sure countless more, hell one of my former employers is using it for mission critical work in place of C++
As you can see Rust is used by some pretty massive services, even if you don't use them, millions of people do. In fact VS Code is the most surprising to me I had no idea it was using it all along. I also believe Atom was looking into using Rust to improve performance for Atom but I'm not sure if it was just native code in place of JS / HTML.
I would argue Rust has entered the mainstream, it will be slow to be far more common, but it is getting there. I will not be surprised if we see it all snowball once there is a full feature web framework like Django or Rails but for Rust with all the batteries included. Go took a little while before it became as big as it did, and some would naively argue Go isn't mainstream, while they deploy code using docker to their kubernetes cluster (for those who missed it both of those tools are coded in Go) or what have you.
* A toolchain manager for getting different version of compiler etc
* Code generation in the language
* Build scripts in the language
* A test framework
And when I write "a test framework" or "a package manager", it's not just that it has one, but that it has one.
On the mainstream question, since I told friends and colleagues I'm learning Rust, I get a lot of statements like "I think I should learn that too, it looks like its going to take off". That is a strong signal that it has already taken off. Like once regular investors have heard of some stock (or bitcoin).
I have many colleagues who have foresworn C++ but are liking Rust (myself included).
Rust already is mainstream. It's being adopted at a very impressive rate and is running in production in innumerable places, serving billions of users.
I think you make that point better than the author.
The author talks about drills and holes, but to me, the conversation is more analogous to cordless drills versus regular electric drills - they both can do the same thing, but have different characteristics about the process of drilling the holes.
The advantage is actually pretty simple and I think this article overcomplicates it.
The Rust community considers safety violations to be the language's fault not the implementer’s fault. In C++ if you violate the language spec then you’re and idiot who just blew their foot off. In Rust the people responsible for the project take it upon themselves to make sure that nobody blows their foot off. If you happen to cause UB in safe code, the community says “oops yeah we messed up how do we fix that”. This is a huge difference and the article alludes to it but I don't think the author states it clearly enough.
Rust’s “hole problem” is that it forces developers to write safe code (conform to the language spec) up front which ultimately saves time and money. Developers are the audience and they want the best tools. Users want a hole (often as a means to an end, sure) and don’t care how it gets there; developers who make holes all day want the hole in the wall and not in their foot as frequently as possible.
This is it right here, a similar analogy this brought up was car manufacturers of old making an excuse that fatalities were the idiot drivers fault and not because of the inherent lack of safety features of the vehicle. It's too damn easy to make the wrong assumption in C & C++ and spend a painful amount of time debugging.
In my experience the added safety guarantees have made me more comfortable in "going faster" and back to vehicular terms the choice is still there to not fasten the seatbelt and go `unsafe`.
That's well and good for safe Rust, but unsafe Rust is hard as hell to audit because nobody _really_ knows what the rules are. We're kind of still figuring out how to write unsafe Rust safely. Have a look at the "too many linked lists" book, which turns out to have had a fundamental error in it for years.
I think miri is a part of the answer to this, but it is not perfect. At the end of the day, you need unsafe at some level to do anything useful, and we need more explicit rules about how to do it properly.
This is (to me) a very odd article. It creates some straw man definitions and points out that Rust doesn't hold up to them, and then gives a more accurate definition and complains that it isn't expansive enough. It concludes by pointing out that unsafe code is unsafe.
Speaking personally, Rust offers a rather nice featureful syntax (and libraries), and saves me the trouble of worrying about certain kinds of very typical mistakes.
I may want a hole, but a cordless drill with a comfortable hand grip is very likely my tool of choice. Especially thinking back to my father's corded underpowered temperamental drill with the easy to lose chuck key...
I was surprised to see that it was written by a Rust implementation insider. The first half is very meandering. Please just get to the point and leave footnotes and asterisks for things like “safe”. (Just my preference.)
> It concludes by pointing out that unsafe code is unsafe.
It spent an awful lot of time on that without making very good points.
About one paragraph of text could have pointed that reducing the surface area of unsafe code is therefore a good thing, which leads to "rewrite it in rust" which gets you more safe code.
There also seemed to be a little bit of conflation of safe code with bug-free code which just isn't possible. Arguing English semantics of words which are being used to describe very specific compiler behavior is going to be a GIGO argument.
Moreover, at some point the rubber meets the road and some "unsafe" code almost certainly must exist at that point. The goal should not be to have zero lines of unsafe code, but to have so few that it is possible to review and understand them and to understand why, though they are "unsafe", they yield safe behavior. Rust does do this!
The value proposition of Rust is that you can Rewrite Stuff in it and it's going to generally run faster, with fewer bugs, taking up less RAM and generating less heat in your processor. The rewriting part is the whole point - that's where all the fun is! I'm not sure why so many devs complain about being told to RIIR. Who doesn't want to be using state of the art tools when coding and developing their stuff? Software is eating the world anyway, so why can't Rust eat software?
I think greenfield projects in Rust make a lot of sense. However, for some existing projects, the math just doesn't check out.
I worked on Google Earth for a few years, and the core was in C++. With ASan and modern C++, memory safety bugs rarely slipped into production... perhaps once every 3-4 months, and this was a million line codebase with 20 engineers working on it.
When you consider the cost of a memory safety bug (some users get odd behavior), how rare they happen (because of our good test coverage), and that everything's sandboxed in WASM anyway, there's just not much cost to this kind of memory unsafety bug... and certainly not as much cost as a full rewrite.
RIIR makes sense for projects whose memory unsafety causes catastrophic failure. And even then, in some of those cases it makes more sense to use Java or Javascript, which don't expose unsafe operations.
RIIR makes sense if someone's doing something with extreme performance requirements, and they're okay with a tiny risk of memory unsafety (from unsafe code).
All just my opinion though, I'm sure there are many other great opinions out there.
I don't want to get paid to write code. I want to get paid to solve problems. My least favorite type of problem to solve is "how do I explain ABC solution in Language 123". I hate it even more when ABC solution is working per any metric the business cares about.
I'm not sure to how many engineers this value proposition appeals. We write software to solve problems. We get excited on new and deeper problems. Besides, a sufficiently large piece of software has tons of tangled and non-generalizable business logic that god knows who would be interested in. I can't think of a single reason for me to want to write them.
My observation is that there is a network effect happening with Rust due to the strict ownership model at API boundaries between libraries. You can call code in libraries without having to rely on your understanding of human-written documentation to get the data ownership right.
I don't think the other nice properties of Rust can explain why it's going viral when so many other fast native languages in the C family haven't. Libraries being sound internally doesn't cause a network effect, but soundness at the interfaces between libraries does. The rust ecosystem goes extremely deep in transitive dependencies, and it's not just a tree; you have many libraries that get used by many other libraries, like serde, rayon, anyhow,... and it all still manages to compile and work together almost every single time you pull some random rust project off github. You can serialize almost anything in Rust because your library authors probably include serde support for their types... because ~their dependencies did. In C++ authors are more likely to be afraid to take on an additional dependency, and roll their own little serialization thing that only works within their library. I've seen the rust ecosystem getting locked into one widespread serialization library discussed as a problem, but it's a lot better than having zero widespread serialization libraries.
This article is focusses on the safety features of Rust the language but this is not something that many developers (or me at least) considered when adopting yet another language. For me I was looking todo computer graphics with something that wasn't c++ but had similar performance characteristics and could compile to WASM.
Rust had the best language features for this and the most momentum behind it with things like wgpu and bevy. Fighting with the borrow checker and unsafe Rust is not something I do all day or every day, it is just something you live with.
> At this point, while reflecting on that topic, I decided to look more into the origins of the drill/hole adage; that diversion led me to a lovely post critiquing the adage, saying it “doesn’t go far enough.” The heart of the argument there is that people don’t want holes either. [... ]
but then TFA didn't actually go there for Rust. After laying out a great example of how the purpose of a hole is ultimately about time (and possibly frustration), the author fails to reach a similar end-goal for Rust, despite hinting at it:
> But, thinking of the drill/hole adage, I stopped and asked myself: “Who wants safety? Is it an end in itself? If it is merely a means to an end, then to what end?”
What is the true end-goal? Saving lives/money/property by avoiding errors?
> Can I just say “Rust developers spend less time debating about who is responsible when issues arise, and they spend less time figuring out how to get a performant solution into shape”?
The author sneaks in the assertion that issue attribution is the primary cost of issue resolution. I don't think this is true at all. What about actually writing & testing the patch?
If Rust has a technical approach to solving issues, then Go has a social approach. The latter is so darn simple that an intermediate Gopher can grok a codebase and contribute patches relatively quickly. Go is easy to hack; it's C with garbage collection and concurrency primitives (and an excellent ecosystem). That's why it was made!
I think Rust's primary value proposition is expressiveness. People enjoy writing Rust, because they can represent complex ideas with few LOC. Safety is a distant second. It's a language for enthusiasts, not products.
If you want language where safety is truly #1, well, Ada is going on half a century of usage in safety-critical systems including aerospace.
I find it kinda amusing that the New York Times lead reporter on cybersecurity has a book out literally called "This is How They Tell Me the World Ends" and we're on the worlds premier hacker forum pondering about the point of safety in software languages.
If you have one team of 10 people write a browser engine in C++ and another team of 10 people write the same browser engine in safe Rust (or as much safe rust as you can get away with), over a 5 year timespan you'll discover fewer UAF bugs in the Rust-written engine than the C++ one.
This is the value prop for any company deciding to use Rust. Obviously every language comes with tradeoffs, but this is concretely what people mean when they throw around the word "safety".
The author is also totally correct in pointing out how easy it is to include unsafe Rust in your code by linking unsafe crates. I think this should definitely be an area of discussion and awareness-raising on the part of developers.
> If you have one team of 10 people write a browser engine in C++ and another team of 10 people write the same browser engine in safe Rust
Has it ever been shown that it’s possible to write a full browser engine in Rust? I believe for C++ it has been proven multiple times. If I am not mistaken, Servo hasn’t been finished in 10 years.
I think Rust’s hole purpose is to be an ergonomic language that supports modern practices and generates very fast executables. Safety is a nice thing to have, but that’s just an icing on the cake for folks who need it. For me at least, a proper type system, reasonable ownership model (slices and co), modular programming are worth much more than “safety”.
> If you are interested in helping solve any of these problems, please reach out!
Coincidentally, we're working on these problems with Vale [0] by obviating the need for unsafe, while still having single ownership's performance benefits, by taking generational indices (a common Rust/C++ technique) and building them into the language itself, and by moving borrow checking to the region level instead of the object level [1].
Many PL folks are now looking into ways to generalize Rust's borrow checking approach. Even the Rust community is getting into this kind of stuff with the GhostCell proposal and its many variations. It remains to be seen how such extensions and generalizations might be adopted in a way that's reasonably intuitive and ergonomic.
Ways to figure out where the bug actually is when using systems built from different parts feels like an underexploited area.
Many things in software actually play this role, from obvious thing like unit tests through to using popular software (if it works for everyone else then it's probably your bug). If no one else uses your exact Chipset/OS/language/compiler/library (version) matrix then the bug could be anywhere.
I'm not sure it has an official academic name though. Modularity? Re-usability? Safety? Reliability? Predictability? Repeatability? Good ecosystem? There's a few things that overlap and combine.
Not sure that is the Unix philosophy but definitely the attitude of many 90s C programmers. But also we want power and safety at the same time. A smart matter drill, if you will, that will dissolve when it hits flesh. Rust currently ushers a lot of thought about safety into the coding process, while with C you can start dangerously and then fix later with Valgrind/Purify etc. fun but bad results for OpenSSL or sudo or parsers in general.
I just got into woodworking as a hobby to keep me active - physically and mentally. So, actually, I do actually want a rather nice drill. The hole it creates is a byproduct of mind, body and tool.
And on safety, what I really want is a sawstop. I'm super super careful, but uh. I really really really don't want to lose my fingers and have them sewn back on. Safety is a really good quality to have, even if it's not idiot proof, even if I can lose my fingers in so many other ways with so many other tools. I want that little bit more, anything just about to not end up in the E.R.
Interestingly, what the adage left out, is the qualities. People don't just want a hole, without qualification. They want a hole that's reliably uniform (smooth bore, sharp edge), quick and easy to produce, and cost effective.
If Rust can avoid more errors with nearly the same performance profile (and control) offered by C, it's an improvement. The Hole purpose is to be a better low level language.
> The end value provided by Rust to its developers (and thus to their customers and employers) is less time arguing linguistic minutia and less time wrestling with a managed language environment, and more time focused on what actually matters to each of those developers (be it business logic, or family time).
Hm, interesting that this boils down to a wholly unsupported claim.
Part of it isn't even coherent to me. In my experience arguing linguistic minutia has nothing to do with programming languages (or any specific domain) and everything to do with personalities and social interactions.
As for spending less time wrestling with the language environment, I suppose that very well may be true. But it may very well not be true. Here it's an assertion without anything backing it up. It certainly seems possible to me that another safe language (e.g., Javascript) may win in this area.
[+] [-] umanwizard|4 years ago|reply
* compiles to native code with no GC or runtime overhead
* Facilities for high-level abstraction well beyond those offered by C
* Widely used in the mainstream.
That language is C++. If Rust becomes mainstream, it will be the second language in that set.
Thus, in my opinion, talking about the value proposition of Rust makes the most sense when comparing it to C++. I find it much easier to write and understand Rust than modern C++, and that’s what makes it valuable, for me.
[+] [-] ribit|4 years ago|reply
[+] [-] dcow|4 years ago|reply
Also Rust is pretty mainstream at this point.
[+] [-] giancarlostoro|4 years ago|reply
* Discord replaced Go with Rust[0]
* Microsoft's VS Code uses ripgrep for searching through code which is coded in Rust.
* npm is using Rust
* Cloudflare (I believe for their serverless platform)
* Figma (unsure how)
* And I'm sure countless more, hell one of my former employers is using it for mission critical work in place of C++
As you can see Rust is used by some pretty massive services, even if you don't use them, millions of people do. In fact VS Code is the most surprising to me I had no idea it was using it all along. I also believe Atom was looking into using Rust to improve performance for Atom but I'm not sure if it was just native code in place of JS / HTML.
I would argue Rust has entered the mainstream, it will be slow to be far more common, but it is getting there. I will not be surprised if we see it all snowball once there is a full feature web framework like Django or Rails but for Rust with all the batteries included. Go took a little while before it became as big as it did, and some would naively argue Go isn't mainstream, while they deploy code using docker to their kubernetes cluster (for those who missed it both of those tools are coded in Go) or what have you.
[0]: https://discord.com/blog/why-discord-is-switching-from-go-to...
[+] [-] lowbloodsugar|4 years ago|reply
* A build system
* A package manager with powerful features
* A toolchain manager for getting different version of compiler etc
* Code generation in the language
* Build scripts in the language
* A test framework
And when I write "a test framework" or "a package manager", it's not just that it has one, but that it has one.
On the mainstream question, since I told friends and colleagues I'm learning Rust, I get a lot of statements like "I think I should learn that too, it looks like its going to take off". That is a strong signal that it has already taken off. Like once regular investors have heard of some stock (or bitcoin).
I have many colleagues who have foresworn C++ but are liking Rust (myself included).
[+] [-] zesterer|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] MR4D|4 years ago|reply
The author talks about drills and holes, but to me, the conversation is more analogous to cordless drills versus regular electric drills - they both can do the same thing, but have different characteristics about the process of drilling the holes.
[+] [-] dcow|4 years ago|reply
The Rust community considers safety violations to be the language's fault not the implementer’s fault. In C++ if you violate the language spec then you’re and idiot who just blew their foot off. In Rust the people responsible for the project take it upon themselves to make sure that nobody blows their foot off. If you happen to cause UB in safe code, the community says “oops yeah we messed up how do we fix that”. This is a huge difference and the article alludes to it but I don't think the author states it clearly enough.
Rust’s “hole problem” is that it forces developers to write safe code (conform to the language spec) up front which ultimately saves time and money. Developers are the audience and they want the best tools. Users want a hole (often as a means to an end, sure) and don’t care how it gets there; developers who make holes all day want the hole in the wall and not in their foot as frequently as possible.
[+] [-] treekogreen|4 years ago|reply
In my experience the added safety guarantees have made me more comfortable in "going faster" and back to vehicular terms the choice is still there to not fasten the seatbelt and go `unsafe`.
[+] [-] leshow|4 years ago|reply
I think miri is a part of the answer to this, but it is not perfect. At the end of the day, you need unsafe at some level to do anything useful, and we need more explicit rules about how to do it properly.
[+] [-] littlestymaar|4 years ago|reply
[+] [-] ibraheemdev|4 years ago|reply
[+] [-] dcminter|4 years ago|reply
Speaking personally, Rust offers a rather nice featureful syntax (and libraries), and saves me the trouble of worrying about certain kinds of very typical mistakes.
I may want a hole, but a cordless drill with a comfortable hand grip is very likely my tool of choice. Especially thinking back to my father's corded underpowered temperamental drill with the easy to lose chuck key...
[+] [-] avgcorrection|4 years ago|reply
[+] [-] lamontcg|4 years ago|reply
It spent an awful lot of time on that without making very good points.
About one paragraph of text could have pointed that reducing the surface area of unsafe code is therefore a good thing, which leads to "rewrite it in rust" which gets you more safe code.
There also seemed to be a little bit of conflation of safe code with bug-free code which just isn't possible. Arguing English semantics of words which are being used to describe very specific compiler behavior is going to be a GIGO argument.
[+] [-] cryptonector|4 years ago|reply
[+] [-] wussboy|4 years ago|reply
[+] [-] zozbot234|4 years ago|reply
[+] [-] verdagon|4 years ago|reply
I worked on Google Earth for a few years, and the core was in C++. With ASan and modern C++, memory safety bugs rarely slipped into production... perhaps once every 3-4 months, and this was a million line codebase with 20 engineers working on it.
When you consider the cost of a memory safety bug (some users get odd behavior), how rare they happen (because of our good test coverage), and that everything's sandboxed in WASM anyway, there's just not much cost to this kind of memory unsafety bug... and certainly not as much cost as a full rewrite.
RIIR makes sense for projects whose memory unsafety causes catastrophic failure. And even then, in some of those cases it makes more sense to use Java or Javascript, which don't expose unsafe operations.
RIIR makes sense if someone's doing something with extreme performance requirements, and they're okay with a tiny risk of memory unsafety (from unsafe code).
All just my opinion though, I'm sure there are many other great opinions out there.
[+] [-] beardedetim|4 years ago|reply
[+] [-] hintymad|4 years ago|reply
[+] [-] jpindar|4 years ago|reply
[+] [-] drewm1980|4 years ago|reply
I don't think the other nice properties of Rust can explain why it's going viral when so many other fast native languages in the C family haven't. Libraries being sound internally doesn't cause a network effect, but soundness at the interfaces between libraries does. The rust ecosystem goes extremely deep in transitive dependencies, and it's not just a tree; you have many libraries that get used by many other libraries, like serde, rayon, anyhow,... and it all still manages to compile and work together almost every single time you pull some random rust project off github. You can serialize almost anything in Rust because your library authors probably include serde support for their types... because ~their dependencies did. In C++ authors are more likely to be afraid to take on an additional dependency, and roll their own little serialization thing that only works within their library. I've seen the rust ecosystem getting locked into one widespread serialization library discussed as a problem, but it's a lot better than having zero widespread serialization libraries.
[+] [-] wrnr|4 years ago|reply
Rust had the best language features for this and the most momentum behind it with things like wgpu and bevy. Fighting with the borrow checker and unsafe Rust is not something I do all day or every day, it is just something you live with.
[+] [-] PaulDavisThe1st|4 years ago|reply
> At this point, while reflecting on that topic, I decided to look more into the origins of the drill/hole adage; that diversion led me to a lovely post critiquing the adage, saying it “doesn’t go far enough.” The heart of the argument there is that people don’t want holes either. [... ]
but then TFA didn't actually go there for Rust. After laying out a great example of how the purpose of a hole is ultimately about time (and possibly frustration), the author fails to reach a similar end-goal for Rust, despite hinting at it:
> But, thinking of the drill/hole adage, I stopped and asked myself: “Who wants safety? Is it an end in itself? If it is merely a means to an end, then to what end?”
What is the true end-goal? Saving lives/money/property by avoiding errors?
[+] [-] pphysch|4 years ago|reply
> Can I just say “Rust developers spend less time debating about who is responsible when issues arise, and they spend less time figuring out how to get a performant solution into shape”?
The author sneaks in the assertion that issue attribution is the primary cost of issue resolution. I don't think this is true at all. What about actually writing & testing the patch?
If Rust has a technical approach to solving issues, then Go has a social approach. The latter is so darn simple that an intermediate Gopher can grok a codebase and contribute patches relatively quickly. Go is easy to hack; it's C with garbage collection and concurrency primitives (and an excellent ecosystem). That's why it was made!
I think Rust's primary value proposition is expressiveness. People enjoy writing Rust, because they can represent complex ideas with few LOC. Safety is a distant second. It's a language for enthusiasts, not products.
If you want language where safety is truly #1, well, Ada is going on half a century of usage in safety-critical systems including aerospace.
[+] [-] 3pt14159|4 years ago|reply
[+] [-] Dig1t|4 years ago|reply
If you have one team of 10 people write a browser engine in C++ and another team of 10 people write the same browser engine in safe Rust (or as much safe rust as you can get away with), over a 5 year timespan you'll discover fewer UAF bugs in the Rust-written engine than the C++ one.
This is the value prop for any company deciding to use Rust. Obviously every language comes with tradeoffs, but this is concretely what people mean when they throw around the word "safety".
The author is also totally correct in pointing out how easy it is to include unsafe Rust in your code by linking unsafe crates. I think this should definitely be an area of discussion and awareness-raising on the part of developers.
[+] [-] nlitened|4 years ago|reply
Has it ever been shown that it’s possible to write a full browser engine in Rust? I believe for C++ it has been proven multiple times. If I am not mistaken, Servo hasn’t been finished in 10 years.
[+] [-] zozbot234|4 years ago|reply
It is. There is an unofficial `cargo geiger` tool that will alert you to these issues.
[+] [-] ribit|4 years ago|reply
[+] [-] verdagon|4 years ago|reply
Coincidentally, we're working on these problems with Vale [0] by obviating the need for unsafe, while still having single ownership's performance benefits, by taking generational indices (a common Rust/C++ technique) and building them into the language itself, and by moving borrow checking to the region level instead of the object level [1].
Time will tell if it works out!
[0] https://vale.dev/
[1] https://verdagon.dev/blog/seamless-fearless-structured-concu...
[+] [-] zozbot234|4 years ago|reply
[+] [-] ZeroGravitas|4 years ago|reply
Many things in software actually play this role, from obvious thing like unit tests through to using popular software (if it works for everyone else then it's probably your bug). If no one else uses your exact Chipset/OS/language/compiler/library (version) matrix then the bug could be anywhere.
I'm not sure it has an official academic name though. Modularity? Re-usability? Safety? Reliability? Predictability? Repeatability? Good ecosystem? There's a few things that overlap and combine.
[+] [-] lanstin|4 years ago|reply
Not sure that is the Unix philosophy but definitely the attitude of many 90s C programmers. But also we want power and safety at the same time. A smart matter drill, if you will, that will dissolve when it hits flesh. Rust currently ushers a lot of thought about safety into the coding process, while with C you can start dangerously and then fix later with Valgrind/Purify etc. fun but bad results for OpenSSL or sudo or parsers in general.
[+] [-] joshz404|4 years ago|reply
And on safety, what I really want is a sawstop. I'm super super careful, but uh. I really really really don't want to lose my fingers and have them sewn back on. Safety is a really good quality to have, even if it's not idiot proof, even if I can lose my fingers in so many other ways with so many other tools. I want that little bit more, anything just about to not end up in the E.R.
[+] [-] garethrowlands|4 years ago|reply
[+] [-] Supermancho|4 years ago|reply
If Rust can avoid more errors with nearly the same performance profile (and control) offered by C, it's an improvement. The Hole purpose is to be a better low level language.
[+] [-] k__|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] jmull|4 years ago|reply
Hm, interesting that this boils down to a wholly unsupported claim.
Part of it isn't even coherent to me. In my experience arguing linguistic minutia has nothing to do with programming languages (or any specific domain) and everything to do with personalities and social interactions.
As for spending less time wrestling with the language environment, I suppose that very well may be true. But it may very well not be true. Here it's an assertion without anything backing it up. It certainly seems possible to me that another safe language (e.g., Javascript) may win in this area.
[+] [-] akagusu|4 years ago|reply