News #25:
@erikagain I didn’t think we could get this close, but you might be right!
gopurs is now down to about 13ms for the full benchmark suite, compared with roughly 11ms for the hand-written Go implementations (which I also optimized: 27ms -> 11ms). There are reasons to believe that the compiled code will perform on par with hand-written native code, once again.
The 10ms mark is starting to look within reach. 
News #26:
Okay, just like with purust, I’m now struggling to gain microseconds. It’s no longer in the millisecond range. So this is no longer a priority.
All my efforts are once again focused on the official release of gopurs. I can now see the light at the end of the tunnel.
News #27:
Good news! 
I’ve decided to keep the backend written in PureScript and compile it to Go using gopurs itself, rather than rewrite it in Rust. That will also be the highway to maintainability for PureScript devs.
In fact, I’ve underestimated the progress made so far: gopurs can actually compile itself now, and the compiled code is super optimized.
It’s no longer just a promise: it’s already working. I’m compiling the small real-world project I usually talk about, in Go, using a Go binary from gopurs (instead of the usual JS one). We can now leverage its parallelism, speed, etc.
Using gopurs to build itself also gives us a substantial real-world workload. Improvements to code generation, the runtime, and the Go FFI can then benefit both the compiler and other PureScript applications.
Cheers! 
