Open eminence opened 3 years ago
nikomatsakis
commented
3 years ago Hmm, this is a nice idea, and I like the name. I'm wondering if it'd be a good project to use when talking about issues like https://github.com/rust-lang/wg-async-foundations/issues/54? Seems like quite plausibly.
eminence
commented
3 years ago Yeah, I think you are right. I could easily imagine you'd have an async IRC library and a sync TUI library, and you need to glue/bridge them together in a cohesive way. You want to be able to use the best crates from crates.io, but don't really care of those crates are async or not.
A possible idea for a new project: ChatteRS, an IRC Client (application development)
This isn't a PR, because I think it needs a bit of discussion first. Is this type of project unique enough?. But if we agree, I'm happy to convert this into a PR
What is this?
"ChatteRS" is an IRC client (designed as an application to be run as a desktop application). This application might be purely text-based, or it could have a graphical user interface
Description
This IRC client doesn't aim to have the worlds fanciest features, or the slickest interface. But it strives to have a solid, small, easy-to-read codebase that can be easily developed, maintained, and extended over time.
🤔 Frequently Asked Questions
When thinking about a new project, asking "how is it different than the others" is probably the most important point. I think I see the following differences: there isn't a need for a custom runtime or custom futures, or anything really performance sensitive, this isn't a library, but an application that will do a "async-like" things (like reading from the network, getting user input). So it's likely to lean heavily on the ecosystem (crates.io) to provide a lot of functionality.
There's nothing fundamentally important about this project being an IRC client (I think any type of "desktop application" could fit in here), but I thought that an IRC client was a familiar example to a lot of people, and it represents a certain type of real-world application that often just "glues" together existing pieces of functionality, with some fairly simple "business logic" or "application logic" sitting in the middle. So with this in mind, one possible way to focus/target is to focus on this "glue" aspect -- can rust async easily glue together a bunch of different async libraries into 1 cohesive application?
This new project is probably most similar to the existing "YouBuy (Traditional Server Application)" project in that both don't need custom/tailored runtimes, both don't need tight control of performance, both want to rely heavily on the crates.io ecosystem. I do sometimes hear complaints like "rust async only cares about network servers", so I wonder if some type of desktop application might help assuage those concerns (though maybe "SLOW" and "DistriData" already fill that role well enough)
Lastly, I wonder if each project should have an FAQ entry titled "Why is this project written in async rust?" where we can explain why we think rust is a good fit for this particular project. Each of the current projects probably already have a successful real-world version that's not written in rust (indicating that rust isn't the only suitable language for each of these projects). For this "ChatteRS" project, I think the answer to "why is this project written in async rust" is something like: rust's strong type system and focus on correct code can help the project reduce the number of bugs. Even though the project is not performance-focused, rust general reputation of being "not wasteful" with resources is useful. The strength of the crates.io ecosystem is also a big draw here