Flask vs Go: What are the differences?
Flask: a microframework for Python based on Werkzeug, Jinja 2 and good intentions. Flask is intended for getting started very quickly and was developed with best intentions in mind; Go: An open source programming language that makes it easy to build simple, reliable, and efficient software. Go is expressive, concise, clean, and efficient. Its concurrency mechanisms make it easy to write programs that get the most out of multicore and networked machines, while its novel type system enables flexible and modular program construction. Go compiles quickly to machine code yet has the convenience of garbage collection and the power of run-time reflection. It's a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language.
Flask belongs to "Microframeworks (Backend)" category of the tech stack, while Go can be primarily classified under "Languages".
"Lightweight", "Python" and "Minimal" are the key factors why developers consider Flask; whereas "High-performance", "Simple, minimal syntax" and "Fun to write" are the primary reasons why Go is favored.
Flask and Go are both open source tools. It seems that Go with 59.6K GitHub stars and 8.25K forks on GitHub has more adoption than Flask with 44.8K GitHub stars and 12.6K GitHub forks.
According to the StackShare community, Go has a broader approval, being mentioned in 892 company stacks & 589 developers stacks; compared to Flask, which is listed in 502 company stacks and 509 developer stacks.
What is Flask?
What is Go?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
Sign up to add, upvote and see more consMake informed product decisions
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
Visual Studio Code worked really well for us as well, it worked well with all our polyglot services and the .Net core integration had great cross-platform developer experience (to be fair, F# was a bit trickier) - actually, each of our team members used a different OS (Ubuntu, macos, windows). Our production deployment ran for a time on Docker Swarm until we've decided to adopt Kubernetes with almost seamless migration process.
After our positive experience of running .Net core workloads in containers and developing Tweek's .Net services on non-windows machines, C# had gained back some of its popularity (originally lost to Node.js), and other teams have been using it for developing microservices, k8s sidecars (like https://github.com/Soluto/airbag), cli tools, serverless functions and other projects...
We've been a big fan of Python ever since we adopted it for my first startup, Ksplice. But it's been an absolutely ideal tool for Zulip, which is now one of the leading alternatives to Slack. Zulip is 100% open source software, with ~10K stars on GItHub. And being written in idiomatic Python has been really helpful for our open source project, because it's such an accessible language: Any programmer can learn Python quickly. And that means we're not restricted to e.g. "folks who are excited about contributing to Zulip and ALSO know Go".
I've linked to a blog post I wrote on Python's awesome new static type system, which fixes the main complaint one might have about using Python for a large codebase, which has a lot more perspective, as well as some commentary on our Python 3 migration.
Back at the start of 2017, we decided to create a web-based tool for the SEO OnPage analysis of our clients' websites. We had over 2.000 websites to analyze, so we had to perform thousands of requests to get every single page from those websites, process the information and save the big amounts of data somewhere.
Very soon we realized that the initial chosen script language and database, PHP, Laravel and MySQL, was not going to be able to cope efficiently with such a task.
By that time, we were doing some experiments for other projects with a language we had recently get to know, Go , so we decided to get a try and code the crawler using it. It was fantastic, we could process much more data with way less CPU power and in less time. By using the concurrency abilites that the language has to offers, we could also do more Http requests in less time.
Unfortunately, I have no comparison numbers to show about the performance differences between Go and PHP since the difference was so clear from the beginning and that we didn't feel the need to do further comparison tests nor document it. We just switched fully to Go.
There was still a problem: despite the big amount of Data we were generating, MySQL was performing very well, but as we were adding more and more features to the software and with those features more and more different type of data to save, it was a nightmare for the database architects to structure everything correctly on the database, so it was clear what we had to do next: switch to a NoSQL database. So we switched to MongoDB, and it was also fantastic: we were expending almost zero time in thinking how to structure the Database and the performance also seemed to be better, but again, I have no comparison numbers to show due to the lack of time.
As of now, we don't only use the tool intern but we also opened it for everyone to use for free: https://tool-seo.com
At Epsagon, we use hundreds of AWS Lambda functions, most of them are written in Python, and the Serverless Framework to pack and deploy them. One of the issues we've encountered is the difficulty to package external libraries into the Lambda environment using the Serverless Framework. This limitation is probably by design since the external code your Lambda needs can be usually included with a package manager.
In order to overcome this issue, we've developed a tool, which we also published as open-source (see link below), which automatically packs these libraries using a simple npm package and a YAML configuration file. Support for Node.js, Go, and Java will be available soon.
The GitHub respoitory: https://github.com/epsagon/serverless-package-external
We are hardcore Kubernetes users and contributors. We loved the automation it provides. However, as our team grew and added more clusters and microservices, capacity and resources management becomes a massive pain to us. We started suffering from a lot of outages and unexpected behavior as we promote our code from dev to production environments. Luckily we were working on our AI-powered tools to understand different dependencies, predict usage, and calculate the right resources and configurations that should be applied to our infrastructure and microservices. We dogfooded our agent (http://github.com/magalixcorp/magalix-agent) and were able to stabilize as the #autopilot continuously recovered any miscalculations we made or because of unexpected changes in workloads. We are open sourcing our agent in a few days. Check it out and let us know what you think! We run workloads on Microsoft Azure Google Kubernetes Engine and Amazon EC2 and we're all about Go and Python!
How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:
Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.
Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:
At Kong while building an internal tool, we struggled to route metrics to Prometheus and logs to Logstash without incurring too much latency in our metrics collection.
We replaced nginx with OpenResty on the edge of our tool which allowed us to use the lua-nginx-module to run Lua code that captures metrics and records telemetry data during every request’s log phase. Our code then pushes the metrics to a local aggregator process (written in Go) which in turn exposes them in Prometheus Exposition Format for consumption by Prometheus. This solution reduced the number of components we needed to maintain and is fast thanks to NGINX and LuaJIT.
Following its migration from vanilla instances with autoscaling groups to Kubernetes, Postmates began facing challenges while “migrating workloads that needed to scale up very quickly.”
The built-in Horizontal Pod Autoscaler (HPA) automatically scales the number of pods in a replication controller, deployment or replica set based on observed CPU utilization. But the challenges for Postmates is that there’s no way to configure the scale velocity of one particular cluster with an HPA.
For Postmates, which runs at least three different types of applications with distinct performance and scaling characteristics, this proved problematic.
To overcome these challenges, the team created and open sourced the Configurable Horizontal Pod Autoscaler, which allows for fine-grained tuning on a per-HPA object basis. The result is that “you can configure critical services to scale down very slowly, while every other service could be configured to scale down instantly to reduce costs.”
Unlike our frontend, we chose Flask, a microframework, for our backend. We use it with Python 3 and Gunicorn.
One of the reasons was that I have significant experience with this framework. However, it also was a rather straightforward choice given that our backend almost only serves REST APIs, and that most of the work is talking to the database with SQLAlchemy .
We could have gone with something like Hug but it is kind of early. We might revisit that decision for new services later on.
Go is a high performance language with simple syntax / semantics. Although it is not as expressive as some other languages, it's still a great language for backend development.
Python is expressive and battery-included, and pre-installed in most linux distros, making it a great language for scripting.
PostgreSQL: Rock-solid RDBMS with NoSQL support.
NATS: fast message queue and easy to deploy / maintain.
Docker makes deployment painless.
Git essential tool for collaboration and source management.
Our new backend micro services are primarily written in Node.js and Go and legacy systems are written in Java. For our new stack decision, we aimed to achieve greater developer productivity, low IO latency and good community so we had couple of technologies in hand to choose but finally we concluded to go for Node.js for API layer and Go for CPU/IO intensive tasks. Currently the inter-services communication is happening via REST but soon to be moved to RPC-based communication.
We have added very little to the CoffeeScript Hubot application – just enough to allow it to talk to our Hubot workers. The Hubot workers implement our operational management functionality and expose it to Hubot so we can get chat integration for free. We’ve also tailored the authentication and authorization code of Hubot to meet the needs of roles within our team.
For larger tasks, we’ve got an internal #CLI written in Go that talks to the same #API as Hubot, giving access to the same functionality we have in Slack, with the addition of scripting, piping, and all of our favorite #Unix tools. When the Hubot worker recognizes the CLI is in use, it logs the commands to Slack to maintain visibility of operational changes.
We are in the process of building a modern content platform to deliver our content through various channels. We decided to go with Microservices architecture as we wanted scale. Microservice architecture style is an approach to developing an application as a suite of small independently deployable services built around specific business capabilities. You can gain modularity, extensive parallelism and cost-effective scaling by deploying services across many distributed servers. Microservices modularity facilitates independent updates/deployments, and helps to avoid single point of failure, which can help prevent large-scale outages. We also decided to use Event Driven Architecture pattern which is a popular distributed asynchronous architecture pattern used to produce highly scalable applications. The event-driven architecture is made up of highly decoupled, single-purpose event processing components that asynchronously receive and process events.
To build our #Backend capabilities we decided to use the following: 1. #Microservices - Java with Spring Boot , Node.js with ExpressJS and Python with Flask 2. #Eventsourcingframework - Amazon Kinesis , Amazon Kinesis Firehose , Amazon SNS , Amazon SQS, AWS Lambda 3. #Data - Amazon RDS , Amazon DynamoDB , Amazon S3 , MongoDB Atlas
To build #Webapps we decided to use Angular 2 with RxJS
#Devops - GitHub , Travis CI , Terraform , Docker , Serverless
For the backend of https://www.rsvpkeeper.com I went with Go.
My past few project have been built with Go and I'm really loving it. It was my first statically typed language after many years with PHP and Node.js - and honestly I couldn't be happier to have made the switch.
The biggest thing for me, is that with the forced declaration of types - it's made me feel like I've made a more solid backend. Sometimes with PHP I felt like a stiff breeze could knock the whole thing down. I know that's an exaggeration - but it's kinda how it feels.
Anyways, everyone knows that it almost doesn't even matter what an app is actually made with - what really matters are the design decisions you make a long the way.
At FlowStack we write most of our backend in Go. Go is a well thought out language, with all the right compromises for speedy development of speedy and robust software. It's tooling is part of what makes Go such a great language. Testing and benchmarking is built into the language, in a way that makes it easy to ensure correctness and high performance. In most cases you can get more performance out of Rust and C or C++, but getting everything right is more cumbersome.
Flask is a light, yet powerful Python web framework perfect for quickly building smaller web applications. It's a "micro-framework" that's easy to learn and simple to use, so it's perfect for those new to web development as well as those looking to rapidly develop a web application.
The first time I actually started using Go was for software on our devices. So on our hotspots we have some custom software running in the firmware. For the first device, that was actually completely built by our manufacturer. But for the second generation most of the parts are built by us in-house and we needed a way to quickly develop software for the device. But we don't have any C programmers in-house, so we were actually looking for something that basically sits in between the friendliness of Ruby, but the performance and the ability to be deployed on an embedded system which you get with C. That's basically what led us to Go and it's been awesome for that. It works so well and so great. Since it works so great, it pushed us into looking into whether we should start using this for some backend services as well.
The following basic API endpoints are implemented on the server written in Go:
- Authorization (Sign Up, Sign In)
- Update user profile
- Community: add post, like post, add comment, delete post, add reply to comment
- Self-diagnosis: send data from the app to the server
- Journal: send user data from the app to the server
- Add groups of community
- Report post, report comment, report reply
- Block user
We wrote our own image processing, resizing, and snapshotting service in Go to allow our clients to send photos and GIFs to each other. Files are stored in S3, resized on the fly using OpenCV, and then cached in GroupCache before being served to clients.
Go allows it all to be quite fast and efficient, and entirely non-blocking on uploads!
Our main web scraping engine is built usign Golang because of the way how efficiently and fast this language is. Also out compilation facility let people who dont know Golang build fast as flash scrapers to run ourside of our platform without any knowledge in programming in Golang.
For some of our more taxing parts of our applications, something able to handle high I/O load quickly and with fast processing is needed. Go has completely filled that gap, allowing us to break down walls that would've been completely impossible with other languages.
I use Flask for times when I need to create a REST API that interfaces with other Python code, or there is no specific reason why I'd want to use Node.JS. I prefer Flask because of its small learning curve, allowing me to get started coding as quickly as possible
This lightweight web framework enables quick REST API development while enabling easy clustering, and the usage of multiple worker processes required to scale the REST API service to meet high volume requirements.
Service to query NOAA weather forecasts data and service to build tidal current forecast maps using AWS EC2 and Geoserver
Flask drives our APIs, both the Website APIs and the majority of the REST Messaging APIs