I've just learned Rust and I think I'm in love

What I find really hilarious is how the OOP propaganda from the 90's got to the GTK+ people on the design level, but not the language level. A mismatch that keeps giving.

I feel a lot of doors will open for Rust once this postponed RFC gets implemented.

but this part of the Rust ecosystem is not mature

In the sense that it's still in nappies, yes.

not denigrating the work of the relm devs, but nobody wants to use GTK if they can help it. It looks like shit on Windows and Mac, making the whole library pretty much a non-starter on those platforms.

[deleted]

Translation:

Well, you don't if your definition of GUI is just "Not what free Pascal does." That's not mine though.

Jesus you don't need to do that at all in basically any non-OOP framework.

Is your head really stuck that far up Pascal's ass?

Have you ever used a non-OOP language or even used any non-OOP features in any language?

Did you know that inheritance isn't the only form of ad hoc polymorphism?

Any system that provides ad-hoc polymorphism could be used, not just OO.

Just having generic methods al a CLOS, even without inheritance, would be enough for that (or typeclasses, or traits...)

/unjerk

I guess this harkens back to the "what is a class" thing. In my very limited experience, you can implement methods and control member visibility on Rust structs, such that they resemble C++ classes closely, insofar as how you invoke them in day-to-day life (obj.method() syntax, RAII, etc.)

What Rust won't give you is fine-grained const interior member variables that are set once during construction, method overloading, and, as already mentioned, inheritance. For the latter, Rust wants you to use traits (read: interfaces) and composition instead.

TL;DR that's correct, u/saddertadder.

(edit: also, going offtopic, Rust enums are closer in spirit to C++ "enum + std::variant" than "enum + struct")

What exactly do you think the major differences are between it and something like React

Eh, I'll try.

The minor point is the web-based part, which results in a lot of flexibility (easy to build all kinds of layouts and designs, at the cost of not having any uniform "platform-native" look - think Spotify for example). But that's not what I'm mainly talking about.

The big difference is the that in 90s-style RAD tools (Visual Basic and the like), you can typically only design the initial state of the UI - how it looks when the program first starts - and then you either manually mutate it in code, or use some kind of data binding library (or a mix of both).

Say you want to display some kind of data that you fetch from a server, e.g. a list of users, and a bunch of buttons next to each user for actions, then you can "expand" each user to see their email addresses and you can do a bunch of actions on those as well. Something like this: https://imgur.com/HxP0ix7.png

Then you have fields on the page that display some aggregate data (total number of users). And the whole screen can also be in a "Loading..." state (https://imgur.com/tnwJC54.png) and a "Failed to load data from the server" state.

With traditional GUI libraries such as Qt, this is a major pain in the ass to achieve. You have to awkwardly wrap your data by subclassing base model classes such as QAbstractItemModel. Then you have to manually notify the model of changes whenever new data comes in, deal with sorting and filtering via additional models, etc. And that's in the better case - the more naive solution would be to manually add/remove UI widgets, manually call .show(), .hide() on the loading screen, enable/disable, setText, and all the other mutation methods, which pretty much guarantees you'll end up with your UI being out of sync with your data sooner or later.

In React, this is way more pleasant to work with. You simply write a render() function that returns how the UI looks in the current state, kind of like immediate-mode rendering, so you can just do:

// Top-level component:
return <Box>
    {props.loading ?
        "Loading users..." :
        props.users.map(user => <User key={user.id} data={user} />)
    }
</Box>

.

// User component:
const data = props.data

let emailView = <span style={styles.loading}>Loading data...</span>
if (!data.loading) {
    emailView = this.renderEmailView(data.emails, state.isEmailExpanded)
}

return <Box>
    <span style={styles.name}>{data.name}</span>
    <ButtonGroup>
        <Button enabled={!data.loading} onClick={() => props.onUserApproved(data)}>Approve</Button>
        <Button enabled={!data.loading} onClick={() => props.onUserRejected(data)}>Reject</Button>
    </ButtonGroup>
    {emailView}
</Box>

And you don't have to worry about "changing" anything in the rendered UI, ever - the library calculates all the changes for you.

You just write a function that answers the question "given this particular state, how does the UI look?". This approach is not a magic bullet - there are still other parts of the app you have to design properly, but it is overall way more pleasant to deal with than any "traditional" desktop UI library.

I even tried writing a toy library like that, and this is a gif of working with it (1.1MB), that I have on its github page.

Does Lazarus have anything like that? (If it does, I just wasted a good 20 minutes writing a long-ass post, lol.)

pwned that redditor le epic style, nice.

You think that because not every single GUI toolkit in your arbitrarily chosen set can be coded against, that therefore Rust is unviable for GUI programming? How retarded.

Not to mention I don't use Rust nor half of those GUI toolkits so why would I know? Spewing out requirements for things to do isn't even close to a valid explanation for why you think there is exactly one viable way to do GUI programming.

Does it have to look native in any of those or you can use Free Pascal?

I wouldn't really say pascaljerk, it's just one dude that likes it and everyone else taking the piss.

This but unhilariously.

intercourse without premature termination

Does Rust impose a specific form of polygamy?