Solod – A subset of Go that translates to C

I'm reminded of the tools in programs like Ghidra or IDA which can take assembly code and convert it into a C-like language. If you could create one of those tools that also takes in the source file so that it names things somewhat reasonably, could you create an anything to C translator? As long as the original file compiles to assembly, that is

I was curious how defer is implemented. `defer` in Go is famously function-scoped, not lexically-scoped. This means that the number of actively-deferred statements is unbounded, which implies heap allocation.

The answer is that Solod breaks with Go semantics here: it just makes defer block-scoped (and unavailable in for/if blocks, which I don't quite get).

https://github.com/solod-dev/solod/blob/main/doc/spec.md#def...

I don't really "get" the sweet-spot being targeted here. You don't get channels, goroutines, or gc, so aside from syntax and spatial memory safety you're not really inheriting much from Go. There is also no pathway to integrate with existing Go libraries.

Spatial memory safety is nice but it's the temporal safety that worries me most, in nontrivial C codebases.

The claim that no goroutines makes this pointless isn't quite right. Migrated 50 services off Docker Compose using Nomad and half of them had zero concurrency needs. A safe Go-syntax C target is actually useful for that layer.

"To keep things simple, there are no channels, goroutines, closures, or generics."

I wonder if it could be integrated with https://github.com/tidwall/neco, which has Go-like coroutines, channels, and synchronization methods.

I seem too stupid. Why not use C11 in the first place? Can anyone explain?

Might this help in memory leaks in go ... what will happen to the code that translated to pointers ....wrong conversation...CODE CRASH??

Love it. And from my experience the need for Go Routines is not that urgent.

Sure when I started Go there were Go routines plastered everywhere. And now I think harder: “do I really need a go routine here?”

Related and currently on the front page: https://news.ycombinator.com/item?id=47627595

> So supports structs, methods, interfaces, slices, multiple returns, and defer.

> To keep things simple, there are no channels, goroutines, closures, or generics.

Sure, slices and multiple return values are nice, but it's not what makes Go good. When people think about Go they usually think about channels and goroutines. YMMV

While I do kind of get what the appeal and target audience is supposed to be, I absolutely don't get why you'd choose a subset and still have it behave differently than the Go counterpart. For me that destroys the whole purpose of the project.

Translating code to C usually results in some nearly unreadable code. I submit the C++ to C translator, cfront, as evidence. I've looked into using C as a target backend now and then, but always "noped" out of it.

I was pleasantly surprised to discover, however, that C code can be readily translated to D.

Love the design considerations here!

Anton also wrote the fantastic codapi [1] for embedding executable code snippets with wasm

[1]: https://codapi.org/

We need this for TypeScript.

Does it work with the preprocessor?

This is a bit too barebones. At least bring goroutines dude

[flagged]