I like Rust and everything, but pretending it’s going to get the job done faster than Go is just that—pretending. If you don’t like Go’s developer experience, then fine (and understandable when the alternative is Rust), but it’s not wasting time IMO.
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.
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.
It’s not pretending. In fact, web application hosts are a great candidate for replacement with faster languages because it can have an immediate impact on infra costs.
Reducing infra costs are rarely the largest opportunity for an organization, and even then the majority of infra waste is typically unrelated to language. Moreover, trading iteration velocity (and/or rewriting your application) for some marginal infra cost improvement is not a very good approach.
