The Rust I wanted had no future

Re:The Rust I wanted had no future by josephg on Monday June 05, 2023 @06:09AM (#36194394)

Its certainly possible with compiler magic. Zig does exactly that - where functions can be colorless and they work slightly differently in async and syncronous contexts, doing the obvious thing in both cases. I'm not sure how well it works in practice (I haven't spent enough time with zig to know). I'd worry that bugs would creep in to whichever variant of the function you aren't exercising.

Its a lovely design though.

https://kristoff.it/blog/zig-colorblind-async-await/

[ Parent | on HN ]

Re:The Rust I wanted had no future by svieira on Monday June 05, 2023 @11:24AM (#36197571)

_Unyielding_ describes the issues that arise when the author of the code doesn't have control of the transactionality / atomicity of their operations at the level they need to: https://glyph.twistedmatrix.com/2014/02/unyielding.html

To my mind it's very much a balancing act between "low power to the developer, high power to the language" and "high power to the developer, low power to the language" all up and down the stack from software / hardware to "consumer / framework".

[ Parent | on HN ]

Re:The Rust I wanted had no future by svieira on Monday June 05, 2023 @05:35PM (#36204104)

See also: https://www.tedinski.com/2018/11/06/concurrency-models.html which is the first article I've ever seen that says that `m:n`-style-green-threads are bad and good at the same time.

TL;DR - he says that "doParallel" and "doConcurrently" are separate operations with distinct semantics that designers of programs must care about and that conflating the two (especially the common "doConcurrently-and-often-but-not-always-in-parallel") is one of the most common causes of bugs in programs that need to make progress in multiple threads of execution.

[ Parent | on HN ]

Re:The Rust I wanted had no future by astrange on Monday June 05, 2023 @09:24PM (#36206867)

A notable and common thing about this article is that it confidently declares futures/promises are good for parallelism, but this is wrong - they are flawed because they introduce priority inversions.

To schedule tasks properly, you need to know who is waiting on them as early as possible. With a promise, you only know when you get to the "wait()" call, which is too late.

The correct solution is called structured concurrency.

[ Parent | on HN ]

Re:The Rust I wanted had no future by svieira on Tuesday June 06, 2023 @02:20PM (#36216978)

Depends on if you're using Monix/Haskell style tasks (lazy, run when depended on) or JS-style promises (E Promise / C# Task / Java Future - run when instantiated, waiting is post-submission). Agreed completely though, structured concurrency is fantastic.

[ Parent | on HN ]