Announcement

Collapse
No announcement yet.

Rust For The Linux Kernel Sent Out For Review A Fourth Time

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

  • binarybanana
    replied
    I like Rust a lot, it's a great language. I have even written a semi-popular project in it. The compile time safetey is great and makes writing insanely daring zero copy multithreadedcode almost a no-brainer.
    But I wonder how much of that will hold for low level kernel code. At that level you don't only have to worry about memory safetey, but also about hardware state. I'm sure there are ways to encode some things in the type system, for example, to prevent enabling interrups while holding some kind of lock in a piece of code that initializes some hardware or whatever in a short loop that polls for readiness. But it will not help you to set the right magic registers to the correct value at whatever memory address the device is placed. So you can still easily trigger nasty bugs and "undefined behavior" if you get that wrong and the NIC or whatever goes apeshit and starts writing random crap into all memory it has access to through DMA or benaves strangeley in other ways the code doesn't expect or foresees to check for.
    Luckily things like that can be mitigated with an IOMMU and testing drivers in a VM, which should (mostly) protect the host system in any case, so it's not that bad.I'll certainly enjoy hacking on Rust drivers much more than what we have now in any case.

    Leave a comment:


  • qm3ster
    replied
    Originally posted by betty567 View Post
    But Rust doesn't use "garbage collection", it uses "unicorn farts that nobody can quite describe"
    > "values are dropped at the end of the block they were declared in" is magical and incomprehensible
    > it's very immoral when a library type can suggest a cleanup/reclamation strategy for itself
    > now stop bothering me with this malarkey, I have more important things to attend to, like remembering to call MY_C_LIBRARY_STRUCT_FREE_METHOD(pointer_to_my_c_li brary_struct) before the last copy of the pointer goes out of scope, but only exactly once. (I also not only know exactly what the dynamically linked MY_C_LIBRARY_STRUCT_FREE_METHOD does, I control it, thank you for asking)

    Jokes aside, thank you for inspiring the following:
    Rust is excellent for an OS kernel because memory management is 100% up to the developer. You decide your own allocation strategy, you decide when and how to initialize memory, your own reuse strategy, and you decide when to free memory. There is no "unsafe" portion of the language that one must rely exclusively on in low-level scenarios. No "garbage collection", which is a "for dummies" feature. Rust is a win, and nothing else.
    Gonna go copypasta it somewhere.

    Leave a comment:


  • mmstick
    replied
    Weird quote pick for System76. We've made better pitches for Rust in the past, and that was just a description of a small project.

    This would be more appropriate: https://www.rust-lang.org/production/users (138 companies listed)

    But it's only a small fraction of companies using Rust, because your company has to willingly and voluntarily request to be added to the Rust website. Apple, Google, Microsoft, IBM, and virtually all the fortune 500 won't bother.
    Last edited by mmstick; 13 February 2022, 09:03 AM.

    Leave a comment:


  • dragonn
    replied
    Originally posted by akira128 View Post

    I was simply pointing out that the steady rise in popularity and increased adoption of Rust is an indication of its "success" as a language.
    Yes, that for sure. Didn't understand you point in this way, was to much focused on other people arguments here about raw comparing C and Rust popularity and adoption without getting the time context in mind

    Leave a comment:


  • akira128
    replied
    Originally posted by dragonn View Post
    It can be if you are talking about languages with comparable adoption time on the market.
    At the current moment it is like saying when the first smartphone come out that the regular old phones are more "successful" because the are more popular and widespread.
    Or when MP3 players come out saying that cd players are more "successful" because the are more popular and widespread. Or pick any example you like.
    They is no value in comparing a 40 years language to a 10 years old (and to be fair, the stable version is only 8 years old..., is they are any language with comparable lifetime and wider adoption? I can not think about any) one in terms of popularity and widespread
    I was simply pointing out that the steady rise in popularity and increased adoption of Rust is an indication of its "success" as a language.
    The time frame is irrelevant (albeit that helps on the "maturity" scale), it's the rate of adoption that really matters.
    Last edited by akira128; 13 February 2022, 09:02 AM.

    Leave a comment:


  • dragonn
    replied
    Originally posted by akira128 View Post

    How "successful" a language is can be difficult to define.....but popularity and widespread adoption (especially by big companies) can be one indication of "success" right?
    It can be if you are talking about languages with comparable adoption time on the market.
    At the current moment it is like saying when the first smartphone come out that the regular old phones are more "successful" because the are more popular and widespread.
    Or when MP3 players come out saying that cd players are more "successful" because the are more popular and widespread. Or pick any example you like.
    They is no value in comparing a 40 years language to a 10 years old (and to be fair, the stable version is only 8 years old..., is they are any language with comparable lifetime and wider adoption? I can not think about any) one in terms of popularity and widespread
    Last edited by dragonn; 13 February 2022, 08:49 AM.

    Leave a comment:


  • jacob
    replied
    Originally posted by Volta View Post

    I bet it's not C fault, but some developer. It's quite hard language, but very powerful one.
    That's a silly thing to say. Memory errors (among others) should be a thing in the first place. Developers shouldn't HAVE to worry about stupid mistakes like that. The C language, in fact, is neither hard not powerful. It's very easy to learn but it's expression power is extremely weak, which means developers must spend their time paying attention to problems that should not exist. That's in comparatively simple programs. In complex ones... we'll, you get CVEs.

    Leave a comment:


  • akira128
    replied
    Originally posted by dragonn View Post

    And what other choices you have before Rust? Really? The only other choice was C++, a lang with adds more complexity without solving ANY C problems.
    And other langs like Java, Python etc. are just not sensible option for some tasks, you just didn't have before Rust a choice if you need a lang with is compiled without a GC.
    Also, I completely don't get how the whole "C is more successful" is an argument here, you are comparing a language with had ~40 years of time to adopt on the market vs ~10 years. Of course at this point in time C will be more "successful", that doesn't mean in 30 years Rust can be at this point now C is and even beyond that.
    How is this even an argument? Man, it is like saying that fuel powered cars are more "successful" then electric because we used them over 100 years and electric cars are only recent getting tracking. HOW IS THAT EVEN AN ARGUMENT?!
    How "successful" a language is can be difficult to define.....but popularity and widespread adoption (especially by big companies) can be one indication of "success" right? That's just one metric. There's also functionality...and perhaps the rate of vulnerabilities should be thrown in there.

    According this report (written 2 years ago):
    https://www.whitesourcesoftware.com/...ing-languages/

    The C programming language accounts for the highest percentage of all vulnerabilities (out of 7 the languages that were tracked/polled) with over 77% in the last 10 years, and 47% for the previous year.

    I understand that C has an incredibly large user-base, but damn that's a high number.
    Last edited by akira128; 13 February 2022, 08:47 AM.

    Leave a comment:


  • mmstick
    replied
    Originally posted by betty567 View Post
    C is excellent for an OS kernel because memory management is 100% up to the developer. You decide your own allocation strategy, you decide when and how to initialize memory, your own re-use strategy, and you decide when to free memory.
    There are many people using Rust for embedded software development today. Perhaps do a quick Internet search for `no_std rust` and `embedded rust`. You get to decide your own allocation strategy, when and how to initialize memory, your own re-use strategy, and when to free memory. Guess you think Rust is excellent now?

    There are no features that must be abstained from when doing low-level things, there is no "unsafe" portion of the language that one must rely exclusively on in these low-level scenarios.
    This ignores the fact that all C code is by default unsafe, and there is no way to build safe abstractions in C. You can't prevent a programmer from calling your API with invalid memory addresses. Everyone writing C libraries is eternally engaged in defensive programming techniques to handle unexpected inputs. Whereas in Rust you have clearly defined types, ways of encoding constraints into types, and the ability to fully capture and ration ownership of data.

    No "garbage collection", which is a "for dummies" feature for people who cannot keep track of allocations. But Rust doesn't use "garbage collection", it uses "unicorn farts that nobody can quite describe" but don't call it garbage collection, because garbage collection has a negative connotation. Rust is a win for it's own marketing folks, and nothing else.
    Is this what you would say about C++? Rust uses the same garbage collection mechanism as C++ — RAII. The compiler tracks the lifetime of variables and inserts drop methods after the last reference of the variable in the code. There's an established spec for the order that the drop methods are invoked, and the order that fields in a struct are dropped. The killer feature of Rust is in how the compiler enforces aliasing XOR mutability, utilizes an ownership model, and allows the programmer to tag lifetimes of references.

    20 years ago, these "unicorn farts" were thoroughly described and explained in an AT&T Labs research paper: https://www.cs.umd.edu/projects/cycl...ne-regions.pdf
    Last edited by mmstick; 13 February 2022, 08:29 AM.

    Leave a comment:


  • jacob
    replied
    Originally posted by Volta View Post

    Can you show us how successful the Rust is? I'm not against it, but I'm trying to figure out on what basis some people formulate their claims.
    https://kerkour.com/rust-in-production-2021/

    Leave a comment:

Working...
X