flat state of the red line. As a reference, Rust trend is in yellow, pretty good for a no-profit. Guess what the light blue line is. Google is pushing hard on the Go propaganda. Google is a damn good Hype-machine: people actually use AngularJS.
CPython VS. Go? Just nope. PyPy VS. Go? Interesting but out of scope. BUT Counting how many requests can handle in a given timeframe a non-blocking server is a little bit easier. Do you know the statement concurrency is not parallelism? Well, CPython gives you a slightly conservative reinterpretation: concurrency shalt not be parallelism
Python devop is usually required to master a superset of the following: virtualenv, pip, pyenv, uwsgi, gunicorn, mod_wsgi, docker, docker-compose, fabric, buildout, pythonz, conda. Desktop software? Better ship your own interpreter, trust me. Typical Go deployment script: scp your_fucking_static_binary your_server: Ok, it's a little bit oversimplified but I'm one of those who knows about buildout, I'm vulnerable.
and environments are better than Python at Hype, Performance and Deployment. So why Pythonistas are moving mainly to Go? Another uneducated guess: Happiness Remember from few slides ago? The average Pythonista is happy and wants to keep this state. How do we keep the grade of happiness for a Python dev? Provide a standard library full of stuff Let them write Pythonic code
Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!
classes, constructors or destructors Methods are plain functions, no self or this func (e Engine) Start() { fmt.Println("Engine started") } No named arguments No generators No iterators No decorators
use structs embedding and get something similar through composition Identifier case sets visibility: not obvious but easy to grasp package geometry // point is not exported type point struct { X, Y int; // X and Y are public name string; } Unicode and UTF-8 handled seamlessly
strangers on the Internet gofmt enforce Go's own PEP8 Type inference saves some typing but is not obiquitous In general, the scarce amount of language features keeps the code simple
to do it The most deceived aphorism of the Zen. How do you write concurrent code? Python : threads, coroutines, generators, tasks, asyncio, futures, twisted, tornado Go : two letters and a space character: go
of those! Packages are like modules but with only one obvious way to use them No way you can do: from foo import bar ...even if you can do: from foo import * (import . "lib/math") Separation of package path ("math/big") from package name (big) package big // ... import "math/big" Impacts on program design, build, testing...
5-25x faster than CPython Go is about 4-10x faster than PyPy PyPy can solve most of the performance issues for the average Pythonista without the costs to learn a new language and migrate old code.
land of Gophers! Let's learn Go, it's easy and it's fun Compute costs and benefits before migrating an entire codebase Sometimes rewriting parts of a Python project in Go can be enough to boost performances Choose the right tool for the job: an e-commerce site written in Go is not fast nor scalable, it's a self-inflicted pain trying to stick a websocket server into a Django project can be cause of death