Go was first appeared on November 10th, 2009 designed by Rob Pike, Ken Thompson and Robert Griesemer. Go was introduced as a new system programming language with quick build times, great tooling, simple concurrency model, and a different approach to object-orientation.
Let’s dive deep, and look at what challenges we have as a backend developer and how Go can address them
Need for ‘Real-Time’
Front-end has evolved quickly, We now have browsers supporting service-workers, fetch, and sockets. Moreover, we have SPA’s ((Single Page Applications)[https://en.wikipedia.org/wiki/Single-page_application]), increasing the abstraction between front-end and back-end. Modern applications need real-time collaborations, deployment on various devices like mobile, desktop, and IoT devices and a ton of (traffic)[https://ourworldindata.org/grapher/internet-users-by-world-region]
This demands a back-end that is enabled to leverage multi-core processing prowess, cloud auto-scaling friendly as well as can handle a ton of traffic.
Given the symptoms above, Go seems a likely candidate; as it has goroutines, channels to provide lightweight and cheap (concurrency)[https://blog.golang.org/waza-talk] that can maintain a ton of socket connection without the much-added overhead. In simple terms, Go can address the (C10K)[https://en.wikipedia.org/wiki/C10k_problem] problem with available resources
Multicore Dilemma
Multicore processors are a reality since 2004 when the first x86 dual-core chips. In simple terms; the processing power of devices has evolved but technologies and tools used are not. Most technologies out there are still unable to leverage more than a single core at any given moment. Go enabled one to leverage underlying multi-core processors without much effort to put in. Go with goroutines are scalable, lightweight and cheaper than threads to acquire
Go has one straightforward model. It multiplexes goroutines onto OS threads (like actors in Erlang), and stacks grow as needed. Go not only addresses the C10K problem, but it also vroom past it!
Introduction to Microservices
Today applications rely on a number of external services: databases, caches, search, and message queues. Monolith applications are hard to maintain and not fault-tolerant. A fault in monolith application will most probably take down the entire application.
Microservices are lightweight, cheap and compartmentalized, hence a fault in a micro-service will still guarantee other services working fine. An application built as a collection of microservices is lightweight and easy to maintain and understand
Go implements asynchronous I/O so that our application can interact with any number of services without blocking other requests.
Advent of Cloud Computing
With the advent of cloud computing and auto-scaling, applications can easily be scaled on-demand, like turning a knob on and off. With a monolith enterprise-scale application written in scripting languages, auto-scaling virtual machines can take longer to come alive.
Application written in Go, being already compiled to machine-code could be loaded quickly to serve the increased demand. And broken into multiple micro-services could make it easier where the only service that is in demand being scaled not the entire application.
Fat Client Renaissance
With native mobile, SPA’s, HTML5 and Web Components, clients are doing more and servers are getting skinny. Modern applications are designed API first, built with the flexibility to support multiple clients, instead of one. Fat clients also able to reduce fat traffic over-the-wire, hence making requests more skinny and data-only oriented.
Go, as with excellent in-built tooling and abstraction, supports writing API’s and JSON out-of-the-box. This comes in handy in curating applications for the 21st century.
Concurrency
In a time when internet users are growing multifold like a highly contagious disease, we need backends that could serve this un-quenching thirst to serve more requests simultaneously or perform multiple i/o ops in parallel
Go channels provide a concurrency primitive comparable to the Erlang’s actors model. With actors we name the endpoints (mailboxes), whereas channels are the conduit.
Static Binaries
Go gets compiled into machine code making it faster than its VM and interpreted rivals, be it startup time or serving on the go. No more AOT and JIT lingo, just run and forget. Slow startup time, AOT and JIT, doesn’t just affect auto-scaling and server restarts. It can also be crippling in development.
Go applications compile quickly and launch immediately.
The Best of Both Worlds
Go provides type inference, hash maps (dictionaries), variable-length arrays, methods on any user-defined type, and implicitly satisfied interfaces. All without diverging far from the familiar syntax and semantics of C-like languages.
It compiles quickly without makefiles, integrates with Git for distributed package management, and auto-formats code with gofmt. Compilation makes a certain class of tests unnecessary, and code completion works really well thanks to gocode built into GoSublime and vim-go.
Go strikes a balance between dynamic and statically compiled languages. It’s fun and efficient. The best way to know if you’ll like Go is to dive in and get some first-hand experience. And then start building small and go from there
About The Author
I am Pankaj Baagwan, a System Design Architect. A Computer Scientist by heart, process enthusiast, and open source author/contributor/writer. Advocates Karma. Love working with cutting edge, fascinating, open source technologies.
To consult Pankaj Bagwan on System Design, Cyber Security and Application Development, SEO and SMO, please reach out at me[at]bagwanpankaj[dot]com
For promotion/advertisement of your services and products on this blog, please reach out at me[at]bagwanpankaj[dot]com
Stay tuned <3. Signing off for RAAM