5 ms·

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 exec

by dbrgn 6y ago

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/ 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.

kccqzy 6y ago
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.
- tick_tock_tick 6y ago
  > 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_allocation https://en.cppreference.com/w/cpp/language/coroutines#Heap_a...
  - deleted 6y ago
    [deleted]
  - millimeterman 6y ago
    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.
  - kccqzy 6y ago
    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.

by dbrgn 6y ago

kccqzy 6y ago

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.

tick_tock_tick 6y ago
> 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_allocation https://en.cppreference.com/w/cpp/language/coroutines#Heap_a...
- deleted 6y ago
  [deleted]
- millimeterman 6y ago
  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.
- kccqzy 6y ago
  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.