20 comments

[ 2.6 ms ] story [ 78.9 ms ] thread
My personal favorite feature of this release: It enables the async/await language feature to work on #[no_std] targets. This means that with an appropriate executor, you can run async/await code on embedded microcontrollers!

Ferrous Systems have written a blogpost on what async/await can look like for writing embedded firmware: https://ferrous-systems.com/blog/async-on-embedded/ With Rust 1.44, this now becomes possible on the stable release of the language (previously you needed nightly). Very exciting.

Meanwhile in C++ land, the recently standardized coroutine feature even requires a heap allocation in order to work.

I can't help but think that the best minds among language designers and systems programmers have probably already jumped ship to Rust.

> The call to operator new can be optimized out (even if custom allocator is used) if

> The lifetime of the coroutine state is strictly nested within the lifetime of the caller, and the size of coroutine frame is known at the call site in that case, coroutine state is embedded in the caller's stack frame (if the caller is an ordinary function) or coroutine state (if the caller is a coroutine)

Basically if you limit yourself to only functionality supported in Rust you'll never actually generate an allocation. Once you start using features Rust doesn't support you need to provided memory via some means.

https://en.cppreference.com/w/cpp/language/coroutines#Heap_a...

(comment deleted)
We'll have to wait and see how finished coroutines implementations perform, but I'm leery of the fact that sidestepping heap allocation relies on compiler optimizations. Optimizers can be fickle and in a language like C++/Rust, I like being 100% sure that the abstractions are zero-overhead.
Relying on compiler optimizations is not the answer. When they work, you don't notice, but an unrelated change could very well change the compiler's state and optimization decisions, falling off a performance cliff.

This is especially pronounced in languages that rely a lot on compiler optimizations. In Haskell you can purposefully use the singly linked list for very large collections, knowing they will be optimized out, until one day the compiler decided not to optimize that and now you have a problem.

There's a reason C++17 made return-value-optimization a proper part of the language with mandatory elision of copies. People like guarantees. Optimizations are but the icing on the cake.

I know you US people are going through tough times and I deeply sympathize with you, but I'm not fan of political ads in release announcements. There are countless more serious problems in the world that would also deserve some publicity, but I don't want to see them there. If I'm alone with this I'm sorry and I'll shut up.
To be clear, it's possibly a political statement but it's hardly an ad, at least in any sense that people (Americans?) traditionally use the term.

I also don't think that the existence of 'more important' issues precludes the discussion of other issues that may be relevant to a large number of people (or a small number of people, for that matter). I would certainly find it annoying if every political conversation I took part in were interrupted with "Well, that's nothing to be compared to climate change", even if I believed it to be true.

It is clearly an ad. Not a commercial ad but those aren't the only kind (as you pointed out).

They've opened themselves up to arguments over what non Rust-related cause to advertise next! "For Rust 1.45 I think we should put replace the release notes with a message about the civil war in Yemen."

Tech is a first-world thing. It is quite clear that the problems in the most tech-y country in the world would spill into tech itself.

By the way, the same thing happens with for example suicides at Chinese factories: companies do take a stance which source from these factories because it directly affects them.

> Tech is a first-world thing.

Wow, quite a statement. Guess I'm giving up on coding, then.

Agreed. Tech is and should never be political.

These kinds of statements also basically says you are not welcome if you decide not to support movements like BLM. Perhaps as a user it does not matter, but imagine if you were a maintainer?

Best to keep these discussions out of Rust and other projects as much as possible. So yes, you are not alone in this.

I have to point out however that there are aspects of just pure human decency that should be a given in any kind of collaborative project.

I might be wrong, but police shows little to no respect for any human being right now. Old people getting hurt because they are "standing in the way" has nothing to do with political views. Just my 2c,oc.
> Tech is and should never be political

I'm curious, do you think internet companies should refrain from releasing statements about political issues like net neutrality or the Patriot Act?

No, but I think that's more comparable to e.g. the Civil Rights Act of 1964 (only the opposite). Even then, it's outside the scope of these software projects, in my view.
BLM has nothing to do with Rust. The fact that the core team thought that it's appropriate to project their political opinions in Rust release notes is honestly an embarrassment.
Not nothing to do with Rust. There is a connection. People. People write and use Rust and people have opinions.

We've got major UK banks, with no presence in the US, making statements on the situation. Why shouldn't the Rust dev team, who are in part US citizens.

Next we see release notes with hints to wear masks or go get the vaccine or whatever because marks and vaccines are for people and people write Rust. Also buy a gun because people. and vote X for president because people. Lets justify every crap in release notes because people.
My personal favorite feature of this release is that I didn't read it. Stooped right as I saw their political balderdash smeared all over a f*cking release announcement. STOP THAT CRAP!