I think Go is a pretty good example of Worse is Better. Go's designers preferred simplicity over correctness. (some copying and pasting here and there is better than introducing the complexity of generics).

(This is without negative sentiment, I use Go for some work.)

"Simplicity over correctness" (in Worse is Better) doesn't mean things are simple and incorrect. Of course, the worse-is-better design has requirements, and it correctly implements them.

I suspect that this is about the requirements being inferior in comparison to some superior, lofty requirements that the author has in mind; that's what is meant by "incorrect". There is some underlying theory which is applicable to the requirements for a given language feature, and those requirements are "incorrect" because they ignore that theory and specify some sort of hack.

TypeScript is an even better example with a lack of soundness in its type system but still being an incredibly useful way of programming in JavaScript.

The unsound type system is hardly simple at this point, and type errors are a pain because they aren't modularized very well (and structural type errors tend to cascade quickly). Still, it beats the alternative.

How does Go lack correctness?

Some examples:

- You can accidentally implement an interface.

- Lack of a proper ownership model can lead to unexpected results, which leads to bugs. Consider e.g. growing of slices:

https://play.golang.org/p/3qfd5B8_ktK

- nil is not equal to nil:

https://golang.org/doc/faq#nil_error

(Obviously, it is is easy to move the goalposts without a proper definition of 'correctness' ;).)

I think correctness is the wrong word. Maybe safety would be better? (Verboseness? Precision?)

Go is quite a stable language. Well-specified, rigorously tested, and conservatively updated.

I think all the behavior you listed is well-defined, albeit perhaps unexpected.

Lack of generics doesn't make code incorrect. Less clear maybe, or easier to make a mistake. Or clearer and a lot more code.

I guess you could argue that it makes writing correct code harder?

I think danieldk specified what he meant: Lack of generics means that you have to copy and paste. He defines "forces you to copy and paste due to lack of generics" as "incorrect for a language".

I think he's stretching the definition of "correctness" past the breaking point, but that clearly was what he meant.

Nil pointers?

The original "worse is better" essay is on to something, but its conclusions are mistaken. Implementation simplicity only accelerates growth when the product must be reimplemented. Unix was a standard that had to be reimplemented for every architecture, so its simplicity compelled more people to do that.

Mesos is not a standard. It's a singular product. It doesn't have to be reimplemented. Implementation simplicity doesn't accelerate growth. In fact, the increased complexity it foists onto clients hinders growth.

Early Linux success vs the morass of "perfection" that is now plaguing its userspace.

What do you mean by that?

Not the op, but the post is probably referring to systemd.

There are a few rough edges on classic init, syslog, dns, x11 session management, unix fs permissions, etc, etc.

Systemd is a “better,” “principled,” rewrite of all that stuff from scratch. It is being done in a monolithic way (i.e., shoved down users’ throats), and none of the replacements for the subsystems are actually ready for primetime use (and probably never will be).

This seems to be a great thing for the BSD’s, except that Linux desktop environments no longer run their properly.

Personally, I attribute this more to the widely-adopted, ever-popular CADT software development process(), but I don’t disagree with the OP’s point.

() https://www.jwz.org/doc/cadt.html

Bitcoin