Postgres 19 introduces native graph queries (following the SQL/PGQ spec — Property Graph Queries). It's currently in beta, but if you want to try the graphs feature, I've set up an online playground: codapi.org/embed/?sandb...

I compiled a Solod program that imports 30 stdlib packages to WebAssembly and did the same with Go and TinyGo. Solod's binary is 2x smaller than TinyGo's and 16x smaller than Go's 😎 All three binaries are fully self-contained (WASIp1).

Running the full Solod stdlib test suite takes 5 seconds (Clang on macOS). It's not as fast as a Go test suite of roughly the same size, but it's still fast enough to provide useful feedback while making changes.

I expect the "javafication" of the Go ecosystem to continue with the addition of generic methods in Go 1.27. We probably won't see unnecessary generic abstractions in the standard library, but plenty of third-party code will gladly take advantage of this wonderful opportunity.

Everyone is creating a new programming language these days, often one that's "like Go but with more features" or "like Rust but simpler". Solod, a systems language for C and Go developers, might look like one of those languages. But it takes a different approach.

For example, Go uses platform-specific assembly code for the block step of SHA-256 hashing. My Solod implementation is 10% slower, even with Arm SHA-2 CPU intrinsics. If I use only pure Solod code (just C), it's 7x slower. Go's cryptography is exceptionally well done.

Solod now has a logo ☀️ I hope it helps the language really shine :)

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.

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.

If you want to see something really wild, here are 13 out of 18 Go built-ins packed into one expression 🤪

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.

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.

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!

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? 😁

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).

For me, the best way to iterate in a language like Go — very imperative, very down-to-earth — is an explicit iterator object. That's how bufio.Scanner or sql.Rows work, and that's what I chose as the standard iterator pattern for Solod (a subset of Go that translates to C). This one I like.

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!

But sometimes, maps are really useful for small, local tasks like routing or counting. So, I eventually made a stack-allocated version of the map[K]V built-in. It's lightweight and super fast — sometimes even faster than Go's map (which is already state-of-the-art).

Solod (a subset of Go that translates to C) shines when it comes to C interop. But it's also quite fast on regular Go code. In this strings.Builder benchmark — a common, optimized case in Go — Solod performs 2-4 times faster. And the binary is only 53K (vs. 1.6M with Go).

While porting Go's standard library to C, I try to avoid heap allocations as much as possible. Of course, sometimes there's no way around them, like in os.ReadFile. But often I can use local stack allocations or a buffer provided by the caller instead. It's working pretty well.