Announcement

Collapse
No announcement yet.

Google To Allow Rust Code In The Chromium Browser

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    Originally posted by Lycanthropist View Post
    With containers and smart pointers, modern C++ can be just as memory safe as Rust. All memory related proplem stem from interfacing with older code. Rust has the same problem when having to interface with a C library.
    I don't know why people think Rust's safety is just not having dangling pointers. Even Rust blogs I read say that, for some reason even Rust programmers think Rust is "just Java/Python but instead of runtime managed memory it's compile time". Any language can implement a referenced-counted pointer, that's not the point of Rust's safety. Rust's safety comes from it's ownership system and enums/matching. It's not just that it eliminates dangling pointers, it requires you to plan out the entire architecture of your program from top to bottom and explicitly define exactly what components own what resources. Nobody can share resources without explicitly saying who owns it or how it can be mutated, your architecture cannot have it's rules ignored and resources scrambled around by other people working on the codebase. There's no issue about forgetting what gets owned or what order of operations something has to go in or forgetting to check something, Rust forces you to consider all of these things and prevents your codebase from having baked-in errors, unless you really go out of your way to make it shut up. I find that I don't even have to write tests for my Rust projects outside of algorithms, because Rust just lets me make my APIs completely fool-proof, they literally cannot be used incorrectly or it just won't compile at all. If I give the user of my API a resource, and then I want to invalidate it, I just can, and they can't use it anymore without their program just not compiling in the first place, no runtime surprises required.

    Comment


    • #62
      Originally posted by kpedersen View Post
      I'm not sure. No longer can a single test suite be used. Different languages effectively introduce a black box that no single i.e static analyser can trace. Now you need multiple and they can't often talk to one another.
      I would hope this isn't a concern? This is the entire point of dependency injection and proper encapsolation. A component, class or even a function should be completely oblivious to the rest of the program, it should only care about what resources are given to it, and those resources can and should be mockable if you can't verify them at compile-time. If this is a serious issue then you should really look into replacing your developers, that sounds like a violation of basic software development.

      Comment


      • #63
        Originally posted by RejectModernity View Post

        Proprietary garbage with Javascript interface.
        95% open source.

        Also, funny that you think the interface is garbage. Firefox users hate Chromium for how little you can do with the interface. Vivaldi allows the same thing as Firefox, yet its interface is “garbage”. Right…
        Last edited by Vistaus; 13 January 2023, 12:37 PM.

        Comment


        • #64
          Originally posted by jacob View Post

          Isn't Vivaldi proprietary?
          It's 95% open source, so not exactly proprietary. I mean: Aldi is a supermarket that sells 95% groceries and 5% laptops and other tech stuff, but no one would call them a tech store. So in that sense, Vivaldi is open source, despite 5% of the codebase being read-only (yes, the missing 5% *is* read-only, so not hidden from view).
          Last edited by Vistaus; 13 January 2023, 12:38 PM.

          Comment


          • #65
            Originally posted by TuesdayPogo View Post

            ...because open-source people want stuff to be open-source? It's like asking why does anime fans like waifu and husbando. It just comes with the territory. Open-source people like open-source stuff, and don't like the opposite, naturally.

            While I don't think it's that big of a deal, I do think that it's fair for people who cares about open-source to not like it and don't trust it because of that proprietary portion.
            The proprietary portion isn't even that proprietary as they do allow you to view the source of that portion read-only.

            Comment


            • #66
              Originally posted by kpedersen View Post
              Your safe Rust sections could still be carrying an expired pointer around in its underlying layers. As my previous example showed, any high level memeory management system can quite happily hold dangling pointers ripped out by other systems.
              But wouldn't you fix and search for them in the C++ section? What could you possibly do in the safe rust section to address those issues? Or do you mean compiler/language errors?

              Comment


              • #67
                Originally posted by Lycanthropist View Post
                With containers and smart pointers, modern C++ can be just as memory safe as Rust. All memory related proplem stem from interfacing with older code. Rust has the same problem when having to interface with a C library.
                I worked with C++ professionally for three decades and modern C++ can not be as safe as Rust. It can be somewhat safe for some types of common issues but the problem is that to be somewhat safe it requires the human writing the code to have perfect discipline using modern techniques and never make mistakes. However, even the best developers in the world makes mistakes, with Rust the compiler just takes over that responsibility of managing lifetimes, shared access, etc. and let's not forget that Rust is much more than just lifetimes.

                What's interesting is I have been lucky enough to having worked with some of the best C++ developers in the business and while we didn't discuss Rust as such at the time, I often see that the more experienced a developer is the more they're willing to admit that we're very fallible and there will always be memory related issues in the code.

                Rust have to interface with C code yes, but if the main bulk of your application is written in Rust the attack surface is vastly reduced and it's easier to validate the unsafe bits.
                Unsafe code is perfectly valid Rust, it's just an agreement between the developer and the compiler where the developer says to the compiler "I know this is a piece of code you can't guarantee is safe, so I will make sure it is with extra care, peer review, careful testing, etc."

                I find I spend much less time debugging with Rust. Once it compiles it's really just logic type errors I have to fix and they're usually easy to hunt down.
                Last edited by hyperchaotic; 13 January 2023, 02:59 PM.

                Comment


                • #68
                  Originally posted by Anux View Post
                  But wouldn't you fix and search for them in the C++ section? What could you possibly do in the safe rust section to address those issues? Or do you mean compiler/language errors?
                  Well that's the problem. The issue is really in the ANSI C sections and assumption of lifetimes not the C++. So C++ couldn't solve it (that is only safe when dealing with 100% C++) but unfortunately neither can Rust (that is only safe when dealing with 100% Rust) because dealing with the underlying system data (and C) is fundamentally unsafe.

                  Comment


                  • #69
                    Originally posted by kpedersen View Post
                    because dealing with the underlying system data (and C) is fundamentally unsafe.
                    Yes, but that still isn't a problem. Your rust code is perfectly fine and depending on how much is written in rust, those fundamental errors become easier to find.

                    Rust never claimed it could make other programms errors disapear. But replacing parts with rust shrinks the area you need to search for them.

                    Comment


                    • #70
                      Originally posted by Lycanthropist View Post
                      It's not a myth even if Rust fanboys keep saying that. Truth is, you can write unsafe code in Rust as well. You have to, when interfacing with C code.
                      I don't think the fanboyism is where you think it is. Sorry but having unique_ptr and std::move doesn't save the day. Anyone with some hands on experience of static analysis of C++ code (including yours truly) can confirm that modern C++ is still comprehensively broken. You can trivially write a program using exclusively post-C++11 features that will segfault, suffer from race conditions, and more. That's not even considering that you always have at least one C-style pointer lurking around: *this.

                      That's what C++ designers themselves acknowledge. Google recognises it, Microsoft recognises it, so do Mozilla, Discord, Dropbox, Apple, Facebook and others. But of course there are always random Joes on the internet who "know" It says more about the Denning-Krueger effect than about C++ if you ask me.

                      And of course it is possible to write unsafe code in Rust, although interfacing with C is a poor example because the whole lack of safety in that case comes from the C code and not from the unsafe binding declaration in Rust. But you will find that even unsafe Rust is actually safer (as in less unprovable) than "modern" C++.

                      PS: nobody says that Rust is forever a silver bullet or that there are no valid reasons to still use C++. But claiming that C++ is as safe as Rust because "I wrote a program in it that doesn't crash" doesn't make one some kind of elite, it just proves that one has no damn idea

                      Comment

                      Working...
                      X