On Mar 5, 2020, at 12:05 AM, roger peppe <rogpe...@gmail.com> wrote: > > Having said all that, I believe there is a valid point to be made > with regard to testing concurrent Go programs that have long-lived > behaviour over time. It can be hard to test such programs, and I've > not yet seen an approach that doesn't feel clunky and/or somewhat > error-prone.
Dijkstra wrote "Testing reveals the presence, not the absence of bugs". This is particularly true of concurrent programs! How do you ensure there are no deadlocks? There may be too many states to test. And debugging is even harder. How do recreate conditions for a deadlock when you don't really know what may be the cause? In contrast formal specification languages/tools such as TLA+/Coq/SPIN seem to have made better headway. It would be good if specification support can be integrated into Go. Or may be, have a separate language analogous to the Bluespec language that can be compiled to Verilog. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/58D60EAB-E90C-4F53-90D0-07751A232923%40bitblocks.com.
