It seems like Python Frameworks like to distinguish from Development Server and Production Server. To deploy Flask / Django projects on production, we have to use some Different server, for example Apache or Nginx.
Django's Official Documentation:
DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through security audits or performance tests. (And that’s how it’s gonna stay. We’re in the business of making Web frameworks, not Web servers, so improving this server to be able to handle a production environment is outside the scope of Django.)
Flask's Official Documentation:
While lightweight and easy to use, Flask’s built-in server is not suitable for production as it doesn’t scale well and by default serves only one request at a time. Some of the options available for properly running Flask in production are documented here.
However, when it comes to go-lang, the story is different. Reddit, Stackoverflow, Quora etc. almost everywhere; community says that net/http libraries of go-lang is well built. We do not need Apache or Nginx to serve webpages when using go-lang.
So, what's the catch here? Does Python lack decent libraries or feature, as a result frameworks do not like to provide production server? Or, is it the other way around? go-lang forgot to put disclaimer on their documentation? I am very confused at this point? Please, share your knowledge regarding this issue.
Disclaimer: I know go-lang is not a thing, It should be Go. But sometimes the name gets confused with verb. So, I am using go-lang here.
Software Engineer At Hasura, Hashnode Alumnus
Without trying to dig into more reason, the first obvious one which came to mind is the poor multi-threading support in Python (and don’t get me wrong, I love Python), and how one has to deal with the global interpreter lock and everything... which is why usually (e.g. Django or Flask) delegate that os-thread management to some external resource (let’s call it a supervisor). A very good example is Gunicorn . It acts as an adapter, exposing WSGI interface (so that you can use it with NGINX of other frontends), and manages your Python for you (e.g. start multiple times the flask app in different threads)
There might be many other good reasons. But this first one is already enough for me ;-) (And that’s where the great built-in concurrency features of Go let you do that stuff without having to delegate it)
I'm not sure what the actual reasons are, but I can imagine people aren't very eager to invest time replicating all the work that went into Apache or Nginx by implementing the same in Python.
Those existing solutions are well-tested, feature-rich and fast. Just use them. It'd be a massive waste of time for every web framework to ship it's own web server.
The Django quote you gave tries to highlight that a web framework and a webserver are different things and that they don't want to include the later in the former.
> We’re in the business of making Web frameworks, not Web servers
I'm not sure why Go didn't go with that approach, because I'm not an active Go user. Does it have good https support? Load balancing? IPv6? Static file caching?
One reason that it is more desirable to offload web server work in Python than in Go is, of course, that Go is typically faster. In Python you'd not only losing a lot of development time, but also performance. In Go it's just the time.
Aravind
As Sébastien Portebois mentioned the Global Interpreter Lock (GIL) is the main caveat. Say you are running your application on a modern multicore server but GIL effectively makes it a single-threaded program. here is a good talk about it.
On the other hand Languages like Go is new. It is built for exploiting modern hardware. Programs written in go can effectively utilize modern multicore processors. It makes writing concurrent programs very easy and straight forward. Go was built for solving problems at Google scale and particularly for writing software like Loadbalancers and Servers. There are projects like caddy which uses the standard library and add a whole lot of features and best practices on top of it.