A rather nice ~10% speed boost for my tool scc from this just with a simple recompile against some input sets.
$ 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'
Trying it on various other inputs it seems to be somewhere between 3% and 10%
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.
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.
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.
Workspace-scoped references, rename, and go to implementation. These features use your workspace root as the search scope, so behavior will vary based on the directory you open in your editor
If you haven't already, it sounds like it would probably be worth your time to open an issue. If things like workspace-scoped references and renaming aren't working for you when they are working for other people, perhaps you have a non-standard setting, or perhaps there is a need to adjust how you open vscode, or perhaps you are hitting bug(s). My experience has been the people working on gopls are very responsive.
VS Code is a text editor not an IDE, right? That's what its proponents always boasted in the beginning at least.
I just got work to pay for a GoLand licensed for me. The VSC experience was slower, more RAM hungry and not as full featured, so it didn't really make sense to stick with.
That was resolved a while ago. Godoc supports modules[1]:
For those who are following this issue because you are waiting for module support in the godoc command (golang.org/x/tools/cmd/godoc), please note that it has been implemented in the latest version. See issue #33655.
it made it painful for a while, but GoLand and VSCode both support modules at this point (though VSCode uses the gopls[1] (language server), that I've been having mixed results with).
Any Go developers with past experience in "heavier" frameworks have thoughts on giving it a try?
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"
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"
I have written several HTTP-based services in Go. When you only expose an API, net/http is 99% of what you need. There are some useful addons like https://github.com/gorilla, and you'll probably pull in a library for auth.
For services with a web GUI, net/http is not comparable to the likes of Rails or Django. There is a templating library, but it's pretty barebones and you'll have to put quite a lot of boilerplate (or additional libraries) on top to make it work for anything beyond hello-world scale. Also you need libraries for all those secondary concerns that are usually handled on the framework level, like CSRF protection.