Yes, but we have a perfectly serviceable term for local software already: "local software".
To me, "local-first software" means something slightly different. The term was coined by this essay[1], which says:
> Local-first ideals include the ability to work offline and collaborate across multiple devices
> This means that while local-first apps keep their data in local storage on each device, it is also necessary for that data to be synchronized across all of the devices on which a user does their work.
But this is clearly not what's going on here. This project is just local software, like we've had forever.
If a fancy new "local first" buzzword makes local-only software seem more sexy, then I suppose I don't want to get too mad about it. I really like local software. But the autist in me likes it when technical terms have a well defined meaning.
Thats like describing a mobile only game as "mobile first", even when the developers have no plans to ever port it to other platforms. Its a mobile game.
The grep command line utility isn't local first. Its just local software.
Just as an FYI, my use-case is we're actually using Go as a replacement for C for some of our bigger projects - we've found that Go is a great language for working together on (as opposed to C which our team has conflicting viewpoints on).
So far we've developed a few seperate services but we're now looking at combining Go with our existing C based module such that we can use JSON-RPC to communicate with different modules in a phone system... it's kinda cool but all commercial so nothing open to hack on sadly.
Huh yes of course it's all commercial but I thought I could add my own examples to that gist since there's much more cool stuff possible with Go+C interop!
A have a couple of such gists too, the idea was to combine them since you've decided to share this one. It's up to you to decide though.
My idea is to have unified environment across all targets, so the only thing that changes is speed and amount of RAM.