I've been thinking maybe I should set up a blog to talk about non-Go
computer science... so maybe I'll get to that...it seems like a big undertaking.
In the meantime, here are some very cool topics I have
come across recently that are (tangentially) related to Golang:
1. Sophie Wilson on the future of hardware, from last year (2024).
This talk is from the designer of the original ARM instruction set.
Fascinating to see where hardware is going, and think about how
Go can be ready for it.
2. Zig as a better C, for more portable CGO.
I heard the founder of Zig, Andrew Kelley, speak last week at a
gathering of TigerBeetle interested folks.
TigerBeetle, the database, is written in Zig, a better C, for maximum control.
Basically TigerBeetle is written very much like an embedded
system, so things like having an operating
system are (almost but not quite) optional.
It is single thread/single core, and so suffers no slow
down from cache-coherency stalls on
multiprocessors. But it uses the network for replication.
Hence even on a 5 node replicated cluster,
it is 1000x faster than general purpose
databases like SQL-Lite, MySQL, Postgres, while being vastly
more safe.
Note TigerBeetle tracks counts and accounting debit-credit
(shifting counts from one account to another); it
is not a general purpose SQL database. But as Joran Greef,
its founder/author, pointed out, TigerBeetle's first application
was tracking energy use for home smart-meters
on 30 minute consumption intervals, which is more general
count-tracking than just double-entry accounting book keeping.
TigerBeetle runs View-Stamped-Replication (VSR) for fault tolerance,
which is equivalent to Raft / Multi-Paxos -- something
that none of the above general purpose SQL databases can manage
out of the box (ignoring 3rd party projects things like rqlite which
are one-man projects and not standard, and ignoring Ben Johnson's
highly useful sqlite streaming backup stuff, which is sadly not Paxos and
thus has a window for data loss.)
Immediate relevancy to Go: If your Go project includes
CGO components, and you want very portable
cross-compilation even for your C components, the Zig compiler
is also a C compiler (building on Clang) _AND_ Zig ships with
the sources for a ton of different C standard libraries from
across lots of OS and architecture platforms.
So using Zig as your C compiler means you can cross-compile your CGO C
parts _almost_ as easily as you can cross-compile your Go parts.
Bigger picture, Zig is fascinating to me in that Zig/Andrew Kelley got generics
"for free" almost immediately when early on he dropped macros and
put in "comptime" compile-time func evaluation instead.
Compared to the pain that was getting Go generics to work, and the
lack of full support for generics as first class data members even at this point
Zig does not have a multi-threaded story at this point. Andrew is busy
ripping out and re-doing a previous attempt at async/await, and taking
alot of inspiration from Go and Go's io.Reader and io.Writer in the meantime. Zig
already stole defer (and refined it in errderfer, a second type of defer) from Go.
But, that lack of non-deterministic (from threading) is one of the reasons that
TigerBeetle chose Zig in the first place. They knew from FoundationDB's
success with Deterministic Simulation Testing (DST) that they wanted
to use DST to bring their database to market in a timely and well-tested
manner, and to take advantage of the gift that DST gives: the ability to
add new features, optimizations, and accomplish refactors in your
distributed system without the fear of breaking the working system.
So TigerBeetle implements their own DST, exploiting Zig's single core
better-than-C safety and efficiency.
Inspiring all around.
- Jason
p.s. links for more on Zig:
humorous shorts...
longer stuff...