Sure, I do hope we can focus on one concurrency primitive, but the possibility that we may have async/await and coroutine at the same time seems kind of unfortunate to me.
Sadly Vala is not safe, which is an essential defect for a high-level language, and It seems to be impossible to get wide adoption outside gnome world.
Lack of inheritance is a shortage of Rust, but maybe we can have a kind of React-like GUI library for it.
My initial motivation of following Rust is because it is the only language that can integrate into and extend the traditional Linux C world seamlessly except C++, which is generally hated by the open source culture. Glad to see the initial attempt goes well, and hope the gnome people will no longer need to construct GUI with C in the second decade of twenty-first century.
Simply comparing M:N threading with futures is not correct. In my experience using futures in Javascript, it does not support control flow at all. The goroutine's equivalent is async/await, which transform the cps of asynchronous I/O back to sync form, but it may impose more overheads than M:N threading since it stores the stack structure in its parameter.
The Windows version is not availiable because mozjs the JavaScript engine, Or say, SpiderMonkey, fails to compile on windows currently, and servo developers can not know when it will be fixed. Once it can be build on windows, windows version may come out soon.
As a gentoo user I would say that the ABI break may still worth it if it can enable a lot of application continuing to work with just a recompile, right?
The controversial around this plan origins from people's inability to understand why such a fundamental library like gtk+ needs to have api break in such a high frequency, which would have a huge impact on the experience of app devs and users? The world has its intrinsic complications, but we all hope to avoid the casual one.
There is no guarantee that the good software you are using have someone maintaining it or interested in porting it, which is really common in open source word. For me they are Texmacs which only have bug fixes nowadays and a bunch of browser plugins whose producer are not willing in porting them.
The serious problem here is that, What this plan shows is a total lack of concern. Doing rolling release for a distribution is OK, but for a fundamental library this is unacceptable. Qt has been doing much better on this.
I already have gtk2, gtk3, qt4, qt5 installed on my linux machine, the situation which I really hope to get rid of.
And now GNOME devs hope user to install gtk2, gtk3, gkt4, gkt5, gtk6 at the same time to solve imcompatibility. Nice try.