chessbot

Thanks :) My point being, if you wanted to execute the following code: https://github.com/cjsaylor/chessbot/blob/11e1059aa77fed84d2... You probably wouldn't be able to, without restructuring how you're handling your state that is being used there. A REPL driven made program usually is made that the runtime carries the state and exposes it, so you could just select that part and run it, and see the output of it. I'm guessing delve is more like a traditional debugger that steps through each line, rather than an REPL, correct?

I don't mind the criticism at all. I don't use it often enough to claim expertise. Fair points about my usage. You can still get proper editor support with Golang (even though it isn't designed for it). I've done so here with VSCode working with a "remote" delve session: https://github.com/cjsaylor/chessbot/blob/11e1059aa77fed84d2...

I rarely use REPL driven development, however in my limited experience using it, it only makes integration testing faster, not unit testing. I used this methodology with a Slack bot, because doing integration testing with Slack is annoying when I'm not directly testing the Slack communication portion. For example: https://github.com/cjsaylor/chessbot/blob/master/cmd/repl/ma... Edit: It seems like there are a lot of comments surrounding him "abandoning" TDD. Not only did he not do that, he literally says in the conclusion of the article that he would not recommend doing it.

I've also created a slack bot for fun to allow slack teammates to play chess within slack: https://github.com/cjsaylor/chessbot. The bot I built is a more traditional server setup, however I did briefly consider using a serverless setup for it. The serverless pipeline seems a lot more complex than the actual application to send the message to a slack channel. I wonder if things like Github's actions would replace the need to have a serverless thing for notifications of this kind (at least within the confines of Github's ecosystem).