I used to present at Python conferences and now use a mix of go and other languages to fill what used to be my all-python workflow. Here's my opinion:
I really like Python for fast scaffolding for low-use items. Django REST framework is really easy to get working and maintain. The language is pretty simple and you could break out into async/await based workflows if you really wanted to -- the last framework I used for that was tornado. But increasingly I'm not seeing Python as a strong enough candidate for scaffolding. Rails has been very dominant in the fast to scaffold web app space and now some really clever solutions like Elixir/Phoenix have come along and DRF just isn't as special. I think right now, Python's position among other languages is highest in data science because you can break into ML and really high ceiling use cases. However, besides that, I wouldn't recommend it. Not for DevOps scripts, not for web services, not for general purpose apps. Here's why:
Python has some really old cruft around the way things used to be. It wasn't async from the get go like node, so it's single-threadedness feels more detrimental than node. It has a few neat syntactic sugars, but lambdas and functional based code is still kinda clunky. But the real pain point for me has been deploys. Python was the itch that Docker first scratched for me because python deployment and package management is such a pain. Getting coworkers to reliably build packages for you is even harder than the initial pain of getting a package to install correctly for yourself every time. The way python dumps package sources globally necessitates tools like Docker,pyenv,virtualenv on top of tools just to run multiple python versions since many systems rely on it for OS tooling. The versioning model of requirements.txt is simply not sufficient nor enforceable enough. I would say Docker is a requirement of modern production Python. Another oddity is that many modern languages have moved over to hosting web services with a reverse proxy in front of a fully capable HTTP server. Python has libraries like tornado, but you're essentially writing nodey python. The strong libraries like Django DRF want a WSGI based setup, which just feels like a lot of effort compared to other languages. gunicorn can help abstract that... but the idea of running uWSGI+nginx just feels very 2008, not 2018, it's hard to express -- but from DevOps side, I despise the idea of the AppServer/WebServer pair up where the web server forks app servers off. It's a bad model; Async won; Reverse proxies + suspended app+web server makes more sense and ends up being easier to host and manage.
Now onto Go; Go is my favorite language while simultaneously being one of the ugliest most utilitarian languages. Nothing in Go will ever feel elegant, but it will feel sturdy. It won't feel state of the art, but it feels fast and efficient. It's a strange dichotomy that it gets a lot of flak for. Understanding the origin of Go really helps with learning to love Go for it's weirdness, and I encourage people to do that -- because from the start it can seem awkward and weird.
Go, to me, isn't the C++ replacement that a lot of people herald it at. Go is a language which is absolutely built on the web, for the web, but more importantly, by back-end engineers at Google, where Java, Python and C++ have been king. At a very high level, each accomplishes a slightly different but partially overlapping task. Java has good speed and stability and is great for long running business logic; Python is great for quick mockups and fast turnaround times and ad-hoc tooling; C++ is blazing fast and can be deployed with few (if any) dependencies. Go is somewhere right in the middle of all that. It is very fast -- only marginally slower than well tuned C++; it is somewhat simple to write like Python or Java; It uses source based importing like Python and C++; It has moderate typing -- better than Python, worse than C++ or Java, but way faster compile times than even Java.
Because of these ties, you have some weirdness. Go has a strange import structure that resembles a monorepo, something common at Google. Go has a somewhat ugly exception handling strategy, like C (not C++). Go doesn't have strongly typed Generics (this again, is like C).
Go does have an insanely good stdlib with coroutines endemic throughout it, Blazing fast HTTP, a very quick compiler, a runtime that is GC'd so you don't have to worry (as much) about memory and some of the niceties that C and Python miss out on by not being Java/C++. That being said, there's something nice about it not being Java or C++. It's great that threading is handled and it's also not using all of the RAM on my box. It's great that binaries take seconds to build but don't depend on the deploy system having a VM installed. Go made a lot of sacrifices to get where it is in the ecosystem and I personally love it, but you might not. I'd recommend Go over Python, but I hope you can appreciate the oddities that make it good and see past some of its hideous features that make people blog about how it's not good.
I used to present at Python conferences and now use a mix of go and other languages to fill what used to be my all-python workflow. Here's my opinion:
I really like Python for fast scaffolding for low-use items. Django REST framework is really easy to get working and maintain. The language is pretty simple and you could break out into async/await based workflows if you really wanted to -- the last framework I used for that was tornado. But increasingly I'm not seeing Python as a strong enough candidate for scaffolding. Rails has been very dominant in the fast to scaffold web app space and now some really clever solutions like Elixir/Phoenix have come along and DRF just isn't as special. I think right now, Python's position among other languages is highest in data science because you can break into ML and really high ceiling use cases. However, besides that, I wouldn't recommend it. Not for DevOps scripts, not for web services, not for general purpose apps. Here's why:
Python has some really old cruft around the way things used to be. It wasn't async from the get go like node, so it's single-threadedness feels more detrimental than node. It has a few neat syntactic sugars, but lambdas and functional based code is still kinda clunky. But the real pain point for me has been deploys. Python was the itch that Docker first scratched for me because python deployment and package management is such a pain. Getting coworkers to reliably build packages for you is even harder than the initial pain of getting a package to install correctly for yourself every time. The way python dumps package sources globally necessitates tools like Docker,pyenv,virtualenv on top of tools just to run multiple python versions since many systems rely on it for OS tooling. The versioning model of requirements.txt is simply not sufficient nor enforceable enough. I would say Docker is a requirement of modern production Python. Another oddity is that many modern languages have moved over to hosting web services with a reverse proxy in front of a fully capable HTTP server. Python has libraries like tornado, but you're essentially writing nodey python. The strong libraries like Django DRF want a WSGI based setup, which just feels like a lot of effort compared to other languages. gunicorn can help abstract that... but the idea of running uWSGI+nginx just feels very 2008, not 2018, it's hard to express -- but from DevOps side, I despise the idea of the AppServer/WebServer pair up where the web server forks app servers off. It's a bad model; Async won; Reverse proxies + suspended app+web server makes more sense and ends up being easier to host and manage.
Now onto Go; Go is my favorite language while simultaneously being one of the ugliest most utilitarian languages. Nothing in Go will ever feel elegant, but it will feel sturdy. It won't feel state of the art, but it feels fast and efficient. It's a strange dichotomy that it gets a lot of flak for. Understanding the origin of Go really helps with learning to love Go for it's weirdness, and I encourage people to do that -- because from the start it can seem awkward and weird.
Go, to me, isn't the C++ replacement that a lot of people herald it at. Go is a language which is absolutely built on the web, for the web, but more importantly, by back-end engineers at Google, where Java, Python and C++ have been king. At a very high level, each accomplishes a slightly different but partially overlapping task. Java has good speed and stability and is great for long running business logic; Python is great for quick mockups and fast turnaround times and ad-hoc tooling; C++ is blazing fast and can be deployed with few (if any) dependencies. Go is somewhere right in the middle of all that. It is very fast -- only marginally slower than well tuned C++; it is somewhat simple to write like Python or Java; It uses source based importing like Python and C++; It has moderate typing -- better than Python, worse than C++ or Java, but way faster compile times than even Java.
Because of these ties, you have some weirdness. Go has a strange import structure that resembles a monorepo, something common at Google. Go has a somewhat ugly exception handling strategy, like C (not C++). Go doesn't have strongly typed Generics (this again, is like C).
Go does have an insanely good stdlib with coroutines endemic throughout it, Blazing fast HTTP, a very quick compiler, a runtime that is GC'd so you don't have to worry (as much) about memory and some of the niceties that C and Python miss out on by not being Java/C++. That being said, there's something nice about it not being Java or C++. It's great that threading is handled and it's also not using all of the RAM on my box. It's great that binaries take seconds to build but don't depend on the deploy system having a VM installed. Go made a lot of sacrifices to get where it is in the ecosystem and I personally love it, but you might not. I'd recommend Go over Python, but I hope you can appreciate the oddities that make it good and see past some of its hideous features that make people blog about how it's not good.
Cheers!
I really appreciate this comment!
I did a lot of this. But now I'm tired of writing low-use applications :P