Announcement

Collapse
No announcement yet.

Google To Allow Rust Code In The Chromium Browser

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

  • Ironmask
    replied
    Common arguments against Rust's safety guarantees:
    - The library you're binding to can have a segfault in it.
    - RAM can physically fail, causing dangling pointers.
    - The computer the Rust program is running on can be hit by a meteorite.
    - Alan Turing can come back from the dead and tell everyone that he actually made up computer science and none of it is real, thus invalidating every program ever made, including all Rust programs.

    Leave a comment:


  • jacob
    replied
    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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:

Working...
X