Needless of a lengthy introduction, Rust is a systems-level programming language that puts "performance", "reliability", and "productivity" at the ...
For further actions, you may consider blocking this person and/or reporting abuse
One of things I like about rust is how well integrated the cargo ecosystem is with the rust environment. Along with what you said about docs and packages, I really like how well the testing is integrated. Personally I have found that it has encouraged me to write more tests and hence a bit "better" code. And again that had allowed me to refactor and change things without worrying too much, as failing tests would show what has broken, which I think leads to your point that it makes one write "better" code.
Don't forget
cargo fmt. Having a opinionated style guide is really a blessing.While I do not know Rust, and honestly have not used it, the integration of cargo seems to be something I see that pops up a lot. I watched a video actually of setting up Rust and the basics of using it and immediately thought “this is what a development environment is supposed to be like. None of the whole let’s glue 20 different packages together in an environment and hope they work together”
Some languages could really learn a lot from that, but refuse to (I’m looking at you JavaScript).
Truly! It still surprises me how
cargo newjust works. The Rust Team has done an incredible job in making sure the developer experience is smooth.I totally agree! The seamless Cargo integration really makes the developer experience of the Rust workflow a thing of beauty.
Let me play a devil's advocate and list things which I think are worth to mention when it comes to pain points in rust and are sadly not mentioned in your post:
For example I can't really rationally justify using rust for my hobby data driven gamedev experiments, because the return on investment is simply too low. I use C# because it allows me to go low level enough (even to SIMD) while having garbage collector and bunch of TODOs with hacky code simply because I don't have enough time.
Btw you can end up with spaghetti code even in Rust, there is nothing which would stop you in writing long and messy block of code with terrible cohesion between modules.
You brought up valid points. To that, I don't have much to counter against because Rust truly suffers from relatively slower compile times and inferior tooling compared to the C++ equivalent (as of writing).
However, these pain points do not outright dismiss Rust's value in the ecosystem. From a developer experience standpoint, Rust empowers me to achieve low-level capabilities using familiar high-level syntax. Meanwhile, Cargo itself automates project management (from dependencies to testing).
All of these features (and the others I've mentioned in my article) combined truly make Rust a language worth considering, even despite its yet-to-mature ecosystem. Or at the very least, all languages should look to Rust as a prime example of a language that puts developer experience at the forefront of its values.
My experience with C++ had none of these "quality-of-life" features. One can argue that C++ is for the "hardcore programmers", but speaking once again from a developer experience standpoint, these languages do not feel empowering. In fact, they are quite intimidating, to be honest. Perhaps that reflects more on me than the language; my point is: if a language goes out of its way to accomodate for developer experience regardless of expertise, then I am all for it, even if the ecosystem will take some time to mature.
Now, regarding your argument on C#, I don't have much to say, but I'm glad C# empowers you in that way! At the end of the day, what really matters is how a language empowers us to create and innovate in the technological space.
For me, I find this in Rust. For you, this is in C#. For others, it may be in C++. For some, it may be in Python and JavaScript. Regardless of language, developer experience and empowerment should always be the basis of our judgements.
With that said, thank you for your insights on the pain points. I must admit that I have failed to add more of them in the article. I feared that they may further lengthen an already lengthy article, hence the rather skewed commentary. But that's what the discussion threads are for, right? Thank you for adding value to the article.
Rust is gaining a lot of traction in security-critical low-level software like browser engines, etc. IMO that's where it shine. You can't write a CSS parser, HTML parser, JS interpreter, etc. in C#. You can do it is C++, in fact most are written in C++ today. However, security bugs are starting to become even more of a problem as the world gets more connected. Which is where Rust come in. You can access all the low-level stuff you can from C++ and get the same predictability and performance, but you get language-level protection against memory errors causing security vulnerabilities.
Well, technically, you can still write a parser and an interpreter in C#. It's just that the language may not be the most ideal option.
And, also, Rust isn't exactly bulletproof from all security vulnerabilities. The onus is still on us, the developers, to make sure that nasty bugs (like buffer overflow vulnerabilities) are avoided. But sure enough, Rust does help in avoiding many memory issues and pitfalls.
You can write it in C#, sure, but not with the performance and memory footprint required. Browsers are already notorious for their appetite for RAM. That's why it is traditionally done in C++. And it is orders of magnitude easier to avoid memory bugs causing security vulnerabilities in Rust compared to C++.
The JavaScript ecosystem is notorious for the todo list made with various approaches within the language... Todo list makes sense as a familiar UI project with different states and the right demo of complexity.... Is there a good equivalent Rust project? Something that demonstrates why Rust or why this approach within Rust?
Iced is a fantastic Rust GUI project that compiles to desktop native and WASM targets, using low-level GPU APIs. It has a good todo-list example that can serve as an example of what a Rust GUI project looks like.
github.com/hecrj/iced/tree/master/...
I've been using Iced now for a personal project, and it's actually really good. Still learning some ins and outs, though.
Yes, there is! As far as I know, the Rust equivalent for the JavaScript todo app is the humble CLI app. There are no particular requirements for the app since it would be up to the learner to make it their "crash course" around Rust's features. As the learner continues to design their app around the ownership model, it gradually becomes apparent how powerful it can be when scaling across multiple threads.
After that point, who knows what the future holds? Maybe the next step is to build a multi-threaded web server!
Nice read (for what I've read, I skimmed, coming back later)! I've written a couple of handfuls of mostly cross-platform CLIs in Rust in the last 6 months or so and I'm loving it. I don't do any web stuff (other than CURL), but otherwise my bins are lighting fast, comparable to Fortran (the only comparable language I'm fluent in, I know lots of languages intermediately) in some area for computation. Been playing with the PBR crate for my next little project.
Of course, I'm still green, so I don't have any deeper opinions of it yet. Oh, I do like closures.
This is my latest project if you're interested (please remember I'm still a NOOB lol):
BlackHosts
Thanks for the read!
Ian, what crates do you leverage when building CLI's? Also do you wrap the Rust code into a NPM package or something that is more portable or just stick to the raw binary compiled for various platforms? I'm brand new to Rust and thought maybe I'd try a CLI project to get started.
I just stick to raw binary and sometimes I'll release a .deb for Debian distros (and maybe an AppImage if needed for portable dependencies), but I code for myself, family, and friends so I don't do anything more extensive for releases. I'm not sure what you mean by "leverage", I try to stay minimal with external crates and just use whatever is needed for my small projects. I use the regex and recolored crates a bit and the rest all depends on the project.
Dang I loved this. I've been hearing all about Rust and memory safety, but this is the first post I've read that really digs into the qualities that are helping it gain so much traction. Thank you for writing this post!
I came from Frontend background, I have used Java before (never liked it, or could not understand how something gets available magically).
But I love Rust now. I'm comfortable with Actix web for API and Bevy for game development. And all this as a hobby, I dont see myself every leaving Rust the way I left GO so quickly. github.com/steelx
Great summary, thanks! I think my biggest beef so far with rust is that I'm really used to easy dictionary usage (literals, operators) from languages like Perl, JavaScript, Kotlin, and Python. HashMap just isn't quite the same.
It feels to me that if you first learn something like C# you won't ever want to touch C++
Great article!
There is a trend towards writing more immutable, functionally pure code and I’ve seen the benefits of this. Does this resonate in any way with you or in how rust is designed?
Yes. Variables and references are immutable by default, and have to be explicitly annotated to be mutable. Also, many features will remind you of functional languages from the ML-family (especially Haskell): algebraic data types, monadic exception handling, typeclasses, associated types.
Yes, it does! But not in the pedantic sense, of course. I still see the value in traditional object-oriented code. Rust is just there to nudge me in the right direction when I attempt to get too clever for my own good.
Overall, what resonates with me the most is the fact that Rust effectively synergizes functional-style code and object-oriented code. It forms a "yin and yang" of sorts between immutability and mutability. This is unlike many languages where the paradigms are set in stone. For instance, Java is
notoriouslyobject-oriented while Haskell isconfusinglyfunctional. Rust just seems to strike a good—if not perfect—balance, you know?Thanks for the article. Would you mind to describe some web (backend) use cases?
Sure! Since Rust can be thought of as a general-purpose programming language, the use cases are quite broad. You can, for example, use the Rocket framework and the Actix Web framework to build web servers. Many people shift to a Rust back-end to reap in the performance benefits, which is why you will most likely find Rust in front-facing API infrastructures. REST APIs, in particular, are blazingly fast thanks to the serde crate's quick data serialization and deserialization.
The Yew framework has also been gaining traction for using Rust in the front-end—albeit indirectly through WebAssembly.
There are also use cases for web development tooling. The swc JavaScript/TypeScript compiler has become quite popular thanks to the performance gains from Rust.
Besides the typical web development use cases, Rust can also be used for image manipulation. A popular package for this is the image-rs crate. If your back-end requires some kind of image generation, manipulation, and compression, then Rust has your back on that one, too! Combined with a REST API, the possibilities are endless.
I hope it is clear that the use cases are broad. Rust is not a domain-specific language, so if you can think of a use case, then it is most likely feasible with Rust. Much of this can be attributed to the wealth of packages in crates.io. I suggest exploring the registry for inspiration. The possibilities are truly endless.
Grateful!
So, what was the solution to the callback problem?
Apologies, but I'm not quite sure what you're referring to. Care to elaborate?
You were referring to callback-based interface that you planned on using but ended up with something different. I am curious on what your new, rust-y solution was :)
Oh, that's an excellent question! I moved on to what is called the "type-state pattern", which is basically a glorified application of state machines using
enumtypes and pattern-matching.I realized that the event-based mindset that I was so accustomed to in JavaScript isn't exactly applicable—or dare I say "idiomatic"—for what I was trying to achieve. The shift from a push-based model (using events) to a pull-based model (via polling the state machine) was a vastly simpler and cleaner solution than whatever I hacked together initially with interior mutability patterns. The push-based model was simply too prone to issues regarding concurrent mutable borrows. This, I realized, thanks to the type system.
Thanks for a well-written and informative article (and many others too)! I would love to see another that digs into this journey, where you explore how a push-based/callback mindset painted you into a corner in Rust and how you got out of there by the means you alluded (possibly idiomatic, pull-based, polling, etc.). In general, push- and pull-based interfaces are duals, so I am curious how the latter might be more conducive to a better design in Rust than the former. I hope you get round to it.
First of all, thank you for such valuable feedback! It's not often that I receive comments that request for greater details on a topic I brushed over. 😅
To make a long story short, I did in fact end up with polling-based state machines instead of event-based callbacks. Rust's type system really made it easy to encode the state transitions. In particular, enums and the type-state pattern were instrumental here.
But then again, I can go on and on about that in a future post. Thanks for the suggestion! I will make sure to give you a mention there.
Bookmarking this page. I'm 2 weeks in with Rust and this page is going to help a lot ;)
Thanks Some Dood
Why I used Rust ...
I initially got into it because of the hype wave months ago where a handful of people in a discord i was in talked about rewriting stuff in rust, plus i was looking for something new as i mainly only code in C++.
Things i liked about Rust
Nothing honestly, um i know it sounds negative but it's honest.
Things i don't like about Rust
I don't like the syntax, I don't like how it's kinda based around a community, and the standard Rust lib is very generic for a systems level language.. For example, you can't even nativly interact with Processes on a windows machine without installing third part crates: windows-rs / sys, winapi, etc, etc.. And thee issue with these right, lets say im a new Rust programmer and i only do Windows development and heavily use the windows API.. There is like 3-5 repos on github to reference, each are using different variations of crates for interacting with the windows api, some may not even use the methods you are looking for.. so you are VERY VERY VERY limited on your resources... Even Julia Language has a native way for calling winapi methods, and it's not even near a systems programming language which imho is pathetic for Rust.
Memory saftey of a lie
First off, out of topic here but Rust compiler does not detect Int overflows unless you build in debug mode... anyways - blog.rust-lang.org/2024/04/09/cve-... Here is a CVE found this year in the Rust standard lib.. and yeah, Rust can leak memory also.
Nothing is made in Rust
Someone please link me a public repo, for Windows that is an actual application, runable.. not some bogus lib.. the only thing i can recall is Mullvad vpn, which i've used and compared to other providers which use C++, it's cheeks.. terrible, buggy, isn't smart enough to check firewall rules to make allowlists on certain networks... overall just a worse product.
Rust is being pushed as some sort of agenda?
Notice how 70% or more of people who glaze Rust all have a furry fox or female anime profile picture as their avatar - kind werid right? Also notice how they all kinda work on the same or nearly similar projects? Also notice how any single Rust library public on github, not even a standardized one, just a random lib has over 1000 stars on it??? Not saying the Rust foundation is GitHub botting, but.. yeah maybe... Notice how companies like Microsoft and Google talk about Rust and those teams being more efficient but doesn't say which products, or even what exactly those teams using Rust are doing???
CVE stats are fabricated
"All of our bugs comes from the C code side of our projects" "~75% of CVEs are all from memory leaks" .. Think about it, really hard ok... C has been around waaaaaay longer therefore more codebases, therefore those codebases are not exactly up to par... Mostly if not all of these stats the Rust foundation compares with C codebases are all probably from C99 on projects with million(s)+ lines of anchient code that's been worked on & maintained by hundreds of different devs with mixed skill-levels.
No room in thee industry
It's no news to us that the tech industry is over saturated and finding jobs is very difficult now... But we already have established tech stacks.. Want to make: Windows app? C#, C++, Android app? Java / Kotlin, iOS app? Swift / Obj-c, ML app? Python / Julia, Windows Kernels? C, Linux Kernels? C.... there is no room for something like Rust, which in comparison feels like an unfinished abandoned project.
In summary, don't use Rust. literally every stat is has over C code is C code running on version 99... C and many other languages are getting better, and have existing job markets... Rust community is weird, there is def something fishy going on behind the scenes with thisone.