Wired Hails Rust as 'the Viral Secure Programming Language That's Taking Over Tech' (wired.com) 126
A new article from Wired calls Rust "the 'viral' secure programming language that's taking over tech."
"Rust makes it impossible to introduce some of the most common security vulnerabilities. And its adoption can't come soon enough...." [A] growing movement to write software in a language called Rust is gaining momentum because the code is goof-proof in an important way. By design, developers can't accidentally create the most common types of exploitable security vulnerabilities when they're coding in Rust, a distinction that could make a huge difference in the daily patch parade and ultimately the world's baseline cybersecurity....
[B]ecause Rust produces more secure code [than C] and, crucially, doesn't worsen performance to do it, the language has been steadily gaining adherents and now is at a turning point. Microsoft, Google, and Amazon Web Services have all been utilizing Rust since 2019, and the three companies formed the nonprofit Rust Foundation with Mozilla and Huawei in 2020 to sustain and grow the language. And after a couple of years of intensive work, the Linux kernel took its first steps last month to implement Rust support. "It's going viral as a language," says Dave Kleidermacher, vice president of engineering for Android security and privacy. "We've been investing in Rust on Android and across Google, and so many engineers are like, 'How do I start doing this? This is great'...."
By writing new software in Rust instead, even amateur programmers can be confident that they haven't introduced any memory-safety bugs into their code.... These types of vulnerabilities aren't just esoteric software bugs. Research and auditing have repeatedly found that they make up the majority of all software vulnerabilities. So while you can still make mistakes and create security flaws while programming in Rust, the opportunity to eliminate memory-safety vulnerabilities is significant....
"Yes, it's a lot of work, it will be a lot of work, but the tech industry has how many trillions of dollars, plus how many talented programmers? We have the resources," says Josh Aas, executive director of the Internet Security Research Group, which runs the memory-safety initiative Prossimo as well as the free certificate authority Let's Encrypt. "Problems that are merely a lot of work are great."
Here's how Dan Lorenc, CEO of the software supply-chain security company Chainguard, explains it to Wired. "Over the decades that people have been writing code in memory-unsafe languages, we've tried to improve and build better tooling and teach people how to not make these mistakes, but there are just limits to how much telling people to try harder can actually work.
"So you need a new technology that just makes that entire class of vulnerabilities impossible, and that's what Rust is finally bringing to the table."
"Rust makes it impossible to introduce some of the most common security vulnerabilities. And its adoption can't come soon enough...." [A] growing movement to write software in a language called Rust is gaining momentum because the code is goof-proof in an important way. By design, developers can't accidentally create the most common types of exploitable security vulnerabilities when they're coding in Rust, a distinction that could make a huge difference in the daily patch parade and ultimately the world's baseline cybersecurity....
[B]ecause Rust produces more secure code [than C] and, crucially, doesn't worsen performance to do it, the language has been steadily gaining adherents and now is at a turning point. Microsoft, Google, and Amazon Web Services have all been utilizing Rust since 2019, and the three companies formed the nonprofit Rust Foundation with Mozilla and Huawei in 2020 to sustain and grow the language. And after a couple of years of intensive work, the Linux kernel took its first steps last month to implement Rust support. "It's going viral as a language," says Dave Kleidermacher, vice president of engineering for Android security and privacy. "We've been investing in Rust on Android and across Google, and so many engineers are like, 'How do I start doing this? This is great'...."
By writing new software in Rust instead, even amateur programmers can be confident that they haven't introduced any memory-safety bugs into their code.... These types of vulnerabilities aren't just esoteric software bugs. Research and auditing have repeatedly found that they make up the majority of all software vulnerabilities. So while you can still make mistakes and create security flaws while programming in Rust, the opportunity to eliminate memory-safety vulnerabilities is significant....
"Yes, it's a lot of work, it will be a lot of work, but the tech industry has how many trillions of dollars, plus how many talented programmers? We have the resources," says Josh Aas, executive director of the Internet Security Research Group, which runs the memory-safety initiative Prossimo as well as the free certificate authority Let's Encrypt. "Problems that are merely a lot of work are great."
Here's how Dan Lorenc, CEO of the software supply-chain security company Chainguard, explains it to Wired. "Over the decades that people have been writing code in memory-unsafe languages, we've tried to improve and build better tooling and teach people how to not make these mistakes, but there are just limits to how much telling people to try harder can actually work.
"So you need a new technology that just makes that entire class of vulnerabilities impossible, and that's what Rust is finally bringing to the table."
Taking over what?? (Score:5, Insightful)
If Rust is so popular, why does it only have 0.70% popularity score in TIOBE index?
https://www.tiobe.com/tiobe-in... [tiobe.com]
Re:Taking over what?? (Score:5, Funny)
are you maybe suggesting that a senior writer for "wired" is writing sensationalist nonsense on "wired" and is paying slashdot for a little bit of promo?
how disgusting! have some respect! people have a right to make a living!
TIOBE is measuring the wrong thing (Score:4, Insightful)
The thing that rust is really really really good at, is "become popular". Mostly with people who don't use it themselves.
But you have to hand it to them, they're really quite very good at making headlines.
Re:Taking over what?? (Score:5, Insightful)
If Rust is so popular, why does it only have 0.70% popularity score in TIOBE index?
https://www.tiobe.com/tiobe-in... [tiobe.com]
This happens because most of programming, despite what everyone tells you, is actually maintaining existing code. Note, for example that "classic visual basic", effectively a dead language ("Extended support ended in March 2008") is still in the top 20. That means that languages like Ruby, that nobody in their right mind writes new code in, will still be in there for years and years because they had a brief flash of popularity around the dot-com boom and important systems got written in them. PHP is a similar story that got so popular that major companies actually paid to fix the problems with the language.
The fact that Rust is at the bottom of that table of top languages and visibly rising is pretty good for it. Languages to worry about are things like Go which has been mega-fashionable recently but is already going down.
Re: (Score:2)
because most of programming, despite what everyone tells you, is actually maintaining or copypasting existing code.
ftfy, otherwise spot on!
Re: Taking over what?? (Score:4, Insightful)
Kind of tired of this popularity contest crap. Nobody uses X, everybody should use Y.
It's not why any of us started started using OSS, and it's not good for it.
Re: (Score:2)
Kind of tired of this popularity contest crap.
For programming languages, popularity matters.
A popular language will have plenty of libraries, packages, frameworks, example code, tutorials, and proficient programmers. An unpopular language ... won't.
These things are way more important than syntax.
Re: Taking over what?? (Score:4, Interesting)
In an ideal world where everyones a one man band programmer, didnt have to maintain code, or share responsibilities with others, nor worry about business continuity it wouldn't matter.
Alas, we are doomed to live in a world with other people. And because of that we have to remember that the primary purpose of any language is to communicate from AND to a language user. Even if primary purpose of a programming language is to communicate to a machine, its being written by a human, conditioned by 100K+ years of language evolution, and importantly will often be read by a human.
The ideal language for programming a computer if we didnt have to deal with human programmers would probably just be machine code. Probably even machine microcode. But we're a long way from removing humans from that equasion.
So considering we are for now stuck with humans writing it and humans reading it (Maintainance, code review, collaboration, etc) we are in a situation where we want A) An ideal language that most closely matches our own cognitive quirks, so far few if any match that, we tried with 4GLs , OOP, Functional, etc but none really have proven to be both maximally intuitive and productive, and B) maximizes the labor pool, to reduce the expenditure involved with finding ideal readers of code.
For that labor pool to be maximized we are stuck with the popularity contest. Unfortunately not all the decisions the crowd runs with are good ones. I'm personally pretty sick of the constant buzz word hype-cycle that causes us to throw away genuinely good ideas (Relational databases) only to scramble later to reinvent them when we are suddenly confronted with the original problems that good idea was invented to resolve in the first place, or are so dumbed down (javascript) that we end up with giant balls of complexity just to make the dumb idea smart again (Typescript, giant build chains, etc).
My favorite language is something called "Crystal", it basically takes Ruby, adds a superb boxed type system with compile time static analysis to give it a rust level degree type safety and compiles to around GO performance (Fast compiled, but garbage collected).
But despite this being almost my perfect language I've never met IRL another coder that uses it. Its seriously on the fringe, great for one offs and personal projects, but sadly useless for workplace stuff because it would be almost impossible to hire someone local who knows the damn thing.
This is why, much to my despair, we STILL see places advertising PHP for NEW projects. Nobody wants to code that cursed language anymore, but almost any coder over 30 knows that catastrophic system.
We might not like it. But it is , as the military puts it, the facts on the ground.
Re:Taking over what?? (Score:4, Insightful)
Ruby, that nobody in their right mind writes new code in,
I do. It's a way better language than Python. The APIs for time are really nice.
Re: (Score:2)
The APIs for time are really nice.
Is there a missing "the" in that sentence? The APIs for getting the time are the ones that you judge a language by?
Re: (Score:2)
It's just one of the many nice things in the language. And no, there was no missing "the". Getting time, converting time, figuring out the timezone, etc. Easy.
Re: (Score:2)
Okay, that makes sense. Ruby is definitely a "powerful" language. With macros and all the functional programming tools and so on it should be possible to make really wonderful programming interfaces in clever ways. In my experience the problem comes when all sorts of different clever things start combining and one bit of code starts monkey patching another to repair bugs in a third and so on and so forth.
Re: (Score:2)
*shrug*
Good programmers write good code in any language, bad programmers write bad code in every language.
Re: (Score:2)
*shrug*
Good programmers write good code in any language, bad programmers write bad code in every language.
That's true to the extent that it's also a cliche, but the quality of the standard libraries and the normal add on libraries is critical and not under your control once the language is chosen. One of the signs of a good developer is that they choose underpinnings for their code that can be trusted.
Re: (Score:2)
You said:
In my experience the problem comes when all sorts of different clever things start combining and one bit of code starts monkey patching another to repair bugs in a third and so on and so forth.
OK, well don't do that. It's your problem.
Re: (Score:2)
That means that languages like Ruby, that nobody in their right mind writes new code in,
Actually, I wrote some code in Ruby this year. I needed something to pull something from a sensor and dump it into a database. I didn't want to go overboard with C/Java/etc. I was going to use PHP, but PHP doesn't guarantee multithreading support on the runtime. (It's enabled by default for Windows releases, but virtually all PHP Linux packages that I've seen have multithreading support disabled at build time. Even for php-cli.) Ruby was something I was wanting to try, and because it does have multithreadi
Re: (Score:2)
TL;DR: Don't assume that your poor opinion of a given language is held by everyone.
I never said that and I don't assume that. The problem with Ruby is not the language itself; one problem is particularly that the greatest application of Ruby is Rails. The other problem with Ruby is the whole community's "clever is better" attitude. This means that, as you get further into Ruby and its libraries you will get more and more convoluted mess. You'll note that both of the defenders of Ruby here are talking about how they had success with tiny tiny projects rather than anything approaching serio
Re: (Score:2)
Re: (Score:2)
Column 4 in the TIOBE list that the original commenter in this thread linked to.
Re: (Score:2)
Re: (Score:2)
I'd rather compare book sales than the metrics that TIOBE uses. Which ever language makes the highest revenue in book sales per year is the most commercially popular language. Because for most people, if they're not willing to pay to learn a language then it's probably regarded as a toy.
Re: (Score:3)
I'd rather compare book sales than the metrics that TIOBE uses.
People still buy programming books? How quaint. Most people I know use the Information Superhighway.
Re: (Score:2)
That's cute, grandpa. Over here we're using web3.0, now with blockchain. /s
Re: (Score:3)
> People still buy programming books? How quaint. Most people I know use the Information Superhighway.
There is good reason to buy books. A lot more effort has gone into their creation compared to random posts on stackoverflow. A book can easily teach you the most important concepts for a certain problem, and in much greater detail than an single article. It also bundles multiple pieces of information in a consistent style.
Sure, you can just google "graph theory" and read whatever comes up, but I'd rather
Re: (Score:2)
I'd rather compare book sales than the metrics that TIOBE uses.
Simple and elegant languages don't need books. More complex languages do.
I don't need a book to write C or Go.
I can't imagine writing Perl without my dog-eared O'Reilly book on my desk.
Re: (Score:2)
I wasn't there when Wall made his design decisions, but I'm guessing it went like "whatever it takes to make a function fit in 80 characters on my VT". That said, it's a pretty safe bet you'll find it on pretty much every piece of non-Windows hardware in existence, so it's a good language to be familiar with, even though deciphering someone else's Perl is in no way guaranteed.
Re: Taking over what?? (Score:2)
Questionable metric.
What if a langue is so easy to use and so well documented online you don't need a book to learn it?
Re: (Score:2)
I'm not too worried that such an example will appear to destroy my argument. ;-)
Re: (Score:2)
Simple: Because it is 99.3% hype and 0.70% actual advantages. These 0.70% also go away with modern compilers and testing techniques. And if you look at the security critical bugs routinely produced using languages _with_ memory safety, you realize the problem is too many dumb coders and not the tools used.
Re: (Score:3)
https://stackoverflow.com/ques... [stackoverflow.com]
According to "studies" the rate of bugs correlates with the lines of code written, more than the language. So the key would be to create well maintained libraries and simple functions that result in less code.
Re:Taking over what?? (Score:4, Insightful)
Now, what would really be interesting is to correlate this with the ones that wrote the code. My take is still that the only real problem we have is far too many incompetents writing code. In my own stuff, I have never found a higher incidence or severity of bugs in C code (some of it having undergone pretty thorough source-code review) and other code on, say, Python or Perl. But here is the thing: I am careful when writing code and I think about what could go wrong all the time and I am an IT security expert. I _know_ what I am doing most of the time and I can recognize when I am not competent to do something and then I can fix that by getting competent.
With what I see in security-critical coding errors, it seems to be universally people that barely understood what they are doing and being unaware of it. People that write SUID code and never have heard of complete input validation. People that set defaults on secure random number generators without ever consulting the documentation. People that write buffer access code but never test the border cases. People that assume ranges for input values but never make sure the values are in that range. People that free memory but do not invalidate the pointer to it. And so on. And none of that is a language problem. These people will just make other dumb mistakes if they have a memory-safe language. They will make other dumb mistakes if race conditions are not possible in a language. They will screw it up and no amount of tooling will ever help. And _that_ is the real problem.
Re: (Score:2)
My take is still that the only real problem we have is far too many incompetents writing code
It's not even that they're incompetent, it's that they don't even care. An incompetent person can quickly learn (after all, I was also an incompetent until I started learning from my mistakes), but a person who doesn't care will repeatedly make the same mistakes over, and over, and over. The main thing is to find people who seriously try to avoid security bugs.
Re: (Score:2)
Well, yes. People that perform any craft but do not care about good outcome will mess it up. You are also quite correct that a person that does care will not stay incompetent for long. On the other hand, these people that are and stay incompetent have jobs in some way that they keep despite being and staying incompetent.
Re: (Score:2)
In my own stuff, I have never found a higher incidence or severity of bugs in C code
People are notoriously bad at identifying their own mistakes. It's why it is difficult to pick up your own spelling or grammar mistakes, and why people type a number in incorrectly and don't notice it while double checking.
Mind you I always suspected you weren't human, so we can add this comment to the evidence pile ;-)
Re: (Score:2)
You seem to have missed the part were some of that C code went trough a security review....
Rust or Go (Score:3)
Which one is Google supporting, Rust or Go?
Re:Rust or Go (Score:5, Interesting)
Re:Rust or Go (Score:4, Informative)
Which one is Google supporting, Rust or Go?
Why not both? They target different use cases.
Re:Rust or Go (Score:5, Informative)
The main thing I don't like about Go is it feels like it forces you into anti-patterns. For example, no enums. Why, google? Just why?
Rust, at least in my experience, is so much easier to work with. You have a much broader range of coding patterns available to you, meaning you're more likely able to use just the right pattern for your situation. Take asyncronous programming for example, this is SOOOO much easier in Rust. And yeah, I get the argument for the right tool for the job and all of that, but one thing that Golang enthusiasts like to sell you on is the idea that Go is such a great language for both concurrent and parallel programming because it's built into the language and all of that. So if that's true, then why does golang make async so god damned difficult?
And the tooling -- Rust is miles and miles ahead of what Go has. Another language with good tooling is C#, so it's not as if there's something special about Rust that enables better tooling. And Golang is older than Rust, so it's not as if they haven't had time to figure it out.
The only hard thing about Rust is it takes maybe a month or so before you finally reach that "eureka!" moment when you intuitively understand the borrow checker. But once you do, your thought patterns for coding tend to improve dramatically. Basically, without even much effort at all, you intuitively plan your program as you're writing it so that you don't run into problems with the borrow checker. Planning on where your memory values will live and what they'll do just becomes second nature. And then, without realizing it, you carry that mindset into other programming languages. It turns out that, when you always have ownership on your mind in even languages like Java where ownership doesn't matter, your code ends up being less buggy and easier to read.
Re: (Score:3)
one thing that Golang enthusiasts like to sell you on is the idea that Go is such a great language for both concurrent and parallel programming because it's built into the language and all of that. So if that's true, then why does golang make async so god damned difficult?
Because you're using crappy old patterns you've used for decades instead of being willing to learn new ones. The pain you are feeling is the pain of being unwilling to learn.
Re: Rust or Go (Score:2)
There are way better ways to deal with async than channels. Google decided to exclude them from the language for the same reason that go doesn't have enums. They're trying to keep the language simple by moving the complexity somewhere else, and the net result is more complexity.
Re: (Score:2)
The pain you are feeling is the pain of being unwilling to learn.
While this is generally a bad thing, people often get so hung up on people's unwillingness to change that they forget to actually provide a justification for the change.
Someone needs to be convinced why they should unlearn something, and to do that it needs to make a material difference to *them*, otherwise it gets decried as change-for-change's-sake.
Re: (Score:2)
True point.
Without understanding more about that person's threading approach, it's hard to give more concrete advice, though. What is certain is that Go's asynchronous programming model is perfectly acceptable, so he must not be seeing something correctly. Not sure what.
Re: Rust or Go (Score:2)
*The only hard thing about Rust is it takes maybe a month or so before you finally reach that "eureka!" moment when you intuitively understand the borrow checker.*
Wish you guys who get that would write some articles on it, *intuitively* understanding the borrow checker. When I was trying to learn Rust it was pure voodoo to make the compiler happy sometimes due to ownership and borrowing issues. Worse was the somewhat silent culture, where it felt impossible to get a top level explanation.
Re: Rust or Go (Score:2)
When Google gives their endorsement, itâ(TM)s the kiss of death. Go, Rust, Dart, Carbonâ¦seriously,â¦soon at least two, if not three will go the way of most Google projects.
Re: Rust or Go (Score:2)
Go, Dart and Carbon are Google projects. Rust is not. In fact one of those, Carbon, is basically a Rust which solves the NIH problem.
Re: Rust or Go (Score:5, Interesting)
That said, Google uses Go for microservices and continues to invest in Rust for new embedded and high performance niches.
Re: Rust or Go (Score:2)
Carbon doesn't solve the problems that Rust aims to solve. See:
https://github.com/carbon-lang... [github.com]
TL;DR: C++ is a shit show, and C++ has obsolete/broken code patterns that don't mesh well with Rust due to Rust being more strict. Carbon is meant to help existing C++ code. Use rust if you're working on something new and you can use RPC to talk to legacy C++ code.
And they're right. Rust integrates very easily with C code, but integrating with C++ is super annoying, particularly when you need to call C++ code tha
Re: (Score:2)
Go's dev team routinely deny feature requests. Even if Google threw their entire weight behind Go it wouldn't be able to take over out of its own technical deficits. Practically speaking Go tries to solve some particular requirements to deployment and shared concurrent data structures and intentionally ignores use cases too far outside of its problem domain. Go is a general purpose multi-paradigm language that is not treated by such by its core dev team. Moving forward we'll probably only see stuff like Kub
The eternal argument (Score:3, Funny)
I bakery conversation 2022:
Baker: I have a new way to make sliced bread! We should eat this now!
Dev: Wait! This bread isn't quite baked yet, it tastes like dough! The slices aren't that easy to handle! Wait! aren't you the guy who sold me that Ada-flavored bread years ago!?!
Baker: Don't worry, if you leave it in the sun it'll finish baking. It just takes time! Ada bread? Never heard of it.
Dev: But, I have this other bread over here, it's already baked, tastes really good, and the slices are perfect. I can get it in different flavors from different bakers too!
Baker: Those other bakers don't know what they're doing! They're all wrong, this new bread will revolutionize the entire industry! It's even carbon-neutral!
Cobol Guy: I'll just keep eating these moldy crackers.
Re: (Score:2)
Cobol Guy: I'll just keep eating these moldy crackers.
fun, but COBOL hardly has the expressiveness necessary to even willingly write a memory leak or buffer overrun (unless one is already deeply buried in its C implementation). it's a glorified report generator, ffs.
Re:The eternal argument (Score:5, Interesting)
Actually, for glorified report generators, see RPG [programmers.io] which was literally for doing just that. I'm not defending COBOL but there's a lot of it out there and you'd be surprised how much there is. It was also one of the first HLAs so respect your elders. I also hear if you say COBOL three times the ghost of Grace Hopper [britannica.com] will appear in your bathroom mirror, try it.
Re: (Score:2)
i know, i know! i used both back in the day, and we had lots of fun implementing conway's life (on band printers!) or even a rudimentary chess, such was the boredom! :-D and yes, definitely COBOL is much more expressive than RPG but both are limited to the same very narrow scope and the same data structures and operations, so i see them as largely equivalent even though having radically different interfaces.
Re: (Score:2)
Re: (Score:2)
made of grapes from New Jersey.
Re: (Score:2)
IBM is New York - UNIX is New Jersey.
Re: (Score:2)
Who'd buy grapes from New York?!?
yawn.....lots of work on language vulnerabilities (Score:2)
There's a series of ISO reports that detail vulnerabilities in various programming languages, https://www.iso.org/standard/8... [iso.org] Ada83 prevented a lot of those problems literally 40 years ago.
The more telling question, in my mind, is why do we continue to use languages such as C that have major known problems? One argument is "training cost", that companies are not willing to invest in staff learning better programming languages and in tools that implement (compilers, analyzers, proof checkers, etc) better
Re: (Score:2)
such as C that have major known problems
Disclaimer: I've written a lot of C/C++ over the years.
Laziness and real estate. Most of the low-level work in C I've had to do in the past 10 years is "hurry, we need this product out the door" and the SDK's I'm dealing with are C. Hell, it wasn't that long ago Microsoft was pushing C in their CE editions of Windows which are thankfully gone and buried.
Re: (Score:2)
it wasn't that long ago Microsoft was pushing C in their CE editions of Windows which are thankfully gone and buried.
I looked it up because it sounded too good to be true, and "extended support will end in October 10, 2023" ... so it may be dead, but it yet shambles for almost another whole year.
Re: (Score:2)
Zombies are a thing at Microsoft.
Re: (Score:3)
I have some background in writing numerical software (for bigger computers) and firmware for embedded systems, but my day job is lately more focused on electronics hardware at a company that makes consumer products. I'm not sure if this is legally required or not, but we at least have a company policy of getting our products recognized by the standards agencies (UL, IEC, CQC, etc.) relevant to the target markets where our products are sold. These agencies evaluate the construction of the products for safe
Re:yawn.....lots of work on language vulnerabiliti (Score:4, Interesting)
I heard a Boeing talk at a safety-critical software conference maybe 25 years ago. To summarize, "Boeing has done a lot of critical avionics software in a lot of different languages. It takes the same amount of time to code in most languages per our coding standards, etc. Ada(83) costs us about 25% more in coding. BUT Ada verification occurs in something like 1/4 of the time as other programming languages. And most of the cost in an avionics software system is in verification, not development." (The numbers might be a bit off, but the differences were -significant- and -obvious-.)
Re:yawn.....lots of work on language vulnerabiliti (Score:5, Interesting)
I learned programming in Pascal which was a predecessor to ADA. I went from that to C, shortly around the time that school CS courses switched off pascal in favor of Java in the late 90s.
All OS and system level code is in C, embedded code is always in C, pretty much my entire professional world of code is in C and occasionally C++. Nobody is likely to change that. It's not lack of training, we can pick up new languages fast. It's time, money, lack of qualified people who understand OS arcana, HW arcana, 50 years of tribal knowledge and practice. All to create a totally redundant code-base, rewrite it in Today's Hot Thing, debug it, establish its fidelity to the existing C stack and then convince customers they want it. All because Today's Hot Thing solves some known security issues, but hasn't had half a century of trial-by-fire and probably has some issues on its own.
It doesn't make sense. Likely some greenfield effort using Today's Hot Thing will arise and things may gradually shift. But continuously trying to push it into established code has been a 10 year running joke of the "Is this the year of the Linux Desktop" variety.
Re: (Score:2)
The more telling question, in my mind, is why do we continue to use languages such as C that have major known problems?
Because C is elegant. C++ is not.
The world is object-oriented (Score:3)
Rust will never gain signficant popularity unless it adds support for fully object-oriented programming, including inheritance. Structs, traits and impl are confusing at best and described as a way to mimic classes, but they don't provide the same functionality.
Re: The world is object-oriented (Score:5, Informative)
You lost me at "Huawei" (Score:2, Informative)
Sorry, but I have serious doubts about any system that Huawei wants to be involved in at a low level.
Re: (Score:2)
Please expand on your doubts.
Someday (Score:2)
Re: (Score:2)
Indeed. But that day is not today.
Mixed feelings... (Score:3)
On the one hand, I'm not 100% confident, as Go was receiving this much fawning praise and popularity of it seems to have plateaued out at a far lower level than folks thought. So not sure if Rust will similarly stall out.
On the other hand, I'm glad to see the new excitement swing back to compiling executable applications and be able to both use and provide C-compatible symbols, rather than managed runtimes/interpreters.
Re: (Score:2)
On the one hand, I'm not 100% confident, as Go was receiving this much fawning praise and popularity of it seems to have plateaued out at a far lower level than folks thought.
This plateau is the fault of the developers that work on Go at Google.
They refuse to give non-Google developers what they desperately need, such as access to goroutine ID, so that logging and debugging complex systems becomes 100x easier.
The reason? "Goroutines are supposed to be anonymous. If we give people access to the goroutine ID, they'll abuse it."
Go is a hopeless cause at this point. <sigh>
Re: (Score:2)
I used goroutine ID in my go logging because it was absolutely essential to figure out what was going on, though I had to use runtime.Stack() (I just copypasted some code I found that was doing it). I always thought that was an oversight and they'd be providing the ID anytime soon. Apparently not.
The truth (Score:5, Interesting)
My overall opinion: Rust is worthwhile to learn and will be a very useful addition to your toolbox, and may reduce the amount of C/C++ you write, but don't expect it to replace all of it. If you absolutely must write a *ton* of unsafe code, I recommend doing it in C++ and linking it against your Rust application. Rust's memory model is too strict and makes writing unsafe rather dangerous if you're not extremely careful, namely anywhere pointers and references touch each other, and you can't turn off those optimizations, so it's a bit like playing Russian roulette, except whether the gun is loaded at all is completely unpredictable. You get subtle heisenbugs if you violate Rust's aliasing model with unsafe code.
For most use-cases, you will actually save time by writing it in Rust most of the time, but only once you learn the language nuances. Rust is not a language you can pick up in a weekend. To fully understand it, you will need time, at least a few months of sporadic study. It's actually harder than C++, but once you know it, it has a lot of features that make life easier.
Don't underestimate the usefulness of stuff like Rust's algebraic enums, its extensive support of iterators, or the value of crates.io for battle-tested implementations of stuff like ring buffers to save you time.
I don't know if Rust will fully replace C++. I doubt it. But I do think that Rust is here to stay for the foreseeable future, and I do think it's worth your time to learn.
The usual bullshit (Score:2)
If the security gains of not being able to have buffer overflows were so great, we would not have the mass of vulnerabilities in PHP, JavaScript, Java, etc. On the other hand, things like the Linux Kernel would not even work. But that is very much _not_ the situation we have.
Certain classes of vulnerabilities (Score:3)
Perhaps Rust eliminates or reduces certain classes of vulnerabilities, such as memory protection. That's good. But every language will always have vulnerabilities. If something can be used for good, it can also be used for evil.
Re: (Score:2)
Re: (Score:3)
Of course, it is a good thing to eliminate a particular class of vulnerabilities. Your example of memory protection is a good one. But it doesn't protect against a Row Hammer attack https://en.wikipedia.org/wiki/... [wikipedia.org] or man-in-the-middle or phishing or countless other issues. It would be wise for Rust developers not to become complacent about security, just because the language automatically protects against certain kinds.
The big problem with Rust (and Go) is... (Score:2)
... that they have automatic dependency management. That means it's easy to add dependencies which means that people will do so without thinking.
This means that programs will become unnecessarily big, which increases their attack surface.
lol (Score:2)
>By writing new software in Rust instead, even amateur programmers can be confident that they haven't introduced any memory-safety bugs into their code
That made me laugh out loud.
Well crap (Score:4, Funny)
Sorry guys time to learn a new programming language. Can the last ones out turn off the lights?
Re: (Score:2)
Rust : The all new Java that will replace everythi (Score:2)
ng and wil bring world peace at the same time.
I think I have been there about 4 times now since I started programming.
Maintainability remains a concern (Score:2)
C is quite readable. C++ less so. Rust...? I'd wager that compilers are happier about it than human beings.
It wouldn't have killed the authors to focus on readability alongside performance, but I guess this has to do with the culture of people who are attracted to Rust.
Typical Wired Reporting (Score:2)
Usually there is some truth to the premise, and nothing necessarily false in their reporting, but the exaggerated conclusions cannot plausibly be supported. Plus, in a year, or two, or ten, when such-and-such trend has failed to go anywher
Zig is worth watching (Score:3)
I've been spending time on rust for the last 6 months to a year and it's not an easy language to pick up. Zig is an upcoming language that's worth watching. It has great C interoperability (in either direction) and while it doesn't have all the memory safety features that rust has, it's much easier to learn and has significantly saner memory safety features than C/C++. At least I found it much easier to learn.
http://ziglang.org/ [ziglang.org]
Re:Say what? (Score:5, Interesting)
[B]ecause Rust produces more secure code [than C] and, crucially, doesn't worsen performance to do it...
You wrote,
And neither has any other language in the last 30 years...
Do any of these more modern languages that provide memory safety guarantees do so while compiling to machine code and without the performance / latency hit of a garbage collector?
I'm really only familiar with C / C++ / Fortran, so I don't know the answer and am honestly asking.
At a previous job, I wrote some C++ utility programs that only used the STL containers and objects in a linear algebra package for data storage. Valgrind ran and said "no memory leaks possible". I had read somewhere that avoiding pointers and using the containers was a good practice, and it worked well. As a C++ acolyte, I'm also contractually obligated to mention RAII in the context of this discussion.
Re:Say what? (Score:4, Interesting)
At a previous job, I wrote some C++ utility programs that only used the STL containers and objects in a linear algebra package for data storage. Valgrind ran and said "no memory leaks possible". I had read somewhere that avoiding pointers and using the containers was a good practice, and it worked well.
Yep, to a large extent you can think of Rust as a clean re-implementation of all of the best ideas from Modern C++, with better compiler support. So what you were able to do by carefully restricting yourself to a small subset of C++ you can achieve in Rust by simply never using the "unsafe" keyword. Most C++ programmers who write a non-trivial amount of Rust code quickly become converts.
Re: (Score:2)
Arguably Rust is not clean, but point taken.
Re: (Score:3)
> Something is very broken where you work.
This could be the motto of almost every company once you grow past the initial startup group.
Re: (Score:3)
Using better tools is a lot cheaper than hiring perfect people.
Re:Say what? (Score:4, Informative)
Yea, no kidding. Write something in Lisp, ML, or SmallTalk and memory safety bugs are not a problem there either. Those examples are roughly 60, 50, and 40 years old respectively. We've had the technology for a very long time, we chose not to use it when we picked up and used C/C++ in almost everything for the past 40-50 years.
Re:Say what? (Score:4, Informative)
Re: (Score:2)
And on the other side of the coin, amateur coders make a _lot_ of security critical mistakes entirely without needing unsafe memory. With Rust, you can apparently have even less competent coders to produce code on the present level of security, that seems to be the only advantage. Because the actual problem is not the languages used, it is the incompetent people used.
Re: (Score:2)
That just might be its greatest security feature.
Re: (Score:2)
Urgh. And there I was almost convinced that I should look at it after all....
You do have a point though.
Re: (Score:2)
Re: (Score:2)
Nonsense. Guns are basically tools designed for random idiots. Ever seen a "safety" on a Chef's knife?
Re: (Score:2)
I mean it is as good as it can be but: "Rust makes it impossible to introduce some of the most common security vulnerabilities."..........
Go ahead and try it for yourself: see if you can deliberately write a Rust program that contains a buffer-overrun error, or a use-after-free error. (without using the "unsafe" keyword, I mean :) )