Old Programmer that's New to Rust


I'm a long time Microsoft Developer going back to 1994 professionally and 1984 overall. I'm ready to branch out and try Rust for a major idea I have. I've never coded a line of Rust in my life, but I understand architecture and the SDLC very well.

My project will be a site to allow teachers to organize their communications with their students and parents that provides an email portal and instant messaging portal that can be combined with online learning platforms via their public APIs. The goal is to get information to students and parents in an accountable way to relieve regulatory burden on teachers and schools. My wife is a teach and I've seen first hand the chaos that remote learning has become and everyone needs a safe and reliable platform for quickly, safely and accurately disseminating important and potentially sensitive information.

I decided to do this in Rust specifically because of the privacy issues and the need for robustness and security. I could do this in C# 9 as well, but I want to use more vender-agnostic tooling to show that there are no big IT influences making decisions about implementation details that may conflict with the goals of privacy and security.

Having said all of that, I have been researching the Rust ecosystem and have decided on using Axios Actix for the back end and Yew for the front end. I would enjoy and encourage feedback on these two decisions and of course any advice for managing large Rust projects. Hosting and Source Control decisions have not been made, I would very much like to find a cloud provider other than AWS, Google and Azure to maintain independence.

Thanks, and I look forward to your feedback.

Update. Typo with framework name, Actix, not Axios was what I meant to say.


It sounds like you are using Javascript for the backend and Rust for the frontend? Normally people do it the other way around.

That was a typo. Actix is the backend I intend to use. I don't believe Javascript is the correct solution for anything, which is why I settled on Yew.


If I was writing it, I would probably go for typescript on the frontend. I think Rust gains you a lot more on the backend than on the frontend, especially compared to a language with proper types such as typescript.


Welcome! Always nice to see experienced people recognizing the goodness in Rust :slightly_smiling_face:

One preemptive reassurance for you: Don't feel bad if (when) Rust seems weird and overly-picky for a while. There are a ton of techniques that are easy and work great in other languages that are just a nightmare if one tries to use them directly in Rust. It's not just you.


Thanks. Yes, the reason I've put off Rust for so long is it's syntax, but it's time to get over it and get to work.


The syntax will make sense quickly. The semantics will read as straightforward but in practice there are cases where the compiler will let you know that your mental model is subtly wrong. It's ok, we all hit that from time to time. If you find things that feel hard to understand, do not hesitate to file tickets in the rustc issue tracker. We regularly improve the UX of errors to make the language easier to pick up by newcomers.


Thanks for the heads up. Error messages and general ergonomics of a language matter a lot to me, which is why I have been developing with Microsoft's tools for decades (not saying they are perfect, btw). I've developed with C# nearly every day since the original CTP was released in summer of 2000, and a huge part of the reason for that is a combination of sane syntax and helpful docs/error messages.

1 Like

I cannot justify writing any code in JavaScript or any language that transpiles to JavaScript. If I had not chosen Rust then I would have chosen Blazor for my framework for the same reason.

I'd go further than @alice and say that using Yew or any other Rust web frontend library in production is a really bad idea. Right off the bat, you're going to make your site incompatible with a bunch of browsers / browser versions by using WebAssembly (see caniuse.com).

Also, your wasm blob is going to be way bigger than most frontend code bundles due to including code for things like container types (e.g. HashMap) and likely also JSON (de)serialization and more (where JS code just uses what comes with the browser).

Further, you will still be using the JavaScript DOM API as wasm doesn't have its own DOM API. This means there is some additional overhead to every DOM operation since you need to switch contexts from wasm to JS and back.

Finally, I don't think there is a Rust web frontend library that is even near production ready. I've used Yew myself for a super simple website (caniuse.rs), and even there I had to code a few browser API interactions myself: caniuse.rs/src/services at main · jplatte/caniuse.rs · GitHub

1 Like

Careful, Rust and JavaScript/TypeScript go hand in hand! You can transpile Rust to JavaScript using the asmjs-unknown-emscripten target, for instance, so this would invalidate your choice based on your statement. Coming from a similar background (I picked up C# in 2005), I would attempt to portray Rust to you as a modern C++ mixed with Haskell. The ecosystem is very similar to working with npm, in that larger projects tend to have a higher number of dependencies, with longer build times. There's also certain features that aren't fully implemented, or were implemented years ago in a questionable way (looks at turbofish and const generics). Consider the use case for the project at hand and use the best tools available to you to get the job done, otherwise you'll find yourself working in a fairly unpleasant environment where you have you reinvent half of the wheel to get anything done. I say this with good intentions, noting that you haven't actually written any code yet. Take heed of the pending compiler battles, because they will be a headache.

What I think I'm hearing is that Rust/Yew is not ready for productuion where Blazor is as Blazor already has tree-shaking in the WASM linker to reduce the cruft going along for the ride. One of the things I'm trying to avoid is splitting technologies at the layers. with C# I can already use the same shared library of POCO objects with different DbContexts on the front end and back end to handle datasource for each end of the app. I was hoping to do the same here.

Most of the things I wrote about Rust/Yew above will most likely also apply to Blazor. In fact I would expect it to create even more bloated wasm blobs. It's not that dead code is not eliminated when compiling to wasm, it's that you end up using things like std's Vec, HashMap, serde and many other things because otherwise there would have to be wrappers for many more browser APIs that just don't exist yet and also might have really poor performance due to constant context switching between wasm and JS.

I may have to do some experiments to see which creates smaller code.

I'd be interested if you'd unpack this sentence a bit. What's a "proper type" and I'm inferring that you're simply saying the TS libraries are more mature, yes?

It sounds to me like you don't actually have much experience with JavaScript and may have the wrong view of it. It is actually a wonderful programming language. It is, however, best suited to rapid development and smaller projects whereas TypeScript is better for larger projects.
Rust is also a great language but its main niche is as a more reliable alternative to c++ ie as a systems language. Back end systems with performance / reliability requirements. If you are expecting millions of users, then sure, use rust, but perhaps you need a larger team as well. Rust and Wasm also have their place, but again, mostly where performance is a requirement.
Also important to remember when choosing a language is what the future of the project will be. Who will be maintaining it. How many people will work on it. Finding good rust developers will not be as easy as finding good developers in other languages. Thus Rust must have other compelling reasons that outweigh this disadvantage before using it in a given situation. This applies to you too, having to learn a new language will cost you time and effort - but may be quite personally rewarding. You will likely get a lot wrong at first and have to change the design over time as you learn the new language and its best practices etc. If this project is about personal improvement then definitely choose Rust, it will teach you a lot. If it is about getting the job done, then you may be better off with what you know or languages where existing frameworks and skills are more readily available.

1 Like

Perhaps you could elaborate on that. I don't get the idea.

If one compiles C or C++ to Javascript (With Enscripten) then you have an executable running in a nice safe sand box. Much like C# and the CLR, Java and the JVM or WASM.

Seems it is even possible to compile Rust to Javascript: Rust Compilation Target to JS with Emscripten | by Bambang Purnomosidi D. P. | Medium

That aside. Why does everybody dump on Javascript? As far as I can tell it is a very sophisticated language. It has always had features that other languages are only now bolting on. First class functions, async programming model, etc.

As I have said here before, I love Rust for its static typing and memory usage checking. Basically it's emphasis on correctness.

I love Javascript for its dynamic typing, because it just does not care. It lets you do what you like when you like.

Kind of paradoxical, but that is just me.

1 Like

Rust seems overkill for a basic web application. The tools for such things are well developed and widely available. I usually use Go for web servers and standard Javascript client side. Go is a mediocre language, but the libraries for everything web-related exist and are used, heavily, by Google, so they actually work.

I'm writing a client for a virtual world in Rust. That has graphics, networking, concurrency, GPU interfacing, a lot of state, and has to go fast. Rust is good for that. No segfaults in four months, no need to use a debugger. Once it compiles, it usually works. This is a huge win compared to C++.

So, use the right tool for the job.

It sounds to me like you don't actually have much experience with JavaScript and may have the wrong view of it.

No, I have used JavaScript for many, many years going back to it first appearance in Netscape Navigator.

Also important to remember when choosing a language is what the future of the project will be.

Which is precisely why I want to avoid using JavaScript in new projects. WASM is the future of the browser. Direct DOM access, when it arrives, will eliminate any necessity of using JavaScript.

1 Like

If your only reason to use JavaScript is it's sandbox, then why look there at all? C# and Java already provide much more performant sandboxes and the CLR is proven safer. WASM is faster than Javascript running in the same sandbox.

But if you also include the sanity of the languages, JavaScript is an absolute disaster when it comes to language design, syntax and standard libraries. There is no good reason to use JavaScript as a language because of TypeScript, but even TypeScript falls into the first pot of perils with JavaScript of poor performance.