<p>Hello, fellow gophers.</p>
<p>As I have been programming in golang, the main issue I have found with the language, other than sometimes subpar speed, is that a lot of the code is repetitive. For example, what is just a protected call or try block in other languages is in Go a block followed by checking the err and lots of branched conditions as a result that messes up my overall structure.</p>
<p>Although I cannot fix or affect the first issue, I am doing my best to give the language a decent chance by having macros to input some of the various repeated snippets such as "if err != nil { x }", leaving my cursor at x. Then I can have a configuration so only x is visible with some comment at the end.</p>
<p>My main issue is that this feels kind of clunky. I am an experienced programmer in a multitude of other languages (JS,LUA,C++,Haskell) so in my efforts to be more productive I've taken it as a reasonable precondition that it is not my style causing these issues.</p>
<p>Based on this, I'd like to ask other experienced devs on how they've handled some of these shortcomings of the language. I get that it is new, but I really feel as though industry has moved a bit too hastily to it, personally indirectly causing my job to require me to learn it.</p>
<p>We are developing a login server for our tool and it feels like I am just rewriting it in "minimally expressionate" C which constantly checks things that are pretty obviously a fixed value.</p>
<p>So for those who actually use this language by choice, what's the trick? Or are most in the same boat as me?</p>
<hr/>**评论：**<br/><br/>natefinch: <pre><p>It's not really that new at this point. 1.0 was 5.5 years ago. </p>
<p>Most of us enjoy the explicitness of deciding exactly what to do with each error. Sure, at first ,and in trivial programs, you may just return every error as-is, but in bigger and more serious projects, you start to think about whether you log the error, add information to it, etc.</p>
<p>I use it 40 hours a week at work and do all my side projects in it. What some people consider drawbacks, I find to be refreshingly simple and obvious. </p></pre>ZetaHunter: <pre><p>So much this, I've never considered explicitness of the error handling to be a drawback.</p></pre>drvd: <pre><p>"Get used to it." is the best advice I can give. So: get used to it.</p></pre>xbooing: <pre><p>Go is just a bad language then?</p></pre>natefinch: <pre><p>No. It's different. I find it a nice middle ground between the (IMO) overly explicit & strictness of rust and the overly permissiveness of python. It fits in the same niche as java or C# without java's boilerplate, huge memory footprint, and tendency to over-abstract, and C#'s neverending feature-itis.</p></pre>burnaftertweeting: <pre><p>Beauty is in the eye of the beholder. </p></pre>PaluMacil: <pre><p>I think you might be branching too much. If you return in your if block that detects an error, then you don't really have a lot of branching. I've seen good devs get tripped up on that at first since they are writing so much error handling. So instead of an else block on something like an error in a handler, try something like...</p>
<pre><code>ts, err := time.Parse("2006-01-02", query.Get("ReportDate"))
if err != nil {
log.Println("ReportHandler:", err)
http.Error(w, "Bad Request: bad start date specified (needs YYYY-MM-DD)", http.StatusBadRequest)
return
}
//use the ReportDate timestamp...
</code></pre>
<p>In other cases it's better to return the error itself. In APIs I tend to add information to an error and return the error until I get to a handler and then log the error in the handler. This gives me all the information needed to understand the context around the problem.</p>
<p>I adapt pretty well to different languages, so I enjoy the paradigm that Go asks me to use. I don't think people who use Go by choice see this as a shortcoming, though people who don't use Go are hesitant about it.</p>
<p>I don't know what you mean about speed. I would think it would be faster than any of the other languages you know besides C++, so it's possible you have some design concerns due to misunderstanding something that you'll learn as time goes on.</p></pre>
