Rust: First impressions from a C++ developer

So, even I started learning Rust 2 weeks back (yay!!) whenever I got free time. And all the time that I spent  learning it has been worthwhile.

This is not going to be a deep technical post, but just my impressions about Rust from where I come from (C++).

My Impressions

Getting Started

• Rust is a sufficiently complex language in that, it is not as easy as Go or Python to just pickup and start. Having said that, one can still just code something useful in a day, but a language which is claiming to be a real systems language needs to be understood a lot better.
• So, for me it would be the regular steps of learning the language and start coding basic data structures and algorithms from scratch and then start contributing to some project or create my own.
• There are some pain points which I will come down to later.

Borrowing & Ownership

• Even though I have been programming in C++ since before C++11 came into picture and understand and make use of its sophisticated / advanced features, I am still not comfortable enough to say that I am an expert in C++ with a straight face. So, coming from this background I did not have any difficulty in understanding the Borrowing and Ownership concepts. Those are the things we strive for in our modern C++ code. Who doesn't love RAII ?
• But striving to achieve is lot different than being enforced by the compiler! 
• It is really amazing if access to invalid memory address is caught at compile time. I was really happy. With C++, there are quite a lot of simple cases which still today cannot be detected by the "-f sanitizeXXX" options.
• This is such a huge win and advantage! I must admit that early in my career, I did return a reference to a local variable and that got passed through code review as well! (The changes were quite big)

Complexity

• This again depends from where you are coming from. If one is coming from Node/JS/Python or even plain C background,  they might get overwhelmed with the concepts.
• And one of the main reason is because the compiler wont budge unless you do the right thing!! :)
• For comparison, it's easier for an average C programmer to write in C++ because they continue to write in C!! They do get overwhelmed if made to code in true C++ style because thats when they understand the concepts involved in getting you Zero Cost Abstractions.
• So, for me it is not at all as complex like C++. But still, I have a lot much left to learn.

Concurrency / Threading / Network library

• It would have been awesome if coroutines was there. But we will be getting it soon I suppose as LLVM has it.
• But then, it has Go like Channels! That itself is a very simple abstraction to get your things done quickly.
• Working with the Socket level abstractions were also pretty easy. I am yet to dig into more details of it and then to MIO and Tokio libraries.
• Not much to report here as I do not have much experience with the provided abstractions.

Lifetimes

• This is still something which I don't think I understand to its fullest especially the Variance and Subtyping. In general, Covariant, Contravariant and Invariant types are kind of easy to understand, but at a deeper level on how to use the relevant markers is till something I do not understand.
• I ran into this especially while trying to implement Vector data structure as put out in the nomicon book. We will see more about it bit later.
• Otherwise lifetimes as a concept for linear type is pretty cool and might give some headache if one is going to use references a lot in uncommon ways which prohibits lifetime ellision.

Allocation

Most of what I will be putting here are questions to the fellow Rust developers. I did not find answers to those when I needed it. So don't consider it as something "you can't do in Rust". It is something which "I didn't get how to use in Rust".

• As a systems programmer, I do want to have access to the base allocator and write my own Allocators.
• While writing my Vector library, the nomicon book says to use "alloc" crate, but that can't be used in stable release. Then I rustup'ed to nightly release and still could not use it! The version was 1.26.
• I want to use Allocators in stable release. How ?
• I know there are example on how to (de)allocate using Vec. I am somehow not comfortable with that. Is it really Zero Cost ?
• What I have done:



    ///
    fn allocate(count : usize) -> *mut T
    {
        let mut v: Vec<T> = Vec::with_capacity(count);
        let ptr = v.as_mut_ptr();
        mem::forget(v);
        return ptr;
    }
    ///
    fn deallocate(ptr: *mut T, len: usize, cap: usize)
    {
        unsafe {
            mem::drop(Vec::from_raw_parts(ptr, len, cap));
        }
    }



• This is really not something I would like to continue doing.

Exceptions

• To be honest, I am glad its not there. I clearly know about when to use exceptions and when to use return codes and blah blah.... But still. Writing exception safe code in C++ is still a challenge especially when you are designing data structures.
• Result<T, E> is something I prefer compared to exceptions.
• Its been hard for me while writing libraries to support both exceptions and error_code for the users who might prefer one over the other. I will probably start using Expected or Outcome whenever its available.
• Do I need to even mention about the pattern matching support ? Its awesome!! Took me back to my days when I used to be Erlang developer.

Overall

• It's a YES!!
• There are still a lot of things I really liked but have not talked about, for eg: Traits, Enums on steroids, Pattern Matching, Functional Programming Style and generic programming. All that maybe for another day.
• But sadly, its still going to be a language for my side projects.
• C++ would still be my go to language for foreseeable future. With all the new features and language additions coming (creeping) in, there is barely enough time to switch.
• Rust obviously has huge potential. But still not quite there to replace C/C++ completely. But I really hope C dies and see people (mostly average software developers) write more structured code.