I'm a Python programmer by day, and I would very much appreciate a stricter type system so it was apparent what arguments a function might accept, what arguments a function might return, etc without having to open up my browser and dig through documentation. I also love that Go doesn't have much in the way of syntactic sugar--it's absolutely obvious what everything does. For example, there's no way to overload `==` so it returns an object (looking at you, SQLAlchemy).
The lack of generics is the only real pain point I feel with Go, but it's not for trivial integer functions--rather for larger data structures, like various kinds of trees. Of course, it's silly to think Python "does it better", Python has no typing at all, which you can do as well in Go via `interface{}`, and there are data structures libraries which do exactly this, but you pay a performance cost (probably still faster than Python).
If you've a python programmer, you're used to high-level, succinct code. If you want a typed language of this kind, try Haskell, or Kotlin, or maybe Rust, or Nim, or even (gasp) java 8.
Compared to Python, Go severely lacks expressive power.
I think that's always been my problem with Go, it feels like it makes a set of trade-offs that really benefit nobody. It isn't low level enough to really unseat C (Rust stands a much better chance there), but it isn't high level enough to replace something like Haskell, Java, C#, or Python. Its type system doesn't seem too terrible until you run into the strange hole left by lacking generics, which considering that basically EVERYONE these days supports generics or a similar mechanism is a very strange stance to take.
TL;DR: Go is a language designed for nobody, no matter what niche you try to fit it into it's missing some feature that's desirable in that space.
> it feels like it makes a set of trade-offs that really benefit nobody
You. I'm extremely happy with its trade-offs, with the only thing I really miss being generics. Most other things people complain about Go I find refreshing like standardizing on vendoring, static compilation, no "expressive" bs to stroke a programmer's ego while producing potentially harder to read/debug code and so on.
Go is a general purpose language for rapid application development. It excels at concurrency, and it prioritizes consistency, simplicity, and predictability. Most everything is super straightforward, easy-to-use, easy-to-understand, etc. For example, most Go programs build with `go build` and no configuration files, deployment is just putting a single binary on the target system (no runtime dependencies, not even libc). In particular, Java, Python, and C# have complex build systems and runtimes, and Haskell is not in the same family of languages, so its learning curve is steeper for a lot of people--patterns and paradigms are fundamentally different, so it will take longer to see a return on investment. This doesn't make Go a "better language" in any objective sense, but those who value a no-nonsense, pragmatic language will probably enjoy Go.
>one persons 'lack of expressive power' is another persons 'this code is easy to read'.
Expressive translates to "easier to read".
Having 100 lines of very simple procedural statements to accomplish what an expressive language does in 5 higher level lines doesn't make the 100 lines easier to reason about or maintain.
At worse it makes reasoning about their memory/speed beahavior harder -- but when it comes to reasoning about their functionality and the correctness of your program it's orders of magnitudes easier.
there's defnly some truth to this -- more concise (via expressive power) code can be easier to grok, because it's easier to see the forest w/o so many trees in the way.
but on the other hand, having simple code where it's easy to point at each bit and say 'that does this, that goes here' can also make code easier to understand.
for me personally, on balance, the latter wins outweigh the former losses when going from python -> go. i'd say it's probably a small bump down in expressiveness for a large jump up in 'look and know what it does'-ness.
(it's not like go is really missing that much that python has -- maybe list comprehensions (which are great!), tuples, and generators?)
it'd be fun to do some empirical investigation of these things. take some toy problem, code up idiomatic, by-the-language-advocates solutions, and then throw them at large groups of people asking them to make some change, or fix some deliberately introduced bug, and see how the #s came out. :)
I agree. If I am doing something "complicated", that won't be obvious to a beginner, I put a comment beside it. Having two or three lines as opposed to 20 or 30 is often easier to read if you ask me.
Python can be very readable. In practice, it's much less readable than Go. Also, Python's lack of typing makes it very hard to follow type arguments (something I lament daily). I love that I can enter a few keystrokes in vim and see the type signature, methods, fields, documentation, or even the full definition. Python doesn't really have this (at least not unless your project is using mypy).
One of the side projects I've been working on attacks this in a different way; what if we efficiently trace every single call point at the Python and C level, including all arguments, such that we can build up a historic inference of types a given object label had at any point in time.
The problem with under-expressive code is boilerplate.
"You cannot pay people enough to carefully craft boilerplate code" (quoting the founder of Jane Street). When you glaze over while reading boilerplate, or wearily copy-paste when you write boilerplate, the chance to make an error grows significantly.
This used to be a problem with Java (and still partly is), despite static typing and top-notch IDEs.
It's sad when a new language suffers from that, too.
OTOH, it took Java 8 years to introduce generics. Go just need to mature a bit (not ironically; it needs to sort out less ambitious technical issues first).
I don't necessarily want "high-level, succinct code", I want something simple that compiles to static binaries with minimal configuration. Rust is most likely what I'll use in the future, but it's fairly low-level compared to Go, and the editor support pales. Eventually I think it will get there though.
Python can be friendly, but in practice people frequently use Python's magic features for everything. Go reigns people in, which can be a burden for some, but I appreciate the predictability.
edit: Also, everyone, and I mean ev-rey-one that writes more than 12 lines of Python code a day needs to be using PyCharm. Navigation, inference, type safe refactoring, pure gold.
> I'm a Python programmer by day, and I would very much appreciate a stricter type system so it was apparent what arguments a function might accept, what arguments a function might return, etc without having to open up my browser and dig through documentation.
While Perl5 is not a typed language, it does have addon type checking modules such as Type::Tiny that play really nice with addon (ahem) object systems like Moo. It doesn't look pretty but it works. Perl6 fixes that and also makes it pretty as you can declare variables as typed and the interpreter will happily complain when you do something like:
my Int $a = '3';
Type check failed in assignment to $a; expected Int but got
Str ("3") in block <unit> at <unknown file> line 1
Add-on type systems have the disadvantage of being add-on, that means that the vast majority of code will not have any type information associated therefore reasoning what code accepts or returns is just as it is without the added type system.
I was thinking of using Typed Clojure, but the advantages would unfortunately not translate to the libraries that I use.
You annotate your functions with types they accept and return. Run this tool and it shows inconsistencies. The more you annotate and the more precise the types, the more helpful it is. This is not Hindley–Milner types here (this is actually called Success Typing), but goes along way to do what you suggest i.e. you can have your cake and even eat some of it ;-)
Python now has mypy, that I understand is rather similar. Guido at least is rather fond of it. But it is still new and I haven't yet heard of it used in real world:
The lack of generics is the only real pain point I feel with Go, but it's not for trivial integer functions--rather for larger data structures, like various kinds of trees. Of course, it's silly to think Python "does it better", Python has no typing at all, which you can do as well in Go via `interface{}`, and there are data structures libraries which do exactly this, but you pay a performance cost (probably still faster than Python).