often hear “PHP / Python / Node doesn’t scale” - they do. • Scaling is more dependent on optimization in data structure and algorithms, good design and architecture. • Example: The case of image upload and horizontal scaling - Disk vs S3 • Go does some things well but Go is not the silver bullet or magic wand.
scaling our servers • Horizontal ◦ Maintains a pool of servers ◦ Add more servers to scale up ◦ Multiple servers share distributed load • Vertical ◦ Add more power to the server to scale up ◦ Upgrade CPU / RAM / DISK etc ◦ One powerful server does it all
X? • Will it scale nicely across your team? • Will they be able to learn it if it’s new to them? If your team is well versed in an existing technology, you should really really think through before introducing a new technology.
Created at Google by some serious talents. Just look up their credentials. • It’s lead by a team at Google but accepts open source contributions. • Google needed a language that could take benefits of multi core cpu but easy to use • The language is small, quite easy to comprehend - (mostly) beginners friendly
It has a very exciting and efficient approach to managing concurrency. • Compiled, quite fast, produces a single binary file, statically typed • Community is pretty decent, adequate resources, lots of open source packages • Lots of success stories of large orgs using it for handling tons of requests Go was intended for system programming, but here we are, building web apis and microservices
using the CPU continuously, for example calculating a prime number. Parallelism is crucial for running operations simultaneously. • IO Bound operations execute some stuff and then wait for IO to finish, for example, reading a file or making a network requests. Concurrency without parallelism would be better suited.
Multi processing - good for CPU bound tasks, but what about network requests? • Asyncio - complex but good, but needs time for adaption Node • Event loop model works well but single threaded - there are ways to use multiple cores but I didn’t like them. • JavaScript, do I need more reasons? • I don’t like the npm eco system - too many modules
cpu efficient - handles a lot of operations • Superior concurrency - can handle a lot of concurrent requests • Single binary - easy to deploy Team: • Simple language, easy to learn • Statically typed nature makes code more comprehensible • There’s only one standard for code formatting • Fixed conventions make it easier to document code • Boring language - no fancy mumbo jumbo, no big brain oneliners - one way to do things
cases. Ask yourself • Do we need the cost saving vs efforts? • Is it going to make the code cleaner / better in anyways? • Is the performance going to be significantly better? • Is the language / framework the bottleneck? (Or the database?)