Comment by voidhorse
1 year ago
Exactly. There are two kinds of programmers, those who enjoy spending a bunch of time thinking about problems and decisions the language has foisted upon you (subtyping hierarchies, lifetime annotations, visibility, design patterns) and there are those that like spending that time thinking about the actual problem they want to solve instead.
I jest, but only a tiny bit. The features of heavy OOP and feature-rich languages tend to show their value only in really large codebases being worked on by several different people—precisely because many of their features are just guardrails to make it hard for people to code incorrectly against another's understanding or assumptions, when shared understanding is more difficult to establish. Contrarily, any solo programmer or really small team is almost invariably better served by a language like go, C, scheme, or Zig.
The idea that memory safety is only, or primarily, a problem in large codebases written by a sizable team is an interesting theory (sort of an inverse Linus' Law?) Unfortunately, it's contradicted by decades of experience.
Just to be clear, I liked memory handling in Rust. It was the sheer size of the language that made it... not fun. But borrow checker made sense.
Go is pretty good for large, shared projects too - thanks to its tooling, formalized best-practices and comprehensive batteries-included standard library.
That is simply not true. The bigger the project gets the more you see the shortcomings of go. You can see that very well in the k8s project
Ok, might want to explicitly point out those shortcomings that still present today. AFAK such shortcomings resulting in issues have been fixed in Go over the years.
1 reply →