I'm starting to port Go's hashing packages to Solod (a subset of Go that translates to C). At first, I thought about porting MD5, but who actually uses it anymore? So I went with SHA-2 instead.

One perfectly reasonable design decision after another. antonz.org/going-backward

Going Backward

Reinventing the generic iterator wheel.

antonz.org

When I stopped writing interactive release notes for Go, I immediately started making them for Solod, the language I'm working on. I guess I just can't stop writing interactive notes 🤔

Solod v0.3 is out! It's a system-level language with Go syntax, zero runtime, and fast C interop. The new release ships concurrency, JSON support, testing and benchmarking tools, and a wider safety net (escape analysis, leak checking, stack traces). antonz.org/solod-0.3

Solod 0.3: Concurrency, JSON, more safety

A strict subset of Go that translates to regular C.

antonz.org

Adding concurrency to Solod (a subset of Go that translates to C) felt great. But my favorite feature in the upcoming release is preventing the most common kind of dangling pointer: returning a pointer to a local variable from a function.

Go has 18 built-in functions (since Go 1.21; there were 15 before that). Personally, I use make, append and len all the time. I never use complex/real/imag or print/println. Everything else falls in between. How about you?

I've put together my own crazy language ranking based on the number of sandbox runs in the Codapi playgrounds. As you can see, Lua is number one, Odin is more popular than C#, and Zig is more popular than C — which obviously doesn't quite reflect the reality 😅

My Go Concurrency book is now available on Amazon: amazon.com/dp/B0H94S2G4K And, of course, it's still free to read on my website: antonz.org/go-concurrency With interactive examples!

The entire Solod language implementation is under 5,000 lines of Go code, plus 700 lines of C built-ins and another 700 lines for tooling. This is only possible because Go's stdlib offers a great lexer and parser, along with a ready-made analysis package in x/tools.

I don't like the functional options pattern in Go, and I'm pretty disappointed that it ended up in the standard library with the new json/v2 package. An honest, plain Options struct is much better.

Saying goodbye to interactive Go tours: antonz.org/on-go-tours

On interactive Go tours

Wrapping up the series.

antonz.org

Can you match the state-of-the-art Go concurrency model using POSIX threads? Of course not. But what exactly is the difference, and how can you narrow the gap? Here's my take. antonz.org/concurrency-...

Go-flavored concurrency in C

Worker pools, channels, and mutexes - backed by pthreads.

antonz.org

You might not remember, but one of the reasons Go was appreciated in the early 2010s was that it came with great tooling right out of the box, specifically for testing and benchmarking. Now Solod (a subset of Go that translates to C) is getting a testing tool too!

Solod (a subset of Go that translates to C) is getting a concurrency model. Instead of Go's M:N goroutine scheduler, it uses an M:N thread worker pool with a task queue. Much simpler, but still pretty efficient.

Solod v0.2 is out! It's a system-level language with Go syntax, zero runtime, and a familiar standard library. The new release ships networking, UUIDs, WebAssembly, and a freestanding mode. antonz.org/solod-v0-2

Solod v0.2: Networking, new targets, friendlier interop

A system-level language with Go syntax and a familiar standard library.

antonz.org

Big day today! Solod (a subset of Go that translates to C) now comes with a networking package. It's pretty basic, but it's still an important step.

As you probably know, UUIDs — v4 and v7 — are finally coming to the Go standard library this summer! I decided to port them to Solod (a subset of Go that translates to C) right away. I also added the Version method, which the Go team chose to leave out.

Solod (a subset of Go that translates to C) now has a freestanding mode. Many standard library packages work fine without needing libc: bytes, strings, slices, maps, mem, math/bits, and utf8. Even the time package mostly works!

After many months of planning and development, here it is. Introducing btype. B-tree based collection types for Go. It's hand-crafted to be faster than the current B-trees for Go, Rust, and C++. github.com/tidwall/btype

Adding WebAssembly support to Solod (a subset of Go that translates to C) was a breeze. I especially like the size of the resulting .wasm file: — Go: 1.7MB — TinyGo: 111KB — Solod: 9.5KB Who's tiny now, huh? 😁

Solod v0.1 is out! Go syntax, zero runtime, native C interop — now with a practical stdlib and a bunch of example applications. antonz.org/solod-v0-1

Solod v0.1: Go ergonomics, practical stdlib, native C interop

A system-level language with Go syntax and zero runtime.

antonz.org

Many new programming languages lack practical examples. I don't want to make the same mistake. More apps are coming soon 💪

Now a clanker can write Solod code for you. But where's the fun in that?

Every day, Solod (a subset of Go that translates to C) gets closer to its first official release. Only two stdlib packages left to port — filepath and flag!

I've been fascinated by RISC-V lately. An open-source processor architecture is a great idea. I hope we'll see a lot more consumer devices and servers using RISC-V chips in the coming years. In the meantime, I've added support for linux/riscv64 to Solod (a subset of Go that translates to C).

When Go introduced iterators in 1.23, they essentially standardized the "callback approach" to iteration, which was already used in some parts of the standard library, such as sync․Map and fs.WalkDir. I actively dislike it.

Made a small progress bar for the first release of Solod (a subset of Go that translates to C). Not quite there yet, but a lot of work is already done!

When I designed Solod (a subset of Go that translates to C), I set a strict rule: no heap allocations in the language or built-ins (only in the standard library). That meant no built-in maps.

Maps are essential in application development. But Go's stdlib uses maps very cautiously. I've ported a dozen core Go packages to C so far and have encountered a map only a couple of times. The fewer maps, the better!

Can a C port of the Go stdlib be faster than the original? I was able to get a 2-4x speed boost with strings.Builder, but couldn't beat Go's substring search. On porting, benchmarks, and optimization: antonz.org/porting-go-s...

Porting Go's strings package to C

With allocators, benchmarks, and some optimizations.

antonz.org