360 lines
16 KiB
Plaintext
360 lines
16 KiB
Plaintext
[1]Jump to Content
|
||
[2]
|
||
Cloud
|
||
[4]Blog
|
||
[5]Contact sales [6]Get started for free
|
||
[7][ ]
|
||
[13]
|
||
Cloud
|
||
[14]Blog
|
||
|
||
• Solutions & technology
|
||
□ [15]AI & Machine Learning
|
||
□ [16]API Management
|
||
□ [17]Application Development
|
||
□ [18]Application Modernization
|
||
□ [19]Chrome Enterprise
|
||
□ [20]Compute
|
||
□ [21]Containers & Kubernetes
|
||
□ [22]Data Analytics
|
||
□ [23]Databases
|
||
□ [24]DevOps & SRE
|
||
□ [25]Maps & Geospatial
|
||
□ [26]Security & Identity
|
||
□ [27]Infrastructure
|
||
□ [28]Infrastructure Modernization
|
||
□ [29]Networking
|
||
□ [30]Productivity & Collaboration
|
||
□ [31]SAP on Google Cloud
|
||
□ [32]Storage & Data Transfer
|
||
□ [33]Sustainability
|
||
• Ecosystem
|
||
□ [34]IT Leaders
|
||
□ Industries
|
||
☆ [35]Financial Services
|
||
☆ [36]Healthcare & Life Sciences
|
||
☆ [37]Manufacturing
|
||
☆ [38]Media & Entertainment
|
||
☆ [39]Public Sector
|
||
☆ [40]Retail
|
||
☆ [41]Supply Chain
|
||
☆ [42]Telecommunications
|
||
□ [43]Partners
|
||
□ [44]Startups & SMB
|
||
□ [45]Training & Certifications
|
||
□ [46]Inside Google Cloud
|
||
□ [47]Google Cloud Next & Events
|
||
□ [48]Google Maps Platform
|
||
□ [49]Google Workspace
|
||
• [50]Developers & Practitioners
|
||
• [51]Transform with Google Cloud
|
||
|
||
[52]Contact sales [53]Get started for free
|
||
[54][ ]
|
||
Application Modernization
|
||
|
||
Why I love Go
|
||
|
||
September 12, 2022
|
||
|
||
• [60]
|
||
• [61]
|
||
• [62]
|
||
• [63]
|
||
|
||
David Yach
|
||
|
||
Director of Engineering at Google Cloud
|
||
|
||
I’ve been building software over the last four decades, as a developer, manager
|
||
and executive in both small and large software companies. I started my career
|
||
working on commercial compilers, first BASIC and then C. I have written a lot
|
||
of code in many different languages, and managed teams with even broader
|
||
language usage.
|
||
|
||
I learned Go about 5 years ago when I was CTO at a startup/scaleup. At the
|
||
time, we were looking to move to a microservice architecture, and that shift
|
||
gave us the opportunity to consider moving away from the incumbent language
|
||
(Scala). As I read through the Go tutorials, my compiler-writing background
|
||
came back to me and I found myself repeatedly thinking “That’s cool – I know
|
||
why the Go team did that!” So I got hooked on the language design.
|
||
|
||
Learning
|
||
|
||
I have worked with many different computer languages over the years, so I was
|
||
not surprised I could quickly get started writing Go programs after reading
|
||
through the online documents and tutorials. But then when I saw a new co-op
|
||
student (a.k.a. intern) learn Go and write a substantial prototype in their
|
||
first two weeks on the job, it became clear that Go was much easier to learn
|
||
than many other languages.
|
||
|
||
Writing code
|
||
|
||
As I started writing my first Go programs, the first thing that struck me was
|
||
the blazing compiler speed. It was as fast or faster starting my application
|
||
than many interpreted languages, yet it was a compiled program with a strongly
|
||
typed language. (I have an affinity for strongly typed languages – I have spent
|
||
way too much time tracking down obscure issues in my own code in dynamic typed
|
||
languages, where the same issue would have been a compile error in a strongly
|
||
typed language.) Even better, in Go I often don’t need to declare the type –
|
||
the compiler figures it out.
|
||
|
||
I was impressed with the standard Go library – it included many of the
|
||
capabilities required by modern applications – things like HTTP support, JSON
|
||
handling and encryption. Many other languages required you to use a third-party
|
||
library for these features, and often there were multiple competing libraries
|
||
to choose from, adding another decision point for the developer. With Go, I
|
||
could go to the standard library GoDoc and get started right away.
|
||
|
||
There were a few other language decisions that I found helpful. One is that the
|
||
compiler figures out if you are returning a pointer to a local, and behind the
|
||
scenes allocates the memory rather than using the stack. This prevents bugs,
|
||
and I find the code more readable.
|
||
|
||
I also like that you don’t declare that you support an interface. I wasn’t sure
|
||
I would like this at first because it isn’t obvious if a type implements a
|
||
particular interface, but I found greater value in the fact that I wasn’t
|
||
dependent on the code author (even if it was me!) to declare that the interface
|
||
is implemented. This first hit home when I used fmt.Println() and it
|
||
automatically used the String() method I had implemented even though it hadn’t
|
||
occurred to me that I was implementing the Stringer interface.
|
||
|
||
The last feature I’ll note is the ability to do concurrent programming through
|
||
channels and goroutines. The model is simple to understand yet powerful.
|
||
|
||
Reading code
|
||
|
||
After writing more Go code and starting to incorporate third party libraries, I
|
||
had a realization that had never occurred to me before – as a developer, I
|
||
spend a lot of time reading code. In fact, I probably spend more time reading
|
||
code than writing it, once you start counting code reviews, debugging, and
|
||
evaluating third-party libraries.
|
||
|
||
What was different about reading Go code? I would summarize it by “it all looks
|
||
the same.” What do I mean by that? Go format ensures all the braces are in the
|
||
same spot; capitalized identifiers are exported; there are no implicit
|
||
conversions, even of internal types; and there is no overloading of operators,
|
||
functions or methods. That means that with Go code, “what you see is what you
|
||
get” with no hidden meaning. Of course, it doesn’t help me to understand a
|
||
complicated algorithm, but it does mean that I can concentrate more on that
|
||
algorithm because I don’t have to understand whether ‘+’ is overloaded, for
|
||
example.
|
||
|
||
I was also pleasantly surprised when I used GoDoc on one of my projects, and
|
||
discovered that I had semi-reasonable documentation without doing anything
|
||
while writing the code other than adding comments on my functions and methods
|
||
based on nagging from the IDE I was using. I did spend some time cleaning up
|
||
the comments after that, but I’m not sure I would have even started that work
|
||
if Go hadn’t given me a great starting point.
|
||
|
||
Testing code
|
||
|
||
Go test is part of the standard Go tools and supported by IDEs, making it easy
|
||
to get started creating unit tests for my code. And like the standard Go
|
||
library, having a standard way to do tests means I don’t have to evaluate
|
||
external testing frameworks and select one. I can also understand the tests
|
||
when I’m evaluating a third party library.
|
||
|
||
Even better, the default behavior running package tests in VSCode is to enable
|
||
Go’s built-in code coverage. I had never taken code coverage seriously working
|
||
in other languages, partly because it was often difficult to set up. But the
|
||
immediate feedback (helped by the blazing compile speed) gamified this for me,
|
||
and I found myself adding tests to increase code coverage (and finding new bugs
|
||
along the way).
|
||
|
||
Go doesn’t allow circular dependencies between packages. While this has caused
|
||
me some rethinking while writing code, I find it makes my testing regimen
|
||
easier to think about – if I depend on a package, I can rely on that package to
|
||
have its own tests covering its capabilities.
|
||
|
||
Deploying code
|
||
|
||
I learned Go at the same time we were migrating towards container-based
|
||
microservices. In that environment, the fact that Go produces a single,
|
||
self-contained executable makes it much easier and more efficient to build and
|
||
manage containers. I can build a container layer with one single file, which is
|
||
often a single-digit number of MB in size, compared to our prior JVM-based
|
||
containers which started with hundreds of MB for the Java runtime then another
|
||
layer for our application. (It is easy to forget how much this overhead ends up
|
||
costing in production, particularly if you have hundreds or thousands of
|
||
containers running).
|
||
|
||
Second, Go has built-in cross compiling capabilities so our development
|
||
machines, containers and cloud hardware don’t all have to all be on the same
|
||
processor or operating system. For example, I can use a Linux build machine to
|
||
produce client executables for Linux, Mac and Windows. Again, this takes away a
|
||
complicated decision process due to artificial constraints.
|
||
|
||
Finally, Go has established a well defined set of principles for versioning and
|
||
compatibility. While not all pieces of this are enforced, having the principles
|
||
from an authoritative source helps manage the real life challenges of keeping
|
||
your software supply chain up to date. For example, it is strongly recommended
|
||
that breaking changes require a new major version number. While not enforced,
|
||
it leads the community to call out any open source package that violates this
|
||
principle.
|
||
|
||
What do I miss?
|
||
|
||
I did miss generics; thankfully Go 1.18 added support. And I do wish the
|
||
standard library offered immutable collections (like Scala and other functional
|
||
languages). Embedding instead of inheritance works pretty much the same in many
|
||
cases, but requires some deep thinking sometimes.
|
||
|
||
My most frequent coding mistake is when I should have used a pointer receiver
|
||
for a method and didn’t, then modify the receiver expecting the changes to be
|
||
visible when the method returns. The code looks correct, the right values get
|
||
assigned if I use a debugger to step through or issue prints, but the changes
|
||
disappear after the method returns. I think I would have preferred if receivers
|
||
were immutable, it would have caught these errors at compile time, and in the
|
||
few remaining cases where I wanted to modify the receiver I would have copied
|
||
it to a local variable.
|
||
|
||
In conclusion
|
||
|
||
As you can tell, I am a huge fan of Go, from even before I joined Google. I am
|
||
impressed by the language and ecosystem design, and by the implementation. For
|
||
me, Go makes me a more productive developer and I’m more confident in the
|
||
quality of the code I produce.
|
||
|
||
Go, give it a [64]try!
|
||
|
||
Posted in
|
||
|
||
• [65]Application Modernization
|
||
• [66]Application Development
|
||
• [67]Open Source
|
||
|
||
Related articles
|
||
|
||
[68]
|
||
https://storage.googleapis.com/gweb-cloudblog-publish/images/
|
||
containers_2022_anH39my.max-700x700.jpg
|
||
DevOps & SRE
|
||
|
||
Best practices for consuming public Docker Hub content
|
||
|
||
By Rishi Mukhopadhyay • 2-minute read
|
||
|
||
[69]
|
||
https://storage.googleapis.com/gweb-cloudblog-publish/images/
|
||
General-GC_Blog_header_2436x1200-v1.max-700x700.jpg
|
||
Google Cloud
|
||
|
||
The overwhelmed person’s guide to Google Cloud: week of Dec 18
|
||
|
||
By Forrest Brazeal • 2-minute read
|
||
|
||
[70]
|
||
https://storage.googleapis.com/gweb-cloudblog-publish/images/
|
||
Google_Cloud_AIML_thumbnail.max-700x700.jpg
|
||
AI & Machine Learning
|
||
|
||
Have the AI build your app for you!
|
||
|
||
By Max Saltonstall • 2-minute read
|
||
|
||
[71]
|
||
https://storage.googleapis.com/gweb-cloudblog-publish/images/
|
||
DO_NOT_USE_Wfx45fA.max-700x700.jpg
|
||
Application Modernization
|
||
|
||
Apollo24|7: Migrating a complex microservices application to Google Cloud with
|
||
zero downtime
|
||
|
||
By Nishu Saxena • 4-minute read
|
||
|
||
Footer Links
|
||
|
||
Follow us
|
||
|
||
• [72]
|
||
• [73]
|
||
• [74]
|
||
• [75]
|
||
• [76]
|
||
|
||
[77]
|
||
|
||
• [78]Google Cloud
|
||
• [79]Google Cloud Products
|
||
• [80]Privacy
|
||
• [81]Terms
|
||
• [82]Cookies management controls
|
||
|
||
• [83]Help
|
||
• [84][Language ]
|
||
|
||
|
||
References:
|
||
|
||
[1] https://cloud.google.com/blog/#content
|
||
[2] https://cloud.google.com/
|
||
[4] https://cloud.google.com/blog
|
||
[5] https://cloud.google.com/contact/
|
||
[6] https://console.cloud.google.com/freetrial/
|
||
[13] https://cloud.google.com/
|
||
[14] https://cloud.google.com/blog
|
||
[15] https://cloud.google.com/blog/products/ai-machine-learning
|
||
[16] https://cloud.google.com/blog/products/api-management
|
||
[17] https://cloud.google.com/blog/products/application-development
|
||
[18] https://cloud.google.com/blog/products/application-modernization
|
||
[19] https://cloud.google.com/blog/products/chrome-enterprise
|
||
[20] https://cloud.google.com/blog/products/compute
|
||
[21] https://cloud.google.com/blog/products/containers-kubernetes
|
||
[22] https://cloud.google.com/blog/products/data-analytics
|
||
[23] https://cloud.google.com/blog/products/databases
|
||
[24] https://cloud.google.com/blog/products/devops-sre
|
||
[25] https://cloud.google.com/blog/topics/maps-geospatial
|
||
[26] https://cloud.google.com/blog/products/identity-security
|
||
[27] https://cloud.google.com/blog/products/infrastructure
|
||
[28] https://cloud.google.com/blog/products/infrastructure-modernization
|
||
[29] https://cloud.google.com/blog/products/networking
|
||
[30] https://cloud.google.com/blog/products/productivity-collaboration
|
||
[31] https://cloud.google.com/blog/products/sap-google-cloud
|
||
[32] https://cloud.google.com/blog/products/storage-data-transfer
|
||
[33] https://cloud.google.com/blog/topics/sustainability
|
||
[34] https://cloud.google.com/transform
|
||
[35] https://cloud.google.com/blog/topics/financial-services
|
||
[36] https://cloud.google.com/blog/topics/healthcare-life-sciences
|
||
[37] https://cloud.google.com/blog/topics/manufacturing
|
||
[38] https://cloud.google.com/blog/products/media-entertainment
|
||
[39] https://cloud.google.com/blog/topics/public-sector
|
||
[40] https://cloud.google.com/blog/topics/retail
|
||
[41] https://cloud.google.com/blog/topics/supply-chain-logistics
|
||
[42] https://cloud.google.com/blog/topics/telecommunications
|
||
[43] https://cloud.google.com/blog/topics/partners
|
||
[44] https://cloud.google.com/blog/topics/startups
|
||
[45] https://cloud.google.com/blog/topics/training-certifications
|
||
[46] https://cloud.google.com/blog/topics/inside-google-cloud
|
||
[47] https://cloud.google.com/blog/topics/google-cloud-next
|
||
[48] https://cloud.google.com/blog/products/maps-platform
|
||
[49] https://workspace.google.com/blog
|
||
[50] https://cloud.google.com/blog/topics/developers-practitioners
|
||
[51] https://cloud.google.com/transform
|
||
[52] https://cloud.google.com/contact/
|
||
[53] https://console.cloud.google.com/freetrial/
|
||
[60] https://twitter.com/intent/tweet?text=Why%20I%20love%20Go%20@googlecloud&url=https://cloud.google.com/blog/products/application-modernization/why-david-yach-loves-go
|
||
[61] https://www.linkedin.com/shareArticle?mini=true&url=https://cloud.google.com/blog/products/application-modernization/why-david-yach-loves-go&title=Why%20I%20love%20Go
|
||
[62] https://www.facebook.com/sharer/sharer.php?caption=Why%20I%20love%20Go&u=https://cloud.google.com/blog/products/application-modernization/why-david-yach-loves-go
|
||
[63] mailto:?subject=Why%20I%20love%20Go&body=Check%20out%20this%20article%20on%20the%20Cloud%20Blog:%0A%0AWhy%20I%20love%20Go%0A%0ALearn%20all%20the%20reasons%20David%20Yach,%20industry%20veteran%20and%20Director%20of%20Engineering%20at%20Google%20Cloud,%20loves%20to%20use%20Go%20for%20software%20development.%0A%0Ahttps://cloud.google.com/blog/products/application-modernization/why-david-yach-loves-go
|
||
[64] https://go.dev/tour/list
|
||
[65] https://cloud.google.com/blog/products/application-modernization
|
||
[66] https://cloud.google.com/blog/products/application-development
|
||
[67] https://cloud.google.com/blog/products/open-source
|
||
[68] https://cloud.google.com/blog/products/devops-sre/using-authenticated-logins-for-docker-hub-in-google-cloud
|
||
[69] https://cloud.google.com/blog/products/gcp/the-overwhelmed-persons-guide-to-google-cloud
|
||
[70] https://cloud.google.com/blog/products/ai-machine-learning/have-duet-ai-make-your-next-app-using-conversation
|
||
[71] https://cloud.google.com/blog/products/application-modernization/migrating-a-microservices-application-with-no-downtime
|
||
[72] https://www.twitter.com/googlecloud
|
||
[73] https://www.youtube.com/googlecloud
|
||
[74] https://www.linkedin.com/showcase/google-cloud
|
||
[75] https://www.instagram.com/googlecloud/
|
||
[76] https://www.facebook.com/googlecloud/
|
||
[77] https://cloud.google.com/
|
||
[78] https://cloud.google.com/
|
||
[79] https://cloud.google.com/products/
|
||
[80] https://myaccount.google.com/privacypolicy?hl=en-US
|
||
[81] https://myaccount.google.com/termsofservice?hl=en-US
|
||
[82] https://cloud.google.com/blog/#
|
||
[83] https://support.google.com/
|