>I'll preface this by saying that neither of us has a lot of experience writing Python async code
> I'm actually really interested in spending proper time in becoming more knowledgeable with Python async, but in our context you a) lose precious time that you need to use to ship as an early-stage startup and b) can shoot yourself in the foot very easily in the process.
The best advice for a start-up is to use the tools that you know best. And sometimes that's not the best tool for the job. Let's say you need to build a CLI. It's very likely that Go is the best tool for the job, but if you're a great Python programmer, then just do it in Python.
Here's a clearer case where the author was not very good with Python. Clearly, since they actually used Django instead of FastAPI, which should have been the right tool for the job. And then wrote a blog post about Python being bad, but actually it's about Django. So yeah, they should have started with Node from day one.
The only issue with writing a CLI in Node is ecosystem. The CLI libraries for Node are (or were last time I checked) inspired by React. Not a paradigm that is fun to write in, and if I'm making a CLI tool it is because I am bored and want to make something for my own entertainment.
Yeah the last CLI app I used was actually a TUI. It routed std out and std err from scripts and programs it'd call out to into separate windows. It had animations and effects and a help system built in. It also had theming support because the library I used for the TUI happened to have that and came with some default themes! It was a bit beyond a simple CLI tool.
If I'm farfing around with the console I'm going to have fun.
Gemini CLI used it, and I actually hate the layout. Never thought I'd see a CLI manage to waste terminal window space to the point of needing to zoom it out.
>I'll preface this by saying that neither of us has a lot of experience writing Python async code
> I'm actually really interested in spending proper time in becoming more knowledgeable with Python async, but in our context you a) lose precious time that you need to use to ship as an early-stage startup and b) can shoot yourself in the foot very easily in the process.
The best advice for a start-up is to use the tools that you know best. And sometimes that's not the best tool for the job. Let's say you need to build a CLI. It's very likely that Go is the best tool for the job, but if you're a great Python programmer, then just do it in Python.
Here's a clearer case where the author was not very good with Python. Clearly, since they actually used Django instead of FastAPI, which should have been the right tool for the job. And then wrote a blog post about Python being bad, but actually it's about Django. So yeah, they should have started with Node from day one.