D and Async I/O

Russel Winder russel at winder.org.uk
Tue May 12 09:23:40 UTC 2020


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20200512/58ae0c5c/attachment.sig>


More information about the Digitalmars-d-learn mailing list