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?
>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.)
> 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.
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.
> 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.
> 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.
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.)
> 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.
I've tried moving one of my projects from Django to Go before. I must accept that I had to wire a lot of stuff in Go, that Django handled for me like a cake. I'm talking about configuration, patterns and common features.
Others who've been where I was: how did you cope up with this? Would you be ready to move another project from Django to Go, without the mental fatigue?
For the majority of my career I haven't worked on greenfield projects. I've been debugging, modifying, and otherwise maintaining pre-existing projects. As a result I've grown to really dislike frameworks that autowire things together. The very same features that made it easy to get started make them harder to maintain going forward. It turns out following the code in your own codebase is easier than following the code in the framework.
Django isn't as bad as some in this respect, (cough, spring, cough), but it still exhibits some of the same issues regarding maintainability. Go front-loads some work so that longer term maintenance is easier. And the vast majority of code work is maintenance not greenfield development.
So this lists the usual stuff that people who aren't experts in any system think are good reasons to pick one or the other for.
1. The single binary is attractive, but with modern virtualenv and wheel and anylinux wheel files this is far far less important than it would have been 10 years ago. I count this as irrelevant but probably python's library packaging is confusing to a beginner.
2. Static types don't really help you here, yes you can run into some issues where you have an object that is a different type than what you thought it was, but this is not common and your tests will catch it for you. I'm not sure why django's orm will fail on the wrong type since SQL is loosely typed anyway, but everything django is garbage so don't use django.
3. Performance in python can be pretty awful. Not going to argue. It's usually not too slow and you should focus on algorithms first, if you agorithm is efficient then you should be able to do whatever computation you need to render html or json for your service in plenty of time. But Python is slow sadly.
4. You don't need a web framework for Python either, Werkzeug is a great toolkit to roll your own micro framework. So I'll just count this as lack of experience and knowledge, plus confusion.
5. Great IDE support. I guess this is a thing people like to have, personally I think if you are being slowed down by how fast you can type or remember method names something is horribly wrong. The other things IDE's do are usually pretty pointless, at least for me, but if you feel like you need it then I agree IDE support for python is usually pretty weak because python is very hard to statically analyze. None of the more productive programmers I've known through the years used IDE's, they all used Vim or Emacs. If you feel like you need hand holding I guess IDE support would be important for you though.
1. There are other ways to do it, yes. But "just upload anywhere and it works" is not just for server, but for tooling. That what comes out of the compiler can be used everywhere is a huge selling point that also, unfortunately, helped PHP even though there were other ways to do that too.
2. I could not disagree more. Just costs between int, float, int64, and double cause lots of bugs. Go makes costs explicit, which may be annoying, but does fix issues. Also lots of python code needs to check if passed args is str, or Unicode, or byte, or list, or dict, (or does, anyway, even though it shouldn't) so when someone passes in a generator when code assumed, or checked for a list, then all hell breaks loose.
4. I disagree with the article and think that the gorilla Go router is so good that you pretty much need it. :-)
As with all "why we changed from technology X to technology Y", the story is that there was this or that perceived shortcoming in technology X and technology Y will be our savior and fix all our problems, or conform to our software ideology/dogma.
I used to read these things but given that I've read one, I've read em all.
The only reason people keep writing these things is blog filler to promote their company or do indirect recruiting. Surely cannot be cause anyone cares why you use a blue pen instead of a black pen.
> Surely cannot be cause anyone cares why you use a blue pen instead of a black pen.
Actually... I think folks do care. But I also think that depends a bit on how you look at what's interesting. Some people want to use new languages or different languages for the sake of them being new or different. Others are more restrained but will reach out to a new language or experiment with it if they have some reason to assume this language can solve their problem better (for a definition of better). Others are set in stone and won't consider moving on from what they know.
What makes some of these posts interesting is when it goes much deeper and has thorough details that show how switching to a different language improved the situation for them, on the axis they were looking to improve. With actual metrics, crashes in production for example, deployment size, time from commit to deploy, resource usage etc. etc.
This article of full of fluff. Citing a static type system as a point for Go? Go's type system is about the weakest of any popular, statically typed language being written today. It's full of escape hatches.
As an aside, the greatest thing about Python is StackOverflow one-liner solutions to common problems. How do you find your developer productivity fares in Go? To take a simple example, I was experimenting with C++ and had the simple task of "reading in a CSV". This simple C++ task does not have a nicely formatted, pre-approved, community rubber-stamped, best practice 500 green ticks StackOverflow top accepted answer (sometimes by Core Python / prominent PyCon developers) that I can just copy and paste.
> How do you find your developer productivity fares in Go? To take a simple example, I was experimenting with C++ and had the simple task of "reading in a CSV".
Not sure if reading data from a csv formatted file is a great example for differentiating Python and Go: both languages have a builtin csv package/module.
Right, it's almost impossible to get any work done without having pre-approved code to copy and paste from. This is especially true for highly complex problems like reading a CSV file. Those virtually require the presence of promiment PyCon developers as no one else can possibly get this right.
If someone switches away from Python he never used the unprecedented expressiveness of it, which is tens of orders of magnitude higher than the next best language.
One line in Python is worth several screens in the next best language.
Python can be as fast as C++ if you use all its features.
Development time is around 20 to 50 times faster than Java.
That's a dumb article.
Take point 5 for instance: You can code in Go with Jetbrain's IDE. Well guess what, Python has a dedicated IDE made by JetBrain: PyCharm. How is this an advantage ?
A copious amount of misinformation in this article. Another honest? effort from the stable of individuals with a shallow understanding of elementary CS.
> Python is great and fun language but sometimes you are just getting unusual exceptions because trying to use variable as an integer but it turning out that it’s a string.
Oh why would I get an unusual exception, if I tried doing that _without even a try except block_ hust, I wonder ... must be because of the language itself and how it works.
> [static typing]
Why would you have started with Python, if you did not like dynamic typing? Also I doubt that static typing saves any time at all. It might also depend on what you are used to.
> [performance]
I am not sure what the application is for what Go is used in this case, so one cannot really talk about the necessity of speed in the authors use case.
However, the static typing example was a Django thing, so might be it is about some web app. Web apps are typically not the most performance needy things around.
Before bringing up the performance argument, one should check whether the performance of the language is the bottleneck or rather some I/O, like reading from disk, database or network (for which the appropriate libraries are responsible, like a database driver, which is likely to have similar performance across libraries).
If it is really about some calculation being done in the language itself, there are many high performance libraries available for Python, which are implemented in Fortran and C, so I doubt that in a proper setting using Go instead of Python and its libraries would have much of a lead in terms of performance. If you are doing massive matrix operations in the language itself, then it is sort of your own fault. Python is a language, which lives from its rich ecosystem. If you don't use it and look out for stuff, which could help you, then yeah ...
> [built-in http json ...]
Many of those Python has as well and since when is built-in automatically better than an available library, if the source code of the library is properly checked, before going to the official repositories? From a minimalistic point of view, one could even argue, that it should not be part of the language and that one can "customize" ones setup depending on the task at hand. If looking at the time needed for setup, it is only once a creation of some virtual environment (virtualenv, anaconda, whatever else there is) and you are done.
What happens, when there is an update to Go or a series of updates, which add a new feature, for example like Python's `async` and you want that in your application? You'd need to update your language compiler. But what if some of the so nicely built-in libraries changed as well and is now incompatible with what you wrote before? Maybe some function had a bad name and got renamed. Bam! You cannot update your language compiler/interpreter without breaking things. And why is that? Because the built-in library is not decoupled from the language itself. If it was not built-in, you could have it tell you, that it is only compatible with some version of Go. That's how it works with Python's libraries in anaconda environments and it is all automatically taken care of for you.
> [IDE]
Meh, Python got those too. I am still using Emacs amd Vim instead of an IDE. It didn't make me any less productive.
If the original title begins with a number or number + gratuitous adjective, we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X," and "14 Amazing Ys" to "Ys."
[+] [-] ra7|9 years ago|reply
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|9 years ago|reply
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|9 years ago|reply
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.
[+] [-] yupyup|9 years ago|reply
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.
[+] [-] fredsir|9 years ago|reply
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|9 years ago|reply
People change. Dynamic typing was popular some years ago, but opinions have changed.
[+] [-] giancarlostoro|9 years ago|reply
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|9 years ago|reply
[+] [-] dragonwriter|9 years ago|reply
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.
[+] [-] lewisjoe|9 years ago|reply
Others who've been where I was: how did you cope up with this? Would you be ready to move another project from Django to Go, without the mental fatigue?
[+] [-] zaphar|9 years ago|reply
Django isn't as bad as some in this respect, (cough, spring, cough), but it still exhibits some of the same issues regarding maintainability. Go front-loads some work so that longer term maintenance is easier. And the vast majority of code work is maintenance not greenfield development.
[+] [-] banachtarski|9 years ago|reply
Goroutines are more performant than python threads if you don't understand the difference between a thread and a routine.
[+] [-] gerenuk|9 years ago|reply
[+] [-] agounaris|9 years ago|reply
https://magic.io/blog/uvloop-blazing-fast-python-networking/
[+] [-] justin_vanw|9 years ago|reply
1. The single binary is attractive, but with modern virtualenv and wheel and anylinux wheel files this is far far less important than it would have been 10 years ago. I count this as irrelevant but probably python's library packaging is confusing to a beginner.
2. Static types don't really help you here, yes you can run into some issues where you have an object that is a different type than what you thought it was, but this is not common and your tests will catch it for you. I'm not sure why django's orm will fail on the wrong type since SQL is loosely typed anyway, but everything django is garbage so don't use django.
3. Performance in python can be pretty awful. Not going to argue. It's usually not too slow and you should focus on algorithms first, if you agorithm is efficient then you should be able to do whatever computation you need to render html or json for your service in plenty of time. But Python is slow sadly.
4. You don't need a web framework for Python either, Werkzeug is a great toolkit to roll your own micro framework. So I'll just count this as lack of experience and knowledge, plus confusion.
5. Great IDE support. I guess this is a thing people like to have, personally I think if you are being slowed down by how fast you can type or remember method names something is horribly wrong. The other things IDE's do are usually pretty pointless, at least for me, but if you feel like you need it then I agree IDE support for python is usually pretty weak because python is very hard to statically analyze. None of the more productive programmers I've known through the years used IDE's, they all used Vim or Emacs. If you feel like you need hand holding I guess IDE support would be important for you though.
[+] [-] knorker|9 years ago|reply
2. I could not disagree more. Just costs between int, float, int64, and double cause lots of bugs. Go makes costs explicit, which may be annoying, but does fix issues. Also lots of python code needs to check if passed args is str, or Unicode, or byte, or list, or dict, (or does, anyway, even though it shouldn't) so when someone passes in a generator when code assumed, or checked for a list, then all hell breaks loose.
4. I disagree with the article and think that the gorilla Go router is so good that you pretty much need it. :-)
[+] [-] forgottenacc57|9 years ago|reply
I used to read these things but given that I've read one, I've read em all.
The only reason people keep writing these things is blog filler to promote their company or do indirect recruiting. Surely cannot be cause anyone cares why you use a blue pen instead of a black pen.
[+] [-] daenney|9 years ago|reply
Actually... I think folks do care. But I also think that depends a bit on how you look at what's interesting. Some people want to use new languages or different languages for the sake of them being new or different. Others are more restrained but will reach out to a new language or experiment with it if they have some reason to assume this language can solve their problem better (for a definition of better). Others are set in stone and won't consider moving on from what they know.
What makes some of these posts interesting is when it goes much deeper and has thorough details that show how switching to a different language improved the situation for them, on the axis they were looking to improve. With actual metrics, crashes in production for example, deployment size, time from commit to deploy, resource usage etc. etc.
[+] [-] leshow|9 years ago|reply
[+] [-] robbrit|9 years ago|reply
For people who are accustomed to Python or Javascript this is a feature, not a bug.
[+] [-] throwaway_374|9 years ago|reply
[+] [-] bpizzi|9 years ago|reply
Not sure if reading data from a csv formatted file is a great example for differentiating Python and Go: both languages have a builtin csv package/module.
Python: https://docs.python.org/3/library/csv.html#examples
Golang: https://golang.org/pkg/encoding/csv/#example_Reader
And, errors handling put aside, both takes more or less the same number of LOC.
[+] [-] slrz|9 years ago|reply
Only use code with at least 500 green ticks.
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] sametmax|9 years ago|reply
There are many good reasons to switch from Python to Go, but that article misses them all.
[+] [-] henrik_w|9 years ago|reply
[+] [-] jwezel|9 years ago|reply
One line in Python is worth several screens in the next best language.
Python can be as fast as C++ if you use all its features.
Development time is around 20 to 50 times faster than Java.
[+] [-] popol12|9 years ago|reply
[+] [-] skynode|9 years ago|reply
[+] [-] zelphir_kalt|9 years ago|reply
Oh why would I get an unusual exception, if I tried doing that _without even a try except block_ hust, I wonder ... must be because of the language itself and how it works.
> [static typing]
Why would you have started with Python, if you did not like dynamic typing? Also I doubt that static typing saves any time at all. It might also depend on what you are used to.
> [performance]
I am not sure what the application is for what Go is used in this case, so one cannot really talk about the necessity of speed in the authors use case.
However, the static typing example was a Django thing, so might be it is about some web app. Web apps are typically not the most performance needy things around.
Before bringing up the performance argument, one should check whether the performance of the language is the bottleneck or rather some I/O, like reading from disk, database or network (for which the appropriate libraries are responsible, like a database driver, which is likely to have similar performance across libraries).
If it is really about some calculation being done in the language itself, there are many high performance libraries available for Python, which are implemented in Fortran and C, so I doubt that in a proper setting using Go instead of Python and its libraries would have much of a lead in terms of performance. If you are doing massive matrix operations in the language itself, then it is sort of your own fault. Python is a language, which lives from its rich ecosystem. If you don't use it and look out for stuff, which could help you, then yeah ...
> [built-in http json ...]
Many of those Python has as well and since when is built-in automatically better than an available library, if the source code of the library is properly checked, before going to the official repositories? From a minimalistic point of view, one could even argue, that it should not be part of the language and that one can "customize" ones setup depending on the task at hand. If looking at the time needed for setup, it is only once a creation of some virtual environment (virtualenv, anaconda, whatever else there is) and you are done.
What happens, when there is an update to Go or a series of updates, which add a new feature, for example like Python's `async` and you want that in your application? You'd need to update your language compiler. But what if some of the so nicely built-in libraries changed as well and is now incompatible with what you wrote before? Maybe some function had a bad name and got renamed. Bam! You cannot update your language compiler/interpreter without breaking things. And why is that? Because the built-in library is not decoupled from the language itself. If it was not built-in, you could have it tell you, that it is only compatible with some version of Go. That's how it works with Python's libraries in anaconda environments and it is all automatically taken care of for you.
> [IDE]
Meh, Python got those too. I am still using Emacs amd Vim instead of an IDE. It didn't make me any less productive.
[+] [-] dom0|9 years ago|reply
5 Reasons Why We Switched from MySQL to Postgres
Why We Switched from Postgres to Oracle
11 Reasons For Switching From Oracle To KDB
7 Reasons Why We Switched from Go to Fortran-77
Grammar errors are provided for free by The Author.
[+] [-] FlorianRappl|9 years ago|reply
I guess we'll have: "This will surprise everyone, but Postgres can actually handle GIS data better than MySQL".
[+] [-] snackai|9 years ago|reply
[+] [-] skynode|9 years ago|reply
[+] [-] jwilk|9 years ago|reply
If the original title begins with a number or number + gratuitous adjective, we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X," and "14 Amazing Ys" to "Ys."
[+] [-] apathy|9 years ago|reply
I learned an important lesson about writing from this author.