> I’ve been using Go since November and I’ve decided that it’s time to give it up for my hobby projects. I’d still be happy to use it professionally, but I find that programming in Go isn’t “fun” in the same way that Python, Haskell, or Lisp is.
I can't leave go, but indeed I think absolutely the same. The thing is that GO was designed to replace c++ thing that absolutely failed. So we have a python/ruby replacement with very old patterns (I think manual checking errors ie.).
Indeed I think go is an awesome language but sometimes I really feel like a monkey repeating myself over and over again.
>The thing is that GO was designed to replace c++ thing that absolutely failed.
I was so excited for GO to become a nice replacement to C++. GO has awesome build times. C++ has awful build times. This is partly due to all the extra work the C preprocessor has to do make sure all the headers are present.
The big lose for me is the fact that GO has absolutely no operator overloading. This is one of the biggest wins in C++, especially since I do lot of high-performance scientific computing. Overloading operators makes code a lot more readable and user friendly, in my opinion (I'm others will disagree, though). I'm aware that you can hack GO to mimic operator overloading but it involves hitting the vtable. And hitting the vtable is completely unacceptable in performance-critical code.
I wrote this analysis [1] in the context of Julia vs. C++ about why I think that Go has not been successful as a C++ replacement. The primary issues are performance (the ability to trade off abstraction for performance, really), generics, and operator overloading. We did not intend for Julia to be a C++ replacement, but it turns out that it's quite a good one and a lot of adopters have come from C++ – I think that these features are why.
Go is also easy to parse, AFAICT, both syntactically and semantically, and they ship a parser in the standard library.
While absolutely not implying that it's a reasonable alternative, someone could try implementing infix operators as a syntactic layer on top of Go (kind of a preprocessor). It might work to fix the use case presented in the OP (math operators being far more readable in their infix form).
Infix operators might just be implemented as a syntactic sugar layer after all, at least as a first draft; if you're able to parse a Go source file and its types in a way that when you see a sum expression, you already know whether both arguments implement a Numeric interface and/or Add method, you might be halfway through.
To clarify: I love infix operators and I'd love if Go added them, and I consider the above just a hack.
> Overloading operators makes code a lot more readable and user friendly,
Completely true for scientific computing, but I've been subjected to libraries written in scala recently and operator overloading there has lead to some very difficult to read and use libraries.
The key to preventing overloading of definitions from being a complete disaster is to be very careful not to overload meanings. I.e. if you're going to have lots of methods for your `frob` function, you had better be crystal clear what it means to `frob` something and only add methods that fit that definition. Scala and C++ libraries tend to like to just pick a random operator and use it to mean some arbitrary made up thing because they feel like it, ignoring the meaning of the operator. The classic example in C++ is using << for stream output. That's the left shift operator for Pete's sake! Why would that be what you use print stuff? Because you liked the look of it? It's not terribly surprising that this a complete usability disaster.
> So we have a python/ruby replacement with very old patterns (I think manual checking errors ie.).
Before using Go, I have always programmed with "modern" languages that use exceptions for error handling. So the concept of only doing manual error handling was new to me, but after a few months of golang I love it now and exceptions in python started to really annoy me.
In Go, I'm forced to do error handling right after every single call that will possibly return an error. While I thought that the resulting code looked ugly and repetitive, the result is a much more focused and intelligent error handling.
If i wanted the same granularity and robustness of error handling in python, I'd have to put a catch all try..except block around every single call .
Exceptions are a good time saver in stateless request based programs (like HTTP/web stuff) where it's sort of accetable if one request fails. I could just not care so much about detailed error handling, the worst that could happen is that i don't catch some error and the wsgi wrapper will catch it and return error 500 to the client.
But building daemons in python is just plain painful. If I don't want my program to crash at some point I have to reckon that anything can raise an exception I didn't think of.
> The thing is that GO was designed to replace c++ thing that absolutely failed.
I don't think Go was designed as a general replacement for C++, I think it was designed as a replacement for C++ for the things that Python was almost better than C++ for, but not quite.
EDIT: Though, OTOH, I do get the feeling that the people who designed Go largely are the type of people who feel that just-plain-C is a superior choice to C++ for most of the rest of the domain where C++ might be used, so they might view Go as a general replacement for C++, because they start with a smaller view of C++'s useful role than the market at large has.
Go wasn't designed to replace C++, Go was designed to replace C++ at Google. And it totally succeeded at that, given the list of critical infrastructure at Google where Go is used, and in some cases has replaced existing C++ implementations.
> I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.
Yes, but he was talking programmers out there, not Google. IIRC, in 2012, they were still _very_ reluctant to talk about any use of Go within Google, with vitess being the only exception.
I can't leave go, but indeed I think absolutely the same. The thing is that GO was designed to replace c++ thing that absolutely failed. So we have a python/ruby replacement with very old patterns (I think manual checking errors ie.).
Indeed I think go is an awesome language but sometimes I really feel like a monkey repeating myself over and over again.