[kelseyfrancis]

The part of this argument I don't really understand is that it seems like the cost of bad programmers is higher, not lower, with a "simple" language where it's _normal_ to have type-unsafe code and mutable state everywhere.

[kjksf]

Go is type safe (unless you use "unsafe" package, that is, but it's no different from Rust).

Or show me how you would subvert Go's type system and tell me which language you're comparing it to that wouldn't allow similar type system subversion. And no moving goal posts, please. "Type safe" has a certain meaning.

The value of immutability is so overblown, as shown by literally every mainstream language being mutable by default.

Not to mention the perf cost of immutability.

For just one example see https://ayende.com/blog/164739/immutable-collections-perform... (immutable version of dictionary is 30x slower, immutable list is 16-32x slower).

I'm not cherry-picking. This is just the first search result. If you understand how immutability works from first principles, it just does much more work.

Ultimately I wouldn't describe Go as "minimizing bad programmers" but "minimizing a damage that well intentioned but ultimately mis-guided good programers can do to the codebase".

For example I believe that your enthusiasm for immutability is well intentioned but I would rather not take 30x perf hit for theoretically safer code.

Bad programmer will write a bug that can be fixed.

A mis-guided good programmer will write a compile-time parser that only he can understand (possibly only for a week after writing it), will baloon compile times, produces incomprehensible error messages and you won't be able to convince him that a standard recursive-descent parser is 10x simpler to write and read.

Go prevents mis-guided smart programmers from inflicting too much pain on everyone else.

[mrkgnao]

Good compilers don't keep immutable things immutable at runtime, but turn uses of clean high-level functional code into tight C-like loops.

https://donsbot.wordpress.com/2010/02/21/smoking-fast-haskel...

It's been seven years since: that's GHC 6.13, and GHC 8.2.1 is being released soon. Performance is even better now as long as laziness doesn't bite you (which is much less rare than people think).

> you won't be able to convince him that a standard recursive-descent parser is 10x simpler to write and read

I don't know what a "compile-time parser" is, but someone used to a good parser combinator library is going to be difficult to convince.

http://www.haskellforall.com/2017/06/translating-c-parser-to...

It reads like the formal spec of the language. Hand-writing recursive descent parsers isn't fun (given a sufficiently complex grammar) and expecting people to accept it as the One True Practical Non-Ivory Tower Way (and expressing dismay at not being able to convince them otherwise) is suggestive of monoculture, the kind that prides itself on copying code and using wrappers over the two or three first-class data structures that exist in the language for everything.

[kelseyfrancis]

> Go is type safe

Functions that accept or return the interface{} type are not type-safe. These are _common_.