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

I've wanted Go without garbage collection for a long time. I've eventually settled on Zig and ended up liking the language, but it's good to see more work in this space. I was hoping that they would include at least stackful coroutines as part of the lang/stdlib. Will definitely watch the project.

no runtime means no goroutines, concurrency and channels. That's the primary reason I use go.

This definitely looks interesting though, i'll try to keep an eye on it

This reminds me of that V programming language

I was curious about the defer in the code snippets so I went to the playground for some tire kicking:

package main

import (
    "solod.dev/so/errors"
        "solod.dev/so/fmt"
    )

func greet(name string) error {
    if name == "" {
        return errors.New("not like that")
        }
    defer (func() { fmt.Printf("laters, dude\n") })()
    fmt.Printf("Hello, %s!\n", name)
    return nil
}

func main() {
    greet("World")
}

you'll need to have the dev-tools open to spot the stderr key in the response, but it's

/tmp/sandbox/main.go:12:12: unsupported expression type: *ast.FuncLit defer (func() { fmt.Printf("laters, dude\n") })()

fun times with keyword collisions, too, courtesy of func static(void int) {}

The benchmark seems odd. Why compare with Go, when the language has no runtime, is focused on things like native C interop? That sounds very much not like Go or Go's use cases. Wouldn't it make more sense to compare with something along the lines of C3, Odin, etc.? Syntax is only a bit related to language, as can be seen with all the languages that compile to JS (not Wasm, things like CoffeeScript, etc.). This seems to be especially true for Go, where the runtime for many people/projects is the main reason to use it, given that some people seem to be very unhappy about the syntax for error handling and such. Another (even worse) comparison would be that you wouldn't usually just see C++ as a faster Java or C#.

That said it sounds cool and interesting project. Just thinking whether with those goals it makes sense to advertise it a bit like "faster Go", when such a big part of what Go is seems to be intentionally left out. That said as one of those weird people that actually like the Go syntax, I can certainly see myself using or at least trying it, just not for the same things as Go.

this reads like something I have been looking for, for a long long time. Curious how it evolves.