1. 6

    Python: I wish asyncio never happened.

    Racket: I wish the compiler was faster and that it had better error reporting.

    Despite having used many other languages, I don’t think I can say I love any of them as much as these two.

    1. 2

      Python: I wish asyncio never happened.

      Just ignore it? Seriously - unless you have use for it, it’s in no way a required part of the standard language?

      1. 1

        What is it about asyncio you dislike so much?

        1. 5

          I wrote about it on HN a while back: https://news.ycombinator.com/item?id=18110319

      1. 2

        Author here, I’d greatly appreciate any feedback, ideas, critiques! Thanks :)

        1. 1

          I’m personally not a fan of Python async code as it adds visual noise in my opinion, but I can understand why you would chose that model.

          Apart from that noise, the task model looks well thought out and approachable. I think that is pretty important in any kind of tool that wants to be an alternative to Puppet, Ansible and what have you. Part of what made Ansible big is probably the number of modules that volunteers added themselves.

          1. 2

            Having people contribute back is key to the success of something like this. While Ansible adopted their third-party repository of modules to use, my hope with Pitcrew is to make it more first-party, think homebrew with the “fork and pr” strategy of contributing to it.

            I’m also struggling with the noise of async code in python, really wish it could be more like Ruby fibers.

          2. 1

            How does this compare to fabric? Or ansible with mitogen?

            1. 1

              I don’t have hundreds of hosts handy, so not easy for me to benchmark it, but that would be fun work.

              Fabric seems to use a process per connection, so seems like a downside instead of using nonblocking io.

              It looks like it should be quite similar to Mitogen. Having spent much time in the Yaml forests of Ansible, I can say I don’t personally want live there (see: inner platform effect). Also, Pitcrew should be able to support an inverted control strategy, where you sync the code then execute it local to where it’s running, to avoid roundtrip latency.

          1. 2

            Does it have support for (multiple levels of) SSH jump hosts, a.k.a. bastion hosts?

            edit: Also, does it allow mixing access to remote and local hosts in a single “script”? To two remote hosts? - (how) can I copy a file between two remote hosts as part of a pitcrew script?

            1. 2

              So, you can definitely mix local and remote host access. Two remote access, I haven’t bothered with that feature, but there is no technical limitation that would disallow that.

              Specifically around bastion hosts, AsyncSSH the underlying ssh library I’m using allows proxies, but I haven’t exposed that in an easy way, but I’ll add that feature. Thanks for the idea!

              1. 1

                Please also make sure “chaining” of bastion hosts is allowed, i.e. when I must connect to one bastion host via another bastion host.

            1. 4

              Hoping to release this project to a wider audience, even if it doesn’t find a big useful purpose, been fun to think about what a performant, nice Ansible alternative could look like. https://pitcrew.io/