> Rust works best with strictly tree-shaped data structures, but event handlers turn trees of widgets into arbitrary webs with possibility of circular references. This is also the problem with closures. And why you can't do Haskell/Ocaml style functional programming in Rust. Rust has the reputation of being fast, but if you force everything into a tree, you are making big compromises from the start.
I'd argue a GC is an order of magnitude bigger compromise though. And that even before considering performance.
Only when disregarding that many languages with GC capabilities, also offer value types and features for manual memory management.
I'd argue a GC is an order of magnitude bigger compromise though. And that even before considering performance.
Yes, so use Rust for all your tree-shaped programming problems. And a GC'd language for everything else. I know if you're holding a hammer it's difficult to not see everything as a nail ...
Exactly, hence why Rust's killer use cases are scenarios where having a GC is a no go option.
The elephant in the room for big CAD/CAM apps is dockable widgets, where (for me personally), the "standard" is how Visaul Studio does it. Even Qt, with it's built-in widgets is not enough (e.g. no multiple widgets/windows in non-main window), but there are some extensions/libraries/hacks to go around. Recently, few years ago, imgui got proper support for these too. And flutter has one or more design docs around it -…
Surprisingly enough, Qt's built-in docking system has not one but two actively-maintained open-source third-party alternatives, KDDockWidgets and Qt-Advanced-Docking-System. (QtitanDocking is a commercial third-party docking system.)
I'm glad Rust* is forcing us out of a rut in UI toolkit design. All of these spell hard-to-debug problems. * Yes, I know elm-derive UIs are also a thing and have laid a lot of ground work in this area. btw I've had great experience 10 or so years ago doing composition-based UI design in GTK with Python. When Maemo switched from GTK to Qt, the requirements on inheritance were one of my points of frustration and I got…
I wouldn't give Rust or Elm the credit for that, though. Although it was not first, React is really what put the declarative method for UI programming on the map. Today, there's a solid argument that by usage numbers React is the most used UI framework today, and it's children like Vue are high up there too. Swift also has a similar problem and unlike Rust has a powerful backer, so SwiftUI is in many ways already a v…
Except the borrow checker hinders the possibility to have components libraries, or a visual designer, unless it is RC all over the place.
I'm pretty sure the mismatch is just that the major ui frameworks were designed for oop languages, not that UI is inherently oo. As the gp said, react type frameworks play fine with languages that have no inheritance. It's just a matter of a few more coming along with the same paradigm(s).
So that's a good point, but I'm not quite sure OO is the issue. Also - as you hint it's entirely unnecessary, I do actually believe OO is a natural match for UI because of the overlap between components. I think it's the fact in UI you have a big chunk of state, with references all over, and sometimes doing sort of 'circular references' ... Rust code starts to have a lot of the various Vec Rc Cell Box all over the pl…
Isn't it done already? Kotlin plus a simpler OOP toolkit like javafx avoids all those problems. You have a GC to handle circular references, you have a decently strong type system, coroutines etc.
> On macOS ... going forward, it’s likely that new capabilities and evolutions of the design language will be provided for the latter [SwiftUI] but not the former [AppKit]. I think this is vastly over-stating the technical churn of UI development on macOS. While we're definitely seeing new UI toolkits introduced that are Swift-only (like the new Charts.framework[0]), nearly every Mac app Apple ships is written using…
Apple clearly stated at WWDC 2022, that the best days of Objective-C and AppKit/UIKit are behind them, they even had a slide for it in case there were any doubts.
> while Electron continues to gain momentum Electron is not gaining momentum, it already is the standard. No matter what people try to invent, it needs to do all Electron does but ways better.
> No matter what people try to invent, it needs to do all Electron does but ways better. Tauri strikes me as a good step up from Electron, and likely a better fit for Rust users (as you can code everything except for view in Rust), but I have just started playing with it.
> as you can code everything except for view in Rust
> On macOS ... going forward, it’s likely that new capabilities and evolutions of the design language will be provided for the latter [SwiftUI] but not the former [AppKit]. I think this is vastly over-stating the technical churn of UI development on macOS. While we're definitely seeing new UI toolkits introduced that are Swift-only (like the new Charts.framework[0]), nearly every Mac app Apple ships is written using…
I would remind you that Microsoft disowned MFC and aggressively pushed all developers off of win32api once .net was released. Then they went about rewriting visual studio in .net and possibly the office suite as well. I hope Apple doesn’t attempt this because, in my opinion, I don’t think Microsoft’s products benefited from that churn.
And yet a couple of devs sabotaged C++/CX efforts to the point that C++/WinRT with WinUI 3.0 isn't a match to MFC in tooling.
I'd argue a GC is an order of magnitude bigger compromise though. And that even before considering performance.
Yes, so use Rust for all your tree-shaped programming problems. And a GC'd language for everything else. I know if you're holding a hammer it's difficult to not see everything as a nail ...
Or, you use a non-GC language for any application where you care about memory (hint, vast majority of applications fall into this category).
GC is imo the single biggest mistake in software engineering.
I don't like React: https://news.ycombinator.com/item?id=31981947 > In Cocoa, scroll position is part of the view's state, a mere property of the view. This is simple because the UI itself is stateful. > In React, scroll position is typically not part of the state from which we project the view. Instead this state is attached to the projection itself (e.g. a HTML node) and we are dependent on the "Memoization Map" to…
I struggle to understand what you are saying here. What do you mean when you say "this memoization is now required for the correct functioning of the app"? I agree that there can be some issues with scroll restoration in routing, but it doesn't seem like a big issue to me and certainly doesn't seem to reveal some fundamentally flawed architecture.
Haven't written React, but it relies on memoization to preserve hidden state (like text carets and item scrolling) not tracked by your application. If you change the tree structure of your GUI (add/remove/move elements), and don't give scrollable UI items a key if they move, React will delete the scrollable DOM element and create a new one scrolled to the top, losing the user's scroll progress. The same goes for text fields with horizontal (or vertical) scrolling and active cursor position, perhaps text field contents (unsure), etc.