Why is every project on the HN front page these days Rust this, Rust that? I understand the enthusiasm, but sometimes it seems a bit much.
Oh, this is my post. Never mind, carry on.
More seriously, this was my contribution to the Rust 2021 blogging effort. I didn't really intend for it to be posted to HN, more as in internal discussion within the Rust community. Even so, I'm happy to discuss and answer questions.
This is coming from an outside perspective, and I'm quite prepared to be badly wrong.
I think the Rust language needs to learn a few tricks from Objective C and Swift to really make this possible. In particular the work being done on extensible protocols.
What you can do, is build a 'Rust-flavored' GUI library. But this isn't what users want: they want a native app, while developers want to write once-run anywhere.
This requires a kind of double decoupling, where UI intent is expressed as an abstraction, and is realized as an OS-native control — but one which itself will dynamically update, insofar as possible, as the OS evolves.
This calls for a kind of API wizardry which Objective C always got right, and C++ never really did. I see that dichotomy extending into Swift and Rust, but it isn't inevitable, Rust hasn't painted itself into that particular corner.
Anyway, it's encouraging to see this work happening, I wish you good fortune in 2021 and beyond.
Check out Raph's retrospective on his xi editor project [1], particularly the section "There is no such thing as native GUI", for his take on why using platform-provided ("native") controls isn't always practical, at least for the applications he's developing. Anyway, cross-platform wrappers over native controls have been done in other languages, e.g. wxWidgets in C++ and SWT in Java, and that approach has enough limitations that AFAIK most developers of complex applications avoid it now.
I will miss dearly the good old days of Cocoa GUIs that adhered to Apple's Human Interface Guidelines (and when HIG itself was about usability, not looks). They all supported all the little things of Cocoa (like click-hold-drag on popup menus activating items on mouseup, or proxy icons that gave quick access to files of documents in any window, or search pasteboard).
Nowadays native apps on Mac are dead. Even Apple is giving up. There are still native-code-running .app bundles, but they're Qt, Electron, or Catalyst that are like knock-off brands of Mac apps. Even if they bother to have vaguely Mac-like skin, they lack all of the nice little details that made Cocoa apps great.
I know you’re saying that in a subjective way, and definitely the percentage of non-Cocoa apps have gone up, but I’m not sure if they’re dead. In fact, I feel that they are thriving once again in 2020 — a lot of indie devs that care about making Mac-assed Mac apps[0] are present and are releasing great apps and replacing ones that were filled with Electron.
Some examples that pop up in my mind: NetNewsWire 5[1] (an RSS feed reader), Shrungs[2] (a Cocoa Slack client), MimeStream[3] (a Gmail email reader), Chime[4] (a Go IDE that’s entirely Cocoa! I seriously considered learning Go because of this app), ProxyMan[5], and I can go on and on...
My feeling is that Electron got a bit of traction in like 2014~6 but people started to realize they really do like Cocoa better.
Agreed. I'm one of the rare folks around here who, despite decades of deep Unix experience, prefer decent GUIs to the command line, and Cocoa really is the best you can get in general use today. The decreasing number of native apps and the increasing number of apps that don't have all the nice little affordances makes me sad.
Same here, that is why I am so critic of those that use 25 inch screens to organize xterms and nothing else, I was doing that in 1994 with twm on IBM X terminals, something better is to be expected in 2020.
> that is why I am so critic of those that use 25 inch screens to organize xterms and nothing else, I was doing that in 1994 with twm on IBM X terminals, something better is to be expected in 2020.
Seems weird to criticize people for working in a way they like to work. The "something better" might just be improved command line tools. I think there's room for both, and different people prefer different types of interfaces.
I haven't used a Mac in ages, so I'm unfamiliar with any unique features of Cocoa over what one gets with e.g. GTK+; what would you say the features that make it better are?
I'm usually a bit skeptical of current-generation GUIs (but then again, I'm ignorant of the Mac world) largely because it's usually so much more painful to extend and compose them. To pick a perhaps slightly unfair example (since it's basically about text processing), I use Weechat for chat rather than Pidgin, since the UI inconvenience of it being a CLI is outweighed by how easy it is to process my chat history, programmatically interact with notifications, and how much more functional Mosh/SSH are than X11 forwarding.
Speaking as a user, I don't particularly care if the widgets are native or reimplemented - what I care is whether they look and feel native. E.g. on Windows, a Qt or even a Tcl/Tk app can easily look "native enough" that nobody will care.
On macOS the native UI language is very consistent and it’s very easy to decide whether an app looks and feels native. And AFAIK Qt is the only production-ready cross-platform toolkit that even comes close to native on macOS.
On Windows there are like at least three or four kinds of “native”, I don’t even know what’s “native enough” there.
I can only think of two kinds of "native" on Windows when it comes to look & feel - Win32 apps, and WinRT apps. Ideally, a modern GUI framework would have backends for both.
(Stuff like WPF still has a Win32 L&F, even if it draws the widgets itself, same as Qt.)
In my opinion there's more than two kinds of native if you pay attention to the details.
Themes: Unstyled Win32, styled Win32, WinForms (which is part Win32 and part custom controls), WPF (which sorta imitates Win32 and doesn't quite look like it), and UWP.
Fonts: Microsoft Sans Serif, Tahoma, Segoe UI, and non-English fonts.
What's the development experience scene like for Rust GUIs? In my experience developing Electron apps there are a a couple major plusses that I'm not sure Rust can compete with, based only on my limited knowledge of the ecosystem:
- Excellent embedded developer tools. Hundreds of thousands of engineer-hours have gone into the chromium devtools, providing everything from styling overrides to layout metrics to profiling tools to a REPL to DOM tree inspection and modification, to an integrated debugger, etc etc etc, and all of that is at your disposal with a simple Cmd+Opt+I. To my knowledge Rust doesn't have anything like this.
- Super quick incremental updates. Making a change and seeing the impact is sub-second, even on large projects (vscode). Based on my understanding of rust, recompilation can take a very very long time. When making GUI's a lot of the time is spent making finicky little changes and reloading -- if that inner loop is slow you're going to have a bad time.
I've talked up the strengths, you've brought up the big weaknesses. I think there is some interesting work on both of these fronts, but the developer experience situation is very primitive so far by comparison.
Compile times have been getting better. For reference, on my machine an incremental build of Runebender is 2.3s. Part of this reflects some choices we've made to use platform capabilities rather than build the entire stack ourselves.
I've developed a Gtk GUI in Rust recently. It wasn't bad, but I probably won't use it ever again. When I'm debugging a UI, I want to right-click it, select Inspect, and be able to tweak everything live.
DevTools is such a force multiplier, that I'm confident I can quickly and reliably develop a whole GUI from scratch, with custom layout animations and bells and whistles using JS+CSS. I have zero confidence in doing anything in Gtk or Cocoa beyond dumping static pre-built controls in a window. The cycle of editing blindly, recompiling, and re-running is the old paradigm that I don't want to return to.
Seems to me like the future could well be TS/Electron with bindings to Rust for system-level high perf activities. Let the UI scripting language and mature rendering platform do the UI scripting and rendering, and let the high performance systems programming language do the performance-critical system interfacing.
For example, in vscode we do almost everything in TS, but shell out to ripgrep for workspace text search.
This is what some people have started doing, and it works well as long as your bottleneck lives outside of the UI itself. But for some highly complex apps, web layout itself can become the bottleneck, and that's really hard to work around. VSCode is an absolute miracle in this regard, but it uses lots of dirty tricks under the hood to accomplish that.
Great, here is an off topic quick feedback to someone from VSCode, in what concerns search I always end up starting notepad++ Ctrl-Shif-F, get what I was searching for, meanwhile VSCode just keeps showing its increasing blue line without any results to show up.
Which is quite disappointing, given ripgrep's reputation in search performance.
Flutter is an example you can have efficient AOT compilation while not sacrificing ability to hot reload during development.
The tooling is not here yet. But there are drawbacks to using web and flutter is already promising. Any progress in this field should be welcomed by us.
Otoh, despite the name, electron apps are very heavy in terms of both memory and disk size, have a long load time, and can be very slow if not designed well.
Same applies to other native GUI tools, like WPF/WinUI(UWP), Qt, Cocoa,...
The Rust semantics also seem to make it quite complex to just drag components around on a GUI designer, because the lifetimes become dynamic and just dropping a component in the middle of a form can have multiple lifetime meanings, depending on the surrounding context.
GammaRay is like Dev Tools but extremely unstable, and requiring fiddling with ptrace permissions on Linux, and I don't know how to make it work on Windows.
> I wouldn’t consider a toolkit “ready” for production use until it supported accessibility, and as far as I know there is nothing in the Rust space even starting to work on this.
Have you given much thought to the design of Druid's accessibility layer yet? I might be able to help with that and with a Windows UI Automation implementation in my spare time (a stable com-rs would help with that). I guess this isn't much of a priority though for your hero app (Runebender).
Help on this is more than welcome. It's also not as far off the roadmap as you might think. I know of at least three very talented font designers with disabilities, at least one who uses a wheelchair. It would please me enormously to make a tool suitable for them, and I would push other priorities back for it, just because I consider it so important.
In any case, I haven't done detailed design work on accessibility, but enough poking around to get some sense of what might be involved.
You are right that stable com-rs will help a lot with this kind of integration; there are soundness and other issues with the custom com implementations we've had to do. Fortunately there are good people working on it.
I agree that accessibility support is a good proxy for maturity. Even if somebody tries to game perception by doing accessibility "early", there are benefits.
On that topic, what are GTK's and Qt's accessibility support like? I remember that once when there was a real prospect of Free Software being made preferred for public acquisitions, somewhere, a big disabled-support group argued that the Free Software stacks lacked accessibility support, and would shut them out. Would such an objection be plausible today?
Qt supports the native platform accessibility on Windows and Mac, and "AT-SPI" on X11 [0].
Windows and Mac has been supported since at least Qt 4 in 2005. I think there was also some support in Qt 3.
The archived Qt 4 documentation says X11 support is "preliminary".
Why not just take the React-native model and port it to Rust (whatever that translates to)? From my POV for 85%+ of things it’s good enough and would be fairly simple to implement.
2) widgets, don’t really care if they are native but some building blocks (button, lists, activity indicator etc.) The list from React native will do for now.
3) layout using flexbox and the exact same simplified css with the cascade.
Which is more broadly known about and used, Tk or React Native? It really doesn’t matter anyway, I’m just suggesting these things that work fairly well to avoid more standards proliferation. It won’t work.
Raph's previous post (linked in the first paragraph) goes into more detail than you could imagine on the options and differences and tradeoffs involved…
Two things. IMHO (of course) and GUI toolkit needs to be usable from other languages, I hope that's part of the plan. And also, Don't use platform-specific features or be a wrapper over their widgets. Be a GUI toolkit that works everywhere.
It came out as programmer's favorite language for the past few years so it shouldn't be a surprise. You should be posting articles for your favorite language and let it float to the top.
That's a pretty broad question, but overall I favor deeper integration with operating system and platform capabilities. Some people see GUI as something to be built over an abstraction layer consisting of delivery of mouse and keyboard events, plus a fast pipeline to render pixels. I think that misses some opportunities.
This is one reason I'm really enjoying Rust. When it comes time to do some platform integration, you just haul out the unsafe keyword and write it, nothing in your way. By contrast, when I was working on Android and had to do a lot of JNI, it was painful.
Can't answer for Raph, but deeper integration with the OS interferes with portability. You need enough integration for things to work at all, but after that, integration is in competition with portable features for developers' attention.
Attention is always the scarcest resource, all up and down the stack.
I don’t know why, but this reminded me of HN about a decade ago when people would post Erlang articles en masse as a means to make sure non-technical people were bored and wouldn’t hang around. I guess it didn’t work in the long run!
1. As your question touches on, it was. The codebase has grown organically from its start as xi-win.
2. The xi-editor project had other problems which I've written about extensively in my retrospective.
3. It's hard to compete against MS VS Code. When I started xi, the competitive landscape had a huge gap between performant and feature-rich but bloated editors.
I agree, but as an emacs user that has tried it multiple times, I really don't "get it".
The main thing that excited me about Xi wasn't Xi itself, but rather that its technology stack could be user to "build your own editor" using a solid foundation. That includes a more modern emacs, vi, vs code, or whatever you like.
Oh, this is my post. Never mind, carry on.
More seriously, this was my contribution to the Rust 2021 blogging effort. I didn't really intend for it to be posted to HN, more as in internal discussion within the Rust community. Even so, I'm happy to discuss and answer questions.
Read some more thoughts about Rust 2021 here: https://readrust.net/rust-2021