Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming

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."
This discussion has been archived. No new comments can be posted.

Wired Hails Rust as 'the Viral Secure Programming Language That's Taking Over Tech'

Comments Filter:
  • Taking over what?? (Score:5, Insightful)

    by devslash0 ( 4203435 ) on Sunday November 06, 2022 @12:45PM (#63029245)

    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]

    • by znrt ( 2424692 ) on Sunday November 06, 2022 @12:50PM (#63029267)

      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!

    • by Anonymous Coward on Sunday November 06, 2022 @12:58PM (#63029285)

      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.

    • by AleRunner ( 4556245 ) on Sunday November 06, 2022 @01:07PM (#63029311)

      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.

      • by znrt ( 2424692 )

        because most of programming, despite what everyone tells you, is actually maintaining or copypasting existing code.

        ftfy, otherwise spot on!

      • by ToasterMonkey ( 467067 ) on Sunday November 06, 2022 @06:13PM (#63030069) Homepage

        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.

        • 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.

        • by sg_oneill ( 159032 ) on Sunday November 06, 2022 @08:50PM (#63030343)

          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.

      • by phantomfive ( 622387 ) on Sunday November 06, 2022 @08:08PM (#63030267) Journal

        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.

        • 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?

          • 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.

            • 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.

              • *shrug*
                Good programmers write good code in any language, bad programmers write bad code in every language.

                • *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.

                  • 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.

      • 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

        • 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

      • According to github statistics, which I found at https://madnight.github.io/git... [github.io] , Go is the 4th most prolific language in terms of github pull-requests, after Python, Java, C++. Where do you see that it is going down?
      • by keltor ( 99721 ) *
        RIP, my #1 language this year so far is Ruby. (This is for checked-in code, I'm sure I wrote more R than anything else, but that was all one-off reporting nonsense.)
    • 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.

      • by tomhath ( 637240 )

        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.

        • by NFN_NLN ( 633283 )

          That's cute, grandpa. Over here we're using web3.0, now with blockchain. /s

        • by andi75 ( 84413 )

          > 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

      • 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.

        • 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.

      • 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?

    • by gweihir ( 88907 )

      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.

      • by NFN_NLN ( 633283 )

        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.

        • by gweihir ( 88907 ) on Sunday November 06, 2022 @07:33PM (#63030209)

          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.

          • 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.

            • by gweihir ( 88907 )

              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.

          • 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 ;-)

            • by gweihir ( 88907 )

              You seem to have missed the part were some of that C code went trough a security review....

  • by packrat0x ( 798359 ) on Sunday November 06, 2022 @12:50PM (#63029269)

    Which one is Google supporting, Rust or Go?

     

    • Re:Rust or Go (Score:5, Interesting)

      by jonathantn ( 6373084 ) on Sunday November 06, 2022 @12:56PM (#63029281)
      Rust is easier to introduce into an existing C codebase than Go. So if you're sitting on a project that is already a few million lines of code, the smart decision is to take all the interfaces that deal with external input and data parsing and rewrite those portions into Rust to help insulate the program from common memory related attack vectors. You don't have to rewrite a few million lines of code to drastically improve the security posture of the application. I'm sure if they are starting from scratch on something, like a new GCP service, they are going to write that in Go.
    • Re:Rust or Go (Score:4, Informative)

      by Waffle Iron ( 339739 ) on Sunday November 06, 2022 @12:58PM (#63029287)

      Which one is Google supporting, Rust or Go?

      Why not both? They target different use cases.

      • Re:Rust or Go (Score:5, Informative)

        by ArmoredDragon ( 3450605 ) on Sunday November 06, 2022 @02:10PM (#63029497)

        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.

        • 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.

          • 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.

          • 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.

            • 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.

        • *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.

      • 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:5, Interesting)

      by hacker_news_rocks ( 6409624 ) on Sunday November 06, 2022 @01:32PM (#63029397)
      Google just launched Carbon, because they think Rust is just too hard to map to existing codebases. Carbon is a cleaner and safer C++ that compiles directly to the language 1:1. The TypeScript approach.

      That said, Google uses Go for microservices and continues to invest in Rust for new embedded and high performance niches.
      • 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

    • 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

  • by Virtucon ( 127420 ) on Sunday November 06, 2022 @12:53PM (#63029275)

    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.

    • by znrt ( 2424692 )

      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.

      • by Virtucon ( 127420 ) on Sunday November 06, 2022 @01:37PM (#63029413)

        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.

        • by znrt ( 2424692 )

          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.

    • IBM System/360 assembly programmer: Sips an aged wine.
  • 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

    • 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.

      • 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.

    • 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

      • by david.emery ( 127135 ) on Sunday November 06, 2022 @02:32PM (#63029595)

        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-.)

    • by Austerity Empowers ( 669817 ) on Sunday November 06, 2022 @02:45PM (#63029633)

      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.

    • 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.

  • by devslash0 ( 4203435 ) on Sunday November 06, 2022 @01:04PM (#63029301)

    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.

    • by hacker_news_rocks ( 6409624 ) on Sunday November 06, 2022 @01:28PM (#63029381)
      Traits are object oriented programming! Have you not used them? Class-based inheritance maps your problem onto a tree of parent and sibling classes for some weird reason. Traits let you declare that anything can provide a given behavior. It's not weird like class inheritance. dyn Trait or impl Trait give you the same type of dispatch you'd get with OO. Because it is OO.
  • Sorry, but I have serious doubts about any system that Huawei wants to be involved in at a low level.

  • We can hope that people won't be swooned by the hype machine.
  • by Junta ( 36770 ) on Sunday November 06, 2022 @01:32PM (#63029399)

    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.

    • by Teckla ( 630646 )

      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>

      • 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)

    by Subsentient ( 6901388 ) on Sunday November 06, 2022 @02:08PM (#63029489)
    I've been using C and C++ since I was 16. I've been using Rust for maybe 3 years now.

    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.
  • 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.

  • by Tony Isaac ( 1301187 ) on Sunday November 06, 2022 @03:38PM (#63029717) Homepage

    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.

    • Respectfully disagree. Example: letting user input cause your program to crap all over memory it doesn't own. I see no way that can be used for good. If a language can help prevent that, then, all else being equal, that seems like an unqualifiedly good thing to me.
      • 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.

  • ... 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.

  • >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)

    by rsilvergun ( 571051 ) on Sunday November 06, 2022 @05:28PM (#63029967)
    If it's one thing that over 20 years of following the it press has taught me is that once wired says something is cool it's basically over.

    Sorry guys time to learn a new programming language. Can the last ones out turn off the lights?
  • ng and wil bring world peace at the same time.

    I think I have been there about 4 times now since I started programming.

  • 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 headline-grabbing reporting: take some thing that has been brewing and is starting to gain some traction, throw a data point or two at it, and then project it out to its most hyperbolic conclusion. They mastered click-bait before that was even a thing.

    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
  • by Argon ( 6783 ) on Tuesday November 08, 2022 @01:10PM (#63036141) Homepage

    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]

Avoid strange women and temporary variables.

Working...