4 ms·
one of the reasons I love Go is because of its simplicity. It just works and it works well. You can even use with without GC if your code has to be fast. I don
by jjallen 3y ago
one of the reasons I love Go is because of its simplicity. It just works and it works well.
You can even use with without GC if your code has to be fast. I don't see what the fuss is about with other new statically typed languages.
So I oppose almost anything that will make Go less simple. Probably the only exception I would make is enums.
I don't want my brain to have to work any harder reading code.
Edit adding:
the whole point of Go is simplicity and speed. That's why it's called Go in the first place.
Let's keep it that way.
- hnlmorg 3y agoI want Go to remain simple but having written a hell of a lot of code in Go that needs to iterate over a stack whose size cannot be computed ahead of the iteration, I can confirm that writing such code in Go does get very complicated very fast. There are a lot of footguns to take into account: - how do you acknowledge the end of a stack? - how do you cancel the operation mid iteration? - how do you make it thread safe? - how do you make fast? The proposal here simplifies these concerns and thus makes it easy to write and use iterators. It makes it easier to read iterators too. And it does so without adding hacks to the standard library. This is one of those instances where the proposal might seem to add complexity but actually it simplifies the code a lot (unlike generics, for example, which complicates the syntax of your code in its effort to dedup lines of code. To be clear, I’m not being critical against generics here. Just using that as an example to show contest).