On Sun, Jun 16, 2013 at 3:37 PM, Andrew Gerrand <a...@google.com> wrote:
> On Sunday, June 16, 2013 4:15:54 AM UTC+10, Jeff Schnitzer wrote: > >> >> * No exceptions. This (and the "debate" around it) is just silly. >> > > There is a much discussion about these topics on the golang-nuts mailing > list. The issues are complex and subtle, so your dismissiveness is not very > productive here. > I've followed several of these topics, as well as the occasional HN thread. Go advocates don't tend convey their opinions in subtle or complex terms; mostly they seem to be grinding some sort of ideological axe forged in the world of C++ systems programming where exceptions are broken. I can appreciate that, since I spent my first six years out of college writing C++... but so far, every argument I've heard for abandoning exceptions looks preposterous when you're 40 stack frames and three RPCs into a multi-hundred-thousand line system that 50+ engineers have been hacking on. > While IDE support for Go is still nascent, the team is working on > improving it. For instance, check out the new ssa > package<http://godoc.org/code.google.com/p/go.tools/ssa>, > which enables whole-program analysis and should power some impressive IDE > tricks. Please don't mistake the relative immaturity of our IDE support > (compared to, say, the decades of work spent supporting Java) for > disinterest. We're working on it, but doing it right (which we pride > ourselves on) takes time. > Great to hear, but I can't resist pointing out that less-mature languages like Ceylon and Kotlin have come out-of-the-gate with first-class IDE support. The language designers were thinking about tooling from inception. I worry about languages like Scala where tooling was an afterthought; fortunately Go seems to be quite a lot simpler. > It's pretty obvious that Go comes from old-school C hacker culture - > people that have probably never worked on webapps. So don't expect Go to be > suitable for writing webapps. > > On the contrary: I and many others have written many web apps in Go, and > we're having a great time. Go's greatest strength, IMO, is simplicity and > readability. I can have way more confidence in the correctness and > robustness of a Go web app than, say, a Python app (where any expression > can raise an exception—did I handle all the cases? I can never know). > I should more properly specify "business web apps"; hell, people still write webapps in Perl. FWIW, I don't find Python very suitable for business computing either - dynamic typing is a disaster in large codebases with large teams (oh, get me started on Ruby sometime...). But the complaint about exceptions is peculiar, because people who write webapps rarely care about handling exceptions at that level of detail. 99% of the time, you catch the exception at the top level of the request handler, return a pretty error page to the user, and log a nastygram for the developers. Exception gets thrown, exception gets caught, and the server keeps going on its merry way. On the other hand, the risk that someone will ignore an error condition and just keep on plowing forward is severe. This problem plagued the C and C++ apps I once worked on, and still plagues the Node.js apps I sometimes consult on today. Eventually your app stops working, but often at a point of execution long removed from the original error and without any of the original context (stacktrace? hah!). These are the types of bugs that you can spend *days* hunting down. I'm not trying to bash Go. It strikes me as an improvement on C++ and appropriate for the same sorts of things I would otherwise apply C++ to. But I wouldn't write my startup's webapp in Go for exactly that reason - it's too low-level. Jeff -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
