This is the central fallacy of developer culture: that complexity is a sign of intelligence and that complex systems are superior.
Simplicity is much harder than complexity. Anyone can add and anyone can subtract recklessly, but it takes genius to subtract without losing too much in the process. The genius is in identifying the essential complexity in a problem and finding ways to dispense with incidental complexity.
I've personally been using Rust more lately for various reasons, but I really do like Go and think its choices are excellent for its niche. In any case simplicity can be practiced in any language by choosing the most straightforward way to achieve things and avoiding over-engineering. Rust has a lot of features and paradigms but I can be productive in it by remembering that just because it's there doesn't mean you always have to use it.
> Rust has a lot of features and paradigms but I can be productive in it by remembering that just because it's there doesn't mean you always have to use it.
The problem with kitchen sink languages is that someone on the team will use a feature you don't know about.
If enough people on a big enough team do that the project inexorably moves towards the most complex representation of any idea.
On solo projects, some of the most complex languages can be used by effectively by a newcomer. On any other project with the same stack, you need to add in significant ramp up time.
The problem with complex languages is that while you can choose to eschew complexity in the code you write, you very often have to deal with the complexity in the libraries you use. So in languages like Rust and C++ you tend to have a high degree of complexity (at least by way of high degrees of abstraction) in the standard library and the wider ecosystem because abstraction (and thus complexity) are valued and idiomatic in their respective ecosystems—it makes it very hard to opt out of. For example, at least for a good while, there wasn’t a great JSON parser library except serde which is immensely complex and I would spend a lot of time troubleshooting errors in the macro expansions for things that would Just Work in Go’s encoding/json (of course, there are plenty of legitimate grievances with encoding/json, but these are mostly orthogonal to the simplicity/complexity discussion).
> This is the central fallacy of developer culture: that complexity is a sign of intelligence and that complex systems are superior
There are two main competing fallacies in developer culture: the first one is that complexity is a good thing, the second one is that complexity can be avoided.
They are both equally wrong, complexity is a curse, but that's the curse of the real world and if you try to hide that under a rug and call that “simplicity”, then everybody is gonna have a bad time. This blog post is a good dicussion on that topic:
People should really watch Hickey’s talk — simple is not easy. Plenty (if not most) problems are complex (otherwise why would we bother with computers?), and complexity can’t be reduced just by “taking it apart”. The composition of two functions can have an entirely different complexity than what they have differently.
Abstraction is the only way we can combat complexity (and as mentioned, most of that complexity is essential that can’t be reduced further), so if a given language sucks at it, it sucks.
I agree that there is a lot of essential complexity in the problems we solve with computers, but I disagree that most complexity in software is essential. I think most complexity in software is incidental, existing to allow interoperability with other software or support legacy software and systems.
If one could hypothetically rewrite the whole stack from the ground up with a 100% consistent set of APIs, interoperability standards, protocols, naming conventions, etc. and only one implementation of each core function, there would be an absolutely massive reduction in code size and complexity.
Not that you could do this in the real world since the labor and cognitive load required would be astronomical, but consider it as a thought experiment.
I have wondered if in the long term AI LLMs might be a way out. I wonder if a suitably powerful code-comprehending LLM (much better than current ones) could do what I just described.
"Here is the source code to an entire Linux distribution with all its applications. Re-implement this entire code base in language X while preserving all functionality with a consistent style, minimal code reuse, maximum parsimony, and maximum performance. Omit all functions and abstractions not required to achieve the objective of each software package or interface..."
Simplicity is much harder than complexity. Anyone can add and anyone can subtract recklessly, but it takes genius to subtract without losing too much in the process. The genius is in identifying the essential complexity in a problem and finding ways to dispense with incidental complexity.
I've personally been using Rust more lately for various reasons, but I really do like Go and think its choices are excellent for its niche. In any case simplicity can be practiced in any language by choosing the most straightforward way to achieve things and avoiding over-engineering. Rust has a lot of features and paradigms but I can be productive in it by remembering that just because it's there doesn't mean you always have to use it.