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.)
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.
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.
I truly hate the social hacks that are causing go to displace much better languages.
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.
My main point is that Java just isn't appealing enough in the first place for me to want to deal with the relatively insignificant issues I ran into.
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.
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.
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.
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.
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.
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.
(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.)
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.
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.
People change. Dynamic typing was popular some years ago, but opinions have changed.
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.
That's a non sequitur.
> Dynamic typing was popular some years ago, but opinions have changed.
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.
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.
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?