The Lead Developer: Go – I made all the mistakes so you don't have to
Sep. 11, 2015•0 likes
2 likes
Be the first to like this
Show More
•1,656 views
views
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
Download to read offline
Report
Software
A talk about Go showing mistakes to be avoided when coming from other languages, discussion about strengths, and perceived shortcomings like dependency management.
Hello, I’m James.
A Technical Architect at GDS is the developer that goes to all the meetings.
I work in the civil service, so a lot of you pay my wages. Thank you!
If I’d know Ben was doing that, I would have used Emacs.
Originally this was going to be a description of journey and mistakes I had made in my code. Less likely to offend people if I point out my own stupidity.
Then I realised I had 10 minutes. Well, architects like to say that constraints are a good thing, so I've hopefully come up with a more useful thing in this way.
The talk has 4 main parts
Comes from the creators at Google sitting around waiting for C++
apps to build.
Target Windows, OSX, Linux, Plan 9, Android, iOS
So what are the core ideas in Go?
CS paper from 1978
Three main ideas
Modelling computation as mutually cooperating processes which participate in events
Go give you both. Concurrency via the goroutines in the language, which model a process, and the IO scheduler in the runtime which distributes those goroutines across all of the cores of the CPU.
So in CSP, communication and synchronisation are equivalent. You communicate by passing messages, not by sharing memory.
Go doesn’t have that.
Why is that so good? That’s the interesting thing.
There is a tool called gofmt which you run on your code.
With that defined as part of the language, formatting arguments go away.
No more fighting over style guides.
But the other things this enables. Call graphs…
Martin Fowler wrote a thing nearly 15 years ago.
In it, he proposes that Extract Method is the minimum height requirement for being a decent refactoring tool. To implement extract method, you need an AST.
The AST for Go is in the language. So tools can be written in Go to manipulate Go.
Sun and later Oracle have worked really hard to maintain backward compatibility for Java.
Guarantee for 1.x. It should just work.
Go sidesteps this, by having tooling.
gofix gives migrations for code
As a modern language, Go has testing in the stdlib. Other libraries are available.
Tests are fast. That’s a great feedback loop which doesn’t interrupt your flow
You can also get code coverage, so that you get detailed information on what is being tested, and make sensible decisions about making the investment in tests.
Here is an HTML version of the coverage, showing me exactly which lines are and aren’t tested.
Although using red and green might not be great from an a11y perspective…
Look at the ns/op
Improved that particular bit of code by 20%
What is dominating the runtime of my application?
Where is all the memory being used?
Recently released Go 1.5 introduced GC intended for next 10 years of hardware and beyond.
Currently you might develop on a quad-core machine, and then deploy to 16-core machines in production. CPUs are only getting wider.
Now concurrent, so reduces the time to do collections.
Here is a graph showing garbage collection pauses over time.
When your application is paused, doing garbage collection, it’s not doing useful work. This is Not Good.
Pauses have gone from 300ms to less than 30ms
https://twitter.com/brianhatfield/status/634166123605331968
Heroku has first-class support.
Travis has first-class support.
AWS has an SDK for it.
So often language conferences will try to fill up the schedule to address the thing they’re most uncomfortable about.
So Clojure confs have lots of talks about people running it in production (hi Bruce!)
Most software developers don’t work at Google. Google has all source code in a monolithic repository. This works for them. Go is open source, and exists outside of Google. So the Go curators didn’t enforce Google’s conventions on the world. They’ve waited for people to explore the problem.
There are a bunch of things (that work currently)
Community have built their own. Not blocked on Google to innovate.
Not a C++ killer, despite intention. People seem to be migrating from Ruby / Python instead.
I think Rust is more likely to supplant new development for C++, see Dan's talk later.
Emerging language for cloud infrastructure. Small tools that do one thing well. etcd. Hashicorp. Packer, Consul, Terraform. hub for Github, Heroku Toolbelt. CloudFlare.
CSP is really powerful (and as someone that doesn’t have a CS degree, Comp Sci isn’t scary)
Fantastically great tooling, which is getting better!