Maybe I missed some opportunities but with my later experience and in my line of work I got pushed towards webapps and these days PowerBI. I can make those work but I feel that as a beginner with VB6 I could build forms faster than I can do now in a browser.
Also, I remember not being completely precise: I maintained a hacked together GUI build in Access VBA. It had its warts but its web-based replacement didn't blow it out of the water and took longer to develop.
That's quite weird. These traits don't look like rust's traits, which really are a port of typeclasses from Haskell. I think the section about scala illustrates this well because scala's "traits" are an OO construct, but now scala 3 also" has typeclasses. So... Rust still isn't OO.
Qt is pretty damn easy I would say. And some Web UIs are easy too.
In any case this article is talking about the features that are unique to Rust that make it especially hard to write GUIs.
Though weirdly it focuses on lack of inheritance which is definitely not that big of a deal (Rust does have trait inheritance - you can even get full implementation inheritance using macros if you really want but I doubt it is needed). The biggest issue by far is state management because of the single ownership rules.
You can of course Rc-RefCell everything but that gets very ugly.
> The instant web enabled and normalized arbitrary UIs, "You can't have that" Delphi people simply went out of business. Because it turned out Delphi was far inferior at doing what people actually wanted.
What people think they want and what would make them happier and productive in the long run are different things. They buy junk food and complain they don't feel well. They buy Marvel movies, but in the long run stop going to the theater because movies aren't interesting anymore. Modern web apps are basically the incarnation of that principle.
Are people really happier and more productive with shitty web apps? Because it seems like everyone complains about Slack, Teams, etc. Google Docs certainly doesn't have the die-hard fans Word Perfect still has. Apple still collects quite a premium remembering that people don't know what they want and need people with judgment to make decisions for them.
> Are there even Delphi enthusiasts still, or is it just nostalgia?
There are.
There is a major commercially relevant DAW produced in Delphi. You can figure out which one.
> I believe Electron and web technologies are superior for UIs given their pragmatism and ubiquity.
This opinion is questionable given a clearly narrow view. Outside of this bubble they aren’t ubiquitous.
There are plenty of LOB apps still used and maintained in VB6. One of the most heavily used applications in the US federal government is a C++Builder app (the C++ RAD counterpart to Delphi) - it is a piece of crap, but that’s a factor of the authors not the language - and when it was first released more than 20 years ago it started up in a few seconds on hardware at the time with slow spinning disks! Looking at the vast majority of LOB web apps - nothing has gotten better on that front.
“Far superior... at making basic 90s UIs that nobody else wants today.
For better or worse, but the reality is nobody wants them anymore. Branding is a thing. When a client wanted something different you used to tell them "You can't have that" and they had to take it, because there was no other option.”
Were you actually there in the 90s and 00s or are you just imagining how things could have been?
I personally developed fully skinned UIs in Delphi’s cousin, C++ builder on Windows in the late 90s and in the 00s. In addition to that, VCL apps had a rich palette of drag & drop widgets, including commercial products that were better than anything the competition was offering, including Microsoft.
I used a lot of Windows apps over the years and literally everything from custom windows shapes, colors and background, to custom widgets and cursors, etc I’ve ever seen was possible to develop in Delphi or C++ builder.
”The instant web enabled and normalized arbitrary UIs, "You can't have that" Delphi people simply went out of business. Because it turned out Delphi was far inferior at doing what people actually wanted.”
Delphi was mismanaged by Borland, sabotaged by Microsoft and they charged a ton of money for the software. Starting with WinForms and C# MS finally had a reasonably competitive alternative to offer.
The web had nothing to do with Delphi’s decline. In the 00s we used a combination of back-end languages with some JS for enhancement and Flash for special cases or multimedia-heavy sites. Macromedia Flash remained the most capable web-based technology for a long time after Delphi was already in decline. As a former Flash developer, I can say confidently that Flash and Delphi/C++ Builder served different use-cases and were not competing with each-other.
One of the employees they lured away was Anders Hejlsberg, former chief architect of Delphi, which built C# at Microsoft. WinForms had an uncanny resemblance to VCL.
Before that Microsoft had tried to extend-embrace-extinguish Java with J++, but got sued by Sun into submission.
MS were utter scum back then, but Borland’s mistakes certainly didn’t help either.
You're not circumventing the borrow checker though. You can only access a hashmap/vec entry if you have the right borrow of it's container. Unless you play around with unsafe, the hash map entries that stay in the container will live at most as much as the container.
This is what the borrow checker does. The index is just for doing an If let Some(entry) = map.get(&ident) {}
and not fail if it does not exist. Do you want to keep stuff alive even if they are removed? You can use reference counter wrappers (Rc and Arc) just fine.
The right pattern for graphs etc in vectors and maps is that the owning struct/type is responsible for keeping its internal state (indices it knows to exist) consistent. But that's not a memory safety issue, it's a logic issue
JavaScript is popular because people like half-baked hacky things that give them instant rush/feeling they can do something (i.e. show something basic in a browser). So much effort was spent on painting a lipstick on this pig or to replace it but nothing succeeded unfortunately. It's the equivalent of some fast food in mental domain. If I wanted to damage programmers' minds I would push for this atrocity to become a universal standard. The quality of most node.js modules is horrible which never disappoint in reinventing existing things from other languages/frameworks in inferior ways.
It's not about styling, it was about how quickly one could develop a complete app by just following a few simple examples in docs. VCL + IDE literally guided you with very few things to learn. So a person uninterested in building UI but in the core of an app could build one in an afternoon, which is not possible unless somebody is an expert in web frontend development, wasting time/effort that could have been spent better elsewhere. I am glad I escaped frontend hell (I used to work on some web standard myself) and pivoted over to ML.
In Electron apps you still have the boundary between frontend and backend, that means it's in its core a distributed app. If you don't like GUI builder, that's a fair opinion, but I do and don't want to waste my time on textual descriptions of what is essentially visual, and don't want a Figma subscription to get some half-baked version of that either. Avoiding React equals to avoiding 95% frontend/fullstack jobs these days so it's only theoretical.
Searching for "expression problem" should find other discussion of the problem and solutions. The two best known solutions to the expression problem are:
- data types a la carte, which takes an FP style approach; and
- tagless final or object algebras, which takes an OO style approach.
Other solutions are possible depending on language features. E.g. the linked paper above uses mixins and units.
Overall I find the discussion in the original post to be a bit naive. It doesn't make the case that an OO approach is necessary or desirable. E.g. that an OO approach provides a form of extensibility that is needed.
In the FP world, if I wanted to build a UI toolkit I would start by defining by a combinator library (usually implemented as an algebraic data type) that describes the UI and then have an interpreter that constructs everything on the screen. This hides all the state within the interpreter, which makes it easier to avoid issues with the borrow checker. The OP didn't discuss this approach either.
I like Flutter and Rust, it's pretty nice. I actually like Dart as well, it has some very interesting features. I've used Electron and Tauri a bit before but I didn't like that it still wasn't "native," it still used a web wrapper.
That does not feel like advantage unless you can do relational algebra on it all, though. Without that, it's more like dBase and similar languages of that era, where you had to manually juggle tables and cursors. People did UI that way too, but there was a reason why the OOP approach with object graphs and references quickly became dominant once it appeared - it's still a much more natural way to model this.
Successfully for whom? As a user, I find that when a desktop app is using a web stack like Electron, that's one of the best predictors for poor and inconsistent UX.
Speaking for myself as a user, I want more basic 90s UIs that work in boringly predictable ways throughout, and less "branded" apps with weird colors and weird UX patterns because the designers (or whoever is ordering them around) are showing off for no good reason. On top of that, this trend killed a lot of customizability in UX that we took for granted for so long, like the ability to change UI colors and fonts system-wide - i.e. it took freedom away from the users. None of that is positive. So, no, it's not "nobody". I don't think you can even meaningfully say it's the majority of app users without polling them, since they generally have to use whatever is available to solve their problem, which all too often means picking the least crappy of 10 different web-style apps.
The biggest problem IMO is the insanely complicated layout system that is the way it is mostly because it was originally meant to handle long text documents. It took a while to bolt on enough things to have decent equivalents of app-centric approach to layout that desktop frameworks have offered for decades, but it still has to integrate with everything else in the spec, and devs need to know exactly what to look for. Ditto for styling. If you compare either to XAML or QML hands on, it quickly becomes clear just how much easier it is to work with the stuff that was designed for apps from the get go.
It was the standard way to do native UI on the desktop before composition became common in mid-00s. I don't recall it being particularly complex in practice, especially when the frameworks abstracted most of it away. E.g. WinForms running on WinXP would still be doing this under the hood, but you as a developer could just set up data binding and write the painting code for any custom widgets (and wouldn't have to care about it getting called at the right time).
37 comments
[ 3.0 ms ] story [ 35.7 ms ] threadAlso, I remember not being completely precise: I maintained a hacked together GUI build in Access VBA. It had its warts but its web-based replacement didn't blow it out of the water and took longer to develop.
Rust can provide encapsulation namespacing as well
ECOOP 2009 proceedings paper from a certain Simon Peyton Jones.
"Classes, Jim, But Not as We Know Them — Type Classes in Haskell: What, Why, and Whither"
https://link.springer.com/chapter/10.1007/978-3-642-03013-0_...
In any case this article is talking about the features that are unique to Rust that make it especially hard to write GUIs.
Though weirdly it focuses on lack of inheritance which is definitely not that big of a deal (Rust does have trait inheritance - you can even get full implementation inheritance using macros if you really want but I doubt it is needed). The biggest issue by far is state management because of the single ownership rules.
You can of course Rc-RefCell everything but that gets very ugly.
What people think they want and what would make them happier and productive in the long run are different things. They buy junk food and complain they don't feel well. They buy Marvel movies, but in the long run stop going to the theater because movies aren't interesting anymore. Modern web apps are basically the incarnation of that principle.
Are people really happier and more productive with shitty web apps? Because it seems like everyone complains about Slack, Teams, etc. Google Docs certainly doesn't have the die-hard fans Word Perfect still has. Apple still collects quite a premium remembering that people don't know what they want and need people with judgment to make decisions for them.
Are there even Delphi enthusiasts still, or is it just nostalgia? Would the people that claim Delphi is superior use it?
There are.
There is a major commercially relevant DAW produced in Delphi. You can figure out which one.
> I believe Electron and web technologies are superior for UIs given their pragmatism and ubiquity.
This opinion is questionable given a clearly narrow view. Outside of this bubble they aren’t ubiquitous.
There are plenty of LOB apps still used and maintained in VB6. One of the most heavily used applications in the US federal government is a C++Builder app (the C++ RAD counterpart to Delphi) - it is a piece of crap, but that’s a factor of the authors not the language - and when it was first released more than 20 years ago it started up in a few seconds on hardware at the time with slow spinning disks! Looking at the vast majority of LOB web apps - nothing has gotten better on that front.
Were you actually there in the 90s and 00s or are you just imagining how things could have been?
I personally developed fully skinned UIs in Delphi’s cousin, C++ builder on Windows in the late 90s and in the 00s. In addition to that, VCL apps had a rich palette of drag & drop widgets, including commercial products that were better than anything the competition was offering, including Microsoft.
I used a lot of Windows apps over the years and literally everything from custom windows shapes, colors and background, to custom widgets and cursors, etc I’ve ever seen was possible to develop in Delphi or C++ builder.
”The instant web enabled and normalized arbitrary UIs, "You can't have that" Delphi people simply went out of business. Because it turned out Delphi was far inferior at doing what people actually wanted.”
Delphi was mismanaged by Borland, sabotaged by Microsoft and they charged a ton of money for the software. Starting with WinForms and C# MS finally had a reasonably competitive alternative to offer.
The web had nothing to do with Delphi’s decline. In the 00s we used a combination of back-end languages with some JS for enhancement and Flash for special cases or multimedia-heavy sites. Macromedia Flash remained the most capable web-based technology for a long time after Delphi was already in decline. As a former Flash developer, I can say confidently that Flash and Delphi/C++ Builder served different use-cases and were not competing with each-other.
One of the employees they lured away was Anders Hejlsberg, former chief architect of Delphi, which built C# at Microsoft. WinForms had an uncanny resemblance to VCL.
Before that Microsoft had tried to extend-embrace-extinguish Java with J++, but got sued by Sun into submission.
MS were utter scum back then, but Borland’s mistakes certainly didn’t help either.
This is what the borrow checker does. The index is just for doing an If let Some(entry) = map.get(&ident) {}
and not fail if it does not exist. Do you want to keep stuff alive even if they are removed? You can use reference counter wrappers (Rc and Arc) just fine.
The right pattern for graphs etc in vectors and maps is that the owning struct/type is responsible for keeping its internal state (indices it knows to exist) consistent. But that's not a memory safety issue, it's a logic issue
Searching for "expression problem" should find other discussion of the problem and solutions. The two best known solutions to the expression problem are:
- data types a la carte, which takes an FP style approach; and - tagless final or object algebras, which takes an OO style approach.
Other solutions are possible depending on language features. E.g. the linked paper above uses mixins and units.
Overall I find the discussion in the original post to be a bit naive. It doesn't make the case that an OO approach is necessary or desirable. E.g. that an OO approach provides a form of extensibility that is needed.
In the FP world, if I wanted to build a UI toolkit I would start by defining by a combinator library (usually implemented as an algebraic data type) that describes the UI and then have an interpreter that constructs everything on the screen. This hides all the state within the interpreter, which makes it easier to avoid issues with the borrow checker. The OP didn't discuss this approach either.