3 ms·

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 (s

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.

pcwalton 2y ago
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.
- bornfreddy 2y ago
  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.
lenkite 2y ago
Go is pretty good for large, shared projects too - thanks to its tooling, formalized best-practices and comprehensive batteries-included standard library.
- merb 2y ago
  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
  - lenkite 2y ago
    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.
    - pjmlp 2y ago
      Partially fixed within the backwards compatibility Go 1.0 promise.

pcwalton 2y ago

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.

bornfreddy 2y ago
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.

lenkite 2y ago

Go is pretty good for large, shared projects too - thanks to its tooling, formalized best-practices and comprehensive batteries-included standard library.

merb 2y ago
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
- lenkite 2y ago
  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.
  - pjmlp 2y ago
    Partially fixed within the backwards compatibility Go 1.0 promise.