[ra7]

> #2 Static Type System

It's really weird to see one of the reasons for their switch to Go was because it's a statically typed language. If you want static typing, you don't choose Python in the first place. You know it beforehand and it shouldn't come as a surprise for you.

> For example it has http, json, html templating built in language natively

So does Python with urllib and json modules. I don't know if it has HTML templating in the standard library, but you can always use jinja2.

> Great IDE support and debugging

Not even a mention for the excellent PyCharm or so many of the useful Python vim plugins?

[jasode]

>If you want static typing, you don't choose Python in the first place. You know it beforehand

Well, people begin using languages for different reasons and it's possible that there was never a conscious explicit choice of "dynamic vs static". Instead, they were actually interested in some specific task library (content management system, numeric computing, scrape webpages) and the underlying language happened to be Python.

For example, a programmer might stumble into Python because he was using Django, or work colleagues used Numpy/Scipy, or the easiest HTML parser was Scrapy. That the language happened to be Python and it happened to be "dynamic" is incidental. In Django's case, that project is 4 years older than Golang. Maybe Java Spring was too verbose but the new Golang with static typing (and less-verbose type inference) hits the sweet spot.

Probably the most widespread example of "dynamic vs static" not being a choice is Javascript. Millions of us didn't program Javascript because it's dynamic; we used it because it's the only language available on all the browsers.

Also, some programmers may not realize they want static typing until they experience pain points with dynamic languages on large projects. (E.g. easier refactoring.)

[unscaled]

> It's really weird to see one of the reasons for their switch to Go was because it's a statically typed language. If you want static typing, you don't choose Python in the first place. You know it beforehand and it shouldn't come as a surprise for you.

It's weirder that many Python/NodeJS switchers cite this reason, since out of all the commonly used statically typed languages, Go has the second weakest type system (the first place obviously Goes to C).

With so many methods returning an interface{}, you'll get exactly the same crashes you had with Python.

If type safety is really such a major issue for you, you'll get a significantly better deal from Python Type Hints (using mypy or PyCharm) and TypeScript/Flow. All of them support generics (and hence nearly eliminates the need for wildcard types).

I suspect performance and static binaries are the real reason for most of the cases of projects switching from dynamic languages to Go.

[uluyol]

What functions return interface{}? I rarely see it outside of marshaling/unmarshaling (where I believe it would remain even if the language had real generics) and contexts (which would also use interface{} if there were generics).

Sometimes you want dynamic typing, how else will you pretty print structs? The compiler could generate code but that's a lot of bloat. For context, the point of it is that you don't know what's in it, it's an opaque container for information to be used by middleware. The fact that data might be missing lends itself to easier refactoring later on.

I want generics in go, but I don't find my code using much interface{} at all.

[bastawhiz]

It really depends on the type of application you're building, I suppose. I've seen applications littered with empty interfaces, and others with hardly any.

[yummyfajitas]

If you really want good static typing while being fairly python like, there are other great options. Java or c++ both have decent generics, speed comparable to go, great libraries and years of collective experience using them.

I truly hate the social hacks that are causing go to displace much better languages.

[nine_k]

It's the learning curve. If you know another imperative language, you can grasp golang in a week. With C++ or Java, you need months.

[SamReidHughes]

Java is pretty darned graspable, at least I think it's way closer to Go than C++. What do you think are the biggest things that make it hard? The language? Warts like int/Integer? Library size or organization? (This is a real question, I can't look at this stuff with "fresh eyes.")

[thomastjeffery]

For me? The environment/runtime.

I can write a simple program in C/C++/go/rust/etc, and compile and run it.

In Java, a bloated IDE isn't just a recommendation, it's practically a requirement.

Evey time I try to learn Java, I smack my head against the toolchain. I ended up just giving up when I tried to wrap my head around classpath, and haven't tried since. I could probably figure it out pretty easily now, but I just don't see any allure in learning Java anyway.

One of these days, I might start using Clojure, but the JVM just feels so messy that I don't want to start.

[yummyfajitas]

There is no requirement to use an ide in Java. I've never written Java in anything other than emacs and never had a problem.

[thomastjeffery]

> much better languages.

I disagree. Java has a bloated syntax, and C++ is a mess. Java also depends on a proprietary runtime, with mostly compatible free alternatives.

The biggest advantage C++ offers is speed, through memory management, which is usually a pain to deal with.

Go, on the other hand, has a well thought out syntax, good support for concurrency, garbage collection, and compiles to native executables.

[yummyfajitas]

Could you illustrate what you mean by "bloated syntax"?

Everything else you mention (besides native executables) Java also has. From what I can see, Java provides far better concurrency support - more paradigms than simply go routines.

[thomastjeffery]

Classes are required. Sometimes I just want a c-style program without a class. Java looks a lot like C++ (just with garbage collection, and some more consistently defined behavior). In comparison, golang (and rust) have some nice syntactical differences: inferred types, postfix type annotations, etc.

Go routines are nice when that is all the complexity you want. Having more paradigms isn't an interesting prospect until it becomes specifically useful.

Java may be more usable in many cases, but it, in my experience, just isn't easy to work with.

[yummyfajitas]

Apart from the boilerplate enclosing class (4 lines, vs 2 in C), you can write a C-style program without classes in Java. There is literally nothing stopping you and generics are helping you significantly for this.

[yupyup]

About the static type system:

When people say they like Go's static type system sometimes they are comparing it to something more verbose like Java.

Think about someone that knows Python and have to use Java, then they think that all static type languages are as a pain in the ass. So they begin disliking static type systems when they really just hate the Java's one.

And so the moment they are using Python and start playing with Go they find a static type system they kinda like because it's less verbose and without so much ceremony.

[dragonwriter]

> When people say they like Go's static type system sometimes they are comparing it to something more verbose like Java.

Go's system throws out a lot of the ceremony of older Java, but also throws out a lot of the benefit; many modern languages (including recent Java) also use type inference and other features to reduce static typing ceremony, but retain at least the power of the classic Java type system, and often far more.

Go's type system seems to be a poor benefit-to-ceremony trade-off.

[asadmshah]

Java the language is verbose, sure... but the type system?

[yupyup]

Well, having a static type system is a tradeoff...

When using Python I feel the least resistance from the language, you can do a lot with a little code. Problem is, when the system grows you begin to miss the checking that static typing provides (esp. when doing refactors).

When coding in Go I feel that there is a little productivity lost upfront, but when your script begins growing and starts to look like a "serious" project you feel more confident changing your old code. This is because some kind of errors are caught by the type system before doing manual/automated testing.

And I'm talking about personal projects where I'm alone, this could be more important in projects with several coders.

[yummyfajitas]

I think yupyup is referring to the fact that all types must be explicitly annotated.

(I favor this and explicitly annotate most of my types in Haskell and Scala. Makes reading easier. But I did occasionally find it annoying in Java when it was mandatory.)

[thomastjeffery]

Inferred types are nice.

They make cleaner, and therefore, more readable code. That is the main thing people want from dynamic typing anyway. It's really not very common to change the type of a variable, and a statically typed codebase is more predictable, and therefore easier to manage.

[fredsir]

> It's really weird to see one of the reasons for their switch to Go was because it's a statically typed language. If you want static typing, you don't choose Python in the first place. You know it beforehand and it shouldn't come as a surprise for you.

Why is it weird? You have to have experience with statically and dynamically typed languages before you can choose the one that will fit your project the best. If you don't have the experience, you probably choose the one you are familiar with. In a world where everybody knew everything, everyone could make the right decisions and none of the wrong decisions. That is not the case, though.

[nawitus]

"If you want static typing, you don't choose Python in the first place. You know it beforehand and it shouldn't come as a surprise for you."

People change. Dynamic typing was popular some years ago, but opinions have changed.

[el_isma]

Projects change too. What's good for a small project might not be for a big one.

[luord]

This is weird. It's not a matter of what was popular a few years ago.

Static typing didn't "stop" being popular while dynamic typing "was" popular, nor have opinions "changed". Dynamic and static typing have coexisted almost the entire history of programming and will continue to do so.

And so will the flamewars about them, unfortunately.

[nawitus]

"Static typing didn't "stop" being popular while dynamic typing "was" popular, nor have opinions "changed". Dynamic and static typing have coexisted almost the entire history of programming and will continue to do so."

That's a non sequitur.

[luord]

How so? It was directly addressing this:

> Dynamic typing was popular some years ago, but opinions have changed.

[giancarlostoro]

> Not even a mention for the excellent PyCharm or so many of the useful Python vim plugins?

I must also mention Python Tools for Visual Studio is REALLY good. I have used PyCharm and PTVS and I must say PTVS is absolutely fantastic. PyCharm wins for me in the Cross-Platform aspect though.

[flavor8]

I haven't used Jetbrains' go ide, but extrapolating from my time with intellij and pycharm it seems that their ides work significantly better with static type systems. (Find usages, rename function, etc are less accurate.)

[tonyedgecombe]

PyCharm does support type hinting now which should help: https://blog.jetbrains.com/pycharm/2015/11/python-3-5-type-h...

[dragonwriter]

> It's really weird to see one of the reasons for their switch to Go was because it's a statically typed language. If you want static typing, you don't choose Python in the first place.

Sure, if your only or most important criteria is static typing. But you can view static typing as desirable, but prefer Python because it has more important positive traits that no alternative with static typing has, so you sacrifice static typing for them. But then Go comes along, that is good enough on those criteria and has static typing, and you prefer it.

Of course, Python now has optional static typechecking available anyhow.