125 pointsby cat-whisperer3 days ago9 comments
  • bfLives3 days ago
    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?

    • cmrdporcupine3 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-whisperer3 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_3 days ago
        Could you elaborate on why using block_on wouldn't be an acceptable solution for users that want a blocking API?
        • cmrdporcupine3 days ago
          Why would I want to add tokio as a dependency if I don't use it?
          • 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-whisperer2 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.
        • cat-whisperer2 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.
  • cmrdporcupine3 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!

    • tmpfs3 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-whisperer3 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.
        • tmpfsa day 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

          https://github.com/tmpfs/anticipate/

  • faizshah2 days ago
    This is awesome, there’s a really nice one in python called prompt toolkit that has some a nice api as well: https://python-prompt-toolkit.readthedocs.io/en/master/
  • serial_dev2 days ago
    Interesting stuff!

    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.

  • hkalbasi3 days ago
    How it compares to other libraries in this space, e.g. reedline or rustyline?
    • cat-whisperer3 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.
  • ilikegreen3 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.
    • fredrikholm2 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.

  • jiaaro3 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?
    • gertlex3 days ago
      I wonder if they could get away with an extra L and using ascii art of the pokemon...
    • dartos3 days ago
      Right up until they start charging
    • 3 days ago
      undefined
  • Y_Y3 days ago
    [flagged]
    • gertlex3 days ago
      Classic bagon comment! :)
    • 3 days ago
      undefined
  • dsffsad3 days ago
    [flagged]