Relying on Go
12 points by cgrinds
12 points by cgrinds
All Solod code is translated to regular C11 and then compiled with GCC or Clang. Solod therefore relies on C tooling and decades of optimization work just as much as on Go's.
This is an interesting choice. Personally, I view Go's build pipeline as one of its best selling points. I love how I can take a Go project and build a static binary for every major platform with no difficulty, and without having to worry about the C stdlib's platform differences. I also really like Go's garbage collection. So, a version of Go that adds C's cross-platform build annoyances and inconsistencies and loses the garbage collection is maybe not for me.
Yeah this is a bizarre direction. Go is a crappy language (with some neat tricks), on a good runtime. That's why there are many attempts to "TypeScript" Go by writing a superset with extra features that compiles to plain Go. To have to write in a subset of Go to make an eventual C compiler happy... oof why?
To have to write in a subset of Go to make an eventual C compiler happy... oof why?
I feel like if you have to ask, you're probably not in the target audience :-)
But there's been many stories posted about Solod these last few months, in particular this announcement with their reasons and a quick language tour.
One of Go's biggest wins for many (not all) people is its simplicity. Some people like the direct, imperative style without too many frills, while still being able to handle concurrency in a reasonable manner (or, at least, a more reasonable manner than Python, say).
That said, there are languages that target Go (XGo is perhaps the best known?) and more seem to keep popping up (e.g. Soppo, OctoGo, Oct). You do essentially need to transpile to Go, though, as the runtime isn't really usable otherwise.