110
Announcing Rust 1.75.0 (blog.rust-lang.org)
submitted 6 months ago by [email protected] to c/[email protected]

Traits now support async fn and -> impl Trait (with some limitations), the compiler got faster, version = in Cargo​.toml is now optional, and many small functions have been stabilized!

top 15 comments
sorted by: hot top controversial new old
[-] [email protected] 29 points 6 months ago

Nice! Just in time for my yearly "I should finally learn rust" and then forget about it a week later habit.

[-] [email protected] 14 points 6 months ago

I kept reading the same few chapters of the rust book. It's a yearly ritual for me. Same as installing Bethesda games and the Sims and just playing a few hours before uninstalling.

[-] [email protected] 7 points 6 months ago

Haha also yearly for me. I have actually written a small utility in rust that interacts with mysql, but it was basically just transposing python to rust, plus it's hacky as hell and I didn't really learn anything.

I've stuck that rust book in the "one day" silo, along with the guitar, learning French, eating healthy, and getting enough sleep. One day.

[-] [email protected] 6 points 6 months ago

Build a ray tracer in Rust. Follow something like Ray Tracing in One Weekend. Don't be scared that the example code is in C, translating it to Rust is easy enough and is part of the learning process; it's good that you can't just copy paste.

[-] [email protected] 17 points 6 months ago

Async traits 🤩

[-] sugar_in_your_tea 5 points 6 months ago

Nice! Looks like a more ergonomic, faster Rust.

[-] [email protected] 2 points 6 months ago

Sorry to ask, is Rust derived from another language? I know some c++, would that benefit me if I want to learn Rust?
What is powerful about Rust in comparison to other languages?

[-] [email protected] 13 points 6 months ago

I find it's a mix between ML languages and C++, and knowing one of them would help yes. If you're tired if chasing a wild pointer because of a subtle use-after-free in a multithreaded monster under gdb, you'll love #rust.

[-] [email protected] 15 points 6 months ago* (last edited 6 months ago)

Honestly the only things that are similar to C++ are small amounts of C-like syntax, RAII, smart pointers, and iterators. And even so, Rust improves those features a lot. The list of things that Rust rejects from C++ is much larger; Rust does not have:

  • new and delete (perhaps discouraged in modern C++)
  • function overloading
  • inheritance (replaced by composition or traits)
  • friend classes (replaced by modules)
  • exceptions (replaced by Result values)
  • 6 different kinds of first-class constructors (hallelujah)
  • templates (replaced by constrained parametric polymorphism)
  • variable mutability by default

Rust does OOP very differently and leans harder into functional paradigms.

[-] [email protected] 4 points 6 months ago* (last edited 6 months ago)

You could argue that C++'s new is Rust's Box::new, and delete is replaced by RAII. Same concepts but way better ergonomy.

[-] [email protected] 1 points 6 months ago

box::new is pretty directly analogous to std::make_unique (factory for unique_ptr), in general rust’s heap allocating types map to c++’s smart pointer types, which are basically universally recommended over raw new/delete. So another column where rust just gives you the one best C++ feature where it still has 4 supported versions.

[-] [email protected] 3 points 6 months ago

The way I often describe it is "Rust makes functional programming feel as intuitive as object oriented programming".

Pedantically, Rust does offer a subset of object oriented programming paradigms so one could argue that it counts as an object oriented language, but the design patterns that work the best with the language are all coming from functional programming, all without feeling too alien to someone coming from a strictly object oriented background (.. which was my own path into Rust).

[-] taladar 3 points 6 months ago

A lot of Rust concepts were also influenced by Haskell even though Rust uses different terms for them.

[-] [email protected] -5 points 6 months ago
[-] [email protected] 12 points 6 months ago* (last edited 6 months ago)

Maybe Rust isn’t a good tool for massively concurrent, userspace software.

This conclusion is a very weak one.

The only argument the article successfully makes is that using the raw async/await mechanisms of the Rust language leads to situations where it's tricky to figure out how to structure your code, and that the raw async mechanisms of some other languages don't have that friction.

But why would we only consider the strengths of the pure out-of-the-box Rust language and forget that it has an enormous robust ecosystem of crates? For any given use case there will be suitable frameworks that make async Rust programming both natural and performant. Or if such a framework doesn't exist it is possible to develop one on top of the async mechanisms of the raw language because those mechanisms are so unopionated by design.

My colleagues struggle with async Rust as-is. I did too for quite a while. But that's why I'm developing two different async Rust frameworks for two different software architecture paradigms (one that fits nicely into an ECS and one that fits nicely into a deterministic scheduled worker pool) each of which we have different use cases for. If the Rust async design was more opinionated and imposing (which is what this article is recommending) then I likely wouldn't be able to produce frameworks that are as effective for each of these use cases.. one or the other would have suffered, likely both.

this post was submitted on 28 Dec 2023
110 points (96.6% liked)

Rust

5463 readers
2 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

[email protected]

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago
MODERATORS