Linux 6.13 Hits A "Tipping Point" With More Rust Drivers Expected Soon

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

  • Weasel
    replied
    Originally posted by darkonix View Post
    You don't need a raw pointer because there are type safe references. You need a raw pointer only to deal with a C library or some systems/embedded access. Similar to C++ references but more powerful (ref https://stackoverflow.com/a/64167719/721855).
    I don't get C++ reference "love" either. For me they are literally the same as pointers, just different syntax. I will never understand why people hate raw pointers but like raw references. It boggles my mind.

    People keep saying references can't be null. But they can. There's absolutely zero guarantee the caller doesn't supply you a null reference, just like passing a null pointer. And that leads to a crash which is just the same as an assertion...?

    The fact Rust has only "smart pointers" while those are just an optional thing (i.e. programmer's choice) in C++ kinda proves which one is superior (it's not Rust since it forces you to one thing).

    Originally posted by darkonix View Post
    I'll refer to the link:
    "If a static item is declared with the mut keyword, then it is allowed to be modified by the program. However, accessing mutable statics can cause undefined behavior in a number of ways, for example due to data races in a multithreaded context. As such, all accesses to mutable statics require an unsafe block.​"
    It allows you to do things that are undefined behavior if you explicitly say it is unsafe.
    How is it undefined behavior if you use atomics to exchange it or set it?

    Originally posted by darkonix View Post
    Apparently no, because it is really unsafe to do so: https://doc.rust-lang.org/reference/...g-union-fields
    "Unions have no notion of an “active field”. Instead, every union access just interprets the storage as the type of the field used for the access. Reading a union field reads the bits of the union at the field’s type. Fields might have a non-zero offset (except when the C representation is used); in that case the bits starting at the offset of the fields are read. It is the programmer’s responsibility to make sure that the data is valid at the field’s type. Failing to do so results in undefined behavior. For example, reading the value 3 from a field of the boolean type is undefined behavior.​"

    Rust uses unsafe as a way for the programmer to take responsibility explicitly for code that can cause undefined behavior. It let's you do it but you have to be explicit. I really like that approach instead of hiding potentially dangerous behavior from the programmer, or the programmer ignoring what they are doing.
    I mean, that's the whole point of unions, lol. Cringe how crippled and baby-mode Rust is.

    There's an alternative to do type punning without union in C/C++ but it requires compiler extensions (may_alias attribute). I don't see how having to cast and use such types is any different than an "unsafe" block...?

    Leave a comment:


  • smitty3268
    replied
    Originally posted by Weasel View Post
    Because then it's C with an infinitely worse syntax, so what's the point? (Rust syntax is horrid, and for the next guy who will start his history lesson about how it borrows from OCaml, I will make it clear so you can understand: OCaml is trash and has terrible syntax)
    The type system is way better than C, and I don't think I'd agree the syntax is worse either. There's definitely some stuff about it I hate, but it also has a lot of nice stuff that C is missing. Kind of a wash overall IMO. (Edit - oh, I see you may have been talking about c++, not c. that's certainly much closer in terms of supporting more stuff than c does, so I could maybe see ranking that as better)

    But really the point is that 99% of your code isn't in the unsafe blocks, so you're really only comparing the 1% as if it was the entire language, which I don't agree with.
    Last edited by smitty3268; 16 December 2024, 03:31 AM.

    Leave a comment:


  • darkonix
    replied
    Originally posted by Weasel View Post
    I can't understand how you can program anything of value without dereferencing raw pointers (which is the same thing as accessing a reference).
    You don't need a raw pointer because there are type safe references. You need a raw pointer only to deal with a C library or some systems/embedded access. Similar to C++ references but more powerful (ref https://stackoverflow.com/a/64167719/721855).
    What does calling unsafe functions mean? Are you saying you can't call functions that have unsafe blocks in them at all without unsafe? Or just the way they are called is unsafe? (i.e. arguments)
    If the function is declared unsafe you have to call it from an unsafe block. It is like the developer acknowledging and assuming responsibility for using a function that is unsafe. Or alternatively avoiding calling something unsafe accidentally.

    Code:
    unsafe fn dangerous() {}
    
    unsafe {
       dangerous();
    }


    Mutating statics is extremely common too but I suppose there's alternatives for that so whatever. (i.e. caching expensive things at runtime that should be loaded on demand, and yes, I mean with thread safety and an atomic exchange)
    I'll refer to the link:
    "If a static item is declared with the mut keyword, then it is allowed to be modified by the program. However, accessing mutable statics can cause undefined behavior in a number of ways, for example due to data races in a multithreaded context. As such, all accesses to mutable statics require an unsafe block.​"
    It allows you to do things that are undefined behavior if you explicitly say it is unsafe.
    And you can't use unions at all in safe Rust code? Yikes.
    Apparently no, because it is really unsafe to do so: https://doc.rust-lang.org/reference/...g-union-fields
    "Unions have no notion of an “active field”. Instead, every union access just interprets the storage as the type of the field used for the access. Reading a union field reads the bits of the union at the field’s type. Fields might have a non-zero offset (except when the C representation is used); in that case the bits starting at the offset of the fields are read. It is the programmer’s responsibility to make sure that the data is valid at the field’s type. Failing to do so results in undefined behavior. For example, reading the value 3 from a field of the boolean type is undefined behavior.​"

    Rust uses unsafe as a way for the programmer to take responsibility explicitly for code that can cause undefined behavior. It let's you do it but you have to be explicit. I really like that approach instead of hiding potentially dangerous behavior from the programmer, or the programmer ignoring what they are doing.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by Weasel View Post
    I was talking about C++ btw, you want C++ examples or?
    Ahh. Yeah, no argument that C++ is syntactically bloated... though I am curious which elements of C++'s syntax you'd pick and how you'd rank them.

    Leave a comment:


  • Weasel
    replied
    Originally posted by darkonix View Post

    Unsafe provides a limited number of extra features:​the programmer takes responsibility For those unsafe blocks. Still the rest of Rust rules like the type system and borrow checker still work and provide extra safety compared to C.

    This analysis of unsafe usage in the wild is interesting: https://foundation.rust-lang.org/new...f-unsafe-rust/
    I can't understand how you can program anything of value without dereferencing raw pointers (which is the same thing as accessing a reference).

    What does calling unsafe functions mean? Are you saying you can't call functions that have unsafe blocks in them at all without unsafe? Or just the way they are called is unsafe? (i.e. arguments)

    Mutating statics is extremely common too but I suppose there's alternatives for that so whatever. (i.e. caching expensive things at runtime that should be loaded on demand, and yes, I mean with thread safety and an atomic exchange)

    And you can't use unions at all in safe Rust code? Yikes.

    Leave a comment:


  • Weasel
    replied
    Originally posted by ssokolow View Post

    Examples?

    In my experience, it's quite concise for what it needs to communicate to the compiler and syntactic sugar like async/await and ? come about later to replace things like manually implement Future or using the try! macro once a need has been demonstrated. Part of that is how it leans so heavily on features like type inference.
    I was talking about C++ btw, you want C++ examples or?

    Leave a comment:


  • darkonix
    replied
    Originally posted by Weasel View Post
    I mean if it offers no benefit (when you use unsafe, that is) than C but it has worse syntax then it's worse, no?
    Unsafe provides a limited number of extra features:​the programmer takes responsibility For those unsafe blocks. Still the rest of Rust rules like the type system and borrow checker still work and provide extra safety compared to C.

    This analysis of unsafe usage in the wild is interesting: https://foundation.rust-lang.org/new...f-unsafe-rust/

    Leave a comment:


  • ssokolow
    replied
    Originally posted by Weasel View Post
    By "bloated" I mean syntactically and so on, we're talking source code here, not in the resulting binary, that's a completely different issue.
    Examples?

    In my experience, it's quite concise for what it needs to communicate to the compiler and syntactic sugar like async/await and ? come about later to replace things like manually implement Future or using the try! macro once a need has been demonstrated. Part of that is how it leans so heavily on features like type inference.

    Leave a comment:


  • Weasel
    replied
    Originally posted by oleid View Post

    If you restrict unsafe usage to a few isolated lines, then it is fine. Because in C you don't even have the possibility. Especially when you note down why the code in the unsafe block is okay.

    And considering the syntax: one gets used to it. It's like club mate.

    On the pro side compared to C are other nice things like the union-like enums, match constructs as an expression and a macro language that is better than a simple text-replacement tool, modules, guaranteed compile time evaluation and the list goes on.
    Yeah I admit C is kinda lacking. C++ has some super nice features I wish C had, but unfortunately a lot of C++ code relies too much on bloated crap (especially overuse of standard library). Don't get me wrong nobody forces me to use them, so for me C++ is almost perfect (barring 2-3 features I want to see), but I can't say the same about C++ code in the wild that I have to deal with constantly. If C got only those features it would be perfect since it would force those specimens to use it the C-style way.

    By "bloated" I mean syntactically and so on, we're talking source code here, not in the resulting binary, that's a completely different issue.

    Leave a comment:


  • Weasel
    replied
    Originally posted by darkonix View Post
    So the problem is not with unsafe but with Rust syntax? That's subjective but valid. I don't particularly like Rust syntax but I like the features it brings to the table.
    I mean if it offers no benefit (when you use unsafe, that is) than C but it has worse syntax then it's worse, no?

    Leave a comment:

Working...
X