The absence of specific features for solving specific problems makes the language surface very small. Which is liberating in the sense that you don't subconsciously look for the "right language feature" for the current coding problem you're trying to solve.
This sentence from the blog post is key:
"For example, it’s now quite clear to me that Rust is a language which has a dedicated feature for everything."
You always have that nagging doubt in the back of the head that you don't know the language good enough yet. And I never got rid of that feeling in over 20 years of coding C++. Turns out, it's not you, it's the language. Switching to a simpler language like C lets you focus on the problem solving again, not solving language puzzles. Zig is truly a "better C" in that sense, because in a way it is an even simpler language than C (while being much more correct), yet it enables fundamental features that C lacks (like comptime and generics).
> Switching to a simpler language like C lets you focus on the problem solving again, not solving language puzzles
Or, read another way, "with simple language X I have to reimplement the things that language Y comes with"
I guess it's all a matter of what level of abstraction one likes to work with. For me, re-implementing a "Set" implementation (eg: go) yet again doesn't count as "productive" just because I'm typing typing typing more more more.
This my point; at least in the past, `go` did not provide a Set implementation.
Some people assert that they feel "productive" because of all the typing they need to do to implement it, AGAIN. My stance is that HAVING to do that decreases productivity. I'm mis-quoting, but something Knuth said is to think of it not as "lines written" but "lines spent".
I feel that `go`'s recent acquiescence on templates/generics is a bigger version of this, and related to the Stockholm Syndrome I mentioned earlier; this caused much anguish in some, and to me it felt like because having that feature would case people NOT GETTING to type in their bespoke, artisinal implementations of all that stuff that's been solved a million times over. To me that's just baffling.
> Switching to a simpler language like C lets you focus on the problem solving again, not solving language puzzles.
But you’re solving a puzzle in either case. Either with a solution you created yourself (much more rewarding!) or a premade one you pick off the shelf (higher chance of first time success, often less time involved)
Distinction without a difference. Most of us are talking about "Provided by the language-ecosystem or not", not necessarily WHERE in that ecosystem it sits.
This sentence from the blog post is key:
"For example, it’s now quite clear to me that Rust is a language which has a dedicated feature for everything."
You always have that nagging doubt in the back of the head that you don't know the language good enough yet. And I never got rid of that feeling in over 20 years of coding C++. Turns out, it's not you, it's the language. Switching to a simpler language like C lets you focus on the problem solving again, not solving language puzzles. Zig is truly a "better C" in that sense, because in a way it is an even simpler language than C (while being much more correct), yet it enables fundamental features that C lacks (like comptime and generics).