3 ms·

I'm happy to see this, I've always liked using embedded assets in executables to make single file distributions for tools. That said, I really don't like the f

• kstenerud 6y ago
  It's a consequence of go's simplicity by design. You can't actually destroy natural complexity; only move it around. And if you're unwilling to design a proper container around that slowly increasing complexity, it just squeezes out between the cracks in odd ways. In go's case, it's manifest primarily through magic (magic files, directories, comments, names, env vars, switches, etc that you just have to know how to invoke). Another warning sign is the need for an external build tool like makefiles in order to build-in-one-command because you need extra steps beyond "go build" (such as "go generate").
• Cthulhu_ 6y ago
  I kinda agree; I get that they don't want to change the language definition itself, and by putting things in comments they don't need to do any change in the compiler, but it makes things feel unsafe, or "stringly typed" if you will. IIRC Java eventually "solved" it by adding annotations as a language feature. I'm not saying Go should add annotations, but just sharing some language history. And C / C++ has had compiler directives (e.g. #define) since forever, although there too (I believe) # is "just" a comment.