[vessenes]

I only know Go well enough to comment on his comments, but he did not do a good job testing and reporting on it in his posts, ignoring basic recommendations about safety taught to all beginners. (Ignores err responses from functions and then later complains that things fail later, most particularly).

I would be cautious about drawing too many conclusions about languages he didn't end up picking; clearly he knows OCaml and Python well.

[Drup]

You should read the first two blog posts in detail. He didn't knew OCaml at all at the time, and answers your remark about Go directly in the second post.

[vessenes]

I did read those. I think it comes down to speed on boot, which seems like a legit concern, and a matter of taste. To wit:

Should os.Getenv return an empty string or an error if the environment variable is not set? -- The answer to this depends on how unix-y you are, I suspect. We might disagree, but it's not wrong to say that you're going to do what bash does, which is, after all the fundamental place these are kept, and return an empty string. In particular, this is well documented in the API, regardless.

If I create an empty list, then marshal some uninspected text into it, and that marshal function fails but I don't check its error status, should my list be poisoned, or should it continue on as empty? -- The idiomatic answer to this is that you should check error status and remediate.

He would prefer that the program vomit when marshaling fails. Fine, but it was entirely his choice to code in this style, against go style guides. To then claim the compiler is 'unhelpful' later when he tries to read the list he declared is empty is blame shifting in my opinion.

I would guess he does not prefer in-line error checking and remediation as a pattern; that's totally fine, but it's annoying to read snark about it.

[Drup]

If you read more carefully, you would see he would prefer that the language would not allow him to ignore errors.

You say "The idiomatic answer to this is that you should check error status", yes, that's a Go design pattern, but nothing enforces that. In other languages, thanks to Option/Result types, this is enforced, hence his opinion.

Such kind of safety and security concerns should not be enforced by conventions.