Looks really interesting. I like the approach of writing pure functions that return descriptions of IO tasks to perform. A couple of questions:
1. Why async?
2. Why couple to anyhow instead of using an associated error type?
cmrdporcupine 2 days ago [-]
+1 for #1. In general, I would recommend providing non-async alternative APIs, with the async runtime as an option rather than assumed default. Not all of us drink the kool-aid there. And no, I don't mean just providing a "sync" API that uses "block_on" behind the scenes but still uses tokio...
Also, for async don't mandate tokio, use the "agnostic" crate to abstract it so people can use alternative runtimes.
And yes, don't use anyhow in a library like this. Anyhow is for your internal code, not public libraries/crates. Define a set of error enums, or use thiserror for it if you have to.
cat-whisperer 2 days ago [-]
Yup, I am planning to use thiserror and error-stack for this in the future updates. But, anyhow provides an insanely easy interface for the person using this library, and keeps their mind off the error handling and rather in managing the domain stuff.
dhon_ 2 days ago [-]
Could you elaborate on why using block_on wouldn't be an acceptable solution for users that want a blocking API?
cmrdporcupine 2 days ago [-]
Why would I want to add tokio as a dependency if I don't use it?
cat-whisperer 2 days ago [-]
I was thinking of making it a opt-in feature, but I saw most of the usecases that I might have, might need concurrency and a runtime.
dhon_ 2 days ago [-]
Yes you're right. I'd assumed that tokio was used internally in the UI but from a cursory read it doesn't seem to be the case.
cat-whisperer 2 days ago [-]
it definitely would be, that was my intention. By passing in a runtime you can either block or schedule. Giving you control on what you want to be concurrent and what you don’t.
cmrdporcupine 2 days ago [-]
Neat. I'll check it out.
One suggestions: the README advertises lovely TUIs. Show us a screenshot, or screencast, so we can see what you mean!
tmpfs 2 days ago [-]
Yes, a screenshot would be good to get a visual on this.
I have done a simple shell using Rustyline and Clap and this could be something I might be interested in but it's hard to say without a visual idea, asccinema would be perfect!
cat-whisperer 2 days ago [-]
asccinema is a killer idea! but I am still chasing my perfect shell . If you end up implementing an insane looking shell with this, contributions are always open.
tmpfs 15 hours ago [-]
I don't have the time to look deeper into it right now as I am quite happy with my current setup but if you do want to make an ascinema recording here is a little tool I wrote to help testing and recording CLIs
Video or gif would be nice! It’s like a UI library need at least a screenshot, this thing needs a video demo of sorts.
Q: why write that the docs is by LLM? In my opinion if it’s correct, and it makes sense, I don’t care even if an alien gave it to you.
cat-whisperer 1 days ago [-]
giving credit where credit is due.
hkalbasi 2 days ago [-]
How it compares to other libraries in this space, e.g. reedline or rustyline?
cat-whisperer 2 days ago [-]
Wow! rustyline has intensive support for a lot of the actions and things the user can do. Though I wanted to provide a more restrictive yet powerful abstraction that’s my I chose a trait based approach. It provides the exact control needed on certain aspects of the shell while providing ample control because of the shared state.
Initially, I was planning to make the functions async, but I rather choose to pass the async runtime instead. It solves for 2 cool use-cases; 1 we can call block_on and manage an async task in the flow, or 2 queue in the action and consider pooling it when needed.
ilikegreen 2 days ago [-]
Please don't mind my possibly simplistic question — but is this something that would bring Rust development closer to a Lisp environment? Seems like an interesting project.
fredrikholm 2 days ago [-]
This is more in line with building a REPL for your own language.
Lisp environments are just that; environments. That is to say that there is a runtime that holds your code in memory, which then enables a REPL to replace parts of the code in memory while the program is running.
This implies an interpreted language (that might or might not also be compiled further at runtime), which Rust is not. It also heavily implies a garbage collector, which Rust doesn't have. Lastly, type guarantees in these languages tend to be less strong as the system almost by definition is already very dynamic.
jiaaro 2 days ago [-]
Cool project! But, I wonder how long can a project like this use a Pokemon as their namesake and mascot before you hear from nintendo's lawyers?
gertlex 2 days ago [-]
I wonder if they could get away with an extra L and using ascii art of the pokemon...
cat-whisperer 2 days ago [-]
ascii art for the win
dartos 2 days ago [-]
Right up until they start charging
2 days ago [-]
Y_Y 2 days ago [-]
[flagged]
gertlex 2 days ago [-]
Classic bagon comment! :)
2 days ago [-]
dsffsad 2 days ago [-]
[flagged]
Rendered at 03:03:11 GMT+0000 (Coordinated Universal Time) with Vercel.
1. Why async?
2. Why couple to anyhow instead of using an associated error type?
Also, for async don't mandate tokio, use the "agnostic" crate to abstract it so people can use alternative runtimes.
And yes, don't use anyhow in a library like this. Anyhow is for your internal code, not public libraries/crates. Define a set of error enums, or use thiserror for it if you have to.
One suggestions: the README advertises lovely TUIs. Show us a screenshot, or screencast, so we can see what you mean!
I have done a simple shell using Rustyline and Clap and this could be something I might be interested in but it's hard to say without a visual idea, asccinema would be perfect!
https://github.com/tmpfs/anticipate/
Video or gif would be nice! It’s like a UI library need at least a screenshot, this thing needs a video demo of sorts.
Q: why write that the docs is by LLM? In my opinion if it’s correct, and it makes sense, I don’t care even if an alien gave it to you.
Lisp environments are just that; environments. That is to say that there is a runtime that holds your code in memory, which then enables a REPL to replace parts of the code in memory while the program is running.
This implies an interpreted language (that might or might not also be compiled further at runtime), which Rust is not. It also heavily implies a garbage collector, which Rust doesn't have. Lastly, type guarantees in these languages tend to be less strong as the system almost by definition is already very dynamic.