6 ms·
Quick and Clean in Go
- arrakeen 14y agoyour $PS1 makes the commandline examples hard to follow
- drivebyacct2 14y agoYes. A simple "$" or a tiny splash of color differentiation would go a long way.
- dtby 14y agoYeah, no. Get over your false self of entitlement. It's not even slightly difficult to follow.
- zeeboo 14y agoSorry about that! I took the suggestion and changed it to just $
- nakkiel 14y agoFocus on the subject at hand, not very minor details. Remarks concerning the author should be addressed to him directly.
- bluesnowmonkey 14y agoLikewise remarks to the author of a comment.
- romaniv 14y agoif err := http.ListenAndServe(":8080", nil); err != nil { panic(err) } I've seen this kinds of stuff in PHP database APIs, and I've seen how much smaller and more readable the codebase becomes with proper use of exceptions. This is a huge downside of Go.
- drivebyacct2 14y agoConversely, this is a huge upside of Go. I enjoy the explicit error handling. It's a very conscious decision. There is panic/recover style "exceptions" but that's for truly exception states and not just error states. It seems a rather bad example anyway, not sure why I'd prefer: try { http.ListenAndServe(":8080", nil); } catch(ServeException se) { // handle se } over the Go alternative.
- masklinn 14y agoIn this precise case, the alternative would be: http.ListenAndServe(":8080", nil) the uncaught exception would kill the task because, really, what is your http server going to do aside from exit if it can't serve? Not sure why you added a bunch of lines which end up doing the exact opposite of what the original code does.
- tomjen3 14y agoLog the error to the logging system (may also fail) and try again, upto a specific number of times?
- romaniv 14y agoExactly. It horrifies me that there are still programmers who don't understand this after so many years of OOP advocacy. The benefits of a properly designed (not Java-like, but C# or PHP like) exception system stems from the fact that in the wast majority of cases you don't need to catch exceptions right away. Most exceptions can be handled in a few centralized locations higher up the stack. If you have 10 calls to ListenAndServe, this means having 10 times less exception handling code. Moreover, when you design a library and the users actually care about errors, exceptions save you from needing to pass your error codes up the call chain from deeply nested methods.
- zemo 14y ago>If you have 10 calls to ListenAndServe ListenAndServe blocks forever. If you have 10 calls to ListenAndServe, it's implied that you're in 10 different, concurrently running processes (goroutines). A panic, in Go, does not cross a goroutine boundary. If, in imaginary parallel universe Go with exceptions, exceptions did cross goroutine boundaries, then one goroutine could crash another goroutine. The point of Go is to be able to sensibly write stable, concurrent programs with compile-time safety. Exception-based error handling would be a mess with Go's concurrency model. In practice, you would only call ListenAndServe 10 times if you were listening on 10 different ports, because you had 10 different projects on the same server. That's a perfectly realistic situation. Now consider that one site has an error and throws an exception. Should all the other sites go down? Error handling in Go is admittedly tedious, but when you work with the language for a bit you'll start to understand why they chose to design it in that manner.
- mark_l_watson 14y agoThat was a very nicely written article - thanks! I don't know Go (well, I am good playing the game, but I don't yet use the programming language :-) and I especially liked the way the MongoDB client code worked.
- papaf 14y agoThis is an excellent article (or I could be particularly stupid). I have been playing with webapps using Go for about 6 months and this shows a much more intelligent use of templates than the naive methods that I have been using.
- knodi 14y agoI been playing around with Golang for about two weeks now and i must say I am in love with it. P.S. in my day time job i work with ruby.