[devuo]

It's interesting how simplicity so often gets mistaken for a lack of sophistication. Designing a language for clarity and maintainability is a laudable goal, and so is choosing to use one. Chasing complexity, or reaching for the latest trendy language that lets you "express yourself" in ten different ways to do the same thing, isn't what makes someone an S-tier engineer. Simplicity isn't a concession. It's a hard discipline.

[rob74]

> Designing a language for clarity and maintainability is a laudable goal, and so is choosing to use one. Chasing complexity, or reaching for the latest trendy language that lets you "express yourself" in ten different ways to do the same thing, isn't what makes someone an S-tier engineer.

But it sure looks good on your resume!

[dwattttt]

In exactly the same way, complexity you don't understand the purpose of is often disregarded as complexity for complexities sake.

It's easy to get things simple and wrong, and hard to get things simple and right. And sometimes complexity is there for a good reason, but if you don't work hard to understand, you'll fall into the "simple and wrong" camp often.

[bb88]

One problem with simplicity is that it often moves the complexity elsewhere, particularly if you're designing things that others use.

Brainfuck the language is simple to use and implement. It has only 8 commands. Brainfuck programs are virtually unreadable, unless you can get your head around it.

The advantage of trying to solve complexity is that if you can solve it, you've solved it once and exactly once for everyone involved.

[valenterry]

But each line of Brainfuck is very simple and easy to understand! - is the type of argument that I often here from folks that like Golang...

[int_19h]

Thing is, it's not even necessarily true for Go. E.g. that whole `iota` thing is hardly a good example of "simple and obvious" language design compared to enums in... just about everything else. Or we could talk about the difference between a nil interface value vs interface value wrapping nil.

[bb88]

Go being simple and fast to compile, doesn't mean go is simple to use.

My friend tells me the primary use case for go are microservices no more than one page worth of code deployed in kubernetes.

I think that's correct. Anything larger is just masochism.

There will be a revolt at some point, the question will be to what? Rust? Probably not. Maybe a C++ resurgence...

[umanwizard]

FWIW, the revolt to Rust is already happening.

Why would anybody choose C++ over Rust in 2025? The biggest (valid) criticisms against Rust are that it is difficult to learn and use, but C++ is like 1000 times harder. When people say Rust is complicated they’re comparing it to modern GCed languages, not to C++.

[masklinn]

> E.g. that whole `iota` thing is hardly a good example of "simple and obvious" language design compared to enums in... just about everything else.

I actually disagree with this specific take. I do agree that iota is an unnecessary bit of cleverness (especially with that name) but I’d much rather a langage have nothing than the pile of lies and garbage that are C enums. At least then it’s not pretending.

[bb88]

Maybe a decade ago I saw a video of Rob Pike telling people they can abandon C++ because golang was good enough. He proclaimed that people can toss out their reams of C++ code and replace it with Go. That never really came to fruition -- even as bad as C++ is.

The only godsend of C is that code written in the 1970's can still be compiled today -- half a century later. You can write code in your 20's in C and still be assured it will still work a half century later in your 70s. (as long as you don't use system libraries which might change.... etc.)

A lot of people complain about Rust compile times. But honestly, I'd rather work in a language that is trying to solve complexity rather than push it off on to the user.

[bb88]

Then tell them to write all their code in Brainfuck if it's that easy.

In fact, tell them to write a brainfuck transpiler in brainfuck to transpile go lang to brainfuck to make it easier for you communicate with their native tongue directly.

https://stackoverflow.com/questions/16836860/how-does-the-br...

But honestly if you're a professional programmer, you should constantly be asking yourself how do I reduce complexity for others first, not myself. And that's where golang gets it wrong. Golang asks very specifically first and foremost how do they get their compiler right -- even if it comes at the potential expense of the users.

I mean golang is not brainfuck by any margin, and it is reasonable for what it tries to do. But, in my experience, if you're writing code longer than a page, golang is probably the wrong language.

[vacuity]

A core conflict is determining who should hold complexity ("how much" is implied). From an operating systems perspective, I like seL4's approach of being a highly minimal kernel, which necessarily means pushing out significant complexity to userspace to handle. I want to go even further in that direction. Despite the massive complexity spike, kernel minimality has significant benefits for increasing userspace programs' power. I think programming languages are somewhat different. Both operating systems and programming languages are deeply foundational notions of abstraction, and even mesh: Smalltalk[0] or Forth being said to include an operating system isn't outrageous. An operating system exposes languages (e.g. shell commands, syscalls, libraries, services) and a programming language undergirds a system. My suspicion is that it's because an operating system is built up, whereas a programming language is the tool in hand. They're at such different levels of construction that they aren't comparable. I have a refinement, which also ties in something I sneakily avoided earlier: programming languages are like kernels, especially microkernels like seL4. Bundling the whole OS is cheating; the job is already done. But I think there's still a difference. When a kernel is built, the OS isn't far behind; a purpose is set. When a programming language is built, it's made (usually) for generality. The exceptions to this (domain-specific languages) prove my point: they have a purpose in mind. The complexity is still there, but building an operating system seems to provoke long-lasting further abstractions (services, components, libraries) whereas programming is more fragmented in its abstractions (frameworks, libraries, language features). Put another way: operating system developers seek simplicity of the whole system, since that is there scope. It's harder to define a system for programming languages, although it is there (the sum of programs produced), and so optimizations are more local at the expense of global progress.

[0] https://dl.acm.org/doi/pdf/10.1145/2525528.2525534

[elktown]

The problem is further exacerbated by needless complexity being seen as sophistication, and in the end; one's competency level. A lot of today's bloat and bullshit is caused by this attitude. Like a football team full of body builders preoccupied with showing of their muscles and wondering why they're languishing at the bottom of the table.