> 100ms with how many responses per second As always, it depends. Benchmarks are cool, and yes we know that Rust and Go will always be faster than Ruby out of

> 100ms with how many responses per second As always, it depends. Benchmarks are cool, and yes we know that Rust and Go will always be faster than Ruby out of the box. Once the number of responses goes up, you throw caching at the problem. But the benchmark says > The requirements were clarified to specify caching or memoization of the output from JSON serialization is not permitted. > the table has 12 rows Which is low and should be quick regardless, but regardless of your tech stack if you are creating a "modern" UI, you handle this update asynchronously with JS anyway, and if you're not, do you really care about sub 100 ms responses? If you want performance out of the box, yes you will use Go, but like I said earlier, you use a hammer for nails and a screwdriver for screws. If you want performance and type safety, you choose one, if you want faster prototyping and a more mature web dev ecosystem, you choose another.