stshine

Rust is the best lisp ever invented. Why bother another lisp inside it?

The real world is always more complicated, since cps carries stack in its arguments.

I'd love to see this goes well with highest performance.

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.

On the other hand, since these methods are not compatible it will create certain split in the ecosystem.

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.

> But the important thing, is to test the software!

Mandate the world to do test is not a good idea sine the philosophy of the world is to make it work.

>I don't think this isn't really any different than choosing your target device version for say, iOS, Android, or macOS.

No it's not. In case of device only a small bunch of things break. For gtk+ everything breaks without a fix.

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.

I used to upgrade my Qt 4.x with none issue.

For a fundamental library like this devs should at least keep core api stable for a long time, and release unstable components seperately.

As I have stated, I really don't like a large number of similar libraries installed on my machine, each with a bunch of dependencies.

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.

Thanks, now I know I don't need to spend time to study the layout system of TeX.

This is awesome, finally we can get a decent java develop environment in emacs.