> 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.
> The page you linked compares golang bindings against each other, not C against golang like my test did
No one disputed that. But it follows that your benchmarks are comparing C to [some very] outdated versions of Go packages. Which is what I tried to point out.
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.