> Yeah, it breaks when the author decides to move from Github into Gitlab to protest against Microsoft.
The import path is disconnected from where the build system looks for the files. Of course, the default is to use the import path as an URL, right, but nothing forces you to do that. And if you do, *you* lock yourself to the hosting you use. But that can be hardly blamed on Go.
tl;dr: Serve this at your domain, update the repo-root when changing host platform for your code: <meta name="go-import" content="import-prefix vcs repo-root">. No one else has to do anything.
The results for the 26.03 benchmark run are in. (golang)
With the recent release of ncruces' drive switching from wazero to wasm2go, there have been expectations of possibly substantial improvements. Our numbers confirm this: the wasm2go-based driver (ncruces) has recovered significant ground compared to the February results, narrowing the gap with its competitors. The driver erased its worse performance on targets not natively supported by wazero. Well done, u/ncruces!
> I wonder what the thought process of the Go designers was when coming up with that approach.
Sometimes we need block scoped cleanup, other times we need the function one.
You can turn the function scoped defer into a block scoped defer in a function literal.
AFAICT, you cannot turn a block scoped defer into the function one.
So I think the choice was obvious - go with the more general(izable) variant. Picking the alternative, which can do only half of the job, would be IMO a mistake.
I wrote a post exploring egg, a new tool that generates recursive descent parsers from Go-style EBNF. The most interesting feature is that it doesn't generate struct nodes; it encodes the AST into a flat []int32 slice for cache locality and reduced GC pressure. I included a walkthrough of generating a JSON parser with it.
Types with inner pointers add difficulty to be sure, but it’s still possible to use them with this pattern. You have to make sure of three things to do so: 1) no pointers outside of the backing memory; 2) an explicit “clear()” function that manually nulls out inner pointers in the stored object (even inner pointers to other things in the backing slice); 3) clear() is called for all such objects that were ever stored before the backing slice is dropped and before those objects are garbage collected.
The import path is disconnected from where the build system looks for the files. Of course, the default is to use the import path as an URL, right, but nothing forces you to do that. And if you do, *you* lock yourself to the hosting you use. But that can be hardly blamed on Go.
Documentation here: https://pkg.go.dev/cmd/go#hdr-Remote_import_paths
Full example: https://github.com/rsc/swtch/blob/master/app/rsc-io/main.go
tl;dr: Serve this at your domain, update the repo-root when changing host platform for your code: <meta name="go-import" content="import-prefix vcs repo-root">. No one else has to do anything.