I did see that! And saw the programmatic select behaviour too by reading the macro. My main issue with chan is actually the lack of SendError, deadlocking on receiver drops would leak way too many resources for my use cases. The low throughput is a bit concerning, though I only have one use case that is performance sensitive, so not a huge deal.
I canāt agree more!
Do you have any examples of something like this in other languages?
(Some might think this is dangerously off-topic, but looking for inspiration in other languages is no sin at all.)
At risk of sounding like a member of the cult of McCarthy: CSP in Clojurescript is fairly mature now and the creator of Om[1] has produced a lot of writing on the subject. As introductory material, there is this[2], and this[3], and this[4], too. The fact that the second link has a 100,000 concurrent DOM updating processing going at the same time and the UI is still responsive, without a single callback or future, should impress anyone with JS experience.
There is also this paper[5] by Rob Pike, the creator of Go, which I have read a few times. It is okay, and has a fair amount of code.
Links can be found at: gist:4f01a160342afe2aca6f Ā· GitHub
I would be forever grateful if you could give me more feedback on the issue tracker. 
In particular, use cases for getting an error on send and use cases for higher throughput. If these are the only things preventing you from using chan, then it seems like I should be able to help you resolve them.
Fun way to start an off-topic conversation: make a new conversation with this button! 
1 Like
In fact Iād like to see a whole new OS written in rust with all major components having interactive GUI representations. We can dream, can we?
1 Like
Issue created!
I'd like to get your opinion on https://github.com/cybergeek94/kiss-ui.
I tried to create an interface that's as Rust-y as possible, considering the limitations of the underlying toolkits. It's still missing a bunch of features that I haven't had time to implement yet, but it works.
The top want for a future KISS-UI 2.0 is to implement it directly on top of the toolkit APIs, instead of using a C library that does the abstraction for me. I have some major nits with IUP's design that are too deeply ingrained to ever be fixed.
Hey,
What I'm thinking is pretty radical, in fact I would like to move away from burdensome interaction with OS-dependent GUI frameworks and starting from scratch in a new OS, perhaps with a new kernel. I'd like to have your opinion on this, specifically the Operating System section. I think that Rust is a great opportunity here.
The entire Android SDK would be nice.
1 Like
I'd rather see a replacement for Android in Rust. The Android API is one of the worst I have ever seen (but I concede I have not looked at the windows or macos APIs, I am sure there are treasures of horribleness there): a maze of almost-identical incompatible modules, depending on whether they come from java, Google or third party, calls to factories to get generators to get accessors to getā¦ Modules that replace useful modules and are deprecated three months laterā¦
1 Like
I completely agree that the Android SDK is horrific, but it's what we got. If Rust gets a replacement for Android it would first have to become popular to actually be useful.
Classic chicken-and-egg problem see I here. It just has to start somewhere.
Late to the party, but the reason why thread pools & multi-threaded event loop are listed as non-goals is because it is trivial to build such things on top, either directly or as part of a micro library that works w/ mio.
I'd like to see (1) a pure rust cross-platform GUI library; (2) a Windows WMI library.
I used to work with the wxWidget Library
https://github.com/wxWidgets/wxWidgets
I think it shows a nice way how to create a Crossplatform GUI Library
Working with Delphi we used to have a Pascal Port of the C MySQL Structures which resulted into a XS Pascal MySQL Library.
I think something like this could be achieved also with Rust.