Why He's Dropping Rust



  • Why I’m dropping Rust

    Turns out this big idea academic circlejerk language falls apart when people try to use it in practice.



  • @cartman82 Bah, I don't expect that Thelema will ever have such problems. A truly academic language doesn't need trivial things like 'a working implementation'.

    Filed Under: that's the sad, sorry truth, and I will probably never get past that



  • @cartman82 said in 🔗 Quick links thread:

    Why I’m dropping Rust

    Hey @Gąska, aren't you our Rust guy? What's your take on this?



  • @boomzilla said in 🔗 Quick links thread:

    Hey @Gąska, aren't you our Rust guy? What's your take on this?

    We have a guy for everything


  • Impossible Mission Players - A

    @cartman82 said in 🔗 Quick links thread:

    @boomzilla said in 🔗 Quick links thread:

    Hey @Gąska, aren't you our Rust guy? What's your take on this?

    We have a guy for everything

    undefined



  • suppose you have a base class Widget and want all your actual Widgets such as a Label or a Button or a CheckBox to have certain easily-shared functions.

    I suppose the author has the Java-style OOP brain worm. Unfortunately, Rust doesn't support class inheritance, so most Java-style OOP patterns don't translate to Rust.

    In Rust, to do something similar to this, you have Traits.

    Vaguely similar. About as similar as light waves and sound waves.

    So a trait can define abstract functions, but can't access any underlying fields. Let that sink into you. My first reaction to this was "Sorry, what?!".

    I wonder what his reaction was when he learned about Java interfaces. Or maybe he still didn't?

    I'm not the only one who thinks this is a severely limited part of the language and there's currently an RFC going to make it less silly.

    You know that "Everyone I don't like is Hitler" book picture? I have to learn Photoshop one day and make it into "Every language construct I don't understand is silly".

    However, this has been going on at least since March 2016.

    Look, compiler development is hard, okay? If you think half a year is enough to make a giant feature that heavily interacts with about every other part of codebase, why won't you make it yourself?

    Traits as a concept have been part of the language for numerous years.

    Just like variable assignment. You know why variable assignment was part of language since the beginning? Because it's fundamental part of the language and not much could be done without it. Same with traits.

    Why is such an important and vital part of the language missing, still?

    Because other Rust programmers don't suffer Java-style OOP brain worms and took the time necessary to learn basic language concepts instead of complaining that copy-paste from Java doesn't work?

    In some cases you can work around this by adding a function to the trait that is not implemented in the trait itself but on an actual object, then use that function to do your function with.

    Now it's really starting to sound like he indeed never encountered interfaces in his entire life.

    So you either don't use abstract functions and have a lot of code duplication or use the setup of the example and have slightly-less-but-still-too-much code duplication AND a leaky API.

    Or you might actually learn Rust and start taking advantage of trait system instead of working against it. Or pick another language if you want to make GUI application, because honestly, Rust's lack of class inheritance makes it very hard if not impossible, despite being well suited in many other areas. Part of being a half-decent programmer is knowing your tools and what they're good for.

    Another example. For nanogui, and CEGUI uses this concept as well, each widget has a pointer to a parent and a vector of pointers to its children. How does this concept map to Rust?

    By solving the ownership problem. Which is pretty hard, since the cyclic reference problem is part of spec.

    Option 1
    This is the option someone new to the language would choose.

    Specifically, the people who don't know that you can't have dynamic polymorphism when you store objects in a container by value.

    Option 2
    This is the option that I chose next. It offers the advantage that it's reasonably similar to the C++ style of nanogui.

    Similar enough to reintroduce all the pain of manual memory management that Rust desperately tries to run away from.

    But the major breaking point of this option is that it is currently impossible to create a self-reference counting object. Note that I don't mean the equivalent of C++'s smart pointers or Rust's very own Rc type. I mean an object that counts how many times it's been referenced and deletes itself when this counter reaches 0.

    Yep, that's definitely not what either C++'s shared_ptr or Rust's Rc are. Not at all.

    You can find an example in the C++ version of nanogui.

    Oh, I see. You didn't mean something like shared_ptr. You meant something like shared_ptr, but with reference count public. Because unlike what you said previously about traits, making refcount public is totally not leaky abstraction.

    For this to work, you need to be able to tell the compiler to only allow deleting/dropping oneself from inside the object.

    That, or just never delete it from ouside the type's methods. You're already managing memory by hand - why not go all the way?

    Alright, I said. Have it your way, Rust. What IS the idiomatic Rust way to do a cyclical directed graph?

    I'm almost certain there's a lib for that.

    Option 3
    After some searching I found a nice Rust library for creating trees called rust-forest.

    Oh look, there is!

    However, the implementation given in rust-forest doesn't allow nodes of different T types to be in the same graph, a requirement for a library such as nanogui.

    Protip: Box<T> is Box<T> is Box<T> regardless of what type the object inside is.

    I like the idea behind traits much like the interfaces in Go

    Oh, so he knows about interfaces after all? This makes the upper half of the article rather confusing.

    If you’ve read the whole article so far and stuck with it, thanks for reading my rant. If not, there's no TL;DR here, sorry.

    Yes there is."Michael Cannot Into Programming Without Class Inheritance".



  • @Gąska said in Why He's Dropping Rust:

    Yes there is."Michael Cannot Into Programming Without Class Inheritance".

    So I'm someone whose contact with Rust is pretty much reading about it on here, but I have thought about picking it up for a particular project.

    But let me ask you, what would be a "proper" Rust way to build something like a bunch of different types of widgets like he was talking about? Where Java / C# / C++ class inheritance seems like a straightforward approach?


  • Impossible Mission - B

    @Gąska said in Why He's Dropping Rust:

    I suppose the author has the Java-style OOP brain worm. Unfortunately, Rust doesn't support class inheritance, so most Java-style OOP patterns don't translate to Rust.

    Class inheritance is not a "Java-style OOP" thing, it's an OOP thing, period. It's been around since the invention of OOP with Simula, and it's the OOP thing, in fact, the sine qua non of object-oriented programming, Alan Kay's trollish attempts to hijack the narrative and redefine basic principles notwithstanding.

    Without inheritance and virtual methods supported at the language level, you don't have Liskov substitution, and without Liskov substitution, you don't have OOP; you have procedural programming with weird dot syntax.



  • @Gąska said in Why He's Dropping Rust:

    Or you might actually learn Rust and start taking advantage of trait system instead of working against it. Or pick another language if you want to make GUI application, because honestly, Rust's lack of class inheritance makes it very hard if not impossible, despite being well suited in many other areas. Part of being a half-decent programmer is knowing your tools and what they're good for.

    Wait, isn't the whole point of rust to drive the next generation web browser?

    If your native compiled language can't handle desktop apps, what use it is at all?



  • @Gąska said in Why He's Dropping Rust:

    Or pick another language if you want to make GUI application, because honestly, Rust's lack of class inheritance makes it very hard if not impossible, despite being well suited in many other areas.

    Hold on one goldurn minute. Isn't the desire to rewrite Firefox in it pretty much the whole reason Rust even exists?


  • Winner of the 2016 Presidential Election Banned

    @cartman82 said in Why He's Dropping Rust:

    @boomzilla said in 🔗 Quick links thread:

    Hey @Gąska, aren't you our Rust guy? What's your take on this?

    We have a guy for everything

    *Sudden Clarity Clarence*
    WTDWTF is an extremely diverse forum.

    Though, to be fair, I've always known that diversity isn't always a good thing for every situation. It's just, you know, much more likely to be good in general. Case in point: if we have an esoteric question about almost any subject, someone here probably has an answer to it, or at least knows where to find it.


  • Winner of the 2016 Presidential Election

    @Fox said in Why He's Dropping Rust:

    : if we have an esoteric question about almost any subject, someone here probably has an answer to it, or at least knows where to find it will mock you for asking it.

    WTDWTFTFY



  • @masonwheeler said in Why He's Dropping Rust:

    Class inheritance is not a "Java-style OOP" thing, it's an OOP thing, period.

    One of several ways to do OOP. Another is what Rust does. And JavaScript is yet another style, closely related to classes but not quite.

    @masonwheeler said in Why He's Dropping Rust:

    Without inheritance and virtual methods supported at the language level, you don't have Liskov substitution

    Rust does have virtual methods. It also has trait inheritance, which is very much like interfaces. Does Liskov substitution strictly requires using base class's data fields? Because if not, then it's perfectly applicable to Rust.

    @cartman82 said in Why He's Dropping Rust:

    Wait, isn't the whole point of rust to drive the next generation web browser?

    If your native compiled language can't handle desktop apps, what use it is at all?

    Well, I made some simplification. Rust doesn't have class inheritance, and the most popular desktop GUI frameworks use class inheritance. So you cannot really use any of them in Rust, and neither can you port them directly. And the libraries written in C tend to be pretty fucked up. So Rust is seriously constrained in using existing GUI libraries, and last I checked, no one was rolling a new one from scratch. And even if someone did so, it would differ significantly from how "classy" libs work, which would make it rather hard to learn (and I think it would come out worse, because classes play very nicely with GUI).

    That was about desktop GUI. A completely different situation is with games. Here, there are numerous libraries for GUI, and they're pretty good. The difference from desktop is that in games, you control the whole screen, and don't have to use native controls. In this regard, browser engine is more similar to games than other desktop apps. Servo (the Rust browser engine by Mozilla) will probably be embedded in browsers written in other languages, that better deal with desktop GUI. That, or Rust gets class inheritance and Qt bindings.



  • Also

    @cartman82 said in Why He's Dropping Rust:

    If your native compiled language can't handle desktop apps, what use it is at all?

    Libraries. Number crunching, encryption and other security stuff, drivers, OS kernels, encoders/decoders, bottom five layers of OSI...


  • Impossible Mission - B

    @Gąska said in Why He's Dropping Rust:

    @masonwheeler said in Why He's Dropping Rust:

    Class inheritance is not a "Java-style OOP" thing, it's an OOP thing, period.

    One of several ways to do OOP. Another is what Rust does. And JavaScript is yet another style, closely related to classes but not quite.

    JavaScript is a toy language designed explicitly for tiny scripts "to make the monkey dance when you moused over it". There's a reason why modern Web development has a strong tendency to use class-based OO languages that get compiled down to JS: because they're designed based on principles that actually work for managing non-trivial complexity, and JS isn't.


  • Winner of the 2016 Presidential Election

    @masonwheeler ES6 has class syntax now.


  • Winner of the 2016 Presidential Election Banned

    @masonwheeler said in Why He's Dropping Rust:

    for tiny scripts "to make the monkey dance when you moused over it".

    I'm pretty sure you could do that with some CSS to overlay a .png over an animated .gif and hide the .png on hover or something. As an added bonus, it would probably work 100x faster than javascript.


  • Impossible Mission - B

    @Fox Eric Lippert's words, not mine.


  • Winner of the 2016 Presidential Election Banned

    @masonwheeler said in Why He's Dropping Rust:

    @Fox Eric Lippert's words, not mine.

    I know. I'm just saying that even the purpose of JavaScript is irrelevant and inefficient.


  • Impossible Mission - B

    1995 - Brendan Eich reads up on every mistake ever made in designing a programming language, invents a few more, and creates LiveScript. Later, in an effort to cash in on the popularity of Java the language is renamed JavaScript. Later still, in an effort to cash in on the popularity of skin diseases the language is renamed ECMAScript.

    -- James Iry, A Brief, Incomplete, and Mostly Wrong History of Programming Languages


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.