My ratio of writing to debugging has never been such that the difference between for and forEach ever mattered.
That being said, debugging complex go code bases 5 years ago (when I last was doing this daily) was less fun than other languages (their armory stocks a nice assortment of footguns and the debugging support was... minimal. Might have changed since then.)
I think he's referring to the "functional" stye APIs which let you write code that looks a lot like operating on java collections with streams. It's actually pretty great, I definitely miss it in other languages.
Did Delve exist 5 years ago? I find Delve to provide a great debugging experience for Go applications. Might be worth checking out if anyone found concern with that comment.
The first tagged release on Delve's GitHub is from 2014, but I have no idea if it was public at the time or not.
Is it possible that there are other factors that could take even more time than writing a little boilerplate? Maybe dueling with the borrow checker?
It's a tradeoff. I'd rather duel with the borrow checker a little bit every day then have a long debugging session figuring out where's a missing copy causing values taken from a map to be not available - that is a fun multi-hour challenge sometimes.
That’s perfectly reasonable if you’re writing lots of parallel code, but frankly 95% of web server code isn’t the sort of hairy parallel code that would benefit from a borrow checker on balance.
There are no threads in this scenario. You can easily lose ownership / crash on bad references when using golang maps in a single thread.
How do you get "bad references" in a Go map in a single thread? Are you thinking of nil pointers? That's a separate issue.