Go prefers that you be more explicit and use more function declarations, even if it means repetition in the library code. When developers try to get around this, you see awkward constructs like the pointer-to-a-config-struct used here.
Go prefers that you be more explicit and use more function declarations, even if it means repetition in the library code. When developers try to get around this, you see awkward constructs like the pointer-to-a-config-struct used here.
Idiomatic Java, Perl and other languages were shit for a long time, they only improved when some brave soulds fed up with it and explorer non-idiomatic solutions (like the Play framework). And some things I see in "idiomatic" Go make my hair crawl...
Idiomatic code is so called, because people familiar with the language can quickly read it. It makes reading code a much lighter task.
Frameworks are a different thing. Frameworks build around its host language, but normally are meant to use in a specific way. In its own idiomatic way.
In the case of Java circa 2000-2006 it needlessly messed up code, making it more difficult and slow to read EVEN for people familiar with the language.
Following conventions doesn't make code better to read automatically just because people are already familiar with them -- those conventions should be good in the first place for that to happen.
Node has the callback hell "idiom" many are familiar with. And yet if somebody rewrote the code with async, await, even the people "familiar" with callbacks would be able to read it faster and understand it better.
You get a channel - you can read from it until it's closed which is always safe. Go-routines are cheap so you don't care about the background details. For simplifying HTTP, this is great.
I got a lot of feedback that I shouldn't do that, so I moved the asynchronous requests to specific functions e.g GetAsync and made the standard API synchronous.
If the porting language isn't as expressive as the original source -- oh well thats a price i'm willing to pay.