Announcement

Collapse
No announcement yet.

Linus Torvalds' Initial Comment On Rust Code Prospects Within The Linux Kernel

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

  • cl333r
    replied
    Originally posted by oleid View Post
    This is a ods file reader, but it would seem they don't use any tree structure here.
    But I guess you're more interested in a writer. Which reminds me at Xi editor. They use an immutable tree datastructure for text.
    As far as I've heard it is easier to keep the Dom in JS as JS expects it do be garbage collected.
    I was trying to reimplement my own C++/Qt5 project in Rust [1] and hoping it would be better but it's now clear Rust isn't suited for my case. Yeah, the calamine project isn't about CRUD an .ods file in a user friendly way (not even close).
    I would have used Swift but I looked at it yesterday and it's clear that Apple's support for Ubuntu is pretty much only on paper.


    [1] https://github.com/f35f22fan/QOds

    Leave a comment:


  • oleid
    replied
    Originally posted by cl333r View Post
    Rust is equipped even worse to deal with my code - all of it is around managing a dom tree structure - which a LibreOffice .ods file is all about:
    https://github.com/tafia/calamine/bl...ter/src/ods.rs

    This is a ods file reader, but it would seem they don't use any tree structure here.

    But I guess you're more interested in a writer. Which reminds me at Xi editor. They use an immutable tree datastructure for text.

    https://github.com/xi-editor/xi-edit...pe/src/tree.rs


    Originally posted by cl333r View Post
    I guess that's one of the reasons why Mozilla's rust WebRender's dom structure is gc managed by JavaScript.
    As far as I've heard it is easier to keep the Dom in JS as JS expects it do be garbage collected.

    Leave a comment:


  • cl333r
    replied
    Originally posted by oleid View Post
    Rust is equipped even worse to deal with my code - all of it is around managing a dom tree structure - which a LibreOffice .ods file is all about:
    you have an office:body which has office:spreadsheet etc etc until you get to table:table-cell and almost all of them have parents, children, values and styles which might be shared across multiple nodes. To create a convenient api each of these types of nodes has to be a class and needs to call into other classes and modify them at any place in code. And so each of them has to have a &mut Arena instance - it's impossible to have it unless you wrap it in Rc<RefCell<>>. I mean Rc<RefCell> works if your code is reasonably small, but once it gets sophisticated (an .ods file needs like 60 types of classes that must interact/modify each other) - you can't design around not violating RefCell's aliased mutability rule at some point at runtime. I guess that's one of the reasons why Mozilla's rust WebRender's dom structure is gc managed by JavaScript.

    Leave a comment:


  • oleid
    replied
    Originally posted by cl333r View Post

    Well so far it's clear that you have to use typical ugly bloated Rust hacks (Rc<RefCell>>, cloning) because you have to pass in a reference to Arena at every call to most methods of this library hence each of my nodes has to have a reference to it to be able to dynamically deal with the tree.
    It is quite possible you're doing something in a very unidiomatic way. Which then feels strange. I had that quite a few times for new code. After design changes things looked a lot better and were faster.

    Do you happen to have the code uploaded somewhere public ?

    Originally posted by cl333r View Post
    Rust seems very nice in those little Rust tutorial snippets but when you want to use it IRL it's a completely different story. Like ESR said:
    A little later he said :
    I understand now that I tested the language too soon. My use case – foundational network infrastructure with planning horizons on a decadal scale – needs stability guarantees that Rust is not yet equipped to give. But I’m somewhat more optimistic about Rust’s odds of maturing into a fully production-quality tool than I was.
    That was about three years ago. The crates he was missing are quite stable by now.

    Leave a comment:


  • cl333r
    replied
    Originally posted by oleid View Post
    Looking forward to hear back! Sadly I couldn't test it myself.
    Well so far it's clear that you have to use typical ugly bloated Rust hacks (Rc<RefCell>>, cloning) because you have to pass in a reference to Arena at every call to most methods of this library hence each of my nodes has to have a reference to it to be able to dynamically deal with the tree.

    And so it seems to have a similar Rc<RefCell> problem as my previous solution because you have to pass in a reference to Arena in many cases, so you need it to be Rc<>, and because you'll also need it mutable - RefCell.

    I don't know if it will eventually panic at runtime cause I'm just testing on a little test project, I expect it to start panicking when there's a lot more code which at some point violates the aliased mutability rule at runtime. I'll report later if this happens.

    Rust seems very nice in those little Rust tutorial snippets but when you want to use it IRL it's a completely different story. Like ESR said:
    In my last blog post I expressed my severe disappointment with the gap between the Rust language in theory (as I had read about it) and the Rust language in practice, as I encountered it when I actually tried to write something in it.
    [1]

    [1] http://esr.ibiblio.org/?p=7303

    Leave a comment:


  • Royi
    replied
    What about Zig as an alternative to C? I find it to be a real contender.

    Leave a comment:


  • Scellow
    replied
    bloated linux incoming, oh wait, it is already

    Leave a comment:


  • Qaridarium
    replied
    Originally posted by marios View Post
    Linus should have just rejected it, just like he has rejected lots of other proposals.
    I admit I have never used Rust, but I have read about its major "benefits". I believe that you cannot ensure type/memory/thread safety without paying a huge price.
    The price might include performance penalties and crippling the programmers' freedom on how to code.
    they only accept zero performance penalties compared to C... the stuff what happens in compiler time is not a factor of what makes it slow after it had compiled.

    Leave a comment:


  • Qaridarium
    replied
    Originally posted by Danny3 View Post
    Ok, but how is the code written in Rust compared to C at the performance level ?
    Is Rust adding any safety checks at runtime that makes the code slower based on the assumption that the code is badly written ?
    i read the wikipedia article on rust and it tells that it only use performance neutral abstraction.
    means zero performance penalty abstraction.
    anything what would cause a performance penalty is rejected in rust.

    means it has the same performance than C

    Leave a comment:


  • Zan Lynx
    replied
    Some of you seem to find Rust overly restrictive.

    Well, I've been programming in C and C++ since I was a teenager. That's 30 years now. So I have experience. And other experienced C++ developers I work with agree with me: Rust is great.

    That's because as you get more experience with writing C++ and importantly, maintaining C++ code that other people wrote, you come to realize that no one can keep everything straight.

    Experienced C++ developers already use linters and static analyzers and max-level compiler warnings because IT IS SO EASY TO SCREW UP. And your mistakes will often work and pass all the tests and only break with unrelated changes made by another developer next year.

    Rust is a static analyzer built into the language itself. It does its best to prevent you from writing code that it cannot analyze.

    Leave a comment:

Working...
X