Rust's fatal flaw


  • Banned



  • I like Rust. It’s named after an awesome parasitic fungus

    TIL



  • Now, having fatal flaws isn’t a deal breaker in itself.

    If it's not a deal breaker it isn't fatal


  • Grade A Premium Asshole

    @Gąska The April Fool's thread is :arrows:



  • 0_1491082263750_upload-4c4ef116-2a91-4b2d-88a6-54c9b084aa36



  • I have done a fair bit of rust programming, and I stubbed my toe on this myself. On the surface, there's something of a disconnect in my mind of when I need str vs. String (i.e., should an API return one or the other). Seeing the table in that article kinda helped put it in focus.

    I do like Rust a lot, but like its name its got some issues ...


  • Banned

    @NCommander in its heart, Rust is rather similar to C++ - it has similar goals and the same target audience. As a long time C++ programmers, all of those names feel very intuitive - Vec is exactly the same as C++'s std::vector, String is exactly the same as C++'s std::string, and & means reference, just like in C++. As for str, it's just an unsized array of bytes that is guaranteed to form valid UTF-8 - and because it's unsized, most of the time you have to deal with it via references - similar to slices. String is a mutable container for this unsized array. For me, the division between "owned" and "borrowed" types is very artificial.


  • area_pol

    @Gąska Yes, I never tried Rust, but I got the impression that Rust's "borrowed" is like C++ reference (or const-reference).
    This would make everything clear :)


  • Trolleybus Mechanic

    Rust's fatal flaw is that it's yet another programming language created by a bunch of idiots who would rather create a new programming language to fix their mistakes than to actually fix their mistakes.

    Go, Mozilla!


  • Banned

    @Lorne-Kates one of defining traits of a good programmer is choosing a right tool for the job. No right tool exists to fix Mozilla's problem - so they made one. And it's damn good.

    @Adynathos said in Rust's fatal flaw:

    @Gąska Yes, I never tried Rust, but I got the impression that Rust's "borrowed" is like C++ reference (or const-reference).

    Reference is reference. Borrowing is borrowing. It's two separate concepts, although closely related - when you take a reference, you're borrowing the value. A reference is more or less a pointer. A borrow is the act of blocking the value from having another reference taken (mutable references when borrow is immutable, all references when borrow is mutable). The borrow lasts as long as reference is alive.

    @Lorne-Kates said in Rust's fatal flaw:

    Rust's fatal flaw is that it's yet another programming language created by a bunch of idiots who would rather create a new programming language to fix their mistakes than to actually fix their mistakes.

    A good developer picks a right tool for the job. Rust developers went a step further - there wasn't any right tool on the market, so they made one. And it resulted in a fairly good language for others to use.



  • @Gąska You double posted within one post :P


  • Banned

    @anonymous234 happens to me pretty often. But usually, I correct myself before clicking Submit.



  • @Gąska I agree with that point btw. Mozilla might do a lot more good with Rust than with Firefox. The state of unmanaged languages was just shameful.


  • Banned

    @anonymous234 TBH, the original mission of Firefox (to popularize tabbed web surfing) was sensible, and they did much good to the world by dethronizing IE as the industry standard.



  • @Gąska said in Rust's fatal flaw:

    Reference is reference. Borrowing is borrowing. It's two separate concepts, although closely related - when you take a reference, you're borrowing the value. A reference is more or less a pointer. A borrow is the act of blocking the value from having another reference taken (mutable references when borrow is immutable, all references when borrow is mutable). The borrow lasts as long as reference is alive.

    So borrowing is a runtime property of the object, not something you check at compile time?


  • Banned

    @Kian no, not at all. But you wouldn't be very wrong if you think of it as actual bit fields and runtime checks that all get optimized away during compilation, and if they can't be optimized, it's compilation error.

    Also, there's RefCell type in standard library, which is literally bit fields and runtime checks, used when you need borrows that can't be statically proven to be correct. Usually used in conjunction with Rc, which is like C++'s shared_ptr except it can't hold mutable data because of borrow rules (RefCell is mutable, but it's treated as immutable by the type system).



  • @Gąska So it's just a way of checking you don't hold on to a view past the owning object's lifetime? I assume you're not allowed to save them into other structures unless the other structure has an obvious lifetime that is shorter than the owner?


  • Banned

    @Kian yes and yes.



  • @Gąska You mentioned they have a sort of read/write lock semantics, where you can take many read borrows but no writes if you did, and only one write borrow at a time. What if I want to read it, not modify it, but be able to see if it was modified later? Can you take a "const mutable borrow"?


  • Banned

    @Kian Borrowing semantics were specifically designed to prevent any and all instances of data suddenly changing under your feet. If this is what you actually want to happen, you need to write some unsafe code that says "fuck it", takes raw pointers and does whatever. Thankfully, someone did that already, and put it in std::cell module.



  • @Gąska said in Rust's fatal flaw:

    Borrowing semantics were specifically designed to prevent any and all instances of data suddenly changing under your feet.

    Wording it this way, it seems like a premature optimization to me. Surely making your own copy of the data is better in the long run than designing an entire language and learning a new way of reasoning within said language? Was data changing under people's feet so frequently an unwanted problem that they faced?


  • Banned

    @LB_ said in Rust's fatal flaw:

    Was data changing under people's feet so frequently an unwanted problem that they faced?

    Tell me, why multithreading is so hard?

    Also - having such strict immutability rule opens up a whole new world of optimizations. Say, you have a lengthy loop, and in each iteration, you're accessing a field of an object behind reference. In C++, if the compiler cached the value, it could change semantics of the program (see @Kian's example use case above). In Rust, it simply cannot change, ever, for the lifetime of your reference (actually it can via unsafe code, but then you violate invariant and get undefined behavior).



  • @Gąska said in Rust's fatal flaw:

    A good developer picks a right tool for the job. Rust developers went a step further - there wasn't any right tool on the market, so they made one. And it resulted in a fairly good language for others to use.

    They should have just made the next FF in electron, like everyone else. :trollface:



  • @Gąska said in Rust's fatal flaw:

    In Rust, it simply cannot change, ever, for the lifetime of your reference (actually it can via unsafe code, but then you violate invariant and get undefined behavior).

    See, the problem I think is they mixed up two things that while related, are two separate properties, both of which would be nice to have. You have static lifetime checks, and then on top of that you can build the read/write lock behavior.

    Strings are a poor example because often the storage of the string changes when the string changes (particularly if it's growing), but for spans of other kinds of objects, being able to separate the container from the view is valuable (saves you one step of indirection when viewing the values). But you don't want the view to outlive the container. Being able to statically check that at compile time would be cool. But they tied it to immutability. Which while useful, is also more limiting.

    Also, I'd compare it less to multithreading and more to global state. You're never at risk of a data race or a deadlock if you don't have borrows in a single threaded application, but holding a reference to something that might change is the same as having global state change from somewhere else in the application.


  • Java Dev

    How do signal handlers work in rust? Always unsafe code?


  • Banned

    @PleegWat I honestly don't know. There are several libraries available on crates.io, but I never used any of them.


Log in to reply