DEV Community

Cover image for My first impressions of Rust
Deepu K Sasidharan
Deepu K Sasidharan

Posted on • Updated on • Originally published at deepu.tech

My first impressions of Rust

Originally published at deepu.tech.

So I started learning Rust a while ago and since my post about what I thought of Go was popular, I decided to write about what my first impressions of Rust were as well.

But unlike Go, I actually didn't build any real-world application in Rust, so my opinions here are purely personal and some might not be accurate as I might have misunderstood something. So do give me the consideration of a Rust newbie. If you find something I said here is inaccurate please do let me know. Also, my impressions might actually change once I start using the language more. If it does, I'll make sure to update the post.

As I have said in some of my other posts, I consider myself to be more pragmatic than my younger self now. Some of the opinions are also from that pragmatic perspective(or at least I think so).
I have weighed practicality, readability, and simplicity over fancy features, syntax sugars, and complexity. Also, some things which I didn't like but found not such a big deal are put under nitpicks rather than the dislike section as I thought it was fairer that way.

One thing that sets Rust apart from languages like Go is that Rust is not garbage collected, and I understand that many of the language features/choices where designed with that in mind.

Rust is primarily geared towards procedural/imperative style of programming but it also lets you do a little bit of functional and object-oriented style of programming as well. And that is my favorite kind of mix.

So, without any further ado, let's get into it.


What I like about Rust

Things that I really liked, in no particular order.

No Garbage collection

One of the first things you would notice in Rust, especially if you are coming from garbage collected languages like Java or Golang is the lack of garbage collection. Yes, there is no GC in Rust, then how does it ensure my program runs efficiently in the given memory and how does it prevent out of memory errors?

Rust has something called ownership, so basically any value in Rust must have a variable as its owner(and only one owner at a time) when the owner goes out of scope the value will be dropped freeing the memory regardless of it being in stack or heap memory. For example, in the below example the value of foo is dropped as soon as the method execution completes and the value of bar is dropped right after the block execution.

fn main() {
    let foo = "value"; // owner is foo and is valid within this method

    {
        let bar = "bar value"; // owner is bar and is valid within this block scope
        println!("value of bar is {}", bar); // bar is valid here
    }

    println!("value of foo is {}", foo); // foo is valid here
    println!("value of bar is {}", bar); // bar is not valid here as its out of scope
}
Enter fullscreen mode Exit fullscreen mode

So by scoping variables carefully, we can make sure the memory usage is optimized and that is also why Rust lets you use block scopes almost everywhere.

Also, the Rust compiler helps you in dealing with duplicate pointer references and so on. The below is invalid in Rust since foo is now using heap memory rather than stack and assigning a reference to a variable is considered a move. If deep copying(expensive) is required it has to be performed using the clone function which performs a copy instead of move.


fn main() {
    let foo = String::from("hello"); // owner is foo and is valid within this method

    {
        let bar = foo; // owner is bar and is valid within this block scope, foo in invalidated now
        println!("value of bar is {}", bar); // bar is valid here
    }

    println!("value of foo is {}", foo); // foo is invalid here as it has moved
}
Enter fullscreen mode Exit fullscreen mode

The ownership concept can be a bit weird to get used to, especially since passing a variable to a method will also move it(if its not a literal or reference), but given that it saves us from GC I think its worth it and the compiler takes care of helping us when we make mistakes.

Immutable by default

Variables are immutable by default. If you want to mutate a variable you have to specifically mark it using the mut keyword.

let foo = "hello" // immutable
let mut bar = "hello" // mutable
Enter fullscreen mode Exit fullscreen mode

Variables are by default passed by value, in order to pass a reference we would have to use the & symbol. Quite similar to Golang.

fn main() {
    let world = String::from("world");

    hello_ref(&world); // pass by reference. Keeps ownership
    // prints: Hello world
    hello_val(world); // pass by value and hence transfer ownership
    // prints: Hello world
}

fn hello_val(msg: String) {
    println!("Hello {}", msg);
}

fn hello_ref(msg: &String) {
    println!("Hello {}", msg);
}
Enter fullscreen mode Exit fullscreen mode

When you pass a reference it is still immutable so we would have to explicitly mark that mutable as well as below. This makes accidental mutations very difficult. The compiler also ensures that we can only have one mutable reference in a scope.

fn main() {
    let mut world = String::from("world");

    hello_ref(&mut world); // pass by mutable reference. Keeps ownership
    // prints: Hello world!
    hello_val(world); // pass by value and hence transfer ownership
    // prints: Hello world!
}

fn hello_val(msg: String) {
    println!("Hello {}", msg);
}

fn hello_ref(msg: &mut String) {
    msg.push_str("!"); // mutate string
    println!("Hello {}", msg);
}
Enter fullscreen mode Exit fullscreen mode

Pattern matching

Rust has first-class support for pattern matching and this can be used for control flow, error handling, variable assignment and so on. pattern matching can also be used in if, while statements, for loops and function parameters.

fn main() {
    let foo = String::from("200");

    let num: u32 = match foo.parse() {
        Ok(num) => num,
        Err(_) => {
            panic!("Cannot parse!");
        }
    };

    match num {
        200 => println!("two hundred"),
        _ => (),
    }
}
Enter fullscreen mode Exit fullscreen mode

Generics

One thing I love in Java and TypeScript is the generics. It makes static typing more practical and DRY. Strongly typed languages(Looking at you Golang) without generics are annoying to work with. Fortunately, Rust has great support for generics. It can be used in types, functions, structs, and enums. The icing on the cake is that Rust converts the Generic code using specific code during compile time thus there is no performance penalty in using them.

struct Point<T> {
    x: T,
    y: T,
}

fn hello<T>(val: T) -> T {
    return val;
}

fn main() {
    let foo = hello(5);
    let foo = hello("5");

    let integer = Point { x: 5, y: 10 };
    let float = Point { x: 1.0, y: 4.0 };
}

Enter fullscreen mode Exit fullscreen mode

Static types and advanced type declarations

Rust is a strictly typed language with a static type system. It also has great type inference which means we don't have to define types manually for everything. Rust also allows for complex type definitions.

type Kilometers = i32;

type Thunk = Box<dyn Fn() + Send + 'static>;

type Result<T> = std::result::Result<T, std::io::Error>;
Enter fullscreen mode Exit fullscreen mode

Nice and simple error handling

Error handling in Rust is quite nice, there are recoverable and unrecoverable errors. For recoverable errors, you can handle them using pattern matching on the Result enum or using the simple expect syntax. There is even a shorthand operator to propagate errors from a function. Take that Go.

use std::fs::File;

fn main() {
    let f = File::open("hello.txt").expect("Failed to open hello.txt");

    // or

    let f = match File::open("hello.txt") {
        Ok(file) => file,
        Err(error) => {
            panic!("Problem opening the file: {:?}", error)
        },
    };
}
Enter fullscreen mode Exit fullscreen mode

Tuples

Rust has built-in support for tuples, and this is highly helpful when you have to return multiple values from a function or when you want to unwrap a value and so on.

Block expressions

In Rust, you can have block expressions with their own scope almost anywhere. It also lets you assign a variable value from block expressions, if statement, loops and so on.

fn main() {
    let foo = {
        println!("Assigning foo");
        5
    };

    let bar = if foo > 5 { 6 } else { 10 };
}
Enter fullscreen mode Exit fullscreen mode

Beautiful compiler output

Rust simply has the best error output during compilation that I have seen. It can't get better than this I think. It is so helpful.

Alt Text

Built-in tooling

Like many modern programming languages, Rust also provides a lot of build-in standard tooling and honestly, I think this is one of the best that I have come across. Rust has Cargo which is the built-in package manager and build system. It is an excellent tool. It takes care of all common project needs like compiling, building, testing and so on. It can even create new projects with a skeleton and manage packages globally and locally for the project. That means you don't have to worry about setting up any tooling to get started in Rust. I love this, it saves so much time and effort. Every programming language should have this.

Rust also provides built-in utilities and asserts to write tests which then can be executed using Cargo.

In Rust, related functionality is grouped into modules, modules are grouped together into something called crates and crates are grouped into packages. We can refer to items defined in one module from another module. Packages are managed by cargo. You can specify external packages in the Cargo.toml file. Reusable public packages can be published to the crates.io registry.

There are even offline built-in docs that you can get by running rustup docs and rustup docs --book which is amazing. Thanks to Mohamed ELIDRISSI for pointing it out to me.

Concurrency

Rust has first-class support for memory safe concurrent programming. Rust uses threads for concurrency and has 1:1 threading implementation. i.e, 1 green thread per operating system thread. Rust compiler guarantees memory safety while using the threads. It provides features like waiting for all threads to finish, sharing data with move closures or channels(similar to Go). It also lets you use shared state and sync threads.

use std::thread;
use std::time::Duration;

fn main() {
    thread::spawn(|| {
        for i in 1..10 {
            println!("hi number {} from the spawned thread!", i);
            thread::sleep(Duration::from_millis(1));
        }
    });

    for i in 1..5 {
        println!("hi number {} from the main thread!", i);
        thread::sleep(Duration::from_millis(1));
    }
}
Enter fullscreen mode Exit fullscreen mode

Macros and meta-programming

While I don't like all aspects of macros in Rust, there are more things to like here than dislike. The annotation macros, for example, are quite handy. Not a fan of the procedure macros though. For advanced users, you can write your own macro rules and do metaprogramming.

Traits

Traits are synonymous to interfaces in Java, it is used to define shared behaviors that can be implemented on structs. Traits can even specify default methods. The only thing I dislike here is the indirect implementation.

pub trait Summary {
    fn summarize_author(&self) -> String;

    fn summarize(&self) -> String {
        format!("(Read more from {}...)", self.summarize_author())
    }
}

pub struct NewsArticle {
    pub author: String,
    pub content: String,
}

impl Summary for NewsArticle {
    fn summarize_author(&self) -> String {
        format!("@{}", self.author)
    }
}

fn main() {
    let article = NewsArticle {
        author: String::from("Iceburgh"),
        content: String::from(
            "The Pittsburgh Penguins once again are the best hockey team in the NHL.",
        ),
    };

    println!("New article available! {}", article.summarize());
}

Enter fullscreen mode Exit fullscreen mode

Ability to use unsafe features if required

  • Useful in advanced use-cases where you know what you are doing. A necessary evil IMO. I like it since its doable only within an unsafe { } block making it very explicit. I would have moved this to the dislike section if that was not the case.
  • When you use these, the Rust compiler cannot guarantee memory and runtime safety and you are on your own to get this right. So definitely for advanced and experienced users.

What I don't like about Rust

Things that I didn't like very much, in no particular order.

Complexity

I don't like it when a language offers multiple ways to do the same things. This is one think Golang does pretty well, there are no two ways to do the same thing and hence it is easier for people to work on larger codebases and to review code. Also, you don't have to always think of the best possible way to do something. Unfortunately, Rust does this and I'm not a fan of it. IMO it makes the language more complex.

  • Too many ways for iterations -> loops, while, for, iterators.
  • Too many ways for creating procedures -> Functions, closures, macros

Edit: Based on discussions here and on Reddit, I say my perception of complexity only have increased. It seems like once you get past all the niceties there are a lot of things that would take some time to wrap your head around. I'm pretty sure if you are experienced in Rust, it would be a cakewalk for you but the language indeed is quite complex, especially the ways functions and closures behave in different contexts, lifetimes in structs and stuff.

Shadowing of variables in the same context

So Rust lets you do this

{
    let foo = "hello";
    println!("{}", foo);
    let foo = "world";
    println!("{}", foo);
}
Enter fullscreen mode Exit fullscreen mode
  • Kind of beats being immutable by default(I understand the reasoning of being able to perform transformations on an immutable variable, especially when passing references to a function and getting it back)
  • IMO lets people practice bad practices unintentionally, I would have rather marked the variable mutable as I consider the above mutation as well.
  • You can as easily accidentally shadow a variable as you would accidentally mutate one in Languages like JavaScript
  • Gives people a gun to shoot in the foot

Edit: I saw a lot of comments here and on Reddit explaining why this is good. While I agree that it is useful in many scenarios, so is the ability of mutation. I think it would have been perfectly fine not to have this and people would have still loved Rust and all of them would have defended the decision not have this. So my opinion on this hasn't changed.

Functions are not first-class citizens

While it is possible to pass a function to another they are not exactly first-class citizens like in JavaScript or Golang. You cannot create closures from functions and you cannot assign functions to variables. Closures are separate from functions in Rust, they are quite similar to Java lambdas from what I see. While closures would be sufficient to perform some of the functional style programming patterns it would have been much nicer if it was possible using just functions thus making language a bit more simple.

Edit: Oh boy! this opinion triggered a lot of discussions here and on Reddit. So seems like Functions and closures are similar and different based on context, It also seems like Functions are almost like first-class citizens, but if you are used to languages like Go or JavaScript where functions are much more straight forward then you are in for a crazy ride. Functions in Rust seems much much more complex. A lot of people who commented seemed to miss the fact that my primary complaint was that having two constructs(closures and functions) that look and act quite similar in most of the scenarios makes things more complex. At least in Java and JS where there are multiple constructs(arrow functions, lambdas) those where due to the fact that they were added much later to the language and those are still something I don't like in those languages. The best explanation was from Yufan Lou and another from zesterer. I'm not gonna remove this from stuff I don't like since I still don't like the complexity here.

Implicit implementation of traits

I'm not a fan of implicit stuff as its easier to abuse this and harder to read. You could define a struct in one file and you could implement a trait for that struct in another file which makes it less obvious. I prefer when the implementation is done by intent like in Java which makes it more obvious and easier to follow. While the way in Rust is not ideal, it is definitely better than Golang which is even more indirect.


Nitpicks

Finally some stuff I still don't like but I don't consider them a big deal.

  • I don't see the point of having the const keyword when let is immutable by default. It seems more like syntax sugar for the old school constants concept. Diane pointed out the difference const provides and that makes sense.
  • The block expression and implicit return style are a bit error-prone and confusing to get used to, I would have preferred explicit return. Also, it's not that readable IMO.
  • If you have read my other post about Go, you might know that I'm not a fan of structs. Structs in Rust is very similar to structs in Golang. So like in Go, it would be easy to achieve unreadable struct structures. But fortunately, the structs in Rust seem much nicer than Go as you have functions, can use spread operator, shorthand syntax and so on here. Also, you can make structs which are Tuples. The structs in Rust are more like Java POJOs. I would have moved this to the liked section if having optional fields in structs where easier. Currently, you would have to wrap stuff in an Optional enum to do this. Also lifetimes :(
  • Given strings are the most used data types, it would have been nice to have a simpler way of working with strings(like in Golang) rather than working with the Vector types for mutable strings or slice types for immutable string literals. This makes code more verbose than it needs to be. This is more likely a compromise due to the fact that Rust is not garbage collected and has a concept of ownership to manage memory. https://doc.rust-lang.org/rust-by-example/std/str.html - Edit: I have moved this point to nitpicks rather than dislikes after a discussion on the comments with robertorojasr

Conclusion

I like programming languages that focus more on simplicity rather than fancy syntax sugars and complex features. In my post "My reflections on Golang", I explain why I consider Golang to be too simple for my taste. Rust, on the other hand, is leaning towards the other side of the spectrum. While it is not as complex as Scala it is not as simple as Go as well. So its somewhere in between, not exactly the sweet spot but almost near that quite close to where JavaScript is maybe.

So overall I can say that there are more things in Rust for me to like than to dislike which is what I would expect from a nice programming language. Also, bear in mind that I'm not saying Rust should do anything differently or that there are better ways to do things that I complained about. I'm just saying that I don't like those things but I can live with it given the overall advantages. Also, I fully understand why some of those concepts are the way they are, those are mostly tradeoffs to focus on memory safety and performance.

But don't be fooled by what you see over the hood, Rust is definitely not something you should start with as your first programming language IMO, as it has a quite a lot of complex concepts and constructs underneath but if you are already familiar with programming then it shouldn't be an issue after banging your head on the doors a few times :P

So far I can say that I like Rust more than Golang even without implementing a real project with it and might choose Rust over Go for system programming use cases and for high-performance requirements.

Note: Some of my opinions have changed after using Rust more. Checkout my new post about the same


If you like this article, please leave a like or a comment.

You can follow me on Twitter and LinkedIn.

Cover image credit: Image from Link Clark, The Rust team under Creative Commons Attribution Share-Alike License v3.0.

Latest comments (71)

Collapse
 
simonvoid profile image
Stephan Schröder

The big advantage of traits over interfaces, is that you can implement (your) traits on structs that you don't have source control over (-> structs from any lib you use).
Orphan rules apply: you can't implement other people's traits on other people's structs (because those could clash with other people's implementations), but all other combinations of who wrote trait and struct work.

Collapse
 
infensus profile image
Dominic • Edited

I really wanted like Rust and I do like several things. Honestly I just find the compiler annoying, it treats all code as if it could be multi-threaded even if it's not - so you have to jump through hoops and hours of learning about things like Arc, Rc, Cell, RefCell, Box, RwLock etc, not to mention the infuriating rules around lifetimes and borrowing.

Simple fact is that these data structures are inefficient and Rust advocates get aggressively defensive over anything Rust, they will tell you things like "A reference counter and dynamic borrow checking is hardly any difference"... yes it is. And they will tell you "Just copy it, it's just 2 fast shallow copies to read and write the value back". We are often talking about systems where nano seconds matter here, otherwise I'd just go and use something like Go. So yes it matters.

C and C++ is much more intuitive to me (ok C++ has a lot of features, some that's missing in Rust), but they are much easier to build a mental model about. I don't need a compiler to whine at me for holding 2 references to an object - that is organic and necessary in many situations (e.g. two data structures that can reference an object efficiently for different operations). And 99% safe on a single thread but Rust will force you to spend hours looking for less efficient solutions. The module system in Rust is also bizarrely over engineered.

The best thing about Rust is Cargo. If C++ had a Cargo equivalent there would be no contest for me.

To me Zig is a much more promising language but not stable yet - ziglang.org

Collapse
 
deepu105 profile image
Deepu K Sasidharan

Btw, I have used Rust for some real use cases and some of my opinions have changed. Take a look at my follow up post deepu.tech/concurrency-in-modern-l...

Collapse
 
turbopape profile image
Rafik Naccache

I think rust must be put in context. This is intended to be a modern systems programming language(I've seen people have developed Operating Systems with it). This is definitely not for Web or Scripting, and so what seems to be complex is just an approach to tackle what's inherently complex in systems programming, I think. You would definitely not use it to write web apps, but if you have to write firewalls or network probes, I guess this is your best choice nowadays.

Collapse
 
deepu105 profile image
Deepu K Sasidharan

Yes, you are right, but I was not talking from building a web app per see, I was purely talking from the language perspective. Btw, Rust is the most impressive language I have come across.

Collapse
 
turbopape profile image
Rafik Naccache

Yep, it is impressive :) I know you weren't mentioning any application type, but to understand the language spirit, one must keep in his back-mind what problems it was meant to address. This was my point :)

Thread Thread
 
deepu105 profile image
Deepu K Sasidharan

I understand, but I feel some of my criticism are still valid even in a systems programming sense also Rust is definitely being used in more than systems now, like web assembly, CLIs and so on

Thread Thread
 
turbopape profile image
Rafik Naccache

Absolutely

Collapse
 
jkgan profile image
Gan Jun Kai • Edited

Thanks for sharing! Actually I like the "Implicit implementation of traits", it allows me to add extension into primitive types so that I can do something like: github.com/jk-gan/aion

Collapse
 
steeve profile image
Steeve

Thanks for your review, Rust reminds me a lot C language but it is much safer about memory, I have to try it out!

Collapse
 
richardeschloss profile image
Richard Schloss

Have you taken the Servo browser for a spin yet? How well does it render DEV.to? I've been meaning to give that one a go again.

Collapse
 
deepu105 profile image
Deepu K Sasidharan

Not yet, unfortunately

Collapse
 
guyinpv profile image
Zack

You compared Rust and Go with the likes of JS, Java, others. I'm curious, would they also make for good replacements as a web server-side language in the place of PHP as an example? Or are they meant for some other purposes like AI or games or data manipulation or something?

It would be nice if you left a very general thought about where using the language would make the most sense. i.e. "If I were building an X, Go would be a great choice."

Collapse
 
deepu105 profile image
Deepu K Sasidharan

I did touch upon that in my other post about Go. But I do have plans to write a post covering multiple languages that I have used in my career where I could atleast highlight why I think certain language fits well for certain usecases. But that post would need some hard work as I need substanciate with usecases and benchmark to keep it fair. Keep tuned.

Collapse
 
louy2 profile image
Yufan Lou • Edited

Thank you for sharing your experience of trying out Rust!

For optional struct fields, there's derive-new which gives you various T::new() constructors. Derive is borrowed from Haskell, similar to Project Lombok for Java.

The three Fn* traits are a consequence of Rust's memory safety model built on linear logic, commonly known as lifetime / ownership. They are still first class values, meaning you can use let to bind them with a name and pass them in parameters like any other. They are just more complicated than function in JavaScript or closure in Java.

Rust has Fn, FnMut and FnOnce in order to enforce at compile time rules which Java or JavaScript can only panic at run time:

  • FnOnce can only run once. These can be functions like free() in C or close() in Closable. Calling FnOnce twice on the same object or context would not compile. thread::spawn() uses FnOnce to enforce that no references are passed to the new thread.
  • FnMut can mutate its captured state. This is most similar to a normal function in Java and JavaScript. There can be only one FnMut capturing the same binding existing at one time. If more, it would not compile.
  • Fn cannot mutate its captured state. This is somewhat analogous to const function in C++.

There's an order: FnOnce < FnMut < Fn. A Fn* can be used in the place of ones to its left.

Collapse
 
deepu105 profile image
Deepu K Sasidharan

Wow. Thanks this is so far the most simple and straightforward explanation I got and now it makes more sense. I guess I would have to update the post to reflect what I learned about functions.

Collapse
 
kip13 profile image
kip

Good perspective.

This is my recommendation related to closures and first-class functions.

Collapse
 
ofergal profile image
Ofer Gal

Why even have yet another language?

Collapse
 
deepu105 profile image
Deepu K Sasidharan

I don't think Rust is just another language. It fills the gap for a systems programming language that is easier to work with than C++ and IMO is a much needed one.

Collapse
 
unicodex profile image
UNIcodeX

I'd be interested to read one of these for Nim.

Collapse
Collapse
 
karrq profile image
Karrq

Regarding your point on functions not being first class citizens:

play.rust-lang.org/?version=stable...

Keep rusting!

Collapse
 
mmstick profile image
Michael Murphy • Edited

Concurrency in Rust is not tied to a particular threading module, and may not even be tied to threads at all. It is up to the programmer to choose how to concurrently execute their tasks.

Using futures, it is possible to join multiple futures together so that they execute concurrently from the same thread. When one future is blocked, the next future in the queue will be executed.

// Concurrently execute two tasks on the current thread
let (result1, result2) = join!(future1, future2);

// Concurrently execute tasks with a common error type.
let result =  try_join!(future1, future2, future3);

It's also possible to distribute them across a M:N thread pool, and interchangeably mix and match both approaches. Spawning a future will schedule it for execution on your executor. The executor may be based on a thread pool, or run on the same thread. Depending on which you choose, they may have Sync / Send restrictions.

task::block_on(async move {
    // Each spawn returns a JoinHandle future to the result.
    let future1 = task::spawn(future1);
    let future2 = task::spawn(future2);
    let future3 = task::spawn(future3);

    // Concurrently wait for all three threads to complete.
    let (result1, result2, result3) = join!(future1, future2, future3);
});

Often times there's two different pools to spawn tasks to: non-blocking thread pools, and blocking thread pools. Tasks which block should be spawned on blocking pools so that they avoid blocking tasks on the non-blocking thread pool. The async-std crate provides spawn_blocking for that.

Without futures, you may use crates like rayon to distribute blocking tasks across a thread pool. This used to be the preferred threading model before the introduction of async/await with futures.


There is an issue with your assertion that functions aren't first class. You can accept both functions and closures as input arguments, and return functions and closures as output arguments. Generics is required for returning closures, however, because closures are dynamically-created types.

fn function_returning_function() -> fn()  {
    name_of_other_function
}

fn function_returning_closure() -> impl Fn() {
    let mut var1 = ...;
    let mut var2 = ...;
    move || {
        ...
    }
}
Collapse
 
deepu105 profile image
Deepu K Sasidharan

Yes, concurrency in Rust is quite interesting