What’s wrong with using Rust for “GUIs, distributed computing, web development”?

In the case of a GUI, I’d expect a modern Rust GUI toolkit binding to look like any other GUI toolkit binding: an FFI-like abstraction that parses its own declarative view format, and exposes handles from those parsed views for native controller methods to bind to. Y’know, QML, NIBs, XAML, those things. This kind of GUI toolkit doesn’t exactly have high requirements of the language it’s bound to. (And I don’t believe many people want the other, procedurally-driven kind of GUI toolkit in the year 2021.)

Re: distributed computing — I can see the argument for Rust being the antithesis of easy network “rolling upgrade” (e.g. via being able to recognize known subsets of unknown messages, ala Erlang); but pretty much all languages that support distribution are very nearly as bad in that respect. (Only the languages that have distribution that nobody else actually uses — e.g. Ruby, Python, etc. — are on Erlang’s side of the spectrum in this regard.) But in terms of pre-planned typed-message version migrations, Rust can do this more idiomatically and smoothly than many other languages, e.g. Go, Haskell, etc.

Re: web development — there’s actually a lot of activity in building web frontend SPAs using Rust compiled to WASM. Started with games, but has expanded from there. Not sure about web backends, but the argument is similar to distribution: you need to do it differently in a static compiled language, but of static compiled languages, Rust is really a pretty good option.

The productivity hit produced by having to deal with the borrow checker and the design constraints it imposes into application architecture.

I won't take a GUI framework without a graphical designer, or a component ecosystem from companies selling GUI widgets in 21st century.

Distributed computing, again when thinking about distributed calls a la Akka, Orleans, SQL distributed transactions, I rather have the productivity of a GC.

Web development with Rust is nowhere close to the stack provided by JEE, Spring, ASP.NET, Adobe Experience Manager, Sitecore, LifeRay, Umbraco, enterprise RDMS connectors, ...

Rust best place is for kernels, drivers and absolute no GC deployment scenarios.

> I won't take a GUI framework without a graphical designer, or a component ecosystem from companies selling GUI widgets in 21st century.

Well, yeah, what I’m saying with “these types of modern frameworks don’t impose very many constraints on the language” is that there’s no reason that Qt, UWP, Interface Builder, etc. can’t support Rust (or most other languages, really), because in the end the tooling is just generating/editing data in a declarative markup language, that the language’s toolkit binding parses. You don’t have to modify the tooling in order to get it working with a new language; you just need a new toolkit binding. Just like you don’t need to modify an HTML editor to get it to support a web browser written in a new language. Qt et al, like HTML, is renderer-implementation-language agnostic.

> Distributed computing, again when thinking about distributed calls a la Akka, Orleans, SQL distributed transactions, I rather have the productivity of a GC.

I think I agree re: the productivity multiplier of special-purpose distributed-computing frameworks. I don’t think I agree that it’s a GC that enables these frameworks to be productive. IMHO, it’s the framework itself that is productive, and the language being GCed is incidental.

But, either way—whether it’s easy or hard—you could still have one of these frameworks in Rust. Akka wasn’t exactly easy to impose on top of the JVM, but they did it anyway, and introduced a lot of non-JVM-y stuff in the process. (I’d expect that a distributed-computing framework for Rust would impose Objective-C-like auto-release-pools for GC.)

> Web development with Rust is nowhere close[...]

Web development with Rust isn’t near there yet, but unlike distributed computing, I don’t see anything about web development that fundamentally is made harder by borrow-checking / made easier by garbage-collection; rather the opposite. I fully expect Rust to eventually have a vibrant web-server-backend component ecosystem equivalent to Java’s.

> Rust best place is for kernels, drivers and absolute no GC deployment scenarios.

Those are good use-cases, but IMHO, the best place for Rust is embedding “hot kernels” of native code within managed runtimes. I.e. any library that’s native for speed, but embedded in an ecosystem package in a language like Ruby/Python/Erlang/etc., where it gets loaded through FFI and wrapped in an HLL-native interface. Such native libraries can and should be written in Rust instead: you want the speed of a native [compiled, WPO-able] language; but you also want/need safety, to protect your HLL runtime from your library’s code that you’re forcing to run inside it; and you also want an extremely “thin” (i.e. C-compatible) FFI, such that you’re not paying too much in FFI overhead for calls from your managed code into the native code. Rust gives you all three. (I see this being an increasingly popular choice lately. Most new native Elixir NIF libraries that I know of are written using https://github.com/rusterlium/rustler.)

I would use Rust for distributed computing and GUIs, and I wouldn't be surprised if it begins to break into the graphics/gamedev world in the next 5 years. Agreed that Rust is still immature in those areas today, but it seems to be on a pretty aggressive trajectory and it's only a matter of time before Rust begins chipping away in those domains.

I did some real-time embedded development (including distributed embedded) in a past life in C and C++, and I really expect Rust to break through in that domain in a big way even though it's incredibly conservative (C++ is still the new kid on the block). It will take some time and it's never going to "kill" C or C++ in that domain (especially considering all the hardware that exists that LLVM doesn't yet target), but I think Rust will carve out a swathe of the embedded space for itself.

Sure if you like to do stuff by hand, I rather use visual design tooling (think Qt Designer, Microsoft Blend) and have bigger fish to fry in distributed network calls than who is owning what, instead of using Akka, Orleans or Erlang.

> I rather use visual design tooling (think Qt Designer,

Oof, I did professional Qt development and Qt designer was basically a joke. Not sure if it improved, but I've never experienced a visual design tool that saved me time. Not that they can't exist, just that the implementation is usually too buggy to justify itself. I don't enjoy debugging XML that gets compiled to C++ (I think it's compiled, anyway--maybe it's parsed at runtime... I forget). In whatever case, if you build a visual design tool for C++, you can build one for Rust as well.

> bigger fish to fry in distributed network calls than who is owning what

Agreed that I don't think distributed is the sweet spot for Rust, but there are certain niches (high performance, low level, etc) where Rust would be valuable. Previously I worked in automotive which is basically a bunch of distributed embedded computers talking to each other over a CAN network, and Rust would have saved a lot of time and money. On the other end of the spectrum, you have high frequency trading where performance is so important that C++'s myriad problems are worthwhile, so certainly Rust could add value here as well.

> GUIs, distributed computing, Web development.

People are trying out Rust in all of these spaces. I don't see why Rust is fundamentally unsuitable to these domains.

Imagine something like Swift UI for Rust, including the live preview.

Now imagine how to implement such designer in a way that supports component libraries, without having the burden of using Rc<RefCell<>> everywhere, while allowing the user to rearrange the component widgets in any random ordering.