• 0 Posts
  • 9 Comments
Joined 1 year ago
cake
Cake day: July 9th, 2023

help-circle

  • 5C5C5C@programming.devtolinuxmemes@lemmy.worldBackdoors
    link
    fedilink
    arrow-up
    3
    arrow-down
    1
    ·
    edit-2
    3 months ago

    There are two big problems with the point that you’re trying to make:

    1. There are many open source projects being run by organizations with as much (often stronger) governance over commit access as a private corporation would have over its closed source code base. The most widely used projects tend to fall under this category, like Linux, React, Angular, Go, JavaScript, and innumerable others. Governance models for a project are a very reasonable thing to consider when deciding whether to use a dependency for your application or library. There’s a fair argument to be made that the governance model of this xz project should have been flagged sooner, and hopefully this incident will help stir broader awareness for that. But unlike a closed source code base, you can actually know the governance model and commit access model of open source software. When it comes to closed source software you don’t know anything about the company’s hiring practices, background checks, what access they might provide to outsourced agents from other countries who may be compromised, etc.

    2. You’re assuming that 100% of the source code used in a closed source project was developed by that company and according to the company’s governance model, which you assume is a good one. In reality BSD/MIT licensed (and illegally GPL licensed) open source software is being shoved into closed source code bases all the time. The difference with closed source software is that you have no way of knowing that this is the case. For all you know some intern already shoved a compromised xz into some closed source software that you’re using, and since that intern is gone now it will be years before anyone in the company notices that their software has a well known backdoor sitting in it.


  • I’ve had the privilege of switching from C++ to Rust almost completely in my professional work. I can tell you in no uncertain terms, the language itself makes an enormous difference.

    When I was doing highly concurrent multi-threaded programming in C++, I would sometimes have to waste entire weeks hunting down subtle data race bugs, despite the fact that I have a solid understanding of concurrency and multithreading. In some cases the bugs would originate in third party libraries that I was using, even though those libraries came from credible sources like Microsoft, Google, and GNU.

    Switching to Rust, those bugs are gone. By the time my code compiles there’s at 95% chance that it will work exactly the way it’s intended to without any debugging. The remaining 5% is silly little logic accidents like saying if condition { ... } when I meant to say if !condition { ... } and those bugs are trivially caught by writing a few simple unit tests (and Rust also makes it easier to write unit tests than any other language I know of).

    When I see my colleagues struggle with debugging problems in their JavaScript, Python, or C++ code, almost every time it turns out to be something that would’ve been trivially caught by the Rust compiler.

    By no means does using Rust guarantee that your code will be completely bug free. But the language alone gets you so close to that goal that it hardly takes any special effort beyond compiling to get all the way there.

    I think this is a huge reason that the ecosystem grows as quickly as it does: it’s so easy to write code that you can feel confident enough about to publish for anyone to use that many people go ahead and do that, and others feel confident using the work of others because the compiler does so much to ensure quality. It creates a virtuous cycle where people can develop faster by taking advantage of other people’s efforts and then release their own effort back into the community.


  • Whenever people complain that in Rust “the compiler is tough to beat”, the real problem is that individual’s mindset.

    I had this problem as well when I first started playing with Rust. I thought I was very smart and that I know exactly what I’m doing when I’m programming, so if the compiler is complaining so much about my code, it’s just being a dumb jerk.

    But if you stick with it instead of giving into your initial frustration, you’ll realize that the truth is the compiler is your friend and is saving you from innumerable subtle bugs that you’d be putting into your code if you were using any other language.

    When you realize that the 1.5x time+effort you need to spend to satisfy the Rust compiler is saving you 5x-50x time+effort that you’d have to spend debugging your program if you had written it in any other language, you’ll come to appreciate the strictness of the compiler instead of resenting it.

    There’s a reason us crustaceans are so zealous and the ecosystem is growing so rapidly, and it’s not because we’re super smart or have some unusually high work ethic. It’s because the language and the tooling is legitimately really good for producing high quality software at a rapid pace.

    There’s going to be an inflection point where the people who keep dismissing Rust are going to be left behind by the entire tech industry because there’s no other language that allows an ordinary developer to produce as high quality software as quickly that can work across EVERY platform, including web (via compiling to web assembly). I won’t pretend I can predict exactly when that inflection point will happen, but it will definitely happen.