asveikau only counted the sct.go file, which is a pretty straight port from ted's sct.c. They counted neither the daemon (75 LOC) nor the vendored geolocation package (58 LOC).
Their count is actually "underselling" the "improvement" as the go port moves command-line handling (half a dozen LOC) from sct to the daemon.
Author of go-sct here. It's totally true that it increased the LOC and is heavily based on C. There's a number of limitations in cgo such as not being able to use macros which caused the LOC bump.
The primary reason I did this was I wanted to learn more about cgo since I haven't used it in any useful way before.
This also allows it to be easily installed instead of having to download a .c file and compiling it.
Just to be clear I am not opposed to what you did, by all means keep doing it. I just followed the link and didn't understand right away. It seemed kind of like a funny substitution. And probably a learning exercise that suddenly was on HN's front page.
Thanks for putting this out there though. It was valuable to read and learn from this since I will probably end up implementing similar things in the future. It definitely seems like a valuable thing to post experimentation like this.
Doesn't cgo allow for using sct.c (possibly slightly tweaked e.g. removed/renamed main and added header) more or less directly rather than have to reimplement it?
If you read the original post[0] sct is not intended to be better than redshift (and probably isn't since as you note the whitepoints are a lifted & pared down version of redshift's), just to be a simpler bridge to the same underlying mechanism.
If you're fine with redshift, sct has no value, and thus neither does go-sct (since it's a port of sct) except maybe as a tool to understand how redshift ultimately does what it does.
