Would you recommend Rust over Elm?

maxmoon · 2 years ago

Would you recommend Rust over Elm?

jokeyrhyme · edit-2 2 years ago

Rust is a very versatile language, so you can make almost any kind of app with it, although the ecosystem around certain use cases (e.g. CLI) is more developed

You could build a web front-end in Rust with these crates (the Rust word for “library”):

https://crates.io/crates/yew
https://tauri.app/ (alternative to Electron)

You could build a HTTP back-end in Rust with these crates:

I use these GUI apps written in Rust:

I use these TUI apps that are written in Rust:

I use these CLI tools written in Rust:

Other places Rust is used:

Mozilla Firefox is very slowly being converted to Rust (rendering and SVG are some pieces that are already Rust, but there’s more)
work being done to support writing Linux kernel drivers in Rust
Amazon Web Services uses Rust in a lot of their services like Lambda
parts of the NPM service (yes, the JavaScript package repository, even they don’t use JavaScript for everything)
Tor is slowly and carefully being rewritten in Rust
Matrix and Signal protocols have official Rust implementations

Dessalines · 2 years ago

Great list, thanks for compiling all these, I’m gonna check some of them out.

maxmoon · 2 years ago

Thanks for this great list. I went through a few, but couldn’t test a lot yet.

If it’s about web development, now I know that Rust can be used to create a back end and with Elm I could create a front end.

The question is: Is it a good combination?

jokeyrhyme · edit-2 2 years ago

Hehe, I actually just remembered that Lemmy itself is also written in Rust: https://github.com/LemmyNet/lemmy (the web front-end is TypeScript, I think)

I don’t know Elm at all really, but it might be worth going over what we think are characteristics of combinations of back-end and front-end stacks

Great:

define types once, and be able to use them or generate them for the other side, e.g. protobuf, or generate types from JSON Schema, or use same language on both sides
tooling available to generate front-end SDK based on OpenAPI/Swagger for the back-end

Fine:

explicitly define the same types in multiple languages, manually keep them synchronised, e.g. probably the out-of-the-box experience whenever you use different languages in front and back
manually create HTTP client helpers in front-end to talk to HTTP endpoints in back-end

Bad:

a core type or data structure concept on one side is missing from the other, e.g. imagine if one side didn’t have arrays or booleans or something that you use all the time, so you had to do extra work just to get both sides to communicate
no common protocols between technologies, e.g. one side doesn’t even speak HTTP

I’m trying to think of other characteristics, but coming up empty :) I’ll update if I think of more :)

maxmoon · 2 years ago

I don’t know Elm very good yet, but as far as I know it, it is a perfect match :)