3 ms·
I find Go's approach to be in the Goldilocks zone. Its not intrusive enough to slow me down (or guarantee correctness for that matter...) but its enough that I
by voidlogic 7y ago
I find Go's approach to be in the Goldilocks zone. Its not intrusive enough to slow me down (or guarantee correctness for that matter...) but its enough that I no longer need to save the multi-threading something I know needs to be multi-threaded for a second pass and very rarely have multi-threading issues or trouble debugging.
That being said, developers often have a bit of learning to get there, but that can greatly be accelerated by good team/mentor code review and discussion.
- pdimitar 7y agoGoroutines are definitely an improvement, no argument from me. It's just that there exist ways to shoot yourself in the foot quite easily. Example: I'd find it much more intuitive if writing to a closed channel returned an error value and didn't issue a panic. But I'm guessing that the Go programmers get used to the assumptions that must be made when working with the language so such things are likely quite fine with them and cause them no grief.
- loopz 7y agoSuch things bites everyone. But writing to closed channel is regarded as programming error. You potentially lose values. So logic should be watertight, which is hard with concurrency. Doing simplest approach to locking helps. Better with panic than silent errors and flawed logic.
- pdimitar 7y agoYeah. I'm not opposed to such idioms. As I mentioned before, you get used to them.