On Mon, 2020-05-11 at 19:34 +0200, Jacob Carlborg via Digitalmars-d-learn wrote: > On 2020-05-11 16:44, Russel Winder wrote: > > > Crickey, a third option. This wil increase my dithering! ;-) > > Forth: Mecca [1] :) > > [1] https://github.com/weka-io/mecca
Hummm… it seems everyone who needed async activity and particularly I/O in D has written their own. Mostly along with all their own data structures and algorithms library. The Rust experience is that there were also many attempts (cf. Tokio and Async_std) but that development and maintenance now seems focused on providing the minimal support for futures in the language (as an API to work with) and the crate futures to provide all the serious stuff, and that all the different event loops are converging on using this – Tokio and Async_std are moving to provide functionality over the std::futures and futures stuff as far as I can tell, indeed Async_std's name tells their story. It isn't pretty in many ways, but it works, and provides a one true Rust-y way of being asynchronous. gtk-rs is working to use the GTK+ async stuff (which is callback based) but provide it in a Tokio/Async_std kind of API based on std::futures and futures crate. This is a huge, huge plus over what D has. GtkD is missing all the added extras that gtk-rs is in the process of providing. As far as I can tell D has no futures… on which to base an equivalent system. I guess the async/.await language syntax will almost certainly never get into D even though it is the choice for Rust and Python – and indeed Kotlin but with a different syntax structure. But is there an alternative, a pure library based way. Clearly yes at the expense of some irritating verbosity that Rust, Python and Kotlin chose not to cope with, but to make language syntax changes instead. Of course this requires effort. Clearly, Rust, Python, and Kotlin have paid people to do all the futures stuff. Firther there is some effort to do this in gtk-rs and I am providing some input with this. If there was effort to add futures to D and extend GtkD in the way gtk-rs is being extended, it would be good for D. D is far, far better than Rust for writing GTK+ code, and could easily replace Vala. However, with the way gtk-rs is developing and GtkD is not, Rust will win out. Well at least people like me will use Rust and gtk-rs instead of D and GtkD because of the language and library evolution in the right direction. Sadly I think that whilst there may or may not be a flurry of activity on this thread, there will not be enough volunteers committed to do the work on futures in D and GtkD to make anything happen. I keep trying to come back to D for GTK+ working, but in the end I keep going back to Python and Rust because D has no futures, and no added extras over GtkD auto translation of the GTK+ API to make it D-y in the way gtk-rs make GTK+ Rust-y. Sorry for the apparent gloom, I just felt the need to tell it how I feel. -- Russel. =========================================== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
signature.asc
Description: This is a digitally signed message part