3 ms·
There is not much point in “being simple”, as essential complexity has to live somewhere. I much prefer that living in some compiler-enforced construct than in
by kaba0 4y ago
There is not much point in “being simple”, as essential complexity has to live somewhere. I much prefer that living in some compiler-enforced construct than in hand-written conventions. Go is terrible because it doesn’t let you use the former way at all.
- valenterry 4y agoWhile I agree with you, the OP still makes a good point that simplicity of a language also has a strong impact on the ecosystem; like it or not.
- cube2222 4y agoWhat I've seen with the current generation of languages with a lot of compiler-enforced guarantees is that they introduce a lot of needless complexity to the vast majority of problems, which are very often simple. Overdoing monadic constructs is probably the biggest offender here, but Rust (even though I like the design overall) lifetime checking will usually also cost you way more time getting right than just using a GC (if you don't need complicated concurrency). Main point being, it's not that easy to contribute to libraries written in these.
- kaba0 4y agoI believe that it is a different axis - GC solves the whole concept on a different level (runtime), but where they choose to not take those tradeoffs that complexity has to live somewhere. Monadic constructs are just a convention though, I think it is different.
- mlindner 4y agoGC languages just move the complexity around. I've never done it but I've heard GC tuning is an incredibly difficult problem.
- kaba0 4y agoIt is a trivial problem to solve at runtime, so it definitely decreases complexity. Also, you really don’t have to GC tune almost ever (hell, most runtimes don’t even expose you the knobs)