Solod – A subset of Go that translates to C
139 points
9 hours ago
| 18 comments
| github.com
| HN
ridiculous_fish
7 hours ago
[-]
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...

reply
hmry
6 hours ago
[-]
What's the point if it's incompatible? The README suggests using go's testing toolchain and type checker, but that's unreliable if the compiled code has different behavior than the tested code. That's like testing and typechecking your code in a C++ compiler but then for production you run it through a C compiler.

Would have been a lot more useful if it tried to match the Go behavior and threw a compiler error if it couldn't, e.g. when you defer in a loop.

Is this just for people who prefer Go syntax over C syntax?

reply
crowdyriver
3 hours ago
[-]
tbh I'd rather have this behaviour, defer should've been lexically scoped from the beginning.
reply
1718627440
4 hours ago
[-]
> This means that the number of actively-deferred statements is unbounded, which implies heap allocation.

In C you can allocate dynamically on the stack using alloca or a VLA.

reply
kleiba
4 hours ago
[-]
reply
Retr0id
8 hours ago
[-]
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.

reply
tidwall
8 hours ago
[-]
Looks to me like having the ability to write Go syntax and interop directly with C is the plus.
reply
Retr0id
8 hours ago
[-]
I do like Go's syntax but I can't help thinking the best language for C interop is C.
reply
AdieuToLogic
7 hours ago
[-]
> I do like Go's syntax but I can't help thinking the best language for C interop is C.

SWIG[0] is a viable option for incorporating C code as well.

0 - https://swig.org/Doc4.4/Go.html#Go

reply
stevekemp
7 hours ago
[-]
I love how SWIG is still around! I first used it about 30 years ago to integrate with Perl, then later with Java.
reply
whateveracct
6 hours ago
[-]
Go's syntax is basically C tho lol

what's the benefit? for loops?

reply
cocodill
4 hours ago
[-]
I guess there is no point except Anton is having fun do it.
reply
0xmrpeter
5 hours ago
[-]
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.
reply
tidwall
8 hours ago
[-]
"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.

reply
voidUpdate
3 hours ago
[-]
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
reply
circuit10
1 hour ago
[-]
I once used Ghidra to decompile a hand-written ARM assembly floating point library and compile the result to a different architecture, and it was significantly faster than GCC’s built in methods…

But in general this kind of thing is very unreliable for any non-trivial code without a lot of manual work, so a better approach could be to compile to WebAssembly which can be translated into C

reply
voidUpdate
1 hour ago
[-]
It may be easier if you also have the original source file (I've not don't much decompilation myself, only seen other people doing it), as more of a custom solution rather than using an existing system
reply
MYEUHD
8 hours ago
[-]
Related and currently on the front page: https://news.ycombinator.com/item?id=47627595
reply
joshuahart
1 hour ago
[-]
Interesting approach. What was the main motivation for targeting C specifically instead of something like LLVM or WASM as an intermediate?
reply
nulltrace
46 minutes ago
[-]
Biggest reason is usually the toolchain. Debuggers, sanitizers, profilers all just work when your target is C. Go through LLVM and you get similar optimization but now you own the backend. With C, gcc and clang handle that part.
reply
xentripetal
2 hours ago
[-]
Somewhat similar language, https://vlang.io

It’s a mix of go and rust syntax that translates to C

reply
remywang
7 hours ago
[-]
Anton also wrote the fantastic codapi [1] for embedding executable code snippets with wasm

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

reply
weitzj
4 hours ago
[-]
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?”

reply
jimgill
3 hours ago
[-]
Might this help in memory leaks in go ... what will happen to the code that translated to pointers ....wrong conversation...CODE CRASH??
reply
numlock86
5 hours ago
[-]
> 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.

reply
Surac
3 hours ago
[-]
I seem too stupid. Why not use C11 in the first place? Can anyone explain?
reply
matthewmueller
4 hours ago
[-]
Love the design considerations here!
reply
vaughan
4 hours ago
[-]
We need this for TypeScript.
reply
WalterBright
3 hours ago
[-]
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.

reply
Someone
2 hours ago
[-]
I don’t think that’s a valid comparison. It compares two entirely different cases.

In general, if the guts of Foo are similar to those of Bar, translating Foo to Bar is fairly easy.

If Foo has additional guts, as in the C++-to-ℂ translator, translating those parts can lead to hard to read code.

In the C-to-D translator case, it’s not Foo that has additional guts, though, but Bar.

Then, a reasonable 1:1 transaction is easy. Doing it in idiomatic style can still be hard, though. For example D has garbage collection, classes and inheritance. I doubt the readily translation of C to D will replace C equivalents (e.g. a garbage collector written in C that’s part of the code) by those where possible.

reply
Onavo
7 hours ago
[-]
Does it work with the preprocessor?
reply
MegagramEnjoyer
7 hours ago
[-]
This is a bit too barebones. At least bring goroutines dude
reply
whateveracct
6 hours ago
[-]
way too hard
reply
lukaslalinsky
2 hours ago
[-]
stackful coroutines are not hard to implement
reply