It's not the same argument. Worse is better is about whether it's more important to have a simple implementation (Unix/C/NJ style), or a simple interface (MIT style).
This post is arguing about whether it's important to have a lot of features in a language, or whether fewer features is more powerful.
C++ has a complicated interface and a complicated implementation. So it's neither NJ or MIT style.
My perception is that Go has a simple interface but relatively complicated implementation (relative to C). It's actually closer to MIT style, despite having the Bell Labs/NJ heritage. Examples: garbage collection, segmented stacks, and goroutine scheduling. Not saying that's good or bad, but the "guts" aren't exposed as much as in C. Unix and C let all the implementation details poke out. They have simple implementations but complicated interfaces.
I guess garbage collection should be the canonical example of an MIT style feature. The interface is much simpler, but the implementation is extremely complex. And it does poke through that abstraction boundary and bite you.
This post is arguing about whether it's important to have a lot of features in a language, or whether fewer features is more powerful.
C++ has a complicated interface and a complicated implementation. So it's neither NJ or MIT style.
My perception is that Go has a simple interface but relatively complicated implementation (relative to C). It's actually closer to MIT style, despite having the Bell Labs/NJ heritage. Examples: garbage collection, segmented stacks, and goroutine scheduling. Not saying that's good or bad, but the "guts" aren't exposed as much as in C. Unix and C let all the implementation details poke out. They have simple implementations but complicated interfaces.
I guess garbage collection should be the canonical example of an MIT style feature. The interface is much simpler, but the implementation is extremely complex. And it does poke through that abstraction boundary and bite you.