I measure, not estimate
Every number I give here has a concrete suite behind it: the whole of toml-test, the differential test against the Go toolchain, interoperability with the Linux kernel. A claim without measurement I would rather not write.
Research
The courage to go where no one has gone before
Every line heads for an artefact anyone can download, run and measure; for most of them it already exists, for the experimental ones it is still the target. The shared rule is a single one: a claim without measurement is a promise, not a result. And the difference between a supposition and a result is precisely the step that cannot be skipped.
Systems code in Go
C itself once replaced assembly. Today there is a whole domain of software nobody questions, simply because C has sat in it for fifty years.
Core network protocols, numerics, language toolchains: for fifty years they have been written in C, and today nobody takes it as a decision any more but as a state of nature. The hypothesis says the decision can go another way. Pure Go with a modern runtime and the standard library is to deliver the same reliability in these domains, without cgo, without a bundle of dependencies and without a third of the bugs that come from manual memory management.
There is already evidence. NFS is an NFSv4.2 server and client, a protocol the Linux kernel implements in C, built in pure Go on the standard library alone and verified against that kernel. Tensor gives Go the numerics the world of Fortran and C used to write, without a single line of cgo. And GAsm SDK replaces the C toolchain exactly where the developer meets the assembler.
NFSv4.2 in pure Go that talks to the Linux kernel; numerics
without a single line of C.
Deterministic, distributed computing
The same input yields the same number on every machine. That sounds obvious, and in numerics it is not.
A computation that behaves differently on two machines corrupts science: the laboratory cannot say which result is right, and reproducibility is lost. Determinism is therefore not a feature on request here: it is a contract, written into the documentation and tested across platforms.
But that is only the first step. The target is a computation split across several machines that stays reproducible after the split, so that every node reaches the same result. Without a deterministic core that is not a computational model but a lottery.
Today determinism across platforms is held by Tensor, without
cgo. Next: deterministic distribution of a computation across
machines.
The portable Plan 9 assembler
Decouple the assembler from the Go toolchain and turn it into a standalone, portable tool.
The Plan 9 assembler is imprisoned inside the Go toolchain: it cannot be run without the whole toolchain, it has no formatter, linter or debugger, and what lives in the runtime often only surfaces through a crash. Yet it is the floor every running Go program stands on.
This line sets it free. The result is GAsm SDK: a lexer, parser, formatter, linter, standalone assembler, disassembler, debugger and language server in a single self-contained binary, pure Go, no external toolchains. Portability is not declared here: the accuracy of the parser and the formatter is verified by a differential test against the Go toolchain itself on four architectures, and two independent implementations must agree on the same input bit for bit.
Bit for bit the same output as the Go toolchain on amd64, arm64,
riscv64 and loong64, in a single binary.
The dependency-free web
Web development learned to build through a toolchain: a bundler, a transpiler, hundreds of packages. The hypothesis: the platform today suffices on its own.
Hardly anybody writes the modern web in HTML, CSS and JavaScript any more; they write in something that gets translated onto it through a hundred dependencies. The hypothesis of this line says the platform has matured to the point where for the vast majority of websites that whole machine is unnecessary: popovers without JavaScript, two colour schemes without duplicated CSS, native form validation, data formatting through Intl.
What came out of it: JSbox, my own toolchain in a single binary. A server with live reload, a formatter for HTML, CSS and JavaScript through real parsing, a static check, and tests in a real browser. No Node, no npm, no build. This site is the proof: two language editions, two colour schemes, a form with its own backend, and zero dependencies.
This site is the proof itself: zero dependencies, zero build.
The method behind this work
All the lines run in the same cycle, and all in one tradition: the theorist at the same machine as the operator, paper growing out of the system, not the other way round. The foundation is dialectical materialism: the material is always right, and a contradiction is where the design begins.
The cycle of work
-
Hypothesis
A design is written so that it can be refuted: what should hold, under which conditions, and what would contradict it. A design that cannot be refuted is not a design but a wish.
-
Measurement
A benchmark, a test, a protocol. The procedure that produced the number belongs to it, and it has to be repeatable by anyone, not only by its author.
-
Revision
A solution holds while it works. A better one arrives, and the old one goes without sentiment; loyalty to my own earlier decision is not an argument.
Four rules
The standard library as the base
Most of my go.mod files do not carry a single line in require, and the operational Perl scripts use only what the interpreter itself provides. A dependency that does appear has to defend its place with a number.
Code is an artefact
A repository without documentation and tests counts as unfinished, not done. Documentation, tests and measured numbers belong in the same change as the code they describe; an artefact that cannot be read in ten years is debt.
What is superseded leaves
When JSbox gained its own sitegen, I deleted the original Go generator of this site outright, though it worked. Keeping two solutions to one task is worse than rewriting one; the better solution retires the old one.
Does one of the lines overlap with your problem?
If so, write to me. I am glad to look at it from both sides: the research side and the production side.
Write to me