2 ms·

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 lik

by derefr 6y ago

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.

pjmlp 6y ago
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.
- derefr 6y ago
  > 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 https://github.com/rusterlium/rustler.)

by derefr 6y ago

pjmlp 6y ago

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.

derefr 6y ago
> 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 https://github.com/rusterlium/rustler.)