I agree with that. Go can be frustrating if you expect the level of expressiveness of Python, Java, or Rust. But if you regard it as a better C, you can appreciate its ergonomic upgrades compared to C. What is unfortunate is that Go could be much more than just a better C, considering Google's potential and the decades of programming language research that were present at the inception of Go. By trying to simplify things too hard, and ignoring precedents, Go missed a huge opportunity cost. And it even failed to fulfill its original intent: it cannot be used in place of C, unlike Rust.
Agreed. I would love for Go to have stolen more pages from Rust's crusade for zero-cost abstractions and high level conveniences. I can appreciate ruthless conservatism in some places, but Go isn't actually ruthlessly conservative. It has quite a lot of weird things in its stdlib.
What I wanted to say was that Go was not a replacement for C, compared to Rust which could have similar performance characteristics as C or C++. The lack of manual memory management is one thing, but there are cultural reasons too. For example, in Go it is very idiomatic to return an error value as a string, which cannot be even imagined of in the C, C++, or Rust ecosystem. That's because as Go is targetted toward backend-level programming nowadays (which was different at the beginning of Go, when Go was marketted as a systems language), some minor overhead is acceptable if the convenience it brings is worth it. Go is full of such compromises, which isn't exactly a bad thing, but unsuitable to the lowest level programming which begs for an extremist position regarding performance issues. The mentality of Go is good enough for conventional programming, but bad for systems programming. And I think such cultural differences stem from Go's simplicity first mindset.
1. Lack of "manual memory management" can be taken as GC (though Rust is neither GC'd nor manual memory managed, it's declaratively memory managed) and a GC is unacceptably expensive for systems programming. Furthermore, until recently GC was also unacceptably bad for FFI. However stable Rust and Haskell with experimental features can nowadays GC across FFI without issue, but I'm still unaware of any other language that can.
2. Lack of "manual memory management" also means lacking direct memory access, etc. This is a problem in systems programming, though you do not need it for all systems programming.
3. Then there's green threads. Early on Rust had them, but they were removed when it was discovered it's theoretically impossible to implement them with acceptably low overhead for a C or even a serious C++ competitor. What's worse, you have to pay the overhead even if you don't use the feature. Nowadays, you can opt in by importing an ecosystem library that provides green threads but mostly people just use futures rather than green threads.
4. Interfaces: Even tinygo's documentation advises avoiding interfaces and tinygo isn't even a C/C++/Rust competitor, it's a micropython competitor.
The obvious case is embedded programming. You can run Go via a custom compiler for microcontrollers: https://tinygo.org/.
But to their point: why incur that sort of overhead for a language that doesn't necessarily give you enough conveniences to be worth it? Or rather, Rust gives you more conveniences with very little runtime overhead.
It's not exactly damning to be unable to compete with C on a microcontroller with 2K RAM, they were just pointing out the end of my comparison with C/C++.
