why IT-enterprise and some people adopt rust language? I already know some reasons(memory-safety), let me know some secret of why rust is so good to in general and specific context.
1 Like
Rust is not the only memory-safe language -- many languages with garbage collection (GC) such as Java, C#, etc, are also memory safe. But Rust is the only (successful and non-proprietary) language that is memory safe (excluding unsafe blocks of course), does not have GC, and performs as well as C and C++. So its main use is for cases where C or C++ would normally be used for performance reasons, but memory safety is needed or desired.
There are other reasons for using Rust, but I think that is the primary reason for using it. It is the reason I am using it.
5 Likes
Why?
- Prevents me from making a lot of silly mistakes that are not detected by other languages and can be very hard to find and debug.
- Provides the performance of C or C++.
- Can make small binaries when needed. No run time bloat.
- Excellent package management and build system. Which is absent in other languages that may be suitable for my purposes.
- Great support for all the processors and operating systems I may use.
- Much nicer syntax than other viable options (C, C++, Pascal, Ada, etc.)
- No OOP. But provides high level abstractions akin to C++ (another viable candidate for me)
- Excellent documentation and community support.
Context?
- Embedded systems, micro-controllers, small Linux or other OS systems.
- Server side services.
- Command line utilities.
None of those in any particular order of importance.
19 Likes
It is also a language that leads to less debugging in practise. You would expect it to be like any other language but without the memory safety bugs. But I found I also end up with fewer logic bugs, and those I have are pretty shallow.
You spend a bit more time up front during the coding, but it often works on first try, or has a trivial bug ("oh, I forgot to actually save the result to a file, whoops") and then works perfectly on the second try.
It is, once you learn the language, a very ergonomic language to code in. It is a joy to code in compared to other languages I have used. Tooling is also great.
Context: my background is systems C++, embedded and test tooling in python. I'm not a webdev, game dev or (much) of a GUI dev. Your milage may vary.
13 Likes
The 2nd most important benefit of Rust for me is the way error handling works. Error handling mistakes are probably the biggest cause of the bugs in my programs. Rust's Result type and its related features give me:
- The errors that a function returns are part of the function type. So when calling a function, the compiler ensures that all possible errors are handled explicitly. Languages that have hidden errors (for example, exceptions that are not part of the function type) make it far too easy to forget to handle all errors.
- Errors can include data related to the error (not just an error code). This is important because proper handling of errors often requires context information.
- The
?operator provides a convenient and concise way to cause the error to be returned upwards, along with a mechanism for converting errors to the type of error returned by the function. This prevents adding verboseifstatements for errors that are intended to be handled elsewhere, which makes the code easier to read.
Note that the Result is an enum in Rust, and custom error types are also often enumss. The enum type, which is used for errors and many other purposes, allows a way to have a set of possible states or outcomes, where each variant (one of the possibilities) can have associated data. And when writing code to handle/process the enum value, the compiler guarantees that all possible variants are handled explicitly.
Note that there are a few other languages with this type of error handling and with enum-like features, so this benefit is not unique to Rust. But it is very well done in Rust and adds a lot to your program's reliability. Reliability and memory safety go together and you could say that memory safety is a form of reliability.
7 Likes
I'm in a situation where I'm programming in different languages, in some block phases. So I do about 4-8 weeks of Rust, and then let's say 4 weeks of another language.
In the meantime, when I switch from Rust to another language, I always have an almost shocked feeling about how vague and shaky many things are solved in these other languages.
Of course, after a few days the feeling is gone, you get used to the uncertainty and the many ambiguities again.
The opposite is true when you switch back to Rust. Then you realize again how well everything fits together and what a huge safety net Rust offers as a language.
The principle of ownership and the borrow checker is worth much more than “just” memory safety. It makes for much more precise and stable programs.
For example, even if you simply use unwrap() everywhere, the mere fact that you explicitly recognize and handle every place where errors can occur makes for better programs because you deal with them.
11 Likes
Since I'm currently porting our software stack from Java to Rust, I can say that we chose Rust because it is a high-performance systems programming language with a lot of safety guarantees and high-level programming ergonomics.
Also I love the algebraic type system.
4 Likes
It's funny, memory safety is the last reason why I use Rust. I have no memory safety problems with C. I like Rust because I can write code smarter than other languages give it to me. But I mean strong typed languages. Of course JavaScript is better than Rust because it doesn't have types.
4 Likes
In my case I would not say "last" but I tend to agree with you.
Having had to use so many different languages in my career and concluding they were all conceptually much the same and hence a waste of my time learning I had no desire to look into any of the recent new languages on the block. But I was tempted to look into Rust because of its promise of strict type checking and memory safety while being a C/C++ style, compiled to native, "real" language. A genuinely new and unique feature that no other language, old or new, had managed achieve. Only to discover that Rust and its surroundings, from its syntax to Cargo and much else, has so much more to offer that memory safety may not even be top of my list of desirable features.
Ha! Oddly enough I love Javascript too. Because it is the polar opposite of Rust. Total type anarchy. If you are going to be a terrible language might as well do it properly, which JS does.
4 Likes
Every language has own niche to use. For example, I won't write a backend code using JS or TS. I will use Rust, C++ or Java. However using Rust on a client side is overkill. All data coming from from the backend are already type verified, why do I need an extra layer to check? Any user input will be double checked by backend anyway. A performance for a client is also not an issue , because it works in a single user environment and modern processors are fast enough. So this terrible language is actually perfect for the task. I already noted a recent problem I had with JS because tried to use it as a strong typed language. I wrote a function which takes one parameter, but this parameter can be a single value or an array. So I did a simple case in to check the parameter type, and it didn't work. Why? My mistake was that I checked if type is an array, but actually I needed to check if the parameter supports operator of. Returning to Rust, I didn't need to check if the parameter is a Vec, I needed to check if the parameter supports trait Iterator. It brings an another idea, we do not need a strong typed language, we need a language where data supports some traits. Maybe, it is the reason why I like Rust.
2 Likes
Now you're just fishing for QOTW 
Strangely enough I do get what you mean: yeah JavaScript has way too many ways to be terrible and it's performance is awful (without absurd care), but it's this weirdly good middle ground between the "every idea I ever had" Ruby and "The One True Way" Python. If you're going to pick a dynamic language for something, JavaScript over the last decade has really come into its own.
5 Likes
I love building Rust especially for low level hardware devices because it's so very fast and efficient. I've always been impressed with the end result.
1 Like
I work in a large enterprise that uses close to zero C++. We mostly use Java, with some Python and Go. So Rust would not seem to be an obvious choice.
Nonetheless my team and I use it a lot, mostly because it allows us to write reliable, comparatively bug-free software. It's not unusual to write code for weeks and have it work in the first real-world test. This never happens with the other languages. The performance is a very welcome bonus, but much less important than correctness.
The correctness is not a first-try experience either: when we later expand and change the functionality, because business hasn't thought through their needs, we find that the compiler helps us in finding all the places changes are required to maintain correctness.
As an example: I implemented a kind of a reverse proxy, which wraps the rest api of a proprietary SDN solution and enforces some business and security constraints for the users of said api. I've worked on it for three months. It went productive 1.5 years ago. Since then we've found exactly one bug - a logic error of mine, and zero runtime errors. This is a dream come true compared to the other languages.
11 Likes
I would be rather writing in C++17, the problems is I cannot easily handle my code to anyone else to work on. While it is possible to write memory safe code in C++17, it is also definitely possible not to write it, no doubt about this. Rust has its own rules that are naturally guarded, unless you start playing with highly visible unsafe. You do not longer need to enforce these rules during draconian code review. Compiler - is not a reviewer, so there are no longer conflicts in the team and everyone is happy.
2 Likes
I don't think this is accurate. Rust's memory-safety promise has an IF—a big IF—the code doesn't use unsafe blocks. This isn't always possible without some other sacrifices. When it's impossible, an algorithmically equivalent implementation in a GC language is still memory-safe, but not Rust. Think about a data structure as simple as a doubly-linked list, or other data structures that require unclear ownership (e.g. graph).
Basically, there's almost no way to perform a memory unsafe operation at the source code level of a mature GC language such as Java and Go, unless there's interop with memory-unsafe code, a bug in the compiler or GC or some very very corner cases. To the contrary, Rust often requires unsafe blocks when the logic becomes complicated—The programmer will have to write unsafe blocks themselves in Rust, but using unsafe language features in a GC language is rare and unusual to the least, probably never for most production code. That’s the critical difference from a GC language in terms of memory safety.
But if the program doesn't require an unsafe block, the program can run faster with the same safety thanks to the absence of GC.
There is another big IF: To match the performance of C, in many programs it is necessary to use unsafe blocks, e.g. probably most graph algorithms. It may be possible to achieve either, but not both. But a program written in modern C++ (except maybe some corner-cases) doesn't need to break OO principles or retreat to plain C just to get as fast as C.
I think, from a technical excellence point of view (the philosophy and design of the language), where Rust shines is when:
- memory safety is important;
- the program is sufficiently low-level or requires running in a resource-scarce environment where a GC is undesirable; and
- either:
- logic is simple enough (e.g. most business logic) that
unsafeis unneeded or used rarely, or - performance is not so critical that it is OK to give up some performance in exchange for compile-time memory-safety.
- logic is simple enough (e.g. most business logic) that
(I'm still refining the conditions above.)
1 Like
This completely miss the mark. There's no Rust code use zero unsafe code. std uses unsafe code, core uses unsafe code. The whole point of Rust is that, you can wrap unsafe code inside implementation details and provide safe interface to others.
6 Likes
Maybe not your mark, but my post wasn't responding to this 
Was just pointing out the accepted answer is inaccurate. There are truly unavoidable memory-unsafety at the language level compared to GC languages. Simply stating "Rust and GC languages are memory-safe" missed the critical difference, especially for someone who came from the background of a GC language.
1 Like
Thank to all reply of my question.
The problem is that a 100% memory safe language is entirely useless as it would be incapable of performing any I/O. No matter if it uses a garbage collector or borrow checker or whatever. Why? Because to do I/O you are interacting with the outside world, a place neither a garbage collector or borrow checker knows anything about.
Garbage collected languages like Python, JS or whatever go unsafe by means of using C++ or whatever is under their hood to do I/O. Those languages have "unsafe" as well, except it's done by dropping down to the C/C++ of the run time or through some FFI.
I'm going to claim that memory safety is always important. We error prone humans need all the help we can get ensuring code is correct.
While Rust is great for resource-scarce environments it certainly has high enough level abstractions to put it up there with C++ or Python.
Rust shines everywhere!
3 Likes
The GC language must at some point also interface with the OS. Which means inevitable unsafe code. And the GC itself is highly unsafe to implement.
3 Likes