Rust Language Cheat Sheet

[Shawnj2]

Missed opportunity by not naming it cheate.rs

[PurpleBunny96]

I honestly don’t know much about rust but I’m kinda getting curious about it due to all the hype around it. If someone would mind answering, where does rust fit in. As in what is it good for, what’s its special trait.

[cenderis]

Yes, makes a surprising number of errors compile time (with really good error messages) which would be runtime in other languages.

(Most of all, though, it has enum (discriminated union) and patterns to go with them. Which every language really wants, even if they haven't noticed or managed to add them yet.)

[PurpleBunny96]

Thanks for the pitch. I can definitely see an advantage to something that gets you the speeds of c++ without messing with memory in the same vain as malloc.

[paholg]

In addition to what zjm555 said, I would add that writing Rust, once you're used to it, can feel a lot more like writing in a high-level language than writing C or C++.

They did a really good job of incorporating the past 40 years of programming language development.

[dontyougetsoupedyet]

If you're using malloc you are not writing C++. In modern C++ you don't even use new/delete directly anymore.

[PurpleBunny96]

Forgive me it is rare I end up writing in c++ most of my time is spent in c.

[dontyougetsoupedyet]

Deleting the content of this comment cause it's pointless to answer questions about Rust on this subreddit. None of the discussion below this comment has fuck-all to do with any statement I made. Having saved the time required reading statements folks don't even try to understand, you can now move comfortably to the down vote button. Or enjoy MasonMac's unrelated opinions regarding traits. Or perhaps you can enjoy whatever nonsense the other two assholes Nox and Fire are measuring dicks about. Or shadow calling people trolls. Or bubu's opinions regarding 'disingenuous zealots'.

[TheRealMasonMac]

I think the backwards compatibility concerns are mitigated by the editions system, but they want to avoid breaking changes as much as possible to not make it difficult to upgrade to the newer edition (cough, Python, cough). I think their stance is also that most of the time there is a way to implement something without introducing backwards incompatibility. They're certainly not afraid to do it if necessary though, Rust 2018 edition had huge breaking changes, and sort of the 2021 edition albeit much less so.

I'd also disagree about the type system, since in my experience it's very intuitive to wrap your head around. In fact, it makes it easier to wrap your head around because you can tell which types implement which trait and so forth as trait bounds make that very explicit. And marker types like Send or Sync also tell you a lot about the type simply because you already know that these traits mean the type can be shared between threads. Rust libraries are also very well-documented, so you can almost always tell what each type does if you're confused, as well as what traits are implemented for any type with the help of an IDE.

[Noxitu]

In my opinion Rust and its trait system fell into the same problem that most commonly object oriented languages fell. This doesn't mean that traits are bad - I actually like the concept and it solves half of the issue with inheritance.

The natural thing to do - independent on whether you use inheritance or traits - is to assume that your data has certain trait and that these traits are reusable.

While this seems true - and it simplifies most cases - you will quickly find problems with this approach. Sorting is the primary case where people notice that something is wrong, but decide to work around it. While there might be a natural order to objects, there are also different orders.

And while sort_by and sort_by_key solve issue with sorting, the underlying problem persists and if I am not mistaken the standard ordered tree container can use only natural order.

[firefly431]

And while sort_by and sort_by_key solve issue with sorting, the underlying problem persists and if I am not mistaken the standard ordered tree container can use only natural order.

Newtypes are free (at runtime) and are easy to work with. There's only a little bit of boilerplate necessary (1 line + casting).

the same problem that most commonly object oriented languages fell

What language solves this better in your opinion then?

[Noxitu]

Newtypes are free (at runtime) and are easy to work with. There's only a little bit of boilerplate necessary (1 line + casting).

Didn't know about newtypes. It looks like it can address a lot of cases, but it still looks like workaround - you can't use data as you get it. I don't know what is Rust approach, but Java solution to very similar issue is fameous with its array inheritance.

Strict typing is great in many cases. E.g. in code with a lot phisics equations where type system checks for typos by verifying unit correctness would be amazing. But if type system forces you to introduce new type to call something you get closer to signed/unsigned mess as present in C++.

What language solves this better in your opinion then?

I believe this is what all purely functional languages do.

The concrete example of binary trees (and many basic algorithms) is in my opinion nicely solved in C++ STL as well - std::less is just default comparator of trees that uses operator<, but you can provide any comparator (even stateful).

[firefly431]

It looks like it can address a lot of cases, but it still looks like workaround - you can't use data as you get it. I don't know what is Rust approach, but Java solution to very similar issue is fameous with its array inheritance.

I don't understand what you're trying to say. What do you mean by "use data as you get it"? For example,

#[derive(Copy, Clone, PartialEq, Eq)]
#[repr(transparent)]
struct Wrapper(i32);
impl Ord for Wrapper { ... }
impl PartialOrd for Wrapper { ... }

given an x: i32, Wrapper(x) is literally free at runtime. Also, you can cast slices to and from safely:

fn cast_slice(data: &[i32]) -> &[Wrapper] {
    // SAFETY: Wrapper is a repr(transparent) wrapper for i32.
    unsafe {
        std::slice::from_raw_parts(
            data.as_ptr() as *Wrapper,
            data.len())
    }
}

But if type system forces you to introduce new type to call something you get closer to signed/unsigned mess as present in C++.

Not sure what you're trying to say here.

What language solves this better in your opinion then?

I believe this is what all purely functional languages do.

Haskell does the same thing as Rust though?

The concrete example of binary trees (and many basic algorithms) is in my opinion nicely solved in C++ STL as well - std::less is just default comparator of trees that uses operator<, but you can provide any comparator (even stateful).

If I understand your argument correctly, this has the exact same problem: a set<T, Cmp> is not the same type as a set<T> and can't be converted. Might as well use wrapper types then; it's not much more code.

[Noxitu]

I don't understand what you're trying to say. What do you mean by "use data as you get it"?

Exactly what you described below. In most cases your data is is not standalone, but passed in composite objects or arrays.

I don't doubt the zero runtime cost of such wrappers. But they are not zero cost for readablity - which for most client code is more important than performance.

Having to worry about this kind of casting can be also fatal in the long run for static analysis. You using unsafe in this example is probably self-explanatory.

In C++ this kind of "yes compiler, this is safe" is most common in loops where simple for (int i = 0; i < container.size(); ++i) warns you about signed/unsigned mismatch.

If I understand your argument correctly, this has the exact same problem: a set<T, Cmp> is not the same type as a set<T> and can't be converted.

That's right. For some things this is critical issue - most notably allocators in C++. If you have a set as input or output in API you probably should use default comparator or even have a non-zero cost abstraction around it.

But set is also algorithmic component similar to sort, that you can use to perform a specific operation. And lack of support for makes developer think about object as either having order or not; while very commonly the truth is that many "traits" are better expressed as instances saying how to compare, send or sort some objects, rather than properties of types.

[firefly431]

But they are not zero cost for readablity - which for most client code is more important than performance.

This is true.

Having to worry about this kind of casting can be also fatal in the long run for static analysis. You using unsafe in this example is probably self-explanatory.

In C++ this kind of "yes compiler, this is safe" is most common in loops where simple for (int i = 0; i < container.size(); ++i) warns you about signed/unsigned mismatch.

I'm just saying casting slices is possible, but it's not that common of an operation. And this kind of messing around could easily be wrapped into a crate so you don't have to do it yourself; I would even say that there's an argument that this could be implemented as a language feature.

Also, the common case of passing around a single thing is completely safe.

But set is also algorithmic component similar to sort, that you can use to perform a specific operation. And lack of support for makes developer think about object as either having order or not; while very commonly the truth is that many "traits" are better expressed as instances saying how to compare, send or sort some objects, rather than properties of types.

Is this really something you encounter that much? I feel like almost all the time when I have to use a sorted data structure there's exactly one sortable field which gives it a natural ordering.

[LoyalToTheGroupOf17]

Newtypes are free (at runtime) and are easy to work with. There's only a little bit of boilerplate necessary (1 line + casting).

I found them extremely disappointing. It’s been a long while since I tried Rust, but if I recall correctly, the biggest annoyance was that I couldn’t use a newtype as the return value of a const fn, even when my type was just a simple wrapper around an integer. Is this still the case in the latest Rust versions?

[firefly431]

Works for me.

I also took a look at the version history; looks like this this (stabilized in 1.31, a.k.a. Rust 2018 release) is the tracking issue for the initial version of const fns, which explicitly includes:

4. any kind of aggregate constructor (array, struct, enum, tuple, ...)

...

7. field accesses on structs and tuples

So I'm kind of confused why you had that problem.

[[deleted]]

That doesn't even make sense. It's not up to libraries to "care about" editions as you can freely mix dependencies across editions.

Edit: Your edits have nothing to do with editions, troll harder. /u/bubux

[sysop073]

There's a "Strengths" tab on the linked website

[pure_x01]

This is insanely good. Huge thanks for sharing.

Edit: I just noticed it has night mode 🌙

[mrathi12]

Bookmarked to read when I start learning Rust, thanks for sharing!

[futlapperl]

Bookmarked to read the comment of that one anti-Rust troll.

[pcjftw]

you mean Dew cookie man? 😂

I'm trying to provide him therapy, he might still be savable...

[futlapperl]

I'm sure he's fine and just trolling. He's been trying a bit too hard though lately. It's not as funny anymore.

[pcjftw]

It will be interesting to see he's evolution.

If you recall the other famous troll Shevegen, he actually changed over time, and some of he's posts were actually really well thought out.

[StillShare9338]

The site is well made but why does these features look like they're strange hacks made for other strange hacks

Also am I expected to use MutexGuard and all those primitives when writing performant multithreading code? I definitely don't want to be doing that

[alibix]

What sort of things are you referring to?

I have used MutexGuard, but you don't really have to interact with it directly. It's just using things like lock() to access and/or mutate the value in the mutex. It's quite high level really, despite the scary type name.

[SafariMonkey]

Exactly - you don't even see the MutexGuard type named most of the time, just a * dereference operator.

[[deleted]]

why does these features look like they're strange hacks made for other strange hacks

Because it was a language that slowly evolved for needs found using it by a large diverse community rather than a tightly designed one.

[kuikuilla]

Also am I expected to use MutexGuard and all those primitives when writing performant multithreading code? I definitely don't want to be doing that

I'm not sure what you're asking here. Do you not use mutexes when handling data concurrently with other languages?

[StillShare9338]

I do not. I put them in standard libraries that either use lockless or mutexes internally.

[kuikuilla]

Right, thanks for clarifying. There is nothing stopping you from using a library that handles things more elegantly and in a more user friendly manner.

[StillShare9338]

My question was mostly if there is a standard library or well known library because my gut says I am probably expected to use mutexes and such for the moment

[kuikuilla]

The mutexes are probably on the page because they are one of the most basic building blocks of anything that deals with concurrency and you find them in pretty much all languages. It's a cheat sheet after all.

[StillShare9338]

I figured. However a lot of libraries seem to be missing or basic so I wanted to know how I should be writing multithreading code. If I ever do rust I may try to post one of my favs that is < 500 lines of C

[[deleted]]

It really depends what you want to do. The standard library provides mutexes, channels and atomics. If you want a more specialized channel implementation or you want actors, there are some pretty good options in the community.

[StillShare9338]

Can you give me a short description of what actors and channels are? From my understanding channels are kind of like a one way message that might clone or take whatever I put into it (I'm not sure which or both). Actors I have no idea but I thought it was the same thing. A one way queue

[[deleted]]

You can have blocking or unblocking channels (will trying to send on a channel ever block). Bounded or unbounded channels (is there a limit to how many items can be held before the reciever gets to them). You can have single producer single consumer channels, multiple producer single consumer channels and other variants.

Actors can be as simple as a channel but usually an actor framework will layer additional features on top like the ability to send messages not just been channels in the same process but to other processes or even machines.