Hacker News Reader

Comment by raphlinus | Hacker News Reader

I'm not sure what you mean by posting just this link. But I'll repeat what I've been saying for a while. The Rust ecosystem is making significant advances toward building what I believe will be a world class GUI toolkit, but we do not yet have a mature, usable solution, and getting there will take time. There are no shortcuts either, though it is possible to get something working by lashing together existing pieces.

I obviously consider Druid to to be one of the most promising approaches, but even that aside there are other projects that could become a solid GUI toolkit, including Iced. I also encourage people to look at Makepad, as it does a lot of innovative things and emphasizes priorities such as small binary size and fast compile time.

View on HN

I would argue it’s not possible for Rust to have a “world-class” toolkit, because it seems implied that it’d be cross-platform. This means it’ll always lag behind UIKit, AppKit, GTK/Qt, and... whatever Windows has these days.

The Iced project used as an example has a custom renderer for example... does it support VoiceOver? Does it support every standard Cocoa keyboard shortcut?

Rust wrappers for these existing libraries (some exist) that maintain all functionality is what would allow “world-class” apps to be built in pure Rust IMO.

wxRust needs to be resurrected. wxWidgets is a wrapper around native controls.

I agree that support for VoiceOver (and other assistive technology) and full support for keyboard shortcuts is essential for a production GUI toolkit. We certainly don't do those yet, but I do think we can get there.

Rust makes it easier to bind platform capabilities at a low level than most other languages. As an example, we do cut'n'paste cross-platform, supporting complex media types, not just plain text, so we can round-trip a vector glyph from Runebender to other font editors. I think that's a taste of being able to take on these more ambitious challenges.

Also, "native" UI toolkits are a lot less actually native than they used to be. On Windows, the old HWND-per-control and GDI drawing model (long considered the standard for "native" Windows UI) is long obsolete, and there are actually a whole bunch of toolkits that people use, with UWP the most actively supported. Apple has a stronger story, but even there you have AppKit + SwiftUI, and technically Catalyst is officially supported, though nobody would argue it's actually a good experience.

And the fact is, a lot of people are using Electron, because it actually solves the business problem of delivering good-enough UI. I think we have a good shot at competing against that niche, and also that building it on Rust is a more solid foundation than any other language ecosystem.

You are also missing the eco-system part, having just a bare bones GUI support isn't enough.

A sucessful Rust GUI also needs the likes Telerik, Component ONE and similar third party vendors with GUI component libraries.

Of course. And once the basics are in place (again, they're getting there but not yet), why wouldn't that ecosystem develop of it?

For sure, it depends pretty much how the framework will look like.

I still can't think of a way to make borrow checker deal with a GUI designer and drag and drop of components(which should be able to be plugged anywhere on the visual tree), or even something like SwiftUI, without forcing Rc<RefCell<>> everywhere.

I am looking forward how Rust/WinRT will look like with WinUI, but again, COM means AddRef/Release everywhere.

> something like SwiftUI

one thing im having a hard time wrapping my mind around is, if swiftui depends on (please correct me if im wrong) the swift compiler itself and emited static type information from that compiler, how can rust build an interface to that easily?

it seems like you'd have to make some kind of wrapper lib that emits extern c interfaces that take and return `AnyView` and thereby hurting performance...?

By having macros that produce the required information, similar to how Qt, wxWidgets do it, and Rust/WinRT is in the process of doing.

https://github.com/microsoft/winrt-rs

But that is the easy part, the hard part is having the ability to plug a widget anywhere on the tree without triggering a bunch of lifetime errors. WinRT gets around this because it is built on COM, so you get reference counting no matter what.

interesting... though since winrt is c/c++ based its probably easier for rust to interface with, guessing...

but afaik with swift there is static type information encoded at the binary level that swiftui (e.g `some View`) utilizes to do type-based tree diffing, so i wondered how rust can generate that, even with macros...

maybe im mistaken though!

(thanks for the reply btw)

React (vanilla, Native, and Electron) is the one to beat here, not platform native toolkits. For a toolkit to be world class today it needs to be cross platform across web, Linux, Windows, Mac, iOS, and Android.

Companies want to reduce duplicated effort per platform, in order to make frontends faster and/or cheaper. That's the number one feature a toolkit can have.

Eh, there have been "promising approaches" for years now. It's clear that GUI is not one of the priorities of Rust developers, and that's OK. Its real innovations are more important for lower-level stuff anyway.

As someone not at all involved in Rust but interested in its progress, I think this is an important milestone to hit.

In most orgs that I've been a part of, no language tends to meet the standard for consideration until it has been the core of at least one very large public software project.

A functioning GUI toolkit is likely a major barrier to that happening in Rust.

Until then, we know it exists but doesn't pass inspection for inclusion. So far the largest things we know of built with it are Servo's CSS engine and the NPM authentication service.

> In most orgs that I've been a part of, no language tends to meet the standard for consideration until it has been the core of at least one very large public software project.

> So far the largest things we know of built with it are Servo's CSS engine and the NPM authentication service.

Here are some others, for your consideration:

* Dropbox's storage layer: https://dropbox.tech/infrastructure/extending-magic-pocket-i...

* CrosVM is an important part of ChromeOS https://chromium.googlesource.com/chromiumos/platform/crosvm...

* Firecracker is the underlying tech of AWS Lambda and Fargate https://firecracker-microvm.github.io/

* More coming from Amazon I don't have the ability to easily cite just yet, I hope the re:Invent recordings go up somewhere sometime soon

* "EdenSCM is the primary source control system used at Facebook,": https://github.com/facebookexperimental/eden

There's a bunch of other stuff too, of course. Apple has been hiring, but I don't think their usage is public yet. Microsoft is hiring rustc hackers, and has some other stuff going on. And tons of other stuff that may count as "large" depending on how you define it.

What about Cloudflare? I thought they were really using a lot of rust, but maybe that was just because you joined for a time!

You know, I was like "I know I am forgetting some major stuff" but couldn't put my finger on it, and yes, that is absolutely one of the things I've been forgetting.

They are using quite a bit of Rust:

* The 1.1.1.1 app's core is in Rust (this is one of the most prominent, if not most prominent, usages of Rust on iOS/Android)

* Their HTTP/3 implementation is in Rust (I am very excited about this one, personally)

* Workers has multiple parts; the CLI, HTMLRewriter... (This was related to the team I worked on, so I have a soft spot for it)

... and probably more that I'm forgetting.

Honestly, it's really nice that there's so much Rust these days that it's easy to forget all of the cool stuff. And there's a lot that I'd consider meaningful that may or may not be "large," so I was shooting for only the largest. 1Password and Discord are huge for me, but maybe others don't think so.

Also Wirefilter for their Firewall Rules

Source: https://blog.cloudflare.com/how-we-made-firewall-rules/

Don't forget fuchsia. It has over 800k lines of Rust (not counting dependencies, then it has >2M): https://i.imgur.com/gknVmYk.png

Its kernel is still predominantly C++ & Assembly.

... but since Fuchsia is totally-not-a-microkernel, a lot of stuff that would be in the kernel in, say, Linux, is not in the kernel in Fuchsia.

True, but outside of the kernel the official SDK languages are C++, Go and Dart.

The "kernel" of fuchsia is a microkernel, but when one talks about the Rust-free core of fuchsia, people usually mean the "zircon" component that encompasses both the microkernel as well as core utilities.

Around this zircon component they built a set of higher level components. They'd still be considered important parts of an operating system. E.g. things like a bluetooth stack.

The SDK you mention is for end user programs targetting the OS.

You're conflating two different things; outside the kernel, but inside of the OS, you can use Rust. They are using an increasing amount of it, as the other comment shows.

What you're talking about is the SDK for people writing applications to run on top of Fuchsia.

I'm not sure that this is true.

The documentation on fuchsia.dev heavily references Rust, and there is even documentation for usage with FIDL. I don't see anything explicitly relegating Rust usage to the kernel or even drivers. Seems like anything is fair game and "official."

Is there another source you are referencing?

He's talking about https://fuchsia.dev/fuchsia-src/contribute/governance/policy...

The summary of this page is essentially:

For the kernel: C, C++

For the rest of the OS: C, C++, Dart, Rust

For the "end-developers" (=regular app developers): C, C++, Dart

The kernel is not what makes fuchsia special. There are plenty of kernels out there. The code around the kernel is far more mission critical to the success of the fuchsia product.

In fact, if you remove the kernel, Rust is the main language of fuchsia already.

Reply on news.ycombinator.com