I'm planning on creating an AI tournament as a project to test out some of the potential AI performance in a game, _eg_ tic-tac-toe. I'd like the AI to know the full history of a game instead of the instantaneous game-state because I might want some AI that use the historical data, _eg_ AI that always put in the opposite cell of it's previous move if possible. The question I am wondering is, what is the best way to setup the tournament. I have a few options in my headspace: 1. Write everything in Rust (since I also am semi-interested in getting experience with the language) 2. Write everything in Python 3. Write the AI's in anything I want, but interact using stdin/stdout. Connect the AI using some shell script. There are a few nice things I want to have: 1. able to run AI ad hoc against each other, or easily modify the tourney. _ie_ I might want to add a new AI that runs against each of the previous AI instead of having the re-run the whole tourney * Rust would require a re-compile of the tourney code each time which may not be convenient * Options 2 and 3 would be much more convenient since it wouldn't require a full compilation and I can easily write a throwaway script 2. be able to run it in a somewhat performant way since I might want to simulate many rounds * Rust AI would be fast, but to avoid the issue in (1), I might go with solution 3 with the underlying AI being in Rust. But I'm not sure how significant the speed of piping IO between programs compare to if I had wrote everything as a Python program Any advice on this would be great, cause there might be some options that I might have omitted.

I had this discussion in my workplace and wanted to share and get opinions from the folks here. (I suspect StackOverflow might not appreciate such open ended questions). Context: We have a microservice involved in pricing signalling to our users. We have an endpoint which have the following: * Input: an array of item ID's * Output: the expected final price of the given items. The item prices are quite volatile (and no, it is not crypto related), and is dependent on things like instantaneous supply-demand, promotions, _etc_. Since the prices change quite frequently, it became a requirement that we commit to the price that was shown to the user initially, up to a certain time period (_eg_ 5 min after the price was calculated). This improves the UX since the user will be charged as according to what they expected at the start. Currently, in our system, we achieve this via a JWT, which contains all the details in the request, the obligatory signature, and the expiry set to 5 min from the time it was generated. After generating this receipt, the FE can then call the endpoint with the JWT which does the actual payment processing using the params encoded in the token. This way, we know that the params + the total cost that is quoted in the JWT originates from our service since we verify that we signed it. And the system evolves once more. We see that in the system, there is this mechanism, that if the token is expired, we do not reject the request at the charging step. Instead, we call the price endpoint internally using the params provided, and check if the price is the same as in the expired JWT. If it is the same, we process it as normal despite the JWT being expired. This is where the contention lies. I believe that we should force the user to procure another non-expired JWT and removing this complex logic while others believe in the value of this improved UX where the user doesn't need to restart the whole flow again. What do y'all think? Which way would y'all architect the endpoint? Or is there something fundamentally wrong with our design (maybe JWT is not the best suited for this use case)?