It looks like some borrowed Go convention, where package statements don't need to be quoted, but import statements may include URLs and, therefore, they are expected to be quoted.
The argument about FFI and CGO was the most unappealing to me. If you really need to do that, it feels that at some point some decisions were made that weren't the right fit for the project.
Also, I feel that many arguments in the article are potential pitfalls for unintended side effects I've experimented in other languages, like Ruby itself. Keyword arguments are nice, but I know that they've bitten me several times.
Go forces the developer to be explicit about their intentions, that's why I also don't find something bad that your struct functions need to have the pointer receiver. It can be annoying when you forget, but that's what linters are for.
> What distinguishes a Go project from any other programming language?
My experience with Go, as user and open source maintainer, is that many libraries just work even if untouched for several years.
There is a culture around building small libraries, with minimal usage of dependencies beyond the standard library. This leads to most CVEs existing in the standard library, which combined with Go's commitment to backward compatibility, makes improving your security posture simple by just upgrading the toolchain.
Real estate is baby boomers and older millennials (as they inherited from their parents) "cryptocurrency" (as speculative asset). They HODL it to manufacture scarcity.
Just for reference, in a small city (40K people, 8 sq. km.) you can find 2K empty properties out of the market because it's more profitable to wait prices to raise.
I experimented a little with NanoVMs. I wanted to deploy them in AWS ARM64 instances to test if it was possible. It took a bit of effort, but I think it's worth it.
There is something nice about them as your mental map is reduced to the minimum amount of components, your app - amalgamated with the unikernel - and the virtualization platform of your choice.
I need to test support for volumes, and if there is interest I might do a write-up about it.
No "compiler assistance" doesn't mean no assistance at all. There is a growing set of linters based on the community-accepted analysis package [0] that prevent this and other gotchas that Go devs may be prone to.
It isn't a perfect solution, but it works at community level without needing to wait for the Go team to take care of or changing the language/toolchain.
The POS can store anything that can trace a customer. It wouldn't be hard to derive a unique token from the credit card information, so it doesn't have to deal storing anything sensible.
In the context it meant "it should work, it can be deployed in a simple way, and it can be observed at runtime".
It was just fixing the buggy implementation, write down a Makefile with everything I thought useful (linting, security scanning, Docker image generation, etc), and integrating with Datadog and Rollbar's SDKs.