When the actual code examples begin, the very first couple of lines confused me:
package hellope
import "core:fmt"
Is the quoting of package names optional?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.
Go CVE archive [1] clearly indicate otherwise. 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.
When I first started with Obsidian I used it that way, but the more I put in it the more I started organizing everything. It became less of a journal and more of a repository for long form stuff.
I’m thinking about using both just so I have a dedicated tool just for the journaling side of things.