[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++.

[int_19h]

Why C++ still gets chosen:

1. There is a lot more experienced C++ devs around.

2. There are a lot more libraries that are readily usable from C++ but would need to be wrapped to use in Rust.

3. The tooling (IDEs etc) around C++ is more mature.

[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.

[pjmlp]

Mostly because he doesn't get why some of us reach out for C++, despite its warts.

As I wrote at the time on Lambda The Ultimate back in 2012,

http://lambda-the-ultimate.org/node/4554#comment-71504

[umanwizard]

As much as I hate Go, I have to admit that it does sort of fill a niche, or at least it did at the time it was released. If you wanted something less baroque and complex than C++, but still care about performance enough to not want to use an interpreted language, and don’t want to use Java because it’s overly verbose and attracts OOP architecture astronauts, there wasn’t much choice other than Go when it came out.

There’s a very high probability that something like Cockroach would use C++ if Go had never existed, so Rob Pike was sort of right, if you squint. On the other hand, if Cockroach were started today it would probably be written in Rust.

[vessenes]

I think you’re missing a couple key benefits to go: compile time and cross arch builds. The story here is best in class by far. It’s so so simple and fast to compile go for 10 architectures and distribute a binary.

[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