A rather nice ~10% speed boost for my tool scc from this just with a simple recompile against some input sets.<p><pre><code> $ hyperfine 'scc' './scc'
Benchmark #1: scc
Time (mean ± σ): 43.5 ms ± 1.7 ms [User: 30.4 ms, System: 88.2 ms]
Range (min … max): 40.5 ms … 48.9 ms
Benchmark #2: ./scc
Time (mean ± σ): 39.6 ms ± 1.3 ms [User: 46.1 ms, System: 89.7 ms]
Range (min … max): 35.9 ms … 42.5 ms
Summary
'./scc' ran
1.10 ± 0.06 times faster than 'scc'
</code></pre>
Trying it on various other inputs it seems to be somewhere between 3% and 10%<p>I am surprised they are still getting these sort of gains to be honest. From memory 1.13 for the same workload came with a ~3% improvement over 1.12. This is purely in terms of wall clock time to run the same code over the same inputs. Have not had a look at the impact of a long running process or memory yet.
Thanks to the Go team for the great work!<p>The more I use it, the more I enjoy Go. Having grown up with the healthy dose of Pascal and later Modula 2, I appreciate many traits of Go which let me just focus on the tasks at hand. With very little "magic" going on, some parts of the code might be a bit tedious, but you also always have the feeling of being in control, as everything is very explicit. Add to that a few underapreciated dynamic features. I am first of all a professional Lisp/Scheme programmer and a lot of Scheme concepts translate surprisingly well into Go due to having first class functions and a garbage collector.<p>It is very nice to see how the Go releases are very careful to add new features while continuosly improve on the "quality" side. Enhancing the performance of "defer" is a great example. Like unwind-protect in Lisp, it is a very elegant way to ensure that cleanup code is run under any circumstance. Removing its overhead is a big thing.
I love Go. It’s too bad that go modules broke ide support and godocs. I miss the simplicity of gopath.<p>Edit:<p>Go modules were not welcomed and godep was supposed to be the official dep manager: <a href="https://twitter.com/_rsc/status/1022588289461743617" rel="nofollow">https://twitter.com/_rsc/status/1022588289461743617</a><p>Godoc is broken because of it and Rob Pike doesn't like it: <a href="https://github.com/golang/go/issues/26827#issuecomment-515849507" rel="nofollow">https://github.com/golang/go/issues/26827#issuecomment-51584...</a><p>VScode with gomodules is still bad even with gopls restarting every 20m: <a href="https://github.com/Microsoft/vscode-go/wiki/Go-modules-support-in-Visual-Studio-Code" rel="nofollow">https://github.com/Microsoft/vscode-go/wiki/Go-modules-suppo...</a>
Any Go developers with past experience in "heavier" frameworks have thoughts on giving it a try?<p>I enjoy working with "batteries included" frameworks currently, and value the approach of "Here's an ORM... here's a template language... here's an auth system... use or remove them as you see fit"<p>I've been told that the Go standard library is fully-featured enough that it can be considered a framework in its own right, but I haven't heard how converts from the Django/Rails world feel about the completeness of that "framework"