Rust 1.63 Released, Adding Scoped Threads (rust-lang.org) 27
This week the Rust team announced the release of Rust 1.63.
One noteable update? Adding scoped threads to the standard library: Rust code could launch new threads with std::thread::spawn since 1.0, but this function bounds its closure with 'static. Roughly, this means that threads currently must have ownership of any arguments passed into their closure; you can't pass borrowed data into a thread. In cases where the threads are expected to exit by the end of the function (by being join()'d), this isn't strictly necessary and can require workarounds like placing the data in an Arc.
Now, with 1.63.0, the standard library is adding scoped threads, which allow spawning a thread borrowing from the local stack frame. The std::thread::scope API provides the necessary guarantee that any spawned threads will have exited prior to itself returning, which allows for safely borrowing data.
The official Rust RFC book says "The main drawback is that scoped threads make the standard library a little bit bigger," but calls it "a very common and useful utility...great for learning, testing, and exploratory programming.
"Every person learning Rust will at some point encounter interaction of borrowing and threads. There's a very important lesson to be taught that threads can in fact borrow local variables, but the standard library [didn't] reflect this." And otherwise, "Implementing scoped threads is very tricky to get right so it's good to have a reliable solution provided by the standard library."
One noteable update? Adding scoped threads to the standard library: Rust code could launch new threads with std::thread::spawn since 1.0, but this function bounds its closure with 'static. Roughly, this means that threads currently must have ownership of any arguments passed into their closure; you can't pass borrowed data into a thread. In cases where the threads are expected to exit by the end of the function (by being join()'d), this isn't strictly necessary and can require workarounds like placing the data in an Arc.
Now, with 1.63.0, the standard library is adding scoped threads, which allow spawning a thread borrowing from the local stack frame. The std::thread::scope API provides the necessary guarantee that any spawned threads will have exited prior to itself returning, which allows for safely borrowing data.
The official Rust RFC book says "The main drawback is that scoped threads make the standard library a little bit bigger," but calls it "a very common and useful utility...great for learning, testing, and exploratory programming.
"Every person learning Rust will at some point encounter interaction of borrowing and threads. There's a very important lesson to be taught that threads can in fact borrow local variables, but the standard library [didn't] reflect this." And otherwise, "Implementing scoped threads is very tricky to get right so it's good to have a reliable solution provided by the standard library."
manual memory management bites (Score:1)
Re:manual memory management bites (Score:4, Informative)
Of course it would be better if programmers didn't have to think about memory management, and in most modern languages (including Rust, but excluding C), they generally don't have to.
OTOH there are some situations where you genuinely do need that level of control (e.g. inside a realtime context where any manipulation of the heap at all could blow your cycle-budget and cause your audio playback to skip, or your Mars rover to fall over, or etc), and in those situations it is useful to have language support for manual memory management so that you can precisely control when heap operations occur (and more importantly, when they don't occur).
Re:manual memory management bites (Score:5, Insightful)
it would be better if programmers didn't have to think about memory management, and in most modern languages, they generally don't have to.
It's a mistake to think that you shouldn't / don't need to think about memory management. I'm a little sick of impossibly slow and needlessly resource intensive software from developers who seem to think that memory is infinite and that allocations/deallocations are completely free.
in those situations it is useful to have language support for manual memory management so that you can precisely control when heap operations occur (and more importantly, when they don't occur)
You have a lot more control than you think. This is not an all-or-nothing kind of thing. It does, however, require some awareness of what your code is doing. That seems to be a pretty big ask these days...
Re: (Score:1)
It seems that in managed languages, you also need to know what everyone else's code is doing. That's where I get tripped up. Like why is that call to Exit calling Dispose but the call to close doesn't (and they are treated the same in all docs). Somewhat maddening when you want to *really* know what's going on.
Re: (Score:2)
...modern languages... excluding C..,.
Who thinks of C as "modern" these days? It's fifty years old.
Not that there's anything wrong with that.
Re: (Score:2)
Anybody with a clue. C is modern. But coder education has regressed and most coders today want to be treated as infantile semi-incompetents that need no insights and no skills to do their jobs.
Re: (Score:2)
If you are doing serious real-time programming, such as on a Mars lander, you don't do dynamic memory allocation in the first place.
Re: manual memory management bites (Score:3)
Just so â" which means you canâ(TM)t and wonâ(TM)t be using any language where heap management is implicit and therefore unavoidable. Thatâ(TM)s why, for example, Appleâ(TM)s CoreAudio API is written in C, rather than Objective C or Swift.
Re: (Score:2)
Nonsense. What you do is dynamic allocation that you completely understand and control and that cannot surprise you.
Re: (Score:3)
When designing code competently you almost always need tot hink about memory management. If you do not, your code will be significantly worse. There is no magic "one size fits all" memory management. It always comes with trade-offs and you absolutely need to understand them or you (or your customer) may run into some pretty bad surprises.
Re: (Score:2)
Is it just me or why do I hate having to think about memory management with any programming language?
Having to is bad; being able to is good.
Re: (Score:3)
Is it just me or why do I hate having to think about memory management with any programming language? Isn't programming hard enough?
Not thinking about memory and ownership doesn't make programming easier, it just makes it buggier. You can pick a language that allows you to share memory willy-nilly between threads. It's certainly easier to get something up and running but making sure it's correct is really, really hard in all but the simplest cases.
Re: (Score:3)
Rust is more like C or C++ in that stuff lives on the stack or heap. But unlike C or C++ you rarely have to think about allocating or freeing memory - the compiler generates the code for you. But the compiler requires your code to pass lifetime & borrowing checks, i.e. that you don't have referen
Re: (Score:2)
The thing is there are some types of control you cannot get and will never get with automatic memory management. (Unless we finally get actually intelligent "AI", but then all coders will likely lose their jobs, so YMMV.) The more systems orientend or real-time a piece of software is, the more critical is keeping memory management unter the control of the coder. Sure, many coders do not like that and most are not really competent to do it either, but that is a different problem.
Re: (Score:3)
Is it just me or why do I hate having to think about memory management with any programming language? Isn't programming hard enough?
"Memory" is only one sort of resource. Leaving things like open file handles in the hands of a garbage collector is an even bigger nightmare.
In the long run it's better to learn to manage resources.
If your language has RAII and stack unwinding then it's mostly easy to do.
experience (Score:3)
Results inconclusive, deliberately (Score:1, Interesting)
They've focused on advocating rewriting other people's projects in rust, rather than doubled down on writing (large) projects in rust by themselves. That way you can claim any "improvements" for your camp but blame any setbacks on "it's not done yet" or "it's because of the legacy code". It's a good trick to drive adoption while sidestepping scrutiny. Once entrenched, mealticket bought and any and all defects are "it is what it is" or at best "we're working on it, honest".
So no, there won't be serious real
Re: (Score:2)
Re: (Score:3)
Nope, not enough time. Bit the numbers of CVEs for Rust are not any better than for other languages. Which is as expected. The other countless times people claimed some language would finally eliminate a problem and would not create other problems did not work out either. Grande claims are a sure sign that something stinks.
Re: (Score:2)
Bit the numbers of CVEs for Rust are not any better than for other languages.
Cite? I'm curious to know how you (or whoever) did the comparison, because it's not an easy comparison to make.
Re: (Score:3)
Now there has been a little time for rust to get established, are there real-world results that show rust programs to be more robust overall than similar projects written in other languages ?
It's still fairly new, and not huge (41kloc), but Android's cryptographic key management daemon (keystore) was rewritten in Rust in 2020, and the results have been very good. The daemon is a fairly complex bit of code, with complex concurrency requirements and a critical role in platform security. The previous (C++) implementation had struggled a bit with hard-to-resolve deadlocks and had a long history of rare and unreproducible crashes that we never managed to track down. The Rust implementation has been
A pretty neat idea (Score:2)
So still unfinished and experimental? (Score:2)
Yeah, _that_ is the language I will depend on in my next large project!