4 ms·
I wouldn't have left Go just because of these but before you write this off as minor thing, I would suggest you look this as one of the core language design dec
by sytelus 7y ago
I wouldn't have left Go just because of these but before you write this off as minor thing, I would suggest you look this as one of the core language design decision. It reveals two important language philosophies:
1. Go doesn't follow "you pay for what you use" model.
2. Go isn't too deeply invested in compilation as means for catching errors.
Above are not binary language decisions. If you go in one direction strongly then there are consequences in other. Therefore all languages chose some balance point (aka compromises). Go has chosen a balance point that is weaker than Rust (and may be even C++) but stronger than Python.
- 0815test 7y ago> Go doesn't follow "you pay for what you use" model. To be fair, isn't that implied since Go uses a GC? The "pay for what you use" model is only really viable for languages that don't rely on a fixed GC runtime. (You could have "pluggable" GC libraries like the Boehm collector for C/C++, but those imply very different tradeoffs.)
- stcredzero 7y agoGo doesn't follow "you pay for what you use" model. It's not "you" in the traditional formulation. It's "CPU." You, the programmers, often have to pay continuously for "you pay for what you use."
- rhinoceraptor 7y ago> 2. Go isn't too deeply invested in compilation as means for catching errors. Except when you've imported a package you're not currently using, that is a mortal sin :)
- jimbo1qaz 7y agoI believe Go is weaker than Python. Python dataclasses/attrs (effectively structs) raise an error instead of silently doing the wrong thing, if you omit a constructor keyword parameter. You can still supply default values, which makes the corresponding constructor parameters optional. Keep in mind that dataclass defaults suffer from the same "mutable default arguments" issue as function parameters.