Iced: A cross-platform GUI library for Rust, inspired by Elm

> That's just your opinion, there's no such thing as a blessed license scheme by the community. GPL is a perfectly valid choice if you feel like it

I didn't state an "opinion." I'm stating an observable fact. And don't paraphrase what I said - my words are right there and you don't need to play games with what I said or didn't say: I never said anything was "blessed," I merely pointed out that by and large, the Rust community has - whether you like it or not - mostly settled on MIT/Apache 2.0 (as in, the de facto license). I even couched my statement very carefully as referring to "foundational" crates, even though - as a matter of fact - it applies to the majority of published open source crates regardless of whether or not you consider them "foundational."

You can see for yourself with this breakdown of crates on crates.io by license (scroll all the way to the right): https://gist.github.com/passcod/2e1983ce415b32bdf3a0

Different languages/communities built around common languages or frameworks tend to "settle" (there's that word again) on different licenses. These are typically (but not necessarily) the licenses that the language/framework itself is licensed under. In rust's case, the majority of what you might consider "foundational" crates - i.e. crates that are intended for consumption by the broader community to build the basis of other projects in the same way that you would depend on the standard library itself, be they runtimes, util libraries, etc. have, by and large, accepted either MIT or dual-licensed MIT/Apache2.0 as the default to start with, unless there's a compelling reason (such as starting a business around it!) to do otherwise. There's nothing wrong with picking a different license, it's just less likely for the community to converge around a more strictly licensed option. That's just the way the world works.

And what makes you think the widget can't give this information to the user of the library which would Then invoke the IME/whatever input system and give the result back to the widget in an platform independent input/character event?

   // pseudo-interface
   class TextWidget {
     ...
     WidgetEvent HandleMouseEvent(const MouseEvent& m, ...);
     WidgetEvent HandleKeyboardEvent(const KeyboardEvent& k, ...),
     WidgetEvent InputEvent(const InputEvent& i, ...);
   };

  // client code.
  PlatformMsg msg;
  while (GetMessage(&msg, ...)) {
      WidgetEvent event;
      if (IsKeyboard(msg)) {
          event=widgets.DispatchEvent(MapKeyboardMsg(msg),...);
      } ... {
     if (NeedsIMEInput(event)) {
       OpenIME(ExtractDetails(event)); 
     }
  }

The client application interfaces with the native/platform/synthesizer API/wrapper library to read/generate events from apps message queue/script/internet/whatever and maps those into platform agonistic events supported by the widget library and dispatches them into the library where the library decides which widget will receive them etc. The widget will react to the event and in the case of the text input widget will return back an event with the relevant information for invoking some IME system (in this example). The client code interfaces again with the native/platform/synthesizer to do what is asked and then dispatches the result back to the widget which will update its state.

This design will basically have the same functionality but will split the responsibilities so that the widget system would not depend on the input system. This allows the two to vary independently and remain agnostic of each other thus promoting reuse and testing and simplifying the implementation (IMHO).

The question is not about how to invoke some IME, it's about how to separate these concerns and de-couple the widget system from the input system by delegating the invocation (and required details) to somewhere else. I don't see any real reason that warrants tight coupling.

> For example, did you know that C#'s string's hash code calculation is nondeterministic across runs? ... iterating Rust's/Go's default hash maps, etc.

I do, but I also know that in Java, C#, Rust and Go it's well documented that you should not rely on the iteration order of the values in a hashmap or hash-based collection, which (at least in Go) is one of the reasons hash-iteration order is randomized across runs.

If a bug is caused by this kind of nondeterminism, you're likely to catch the bug by replaying the history multiple times. In other words, if the history isn't perfect due to nondeterminism, the history is still useful in tracking down bugs because that nondetermism will be revealed over multiple replays.

"By opaque, do you mean encapsulated?"

By opaque, I mean the only thing you can do is execute them. While this is encapsulated, it isn't at the right level of control.

" but the GUI layer is (imo) definitely the wrong place to do it. When's the last time you wanted to filter, prioritize, secure, or distribute UI events?"

Ironically, the GUI is already that way. Under the hood, enumerated values were passed to your program by the windowing system. It has to be, because there's a serialization layer there. GUI programs already have no choice but to be structured this way, and indeed, also certainly have some sort of filtering mechanism in them to do things like ignore events it doesn't want to handle. You're probably programming at an abstraction layer that is already sitting above that. You think this isn't useful in a GUI precisely because the GUI framework you're using implemented this pattern for you already!

"Your hybrid idea is interesting! Is that doable with Rust in practice?"

Really it's just creating objects that have various inspectable attributes as needed, that also have some trait or something that allows them to be called in a uniform manner. It's not too hard, it's just a bit more structure around what is already there; you basically copy & paste the closure into the method of a new object, and make the capture explicit in the object.

> I don't think you're suggesting we serialize the entire GUI?

I am, exactly -- to enable WYSWIG construction/editing of the GUI. Just added another comment saying this below, but consider Android Layout Editor/Apple Interface Builder (or someone else mentioned QT Creator, which I'm not familiar with but has the same idea).

> I don't think you're suggesting we serialize the entire GUI?

Yup that's exactly what people do in some GUIs. Tons of GUI frameworks and systems rely on varying degrees of defunctionalization and serialization. Microsoft COM and XServer for example. I don't know exactly how granular they get but I believe it's quite granular in what you can do over RPC.

> Do you think that at one point Rust could automatically transform my code into defunctionalized form, and thus make it serializable?

For a pure function some kind of bytecode representation is certainly conceivable, but as soon as you add captures it gets much more complex.

> QT Creator

Precisely, yup; or Android's Layout Editor/Apple's Interface Builder.

Bare function pointers are, but not state-capturing ones (see my other comment for why that is). Without state capture, closures really aren't more ergonomic to use than enums in most cases, and are often less so.

It seems you're right. That didn't work the last time I tried it—which I admit was some time ago—but it does work in the latest stable version of rustc.

Relying on "type stability" (which I assume means no structure-altering mutations are allowed) is pretty similar to "just use atomics" as a strategy, which is what languages like Java and C# employ (it also has some similarities to the "value restriction" in languages like Standard ML and OCaml).

However, this can be quite restrictive depending on your definition of type stability (and what optimizations are allowed); for instance, Rust considered changing a value to null to be a structure altering mutation and is able to optimize around that, while it sounds like Vale cannot.

The rest of it sounds a lot like Rust (though I'm not sure whether regions are more like arenas or lifetimes, I'd have to look at the implementation, but generally speaking people call the same kinds of things regions even if they weren't trying to coordinate, and the performance tradeoffs you're describing sound really similar to those of regions in other languages). Overall, like I said, it sounds like a very interesting point in the tradeoff space!

Edit: Also, I misspoke when I said MLton, what you actually want is the similarly named sister project MLkit (http://www.mlton.org/MLKit ; see http://www.mlton.org/Regions for details on why they did not end up going with this strategy).

> I've never dabbled with multi-threading in Rust, so I'm curious how far it can go in practice.

Extremely far. The strict mutability rules are basically your downpayment for the easiest safe parallelism of any production language (that isn't purely functional, anyway). In particular the Rayon library (https://docs.rs/rayon/1.5.1/rayon/index.html) allows you to make your sequential code parallel by merely changing `.iter()` to `.par_iter()`, and experimentally offers comparable performance to best in class work stealing schedulers, often outperforming manual C and C++ implementations of the same algorithms.

> In our closure, we probably can't have any RefCell or Rc or anything that could reach either of those things, because those can't be safely reachable by multiple (even read-only) threads.

Assuming you're talking about Vale, I'm curious how you actually enforce this in practice. `Cell<T>` is basically an "overhead free" type in a single-threaded context, but it's not safe to access from multiple threads since it lets you mutate through a shared reference. To get around that, you either need to have a different type for shared references from other threads, or you need something like GhostCell, which separates permission to read/write to the Cell from access to the Cell itself. I would have to learn more about how your language works to say more.

If you're talking about in Rust, yes, you're correct. Using `Cell` or `RefCell` prevents use with automatic parallelization APIs, which is one big reason they aren't just done automatically for you (as they effectively are in many other languages). However, there are thread-safe mutability types with various tradeoffs: atomics in specialized cases where the type has native atomic operations, mutexes and reader-writer locks for thread safe concurrent mutable access, and APIs like GhostCell that use type-level trickery to make access safe without overhead, at the cost of a more complex API (something like GhostCell probably has the best performance tradeoffs for the UI case, but it is not very easy to use!). For `Rc`, your option is more straightforward: just use `Arc` and you are thread safe again (assuming the type you're protecting is).

> And I think these closures can't contain references to the outside world? I might be wrong on this one. And maybe structured concurrency could help here, though RefCell and Rc might confound that.

Rust closures can contain references to the outside world--and usually do! The references are just heavily restricted, as the text notes, to the point that it's hard to use them for callbacks (it's still possible, but there's a lot of ceremony).

> How well do Rust closures work in practice? Have you found a good use for them?

Hm, apparently I should have explained this up front, since apparently I did a bit too good a job explaining the downsides! Closures are used very heavily in Rust, almost everywhere in fact. They're a cornerstone of the Rust iterator API (probably the most commonly used trait in all of Rust), Rayon's parallelization API, numerous methods on Option, Result, etc., and are exploited by tons and tons of functions. Closures are very restricted, but you also get a lot as a result--they not only parallelize well, they are zero overhead abstractions that frequently inline to the same thing as hand-rolled SIMD (as noted here: https://twitter.com/badamczewski01/status/138634513508098458...) which means people are never worried about performance overhead when including them in abstractions. They can also be boxed, reference counted, etc. to erase their types in cases where you're okay with paying for dynamic dispatch (in which case they more closely resemble closures in typical languages).

So, they work extremely well in practice! What don't work well in practice in Rust are "callback registration" patterns in general. In fact, this is so much the case that I'd say finding a way to do things without callbacks is the main reason people need to refactor their applications for Rust.