Giving up on wlroots-rs (2019)

I remember what C++ looked like in 1990s.

No, the roots, the general unkempt hacked-together style had started by then already :( it's the efforts of last decade or so which made a relatively reasonable language out of C++. It wasn't corrupted by the industry, but it did corrupt the industry to some extent.

Read this article and tell me it all makes sense to you:

https://eli.thegreenplace.net/2015/c-deleting-destructors-an...

Then have a look at what C++23 might bring,

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p137...

And the 'cetera' means essentially 'the rest'. Though it is common in modern usage to to use 'et cetera' to imply a continued list of items not named. A stricter interpretation would only use 'et cetera' to refer to the rest of a full list that has been previously explicitly enumerated earlier in the text.

As an example:

The authors of the text were James, Malik, Susan, Srini, and Ying. ... <some more text goes here> ... This was the primary finding supported by Srini, James, etc.

Above, the usage of 'etc' is to shorten the sentence, by avoiding a second instance of the full list.

A simple translation to English shows that the common usage can leave much up to the interpretation of the reader.

As an example:

I like sweet foods: cherries, apples, grapes, and the rest.

So, do I actually mean fruits? Do I mean all other sweet foods that exist? This sentence leaves a lot of interpretation to the reader, and depends on shared context to have any useful meaning. This usage of 'et cetera' generally means "and more in a sequence made up of items categorically in line with what I've named, which I assume, you, the reader, can infer."

This reply is not meant to critique modern usage. Language is a fluid thing, and the use delineating implication, rather than eliding a fully enumerated list, is perfectly acceptable in the vernacular. I just wanted to share some additional nuance regarding the phrase.

> It has the async/await syntax except it's extensible to any kind of coroutine semantics Interesting, I didn't know about this.

> You're also not forced to use it when it is not a good fit. But like all language criticisms that contain this sentence, it's better when the language makes it somewhat tedious to go outside of the norm, where the norm is defined as the 99% use case. C++ is the opposite; you have to go out of your way to use the generic, safe features like smart pointers or create copy constructors.

Rust's syntax takes cues from ML which means that things like switch statements (matches), if's, and even return are also expressions, which makes it nicer to refactor and allows you more choices when structuring your code.

Would this not be necessary in C? I've not written C since that one semester in college, so I'm having a hard time imagining how C handle this differently.

I'm going to go out on a limb and assume that they did not build a small proof-of-concept and do some benchmarking to see if those unnecessary branches actually result in any meaningful performance issue in the context of a Wayland compositor.

If I understood it correctly, monitor doesn't really go away in your event handler, so C code don't have to deal with that.

In C, you're supposed to listen for a "destroy" event on the output and then in the handler you would delete all your references to the object. I would be interested to know if any language has a way to statically analyze this, instead of using a monad.

Because, IMHO, a lot if not every of the GUI frameworks have been born by necessity and has a lot of cruft around that requires type magic incompatible with a strict language like Rust.

GUI toolkits are often really old (more than 20 years old at least) and have been either hastily hacked in C (often in C89, like Win32 and GTK+, which is famous to abuse refcounting and C macros and is a prime example of what I was mentioning above as a poorly designed library), or have been designed in C++ before C++11, so they largely depend on nasty hacks and practises that are considered obsolete in modern C++ (like Qt).

Other GUI toolkits are designed around modern garbage collected languages (see WinForms, WPF, Swing, ...) so they're not really usable from non-managed languages. Cocoa is in a weird spot, being written in a pretty-much duck-typed language like Objective-C.

My point is that IMHO it's not Rust itself that's not suited for GUIs, but it's the GUI toolkits that have often aged very badly and are out of touch with modern software development. The ugliness of developing UIs with the old frameworks is I think one of the main reasons why the web has taken over, and why others such as Qt have largely moved to a declarative approach with things like QtQuick (i.e. "almost JS") or Apple's SwiftUI.

It's all about keeping development sane, something Microsoft has IMHO canned several times by trying fix the mess they made with Win32, only by making it worse creating a dozen of competing, almost incompatible toolkits. The fact that the newest of them, written since its inception in modern C++ (C++/WinRT) has a nice to use Rust alternative (Rust/WinRT) shows that the problem wasn't the language all along.

GUIs can easily use shallow trees for ownership. There's a natural harmony between the hierarchical composition of UIs and ownership hierarchy.

E.g. Delphi's VCL has a simple and clear ownership mechanism. Components are owned by their Owner, which is either the Application (forms), a form (for almost all the controls on the form), or a control (for custom controls - normally nested controls are owned by the form). And there's a couple of eventing mechanisms to resolve peer reference relationships, and to negotiate dynamic control addition and removal. Unless you start adding components to collections or otherwise capturing long-term references to them (and you can use name-based access if you need a safe indirection), leaks and dangling references aren't that common.

Implementing that model in Rust, with usable borrows that stop you creating dangling references, isn't trivially obvious to me, but there are ways around, I think: message passing communication, passing closures in, or ephemeral trees which proxy access to the real UI tree.

Not having any control on how a library allocates memory is a huge downside, though, and it's something C++ has in my experience largely resolved (at the expense of ABI compatibility, which is something that IMHO hasn't hindered its adoption that much). Not being able of using stack for short lived objects is also pretty bad for performance, especially if the allocation/deallocation is done in a cycle. I understand the desire of maintaining a stable ABI, but I think this should be optional and at the discretion of the user instead of being shoved down as the only way to use a library. At least, I think such libraries should allow their users to overload whatever malloc/free the library is supposed to use, even though it's less than ideal.

You can implement monads yourself if you have higher-kinded types, but Rust doesn't. Without them you can't implement any of the standard helper functions that you need generically (e.g. monadic versions of control flow functions like ifM, whileM), you'd have to implement them by hand for each different monadic type instead. Thus the control flow problems in the #[dehandle]-based code.

And if you look at what #[dehandle] is doing, it's blatantly an ad-hoc implementation of do notation for these handle types. It's doing the same thing as async/await, or try!, but in (present-day) Rust everyone implementing a new "context-like" type has to write their own "very complicated procedural macro" to implement a specific variant for that context-like type.

(I don't think you necessarily need do notation to write maintainable monadic code - I'm a big fan of railway-oriented programming style i.e. (Kleisli) arrow composition. But of course you can't do that in Rust either, except by writing ad-hoc implementations of all the operators and helper functions for every different type you want to work with).