Thanks for this article, I was reading it, as js/ts developer, who also know a thing or two about golang. (and usually dislike java).
I can't agree more about the aweful error handling. every second line checking for an error.
Once I was writing unit tests, for an existing project. I was using an sql driver mock. It feeled very cumbersome, not productive. Along the way I did some refactoring. First doing the change I wanted, then recompile and run the test as long as everything got into its place again. It was very much guided by golang. (statically types language). While I did not feel productive, only fixing what the compiler tell me, (can't the compiler fix the code for me),... but it absolutely feeld satisfying in the end. and I was a little proud when that work was done.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for this article, I was reading it, as js/ts developer, who also know a thing or two about golang. (and usually dislike java).
I can't agree more about the aweful error handling. every second line checking for an error.
Once I was writing unit tests, for an existing project. I was using an sql driver mock. It feeled very cumbersome, not productive. Along the way I did some refactoring. First doing the change I wanted, then recompile and run the test as long as everything got into its place again. It was very much guided by golang. (statically types language). While I did not feel productive, only fixing what the compiler tell me, (can't the compiler fix the code for me),... but it absolutely feeld satisfying in the end. and I was a little proud when that work was done.