Language choice is among the most expensive strategic decisions a technical leader will make, and many CTOs choose to delegate it.

Every technical leader knows the pain: your team is debating languages, everyone has data, much of it conflicts, and somehow a decision that will determine 40-60% of your development costs is being made based on whoever argues most passionately.

There’s a reason these conversations feel broken. We’re having thewrong conversation entirely. We debate technical features when we should be evaluating economic impact. We argue about what languages can do when we should be measuring what they will cost.

In my roles at MongoDB, Docker, and Google, I’ve watched hundreds of companies treat programming language choice as a purely technical decision, often made by the engineering team, sometimes inherited from history. Given everything else a CTO has to worry about, it often seems like a decision best delegated to the team.

That made sense when language choice was mostly about whether a language could do the job. But today languages have matured to the point where many languages could accomplish most tasks, the question isn’t “could” but “is the right choice considering all the economic factors”.

The choice of language determines how expensive the job will be, how long it will take, and how reliable the result will be. Language choice has become a deeply strategic decision, one that requires moving the conversation from preference to performance, from opinion to economics.

We need a framework that makes invisible costs visible and ensures we’re evaluating what actually determines success: not which language your team prefers, but which language your business can afford.Part 1 of this series unpacked the emotional and identity drivers that keep teams stuck in the old debate; this post unveils the economic counterweight.

The Nine Cost Factors

I started developing this framework during my time as product lead of Google’s Languages, Optimizations, and Libraries team, then refined it over several years working with dozens of companies facing exactly this decision. It evaluates the total lifecycle cost of a programming language across nine critical dimensions, organized into three domains:

• What it costs to build
• What it costs to run
• The externalities that compound over time

This framework won’t prescribe a single right answer, your context determines that. But it will ensure you’re evaluating the right variables across your project’s full lifecycle, not just the features that make for passionate debates.

Core Development (Factors 1–3)

Shipping & Operating (Factors 4–6)

External Forces (Factors 7–9)

Did I miss something or get it wrong? Join the conversation onX,Bluesky, orLinkedIn.

This framework is a living document. As languages evolve and new considerations emerge, the factors may be updated to reflect current realities.

The Leadership Blindspot: How Identity Drives Multi-Million Dollar Technical Debt

A programming language is the single most expensive choice a company makes, yet we treat it like a technical debate. After watching this mistake bankrupt dozens of companies and hurt hundreds more, I’ve learned the uncomfortable truth: these decisions are rarely about technology. They’re about identity, emotion, and ego, and they’re destroying your velocity and budget in ways you can’t see until it’s too late.

Early in my career, I worked at Takkle, a promising social network. A sudden departure vaulted me from lead engineer to VP of Engineering, leading a team of 12. While we were delivering on all our goals, I was in my early 20s and lacked experience, a risk our board wanted to fix. They pressured our CEO to recruit a CTO with more experience. I looked forward to learning from him; he was a well known figure in the Perl community and arrived with a stack of O’Reilly “camel” books.

One of his first acts was to pronounce our language, PHP, the wrong choice. He decreed a switch to Perl. This decree happened after what felt to me like a sham analysis comparing PHP and Perl.

Our velocity collapsed. Our team had to not only learn a new language but rebuild from scratch, delaying our product by nine months. Our monthly burn rate jumped from $200K to $500K as we more than doubled our size to make up for the lost velocity while building the new Perl based system, which halved our runway.

Our CTO did deliver, at least on some of his promises. We built a beautiful system, one I was truly proud of. But it was too late. By the time we finally launched, the market opportunity had vanished. Facebook had now expanded beyond colleges, and we were at the end of our monitary runway. The increased spend had shortened our runway by half, and we didn’t have enough momentum with the new site to reach the milestones required to raise more money.

I’ve often wondered: What if we had just stuck with PHP? We had a fine system and real momentum. We would have launched much earlier at a fraction of the cost. PHP was good enough for Facebook; why not us?

But the question that haunted me was:Why did such an experienced leader make such an terrible mistake?

The Pattern Repeats

As my career progressed I saw this same pattern over and over. As Languages Product Lead at Google, my group included C++, Java, Go, and Python. At MongoDB, I managed teams writing in 13 different languages. In both places I saw brilliant engineers arguing past each other, armed with conflicting data, all of it true, but none of it complete. At Google Cloud, I saw these same challenges across our customers.

Fast forward two decades from Takkle, and I had déjà vu. I watched as a VP of Engineering presented to leadership why his team needed to build their next system in Rust. The presentation eerily paralleled that Takkle experience. In that old presentation, nearly every reason the CTO gave for Perl was truer of PHP at the time. Now, every single reason given for choosing Rust in this presentation, Go was objectively better at. As an example: they cited “easy build and deploy” as a Rust advantage. It’s true that this is a strength of Rust, but Go’s nearly instant cross compilation and single static binary is even stronger than Rust in this specic critera with Rust’s very long build times.

It’s not that I think they should have chosen Go, Go would have been the wrong choice for their situation, and I believe Rust was the right choice. But what struck me was how broken their reasoning was. If they were making a logical argument, surely they would have considered Go and in doing so with their presented criteria they would have realized Go was a better option and, at the very least, refined their critera.

I pulled the VP aside after the meeting. “Walk me through how you evaluated other language candidates,” I said. His face went blank. “We… didn’t really look at any others,” he admitted. “Everyone’s talking about Rust.” There it was: a 50 million dollar decision made on hype, about to be green lit.

For me this was the moment of epiphany, finally an answer to the question for the beginning of my career. The presentation didn’t share an analysis, they hadn’t done one; it was a justification for a choice already made. This was a decision based purely on hype, emotion, and identity.

Every Technical Debate Is Really Two Conversations

In every language discussion, two conversations are happening simultaneously.

The Visible Conversation: “Rust has memory safety without garbage collection.” “Go has faster compile times and easier deployment.” “Python has the richest ML ecosystem.”

The Invisible Conversation: “I am a Rust programmer.” “I want to become a Rust programmer.” “I cannot imagine being someone who doesn’t choose Rust.”

If you just read that and thought “well, my last language choice was different, I was being rational,” your invisible conversation is running right now, defending itself while you read this sentence.

My CTO at Takkle was having the invisible conversation. Every point in his visible Perl analysis was technically true, but it felt like a sham because it was only there to cover the much deeper invisible conversation. He wasn’t evaluating languages. He was protecting an identity he’d spent a decade building. What our company paid $300K per month extra for wasn’t better architecture or faster hiring. We paid for the opportunity for him to be a Perl CTO instead of a PHP CTO. That was the real transaction. The rebuild was just the payment plan.

That VP’s Rust presentation listed “easy build and deploy” as an advantage, technically true, but Go is objectively better on that specific criterion. If they were truly having the visible conversation, they would have caught that. They would have at least considered Go in their analysis.

They hadn’t. Because they weren’t having that conversation at all. And they were about to spend $50 million on the invisible one.

We’ve Built Our Industry Around the Wrong Conversation

We call ourselves Pythonistas, Gophers, Rustaceans, we wear these labels like badges, sometimes we even wear literal badges (t-shirts, stickers, etc). There’s a reason so many of our surnames come from people’s crafts: Potter, Smith, Brewer. What we do becomes who we are. What looks like decorative labels are really decision making frameworks that operate beneath conscious thought.

We’ve built our entire industry around thevisible conversation. We train engineers to debate technical merits. We create decision frameworks based on feature matrices. We think if we just gather enough benchmarks and case studies, we’ll make the right choice.

But theinvisible conversation is much stronger. It’s why my CTO chose Perl. It’s why that VP chose Rust. And it’s operating in your next language decision right now, invisible and unexamined.

The moment you hire a Rust developer to evaluate languages, you’ve already chosen Rust. You’ve just added a $2 million feasibility study to make the predetermined decision feel rational.

The Real Cost

The question isn’t whether this bias exists, the science is conclusive. The real question is: can you afford to let it make your decisions?

Because the invisible conversation has a price tag. Industry research suggests that technology stack decisions account for 40-60% of total development costs over a product’s lifecycle.Research by Stripe found that developers spend 42% of their time on technical debt. When you let identity drive that decision you’re mortgaging your velocity, your budget, and your runway to pay for someone’s sense of self.

The visible conversation is about technology. The invisible conversation is about identity. And the invisible conversation always wins.

A New Framework: Language as Economic Decision

So how do we win, when the invisible conversation is constantly working against us?  Change the conversation entirely.

Instead of asking “which language is best?” we need to ask “what is this language going to cost us?” Not just in salaries, but in velocity, in technical debt, in hiring difficulty, in operational complexity, in every dimension that actually determines whether you survive.

Reframe it from a technical debate to an economic one. And unlike identity, economics can be measured, compared, and decided without anyone’s ego being threatened.

Choosing a programming language is the single most expensive economic decision your company will make. It will define your culture, constrain your budget, determine your hiring pipeline, set your operational costs, and ultimately dictate whether you can move fast enough to win your market.

We need a framework that makes the invisible costs visible. One that lets us have the economic conversation instead of the identity conversation. One that works whether you’re choosing your first language or evaluating a migration.

Our industry has never really had that framework…Until now.

How a teenage printer’s writing exercise reverse engineered the timeless principles of learning.

The core algorithm that powers today’s most advanced artificial intelligence wasn’t born in Silicon Valley or has anything to do with computers. It was engineered in the dusty, ink stained backroom of a Boston print shop, nearly 300 years ago, by a teenager who was tired of being told he wasn’t a good writer.

Long before he was a world famous statesman and inventor, Benjamin Franklin was an ambitious, self taught apprentice with a chip on his shoulder. Working for his older brother, he devoured books and secretly submitted anonymous essays to his brother’s newspaper, desperate to succeed in this world of words. But he had a problem. While his ideas were sharp, his prose was clumsy.

His own father, Josiah, delivered a blunt critique: Ben’s writing lacked “elegance of expression, method and perspicuity.”¹ For an aspiring intellectual, this was a devastating diagnosis. It confirmed his fear that he simply didn’t have the innate ‘gift’ for writing.

Instead of giving up, Franklin did something extraordinary.He rejected the idea of ‘innate talent’ and treated his flawed writing not as a personal failure, but as anengineering problem. He asked himself:Is there a system, an algorithm, that can build the skill of writing from the ground up? In effect, he decided to debug his own brain.²³

What Franklin developed wasn’t just a writing exercise, it was something far more profound. His process reveals something fundamental about how intelligence, artificial or human, actually improves. When we examine his method through a modern lens, we discover he had unknowingly architected the same learning principles that power today’s AI.

Franklin’s method can be seen as a kind of human powered, conceptual gradient descent, where conscious insight replaces calculus to minimize the ’error’ between his writing and his goal. By deconstructing his 300 year old protocol, we can uncover a powerful blueprint for how anyone can master a complex skill.

Franklin’s breakthrough wasn’t just in learning to write better, it was insystematizing the process of improvement itself. He created a feedback loop that could be applied to any skill, making excellence reproducible rather than accidental.

The Learning Algorithm

Franklin chose articles fromThe Spectator, a respected British periodical, as his “training data” and ran them through a repeatable loop that tightened his prose with every pass.

1

Feature Extraction

Compress the source to its signal

First, he converted exemplary essays into compact notes. He took several articles and made “short hints of the sentiment in each sentence”², forcing himself to distill structure, tone, and argument the way an AI model pulls features from raw data.

2

Reconstruction

Generate from compressed understanding

After a deliberate pause of a few days—an instinctual guard against rote memorization—he rebuilt the article sentence by sentence from those hints. This was his forward pass, a prediction generated from the representation he had just engineered.

3

Error Calculation

Compare against the ground truth

He then executed the most critical step: “I compared my Spectator with the original, discovered some of my faults, and corrected them”². The side by side review supplied a loss signal that surfaced concrete gaps in diction, cadence, and logic.

4

Parameter Update

Adjust the mental model

Franklin leaned into every discrepancy. By rewriting awkward phrases, borrowing structure, and noting superior turns of phrase, he updated the parameters of his own style so the next prediction would land closer to the target.

⚡

Deliberate Practice, 1720 Style

Psychologist Anders Ericsson later coined the term“deliberate practice”³ for exactly this pattern: a structured activity with explicit goals, rapid feedback, and relentless correction. Franklin was running that playbook two centuries early.

The Modern Parallel: Deconstructing the Training Loop

Franklin’s protocol is a striking parallel for a modern machine learning training loop:

The Learner’s Playbook: Applying the Franklin Protocol

Anyone can use the Franklin Protocol to master a skill today, from coding to cooking to playing a musical instrument. The key is tostop passively consuming information and start building your own active learning loop.

The beauty of Franklin’s method lies in its universality. Whether you’re debugging code, perfecting a recipe, or learning a musical piece, the same principles apply: compress the knowledge, reconstruct from memory, compare against excellence, and iterate based on the gaps you discover.

🍌

Even when our primary ventures fail, we have to remember that there’s always money in the banana stand. The fundamental practices that seem mundane often contain the greatest value.

1. Find Your “Spectator”

Every skill has a “ground truth”, a gold standard you can learn from. Franklin hadThe Spectator. For you, it might be an exemplar that proves what’s possible.

• Developer: The source code of a well written, open source project or a language’s standard library
• Musician: A virtuosic recording of a difficult piece
• Chef: A classic, time tested recipe from a master like Julia Child

The goal is to find an authoritative model you can meaningfully compare your own work against.

2. Implement Your Learning Loop

I used a very similar protocol when I was learning the Go programming language, treating the effort like aCode Kata. After learning the basics, I designed focused challenges such as reimplementing functions from thestrings package.

FP

Forward Pass

Attempt the skill from your current understanding

I’d write my own version ofstrings.Split orstrings.Join from scratch, based on my current knowledge

LF

Loss Function

Compare against a trusted ground truth

Then, I would open Go’s standard library, written by the Go creators, and compare my code, line-by-line, against the official, production-grade implementation

ES

Error Signal

Capture precise deltas to correct

The difference was my feedback. My clumsy error handling, inefficient loops, and non-idiomatic variable names became glaringly obvious when placed next to the work of masters.

3. Internalize the Patterns (The Master’s Step)

This final step is what separates simple practice from true mastery. After refactoring based on insights, ask the master’s question:“What pattern did I miss that an expert sees instantly?” This meta analysis, thinking about your thinking, accelerates the internalization of expert mental models.

For me learning Go, the most crucial step was not just seeing the difference, but going back andrefactoring my own code based on those insights. Each cycle transformed the exercise from a simple task into a kata, a mindful practice where the goal wasn’t just to get a working solution, but to internalize the patterns of an expert. I even gavea presentation about my mistakes and how I learned from them.

🧩

Leverage LLMs for your learning

Today modern AI models can facilitate this step much more efficiently, as these models are excellent at identifying and evaluating the differences between two blocks of text and explaining why one is superior.

True Learning

This principle extends far beyond Franklin’s era. It is the very essence of modern AI. Large language models don’t “know” anything; they are sophisticated pattern recognition engines. They have learned the statistical patterns of language so well that they can generate coherent, novel text because they have captured the distribution of language itself⁴⁵.

People who master any field follow the principle. They don’t win by consuming the most tutorials, but have built the most effective systems for recognizing patterns, crafting systems that surface errors quickly, and converting them into new capabilities.

Perhaps Franklin’s greatest insight wasn’t the method itself, but hisrejection of the fixed mindset. In an era when talent was considered innate, he proved that expertise could be engineered systematically. This islearning how to learn, the ultimate meta skill.

Three hundred years ago, a teenage printer reverse engineered the algorithm of learning with nothing more than paper and ink. While Franklin’s method and machine learning operate in different domains, they share the same core architecture of systematic improvement through error correction.

Today, we have access to endless “Spectators” in every field imaginable. Franklin gave us the blueprint.It’s time we started building ourselves with it.

I’ve spent most of my career working in New York City. Every morning, I’d walk past those towering skyscrapers, genuinely amazed at what humans can build together. The engineering, the coordination, the trust required. It’s breathtaking.

What fascinates me most is the foundation. While everyone admires the gleaming towers, I think about the engineers who spent months planning what goes sixty feet underground. That invisible work makes everything else possible. No Instagram posts about foundation concrete. No TED talk talks about rebar placement.

In software, we build on similar foundations, and I’ve been incredibly fortunate to help create some of them.

An Honor and a Renewed Responsibility

When I learned thatCobra andViper were selected for the inauguralGitHub Secure Open Source Fund, I felt a mix of profound gratitude and renewed responsibility.

These projects started over a dozen years ago. Cobra was born because no library existed in Go at the time that could enable theHugo experience I had invisioned. Viper? I just wanted config management that didn’t make me question my career choices. I never imagined they’d become the foundation for projects likeKubernetes,Docker,Caddy, and theGitHub CLI.

The responsibility isn’t just an intellectual exercise, it’s real and troubling. When millions of production systems depend on your code, “YOLO-driven development” stops being funny real quick.

Learning from Shared Challenges

TheLog4Shell vulnerability was a wake up call for all of us. TheLog4j team, who graciously shared their experiences as part of this GitHub cohort, showed us how quickly a single vulnerability can become a global crisis.

Their openness taught me so much. We’re all vulnerable. We’re all doing our best with limited resources. And we all need to support each other better.

That’s what made this GitHub program so powerful: it was about learning together how to do better.

A Cohort of Collaboration

The GitHub program exceeded every expectation. We worked with tools likeCodeQL andDependabot, but more importantly, we worked with each other.

Being in the program with teams fromOllama,Caddy,Flux,Colima,Ente, andZITADEL reminded me why I love open source.

We shared our struggles, our solutions, and our hopes. The Ollama team showed us how they handle AI model security. The Colima team shared their experiences with container security in a world where containers are the new VMs.

We weren’t competing, we were collaborating. Every improvement to one project strengthens the entire ecosystem. Your security is my security. We rise together.

Security Boot Camp, Not Security Theater

In a workshop titled “CodeQL from Zero to Hero,” we were instructed by GitHub’s leading security researcher. She didn’t just teach us theory but how to practially leverage CodeQL. After a few introductory exercises, she had the participants switch from a test database to a real one from an open source project she had previously analyzed.

She guided everyone in writing a data flow query from scratch. The goal was to find any place where user input (source) flowed into a dangerous command execution function (sink). After assembling the final query, the group ran it. The results lit up the screen, revealing 16 distinct command injection vulnerabilities.

The “aha” moment was seeing how they all stemmed from a popular machine learning framework called Gradio, which the query had identified as a source of user input. The instructor explained how she had previously modeled that framework in CodeQL, allowing her to find all these “variants” of the same vulnerability. It was a live demonstration of moving from learning a new skill to finding critical, real world security flaws in a matter of minutes. This wasn’t just a workshop; it was a masterclass in how to think like a security researcher. It was about building skills, not just checking boxes.

Building on a Strong Foundation

During my time leading theGo team at Google, I had the privilege of working withRob Pike,Robert Griesemer, andKen Thompson. They didn’t just create a language, they encoded decades of hard won wisdom about what goes wrong in systems programming.

The decisions we made: immutable strings, no pointer arithmetic, explicit error handling, integrated fuzzing and vulnerability scanning weren’t just technical choices. They were investments in the future security of every Go program. When I started Cobra and Viper, I wanted to build on that foundation. I wanted to create libraries that were not just powerful, but also secure by default. When I joined the Go team, I thought of this heavy responsibility as a privilege. I wanted to make sure that the tools we built would help developers avoid the pitfalls that had plagued so many other languages.

The Uncomfortable Economics of Open Source Security

I want to be transparent: maintaining critical open source infrastructure is challenging. I’ve been fortunate to have support from companies likeGoogle,Docker,MongoDB, andTwo Sigma throughout this journey.

But even with that support, security improvements often take a backseat. Why? Building new features is exciting. Users shout in celebration about new features (or riot over missing features). They only whisper about security… until something catastrophic happens.

The GitHub fund is a start to changing this dynamic. It’s recognition that this often invisible security work is essential infrastructure that deserves dedicated time and resources.

A Community Achievement

This recognition belongs to everyone who has contributed to Cobra and Viper. Every person who submitted a PR, reported an issue, or reviewed code late into the night; You made this possible.

I especially want to acknowledge the people who do the quiet, essential work: writing documentation, patiently answering questions, and creating examples that make concepts click. You are the heart of these projects.

This achievement is yours as much as ours.

Your Action Items (Yes, You)

If you use Cobra or Viper: Thank you for your trust. Update to the latest versions to get these improvements. We’re committed to maintaining this higher standard.

If you maintain open source: I encourage you to explore the security resources available throughOpenSSF. The tools are accessible, and the community is supportive. We’re all learning together.

If your company depends on open source: Please consider how you might support the projects that form your foundation. Giving your employees time to contribute back is often the most valuable support you can offer.

The View From Here

Looking at where these projects are today fills me with gratitude. We built the foundation. The Go community reinforced it. And now, thanks to GitHub and this incredible cohort, we’ve done the seismic retrofitting to make sure it can handle whatever comes next.

To everyone who’s been part of this journey thank you.

Now if you’ll excuse me, I need to update some dependencies. Security never sleeps, but at least now it has better tooling.

P.S. - For a deep dive into the technical details, theCobra team’s post has comprehensive notes. If you have questions, we genuinely want to hear them—that’s how we all improve.

P.P.S. - If you’re wondering about the impact: when you runkubectl, you’re using Cobra. When your services load configuration, they’re likely using Viper. We’re all connected in this dependency graph we call modern software. Thank you for being part of it.

I’m leaving my role as the Product Lead for the Go Language at Google. I’m super proud of everything the Go team has accomplished in the last six years, and I’ve never been more excited for Go’s future.Read on if you’re interested in what led me to my decision, what I’ll be doing next, and what I’ll miss about my time at Google.

Go has been my passion for the past 10 years

Ten years ago, I used Go for the first time. I immediately fell in love with the language and its simple elegance. For the first time in a long time, I loved programming again. So much so that I was eager to write Go whenever I could. This led to the creation ofHugo,Cobra,Viper and a handful ofadditional Go libraries.

This passion also led me to get involved in the broader Go community. I spoke at the first Gophercon, the first Gotham Go, and the first Gopherfest. I fondly remember sitting in a room withBill Kennedy the night before the first Gophercon, putting together all the swag bags alongsideErik andBrian. For the second Gophercon Brian and Erik asked me to run the lightning talk program withMark Bates. We quickly became close friends and organized and emceed the next several Gotham Go conferences and Gophercons (lightning track) together.

This work in the community led to relationships with a few members of the Go team, which led to the opportunity to join the team myself. I blogged aboutjoining the Go team.

Taking Go to the Enterprise Mainstream

Ijoined the Go team 6 years ago with a goal to take Go from a niche hobbyist language to a mainstream, enterprise ready language. Looking back now, I believe we have accomplished, and even exceeded this goal.

When I joined the Go team their primary focus (and roadmap) was centered around addressing the needs of Google’s internal users. I drove a pivot in our focus to address the needs of our entire global user base of both current and future users. Our focus on Go’s global user base led to identifying and addressing friction around the entire Go developer experience.

My first project reflected this change of focus. I started the now bi-annualGo user survey, one of the world’s largest developer surveys. This survey has done more than anything else to drive the Go roadmap over the past 6 years. The direct feedback from our users led to the team addressing Go’s two biggest enterprise adoption blockers with the addition ofmodules andgenerics to the Go language.

Based on feedback from enterprise users we made significant updates toGo’s Brand. This led to publishingGo.dev,a single destination for all Go web properties withover 30 case studies,helpful use cases,a learning center,a Go playground andGo’s package discovery portal.

We deliveredVSCode Go andGopls, significantly improving the Go developer experience. We’ve improved our documentation andexpanded our tutorials around use cases that Go’s users identified. We improved how folksinstall Go and createdGo workspaces to facilitate multiple module projects.

Our global focus led to embracing our worldwide community and contributors. We ensured that Go was accessible in as many countries as possible includingChina. We held severalcontributor summits anda contributor workshop. The Go project evolved fromone that was primarily written by Googlers, to primarily written by community contributors. The Go project madeimpactfulrefinements to ourCode of Conduct, ensuring that the Go community remains welcoming and friendly. We created aGo Developer Network of nearly 200 meetups in over 50 countries.

Over the past 6 years Go’s user base has grown ~10x and Go users have increased their frequency from occasional to daily usage. Today, Go is now widely considered a mainstream enterprise language. Go is the modern cloud language both as the primary infrastructure language, with over 75% ofCNCF projects written in Go, and as one of the main cloud application languages.

I’m so fortunate to have played a role in assisting the Go team and community, who worked incredibly hard to accomplish all of this (and more) to take Go to where it is today.

The Exceptional Go Team

I can’t overstate how much being a part of Go has meant to me personally and professionally. I’ve made many of my closest friends through the Go community. These are some of the most genuine, caring people I’ve ever met.

During my time at Google, I’ve been fortunate to work alongside and learn from the most talented people in our industry. Even at a company made up of exceptional people, I believe the Go team is the exception within the exceptional, truly the best of the best. I think there is nothing more empowering as a product leader than knowing that regardless of the vision you have, your engineering partners will be able to build it better than you imagined.

I’ve learned more about what it means to lead and what it means to be a good teammate over the past six years than I ever thought possible. I will deeply miss my partners,Sameer Ajmani andRuss Cox, and the rest of the Go team. Together we have made something amazing and I’m deeply proud of what we’ve accomplished.

Personal highlights from my time on the Go team

Indulge me while I share some personal experiences. Things that really nobody else saw and might not have been meaningful to anyone else, but will remain with me as some of my fondest memories.

• The Go team’s first movie night where we watchedHackers in the NYC Google office’s small theater room.
• Going to seeCJ Ramone &The Aquabats with the NYC Go team
• My first Go team summit whereJessie Frazelle and I madePJW face stickers for the team.
• Karaoke with the Open Source Strategy Team in SF
• Eating lunch withBrian Kernighan andPeter Weinberger and hearing stories about their days at Bell Labs
• Skateboarding with Suzy Muller,David Chase andRuss Cox at Gophercon San Diego
• Teaching a room full of excited gophers Go withAshley Willis during the Go CLI workshop
• Our first contribute-a-thon reaching over1000 points
• Pair programming a new Go installer withBradFitz
• Writing the Story of Go’s Future with Sameer & Russ for a presentation to SVPUrs Hölzle
• Exploring Iceland with a bunch of Gophers during Gophercon EU

Why I’m leaving

With all of these great experiences and accomplishments, I’m sure you are wondering, why would anyone leave this behind? With each of the past few Go releases it increasingly felt that my journey with the Go team was coming to a close. When I first joined there was so much to learn about both Go and working within Google. My learning had slowed down dramatically. I was torn. I loved the team and the work we were doing, but was feeling personally stagnant.

With the monumentalGo 1.18 release it very much felt to me that my mission on the Go team was accomplished. I began to explore what could be next. I came up with a very short list of things that I wanted to make sure my next endeavor had:

1. Continue working with exceptional people
2. Continue working with nice people
3. Opportunities to learn new skills
4. Pioneering a new path for our industry
5. Opportunities to work with open source in the data science and machine learning domains
6. Work in a leadership role in a smaller company, one where I could effect change

After months of searching I believe I have found a company and role that checks all of these boxes.

→ Two Sigma

Looking back on my career I’ve been very fortunate to be at the bleeding edge of many different industry innovations. I led the team that designedMongoDB’s pioneering user experience. I ledDocker’s core engineering team. I created the world’s leading static site generator,Hugo. I created the popular CLI framework,Cobra, which has contributed to a resurgence of CLI applications. I’ve now led theGo Programming Language. Next I’m going to put my attention to data science and machine learning.

My search took me toTwo Sigma, who for the past two decades has been at the bleeding edge of innovation in data science, distributed computing and machine learning with deep investments intoopen source.

As I spoke withMatt Greenwood,David Palaitis,Jason Bigler and several others at Two Sigma I saw their potential to propel machine learning and data science forward. I recognized the opportunity to be on the forefront of another paradigmatic shift and felt the same excitement and passion that I felt when I first discovered MongoDB, Docker and Go. I’m thrilled to be joining the incredibly talented team atTwo Sigma.

I’m proud to present the new and improvedspf13.com a dramatic redesign of the very firstHugo powered website.

After 25 years of building websites I’m happy to say that this is the best website I’ve ever made and I look forward to sharing more content than I ever have before. Something about the new design is really inviting and honestly just makes me happy, and I think it’s going to be a big motivator to write more content.

Some History

In late 2012 I decided to rebuild my website from scratch. I wanted to learnGo and CSS3 and really learn them, not learn how to use the latest front end framework. My rule wasNo frameworks, no libraries, no templates, no plugins. I started with an empty file, wrote my own custom HTML and CSS and wrote a markdown / template processor in Go.

I wanted something simple, minimalistic, and clean. I also wanted something that was easy to maintain, easy to write and was very secure.

There was something very liberating about starting from scratch. I had a lot of freedom to experiment with different ideas and see what worked best for me. I was also able to do things I didn’t know I could do before.

I wrote my website alongside of a CSS framework I called Zombie — that nobody ever used again, a static site generator which I calledHugo — that loads of folks are now using includingvote.gov,2k.com,kubernetes.io,getboostrap.com,budweiser.com,brave.com,freebsd.org, &kde.org, and severalGo libraries which are now among the most popular in the Go ecosystem.

I documented the launch ina blog post. That blog post was the first post ever published in Hugo. After nearly 10 years I’m really excited to reinvent it.

About this site

This time around I took a totally different approach.

Today there are100s of Hugo themes available, both free and commercial. Here are a few places to find them:

• Official Hugo Themes Gallery
• JamStack Themes
• Hugo Themes Free
• Awesome Hugo Themes
• Theme Forest $$
• Get Hugo Themes $$
• Wowchemy Themes $$
• Zero Static $$

I decided to go with themenca theme. It’s a very clean theme with a striking visual design. I loved the look and wanted to support our theme designers in our community.

This site is intentionally very close to the basemenca theme. I’ve added a few small features to it and customized the style a bit, but thanks to thanks to a well designed theme and Hugo’s excellent theme overriding support this was trivial to do.

On the other hand, updatingspf13.com to the latest version ofHugo took me several months. I had a lot of posts and wanted to convert them to page bundles and add images for each post. Neither of these features existed when I launched spf13.com the first time around. I went through each post one by one, added an image, cleaned up the meta data and fixed the ocassional typo.Unsplash was a great resource for the images.

In addition to adding images, I went through and added videos for many of the olderpresentations (the more recent ones mostly already had them). I also added quite a bit of content from presentations, podcasts and articles I’ve written over the past couple of years which regretfully didn’t make it onto the site until now.

Lastly, I added a featured section tothe homepage. If you are new here, please checkout the featured content. I consider those my best work and I hope you enjoy them.

This new site supports in-site search, a wonderful feature that uses the approach found byDeclaration of VAR. This approach uses Hugo to generate an index (which it does instantly on build) and then uses javascript to search the index. I imagine there’s a limit to the number of posts that this approach works with, but it works well for me with a few hundred posts.

I’m exicited to share this new site with you. I hope you enjoy it.

— Steve (aka spf13)

Disclaimer: Some links on this page are affiliate links. If you choose to make a purchase after clicking a link, I may receive a commission at no additional cost to you. Thank you for your support!

I had the pleasure of speaking with Olimpiu Pop fromInfoQ about the Go language and community.

The article can be found athttps://www.infoq.com/articles/go-language-13-years.

Go Time panelists Natalie & Jon join forces with Go Team members Steve Francia, Katie Hockman, Julie Qui, and Rob Findley to battle it out and see who can better guess what the GopherCon gophers had to say!

Listen to the podcast athttps://changelog.com/gotime/211

Transcript

Mat Ryer: Hello, and welcome to this Go Time GopherCon extravaganza… Yeah, extravaganza, yeah. I’m Mat Ryer, and I’m thrilled to announce that today again we’re playing Gophers Say, the excellent, popular, family game show based on Family Feud, or Family Fortunes if you’re in the U.K, which I am.

Let’s meet the teams. We have Team Zero, is – well, let’s meet our contestants here. We’ve got Julie Qiu around… Hello, Julie.

Julie Qiu: Hi!

Mat Ryer: Welcome to Go Time/GopherCon. We’ve also got Steve Francia. I can’t believe it. Hi, Steve.

Steve Francia: Hi, everyone.

Mat Ryer: I can’t believe you’re here, Steve, really. Can you?

Steve Francia: I mean, I’m here…

Mat Ryer: Well, you won a competition, so congrats. Jon Calhoun is also here. Jon.

Jon Calhoun: Hey, Mat. How are you?

Mat Ryer: Hi, Jon. I’m good, mate. I’m excited. Are you gonna win?

Jon Calhoun: [03:59] I don’t know.

Mat Ryer: That’s a good answer. An honest answer.

Jon Calhoun: If my team carries me, I’ll win. But if my team doesn’t carry me, I probably won’t.

Mat Ryer: Okay, good. So he’s not gonna be pulling his own weight there. Well, Natalie Pistunovich is in town. Hello, Natalie.

Natalie Pistunovich: Hi, Mat.

Mat Ryer: Welcome back. Are you looking forward to the game show?

Natalie Pistunovich: I’m very excited to be the one person who is aware of the rules, yes.

Mat Ryer: Yeah, absolutely.

Natalie Pistunovich: Because I already played it.

Mat Ryer: Yes. Please remind me if I forget, as well. Katie Hockman also around. Hello, Katie. Welcome. How are you doing?

Katie Hockman: I’m good. I’m very excited to win, despite Jon not believing that we can.

Mat Ryer: Ah, okay. Well, you’ll have to carry him. That’s it. Rob Findley is also here, aren’t you, Rob?

Rob Findley: I am. Hi, Mat.

Mat Ryer: Hey. Welcome to the Gopher Time/Go Time Mashup. Yeah, don’t worry, I said it wrong on purpose. I need to tell you about this game that we’re gonna play, because it’s lovely. Essentially, we’ve asked a load of gophers some questions, and you’ll have to try and guess the answers. So you’re trying to match the popular answers from the survey. It’s not about right or wrong, it’s just about what gophers say. That’s why it’s called Gophers Say.

The top answers will go on the board. Any response that had five or more answers will appear on the board, and in order to get control of the board, each team has to do a face-off, basically, where you’ll just have a guess and see the highest score, and that’s how you’ll take control of the board. Once you’ve got control, you have to then guess all the other answers, and then you’ll win. That’s how you win, you get points. But be warned, if you get three of them wrong, you’ll lose three lives, and you’ll give the other team a chance to steal, and they’ll be able to take your points, essentially. So don’t let that happen.

You cannot confer through the game, but while you’re stealing, you can confer, and I’ll remind you of that later. Do we feel like we’re ready to play? I’m gonna announce the teams that we have here.

So team zero - it’s Natalie, Steve and Julie. You are our first team, team zero.

Natalie Pistunovich: Woo-hoo!

Julie Qiu: Woo-hoo!

Mat Ryer: There you go. And you know, don’t take anything by the fact that zero is in the name of your team; it’s literally just zero-bound, like with the Go slice. That’s why I’ve done that. Jon, Katie and Rob, team one. You’re our second team.

Rob Findley: Go team one!

Jon Calhoun: Katie apparently isn’t happy. [laughter]

Katie Hockman: It’s one for the first place, yeah.

Rob Findley: Very happy.

Mat Ryer: Yeah. Okay, good. They’re definitely happy, we’ve been assured of that verbally. Okay, we’re gonna now look at the board, we’re gonna show the screen… Can we see this? I’m gonna jump into our first round here… Natalie and Jon, you’re gonna go face to face; we’re gonna have an interface-off, if you like puns… Natalie, what would your guess be to this question: “Describe the Go community with just one word.” What did most people say when they were asked to describe the Go community with just one word?

Natalie Pistunovich: Welcoming.

Mat Ryer: Welcoming. Gophers say… [win sound] Yes, it’s on the board, in number two. Nine points there. So Jon, you’re gonna have a guess. If you beat Natalie, you have to get that number one spot. You’ll take control of the board.

Jon Calhoun: Natalie stole my answer, and I don’t know if my back-up is… I guess – is “friendly” the same as “welcoming”? I don’t know how that would be categorized.

Mat Ryer: Let’s see if friendly is on there. Gophers say… [win sound] Yes, friendly… And where is it? At number three.

Natalie Pistunovich: Wooooh!

Mat Ryer: Natalie’s team, team zero, takes control. And we’re over to Steve Francia. Steve… How’s it going, Steve? Are you gonna have a guess? What do you think the Go community said about this?

Steve Francia: [08:05] I was gonna say welcoming and friendly…

Mat Ryer: Okay…

Steve Francia: But those have been taken. So I’m gonna say “good-looking”. No, it’s two words… Attractive.

Mat Ryer: [laughs] Okay. Gophers say… [fail sound] Oh, no, I’m sorry. Attractive was not on the board. You lose a life. But don’t worry, you’ve got two other lives.

Steve Francia: It should have been. It should have been.

Mat Ryer: Agree, yeah. Julie, would you wanna have a guess?

Julie Qiu: I’m gonna say “fabulous”.

Mat Ryer: Fabulous, okay. Gophers say… [fail sound] Oh, sorry. Nobody said it was fabulous. Well, five or more people didn’t say that. We’ll loop back around… Natalie, what do you think?

Natalie Pistunovich: Inclusive.

Mat Ryer: Inclusive. Gophers say… [fail sound] No. Nobody said inclusive. And that’s your third and final life gone, I’m afraid… So now the other team, team one, have a chance to steal. You can confer. I just need one answer from you, Jon, the team captain, after you’ve conferred with your team.

Jon Calhoun: Alright. From my team, does anybody think the word “gopher” might be on the board?

Katie Hockman: I don’t know…

Rob Findley: The Go community is gopher?

Jon Calhoun: That, or like programmer, or like nerdy…

Katie Hockman: I was gonna say diverse…

Rob Findley: Yeah, I think diverse…

Jon Calhoun: That’s a good one.

Mat Ryer: Okay, is that gonna be the answer you’d like to submit?

Jon Calhoun: Are we going with diverse?

Mat Ryer: Do you wanna lock it in?

Rob Findley: Yeah.

Jon Calhoun: Okay, we’re locking diverse in.

Mat Ryer: Okay, we’re gonna lock diverse in. Gophers say… [fail sound]

Katie Hockman: What?!

Mat Ryer: No, I’m afraid not. You did not steal. Let’s reveal the board. Number six was “opinionated”. Five people said that.

Rob Findley: It makes sense.

Mat Ryer: And at number five, we have “fun”, with six people. And in position number four, we had “helpful”, seven people said that. In position three we have “friendly” with eight people, “welcoming” is in position two with nine people, and at number one it is “awesome”, and that was said by 17 people.

Katie Hockman: Wow…

Mat Ryer: There we go.

Jon Calhoun: We’re getting off to a rough start.

Katie Hockman: Yeah.

Natalie Pistunovich: Isn’t it the same as fabulous?

Steve Francia: Yeah, I was gonna say, “awesome” is fabulous, right?

Natalie Pistunovich: [laughs]

Mat Ryer: Yeah. Well, there we go. Let’s move on to our next round. Okay, round two… Name a place outside your house where you like to code/work. This time it’s Steve versus Katie going face to face, to find out who controls the board. Steve, I’ll ask you after Katie. Katie, what’s your answer?

Katie Hockman: Wait, so it’s me first?

Mat Ryer: Yeah.

Katie Hockman: Okay. I had two guesses… I will say “coffee shop.”

Mat Ryer: “Coffee shop.” Good one, I think… Gophers say… [win sound] Yes, of course. And it’s the top answer…

Katie Hockman: Yaaay!

Mat Ryer: That means that Steve doesn’t even get to have a guess. You’ve basically snapped his dream out of the clutches of his tiny –

Steve Francia: And I was gonna say coffee shop, so…

Mat Ryer: There we go.

Steve Francia: Good one.

Mat Ryer: Yeah, good one. Okay… Right, so - now it’s Rob’s turn to have a guess. You’ve got three lives, Rob… What do you think?

Rob Findley: Okay. We used to work in offices… So how about the office?

Mat Ryer: Okay, let’s find out. The office. Gophers say… [win sound] Yes, indeed. In at number three, “the office”, with 21 people. By the way, 38 people said “coffee shop”. Very cool. Alright, John, three lives still. Going strong. Where do you like to code/work?

Jon Calhoun: [12:02] I’m gonna go with “park”.

Mat Ryer: In the park, how beautiful. Gophers say… [win sound] Yes, indeed. Number two. Park/garden/yard. 26 people. Okay, Katie - you’ve still got your three lives…

Katie Hockman: I don’t do this, because I watch movies instead, but I know a lot of people who do… I’m gonna say “airplane”.

Mat Ryer: Oh, airplane. Gophers say… [fail sound]

Katie Hockman: Ugh…

Mat Ryer: No, nobody does that outside – they don’t tend to do that, apparently. They watch movies too, I guess. You lose a life, but that’s okay. You’ve got two more lives. Rob, what do you think?

Rob Findley: Okay, how about the beach? Some people work at the beach.

Mat Ryer: Oh, do they? Well, let’s see. Gophers say… [fail sound] No. Have you met a programmer at the beach?

Rob Findley: Well, yeah…

Mat Ryer: Yeah, there’s some cool ones, aren’t there? Not in this survey, mate…

Rob Findley: Not me.

Mat Ryer: Not me either. Okay, Jon, back around to you, talking to cool people… What do you think?

Jon Calhoun: Oh, boy… I’m gonna guess campground.

Mat Ryer: Campground. Okay. Gophers say… [fail sound] No. I can’t believe no one’s going camping, setting up a tent, sorting out the electric, sort out the water, look up the local amenities…

Jon Calhoun: I figured if everybody’s going remote, they’re gonna go camping and working.

Mat Ryer: And just get some code written. They’re not doing that. I can’t believe it. Katie, what do you think?

Katie Hockman: I always have a life left…

Mat Ryer: One life left…

Katie Hockman: Oh, gosh. I thought we were dead, so I wasn’t even thinking… [laughs] Pressure’s on… Um, I was gonna say –

Steve Francia: They are good, they’ve had three x’es.

Mat Ryer: Oh, really?

Rob Findley: Yeah.

Jon Calhoun: Mat, are you good?

Mat Ryer: Oh, okay.

Katie Hockman: We did die three times, so I’m pretty sure…

Mat Ryer: Yeah, that’s a mistake by me then. Okay. Okay, that means –

Natalie Pistunovich: Mat started counting at zero.

Mat Ryer: Yeah, thank you for getting me out of it… Okay, unfortunately that was your last life, so that means the other team get to steal. You can confer, and Natalie, I’ll take your answer. What do you think?

Steve Francia: So we get to talk to each other right now?

Mat Ryer: yes.

Natalie Pistunovich: Yes, we get to decide together.

Steve Francia: What about library?

Julie Qiu: I thought train.

Steve Francia: I was thinking train, too. Train and library.

Natalie Pistunovich: That’s because you live in the U.S. [laughs] Maybe most of the people who took the survey live in the U.S. How about a co-working space? Is that like the office?

Julie Qiu: Hm…

Mat Ryer: Okay, I’m gonna have to take an answer.

Steve Francia: I think four, five and six are co-working space, library and train.

Mat Ryer: Okay.

Natalie Pistunovich: By this order? [laughs]

Steve Francia: Well, I don’t know… Any of those sound good to me, Natalie. You choose.

Julie Qiu: Yeah.

Mat Ryer: Natalie…?

Natalie Pistunovich: I was about Julie “What do you think?”, but okay. Yeah, let’s try train.

Mat Ryer: Okay, “train” to steal. Gophers say… [fail sound] No, I’m afraid not… Well, that means the points go to team one. Let’s unload this board then. Number six was “nowhere”. [laughter] People that don’t leave to do any work. That got five answers. In number five it’s the pub or the bar; six people said that. I can’t believe that. And at number four - let’s see if this is one of yours, Steve… Number four was the library, indeed. 14 people.

Natalie Pistunovich: Wow…!

Mat Ryer: That’s okay, don’t worry though… It’s going well, we’ve got team zero have 17 points, team one are forging ahead with 85 points. Let’s go on to round three…

Break: [15:50]

Mat Ryer: Okay, round three. The question we asked our gophers is “The most useful Go keyword is what?” What is the most useful Go keyword? What did people say? We’re gonna find out which team takes control of the board when Julie and Rob go head to head… Julie, this time.

Julie Qiu: Oh, boy… Um, switch.

Mat Ryer: Switch. Gophers say… [fail sound] No.

Julie Qiu: Sorry.

Mat Ryer: That’s okay, you just lose one life, no problem. Rob, you have to have a guess. Actually, Julie, you don’t lose a life. We’re just still finding out who’s gonna take control… So Rob, you have to get one of these to take the board.

Rob Findley: Well, you can’t switch without a func, so I’m gonna say func.

Mat Ryer: Func indeed. Gophers say… [win sound] Yes, indeed, at number two. Eighteen people said func was the most useful Go keyword. And that means team one steals the control of the board, takes it. Jon Calhoun, what do you think the most useful Go keyword is? What do you think our Gophers said?

Jon Calhoun: This is one of those ones where I just expect people to not name keywords as answers…

Mat Ryer: [laughs] Why would that be, Jon? That’s very unusual.

Jon Calhoun: Like, if you asked me to list all the Go keywords, I couldn’t list them all. I’d definitely get something wrong.

Mat Ryer: But you could do some of them, right?

Jon Calhoun: I’m gonna go with select…

Mat Ryer: Select. Gophers say… [win sound] Yes, indeed. Down at number six. Seven people said select. Nice work. Okay, Katie, what do you think? Return would be very useful. Let’s see if the Gophers said it. Gophers say… [fail sound] No…! And it honestly shocks me that that’s not on there.

Katie Hockman: Everybody needs that… [laughs]

Mat Ryer: What are their programs?

Rob Findley: You need to return…

Mat Ryer: Well, we can’t figure that out now, Rob. You’ve got two lives still, so… What do you think?

Rob Findley: Okay. I think people will have just heard the word Go, so they’ll say “go”.

Mat Ryer: Okay, that’s how much respect you have for the audience of Gophers that have answered this…

Rob Findley: It’s useful.

Mat Ryer: Yeah. It is useful. Let’s find out if they’ve said it. Gophers say… [win sound] Yes. And look at this - top answer. 29 people said that “go” was the most useful Go keyword. Very cool, indeed. Two lives, and it’s Jonny Calhoun. Go on, Jon. Do a guess.

Jon Calhoun: Var?

Mat Ryer: [20:01] Var… Good one.

Jon Calhoun: I mean, how else are you gonna create those globals?

Mat Ryer: Good point.

Jon Calhoun: …that everybody loves.

Mat Ryer: [laughs] Trollin’. Gophers say… [fail sound] No. You lose another life. You have one more life. Katie, that life sits delicately in your hand. Are you gonna set it free, or crush it to death more? What’s your guess?

Natalie Pistunovich: I’m between two, so I’m gonna go with – I think people said “if”.

Mat Ryer: If. Gophers say… [fail sound] No. These programmers are very certain. There’s no uncertainty.

Natalie Pistunovich: Apparently…

Mat Ryer: Yeah, yeah. They know what they’re doing. This is not like “Yeah, if this…” Make your mind up.

Jon Calhoun: These are interesting programs.

Mat Ryer: That was your last life, I’m afraid… This gives the other team, team zero, a chance to steal. Please confer amongst yourselves, and then Natalie, team captain, I’ll take an answer after you’ve conferred with your team.

Natalie Pistunovich: Alright, this time we’re doing this right…

Mat Ryer: Yes, please.

Natalie Pistunovich: What do you think?

Steve Francia: I think it’s “defer”.

Natalie Pistunovich: I was thinking of that, too.

Julie Qiu: I was thinking “panic” or “type”, but I’ll defer to you two…

Natalie Pistunovich: [laughs] This was meant to be. Let’s go with “defer”.

Mat Ryer: Oh, excellent. I don’t know when to do this now… I feel like we need to wait for the end of the game show before I announce this one… I’m just kidding.

Natalie Pistunovich: [laughs]

Mat Ryer: Defer. Gophers say… [win sound] Yes!

Julie Qiu: Yaay!

Mat Ryer: You’ve successfully stolen! Third space there, with 11 people, “defer”. And you steal the points. 65 delicious points coming your way.

Rob Findley: Oh, it’s so close.

Mat Ryer: So team zero is now on 82, team one is on 85. Let’s reveal the rest of this board then. What was the most useful Go keyword? Number seven, people said “struct”, five people said that. At number six was “select”, with seven people. Number five is “interface”, nine people said that. At number four, “for”. Clue is in the number… Ten people said so. And defer was at number three, with 11 people, func in spot two, 18 people, and go at number one there, with 29 people.

Wow, things are heating up here… 82 and 85 it’s not much in it is there? Now we’ve built some tension… It’s time to go to round four! Pam-param-pam-pam-pow! Right… What are we doing again…? What are we doing again? Okay, the next question… The best thing about the tech industry is - what? What is the best thing about the tech industry. And it’s Natalie and Jon to go head to head… Jon, what’s your guess? What’s the best thing about the tech industry?

Jon Calhoun: The paycheck?

Mat Ryer: The paycheck. Gophers say… [win sound] Yes, at number two. The pay/benefits. 20 people there. Interesting. Okay, Natalie, can you beat that? Can you find that number one spot?

Natalie Pistunovich: Twitter?

Mat Ryer: Twitter. [laughter]

Natalie Pistunovich: It’s my honest answer…

Mat Ryer: Gophers say… [fail sound] No, I’m afraid. No one gets that. That means team one take control of the board. Katie, we’re over to you… Three lovely lives. Don’t ruin them. What’s your guess?

Katie Hockman: I think people would have said “the people”.

Mat Ryer: The people. That’d be nice, if they people said “the people”. Let’s see - did the people say “the people”? Gophers say… [win sound] Yes indeed, at number four. The people or the community that they’re in. 15 people said that. That’s very nice, isn’t it? Rob, can you find a nicer one than that? Or just any?

Rob Findley: [23:53] I don’t know about that, but… How about the fact that we get to program? How about the work?

Mat Ryer: Oh, the work itself, programming. Gophers say… [win sound] Yes, indeed. People did say that. Problem-solving, we grouped into that. 19 people, at number three, yes.

Rob Findley: Generous.

Mat Ryer: Very cool. Three lives still. Jonny Calhoun…

Jon Calhoun: I’m gonna go with the impact.

Mat Ryer: The impact.

Jon Calhoun: You can impact more people.

Mat Ryer: Okay, the impact - did they say that? Let’s find out. Gophers say… [win sound] They did indeed say “impact”. They said “opportunity” or “the impact to make a change”, things like that. Ain’t that nice? Eight people there, and it was at number six. And still, three lives… This is looking good. Katie, can you keep up the running streak of success?

Katie Hockman: I don’t know if I can… I feel like the thing I wanna say is probably within the category of benefits. I was gonna say “flexibility”…

Mat Ryer: Hm, okay… Yeah, flexibility. Let’s see if it’s up there. Gophers say… [win sound] Well done. Yeah, work from home, or flexibility. Ten people said that. I’ll tell you what - I genuinely thought this was probably gonna be the hardest question, and you’ve really just nailed this. Very impressive. Rob, I think we’re back around to you, aren’t we?

Rob Findley: I’m mystified. I have no idea. I was gonna say flexibility. I don’t know, how about the opportunity to grow?

Mat Ryer: Okay, let’s see…

Rob Findley: I don’t know, I’m doubtful.

Mat Ryer: Let’s see if more than 20 people said “opportunity to grow.” Gophers say… [fail sound] No. And you lose a life. But it’s okay, you’ve got two other lives, so Jon and Katie are both gonna get a guess here… Starting with you, Jonny Calhoun, down at the local saloon… What do you think?

Jon Calhoun: I am equally mystified… I don’t know, I’m gonna go with Go.

Mat Ryer: The language, Go.

Jon Calhoun: Go.

Mat Ryer: The best thing.

Jon Calhoun: The best thing about the tech industry is Go.

Mat Ryer: Okay, let’s see. Maybe Gophers did say that. Let’s see, Gophers say…? [fail sound] No, I’m afraid not. You lose your life. Katie, the last life, to prevent the steal…

Katie Hockman: Oh, no, that was gonna be my guess… [laughs] I don’t know…

Mat Ryer: You’re very close with that answer, apparently…

Katie Hockman: Okay… Coding?

Mat Ryer: Okay, let’s do it. Let’s find out. Gophers say… [fail sound] No, I’m afraid not. So that means the other team get a chance to steal. Can you get this right, team? Please confer.

Natalie Pistunovich: My idea is conferences.

Julie Qiu: Me too!

Natalie Pistunovich: Okay! Steve?

Steve Francia: I was gonna say travel. So I think conferences is great.

Julie Qiu: Yeah.

Natalie Pistunovich: Cool. Okay. So that’s our answer.

Mat Ryer: Okay, conferences… Let’s see if it’s conferences. Is it conferences? Gophers say… [fail sound] Oh, no…! I’m afraid not. That means team one steals all those delicious points… And we’ll look at the scores after. The top answer for this one was in fact the tech, the innovation. Tech, or innovation is the best thing about the tech industry.

Okay, so let’s check in with the scores. Team zero, in our slice of team here - team zero has 82 points. But team one out in the lead again, it’s 157 points. You know, celebrate…

Rob Findley: Yay!

Mat Ryer: There we go. Okay, let’s move on, shall we, to the next round. Round five. Daram-pam-pam-pow! Someone else is having a party at their own house by the sound of that… Okay, right. Here we go again. This is round five… This time the question is “The worst thing about the tech industry.” This is what we’re after now - what’s the worst thing about the tech industry? And last time it was Jon and Natalie went head to head, so it’s Steve and Katie. And Steve goes first. Steve, what’s the worst thing?

Steve Francia: [28:20] Um, bugs.

Mat Ryer: Bugs. What a great answer.

Steve Francia: Bugs.

Mat Ryer: Bugs. Yeah. We’ll submit it in your accent then, shall well.

Steve Francia: Bugs.

Mat Ryer: Gophers say… [win sound] Yes, bugs. Bad practices. Okay, yeah. There we go, we’ll give you that one. Bad practices and bugs, things like that. In position four there, 13 people said that. Okay, Katie, can you beat that? There are three other answers ahead of this one.

Katie Hockman: I feel like no matter what I say, I’m gonna get in trouble for it… [laughs] I’m gonna say this in the most diplomatic way possible… Potentially like the room for growth as far as diversity goes.

Mat Ryer: Okay, so… Right, diversity being the worst thing currently. Gophers say… [fail sound] No, Katie. Apparently, that’s all sorted.

Katie Hockman: It’s all done. Fixed it.

Mat Ryer: Yeah, we’re finished. Put that into the Done column. Okay, so that means team zero - you need it. You’ve taken control of the board. And Julie, it’s your turn. Three lives… Have a guess. What do you think the worst thing about the tech industry is?

Julie Qiu: Um, I’m gonna say the bad people. The people, but specifically the people who are bad.

Mat Ryer: The baddies. Bad people. Like villains, and the like. Charlatans.

Julie Qiu: Yeah.

Mat Ryer: Scallywags.

Julie Qiu: Exactly.

Mat Ryer: Okay. The bad people. Gophers say… [win sound] Yes, indeed. So people are saying people or the culture. 14 there, and that was a top answer. Merry, merry festive holidays to everybody. That was a little surprise… And that surprise there means Steve Francia is gonna donate $100 to a charity. That’s what that lovely piece was. Thank you so much, Steve. That’s lovely.

And Natalie - we’re back around to you now. It’s your turn to have a guess. What do you think the worst thing about the tech industry is? Three lives…

Natalie Pistunovich: Something along the lines of agile, sprints, JIRA… Something there.

Mat Ryer: Okay. So like management practices, stuff like that.

Natalie Pistunovich: Yes.

Mat Ryer: Okay, let’s see if that’s on the board. Gophers say… [fail sound] No, everyone loves all that. Not a problem at all.

Natalie Pistunovich: Good! It’s not a problem. Alright. That and diversity is all good.

Mat Ryer: Steve, what do you think? Do you wanna have another guess? You’ve got two lives left still.

Steve Francia: I think it’s the hours.

Mat Ryer: Oh, the hours could be the worst thing about the tech industry. It is nearly 9 PM and I’m hosting a game show… So let’s see what Gophers say. [win sound] Yes, indeed, Steve. Number three there. The pressure and the long hours. 16 people said that. Yeah… Take a break, everyone. Not you though, Julie, because you’re up to answer a question now. You’ve got two lives still… What do you think the worst thing about the tech industry is? We’re looking for that second answer.

Julie Qiu: Hm… It is very hard. Can I say like the bad impact?

Mat Ryer: So the evil? Would you class it as evil?

Julie Qiu: Yes, the evil. Yeah.

Mat Ryer: Yeah, the negative impact of tech. Okay, let’s see if that’s up there. Gophers say… [fail sound] No, Julie. Not there. Down to one life. Natalie, you’ve got your thought on it, so what are you gonna do? What do you guess? What’s the worst thing about the tech industry?

Natalie Pistunovich: Bad code was already said, right? That was kind of the bad practices one…

Mat Ryer: [31:57] Yeah, bad practices in existing code was at number four there. We’ve got number three, the pressure of long hours, and at number one is the people.

Natalie Pistunovich: Legacy?

Mat Ryer: Well, that would probably fall under the existing code…

Natalie Pistunovich: Okay. Oh, man… I’m out of ideas. Um…

Mat Ryer: Tough one, isn’t it?

Natalie Pistunovich: Not the people, not the long hours, not the bad practice… Nothing about management then? Did we say that? Is that management practices, that also doesn’t work?

Mat Ryer: Yeah. That one wasn’t up there either, was it? What are we going to say? Or should we time you out?

Natalie Pistunovich: Does that mean we get to keep the life? [laughter]

Mat Ryer: No, it means the other team will get a chance to steal…

Natalie Pistunovich: Right. Bad documentation?

Mat Ryer: Okay, let’s go for that then. Bad documentation. Gophers say… [fail sound] No. But what a great guess…! Okay, so now the other team have a chance to steal. Jon, I’ll accept your answer after you confer with your lovely team.

Jon Calhoun: So I’m assuming that if they voted the podcasts, that they would have filtered that one out, right? [laughter] Jerod wouldn’t have let that fly.

Mat Ryer: Didn’t take conferences out

Katie Hockman: My idea is like Twitter, Reddit, Hacker News, that kind of – like the social media aspect. What do you guys think?

Jon Calhoun: I was actually thinking Twitter, but Natalie used it for the best things about tech. But I think it’s kind of like people as well - they can be good and bad.

Rob Findley: They can be both. I think that’s good. I was also gonna say –

Jon Calhoun: Do we go with like social media, or do we want a specific –

Katie Hockman: I would hope that they would take either, if that was actually the answer.

Rob Findley: Sounds good.

Jon Calhoun: Okay. So let’s go with social media.

Mat Ryer: Okay. Social media. Let’s find out. Gophers say… [fail sound] No, they didn’t say that, so you don’t steal the points. That means that team zero keeps those lovely points… But let’s find out, what was number two on this one? It was “There’s too much to learn.” There’s too much to learn in this old tech industry of ours, and it’s making us angry. That’s what we’ve learned today.

Okay, I don’t know, I probably wouldn’t have guessed that one. I thought there were some great answers there, everyone… How’s it going so far? Are we having a fun quiz?

Natalie Pistunovich: Yaay!

Rob Findley: Wooh!

Steve Francia: This is fun.

Jon Calhoun: I’m realizing that I do not resonate with all the people who took the survey. [laughter] We’ve missed the top two answers several times now, I feel like.

Mat Ryer: Yeah. It’s surprising; you learn things. It is a surprise. Let’s check in with the scores, shall we? Please? Team zero has got 160 points. Just slightly ahead of team one, who have 157. This is so tight, you won’t believe it… But the next round is Double Points Round! Round six. Let’s go!

Break: [34:42]

Mat Ryer: Okey-doke, this is the final round for double points. Anyone could win the amazing prize. Any one of the three of you can win this… And then you have to share it, which I’m sure will be no problem.

The question for round six is - we asked people to describe the Go language with just one word. Describe the Go language with just a single, solitary word. What did people say? Julie and Rob, you’re going head to head, starting with Rob. What do you think people said, Rob?

Rob Findley: [36:06] I think people said “simple”.

Mat Ryer: Do you know? Let’s see if people did say “simple”.

Rob Findley: I hope.

Mat Ryer: Gophers say… [win sound] Yes, and it’s the top answer. So it means you take control of the board straight away there… And we’re over to Jon. You’ve got three lives, there are three ones to guess. The top answer is already taken. Simple. What else did people use to describe the Go language, Jon? One word.

Jon Calhoun: I’m gonna go with verbose.

Mat Ryer: Verbose. Okay. And just for anyone that doesn’t know, verbose is when you use lots of extra words that really aren’t necessary and you don’t need, to try and explain something to somebody, or it could be in documentation… And essentially, you’re using way too many words that’s unnecessary, essentially… And the idea is –

Jon Calhoun: This is what happens when Jerod tells you we have 11 minutes…

Mat Ryer: Oh, no, 11 minutes to fill? Oh, okay. I won’t carry that joke on then for 11 minutes… That would have been gold.

Natalie Pistunovich: About being verbose…

Mat Ryer: Yup. Okay, a good bit of comedy, everyone. We’re all equally guilty. Katie, what do you think?

Katie Hockman: Is verbose on the board?

Jon Calhoun: I was gonna say…

Mat Ryer: Oh yeah, I genuinely forgot what we were doing… [fail sound] [laughter]

Katie Hockman: I’m gonna assume no… Okay…

Mat Ryer: No, unfortunately… It should be now, after that… So unfortunately - yeah, Jon, you lose a life. Thanks, Katie… Hopefully, we can edit that, so I don’t look like an idiot. [fail sound]

Katie Hockman: No worries…

Mat Ryer: No, we can’t apparently… [laughter] Okay, Katie…

Katie Hockman: Alright, I’m gonna say “fast”.

Mat Ryer: Fast. The Go language with just one word - fast. Gophers say… [win sound] Yes, indeed. It was in at spot number three there. Nine people said it, so you get 18 points. By the way, for the “simple” answer, because 25 people said it, you’ve got 50 points there. So there’s a lot of points on this board. And with two lives left, Rob’s to guess. Robs?

Rob Findley: How about “concrete”?

Mat Ryer: Concrete. Oh, okay, concrete. Let’s see if people said that; that’d be interesting. Gophers say… [fail sound] No, obviously not, Rob. But good answer. But you lose a life, I’m afraid. Jon, over to you now.

Jon Calhoun: See, this is the problem…

Mat Ryer: Last life, Jon…

Jon Calhoun: It could be a self-fulfilling prophecy if I lose this for us…

Mat Ryer: Come on, get in the minds of these surveyed Gophers. You know them by now… You got to know them over a series of five rounds of simple questions; you feel like you know them pretty well… What do you think?

Jon Calhoun: Um, readable?

Mat Ryer: Readable. I love that answer. Let’s see. Gophers say… [fail sound] No, they did not. That is a surprise. And unfortunately, that was your last life, which means team zero has a chance to steal, and basically win the game if they can get either the second or the fourth answer from this board. You’re allowed to confer, of course… Natalie, I’ll accept your answer after you’ve conferred with your team. What do you think?

Natalie Pistunovich: What do you say?

Julie Qiu: Oh, boy…

Steve Francia: I think I would say – I’ll give you a few. Efficient…

Julie Qiu: That was mine!

Steve Francia: Secure…

Julie Qiu: That was what I have in mind.

Steve Francia: I mean, it is what it says on the Go website, which I’ve put there. You could also say “fun”. “Fun” is another one. So fun, efficient, secure.

Natalie Pistunovich: Secure is a good one.

Julie Qiu: I like efficient.

Natalie Pistunovich: Efficient? It’s interesting that some of the other questions have seven answers, and this one has only four, so it looks like everybody has the same thing in mind… Or they’ve just dropped out of the questionnaire. Okay, so I guess –

Jon Calhoun: I think anything below five answers gets dropped.

Natalie Pistunovich: Oh, so it’s actually the other way around. So many answers.

Mat Ryer: Mm-hm.

Steve Francia: Many people answered the same things in this one.

Julie Qiu: Yeah.

Mat Ryer: 25 people said “simple”, 9 people said “fast”. There’s still two answers to get on the board, positions two and four.

Natalie Pistunovich: Then how many people said “efficient”?

Mat Ryer: Shall we find out? Is that your answer?

Natalie Pistunovich: [40:23] Yes.

Mat Ryer: Would you like to lock it in?

Natalie Pistunovich: I would like to lock it in to number two, please. [laughter]

Mat Ryer: Well, you don’t get to choose… Let’s find out. Efficient. Gophers say… [fail sound] You’ve been hanging out in Germany too long, Natalie…

Jon Calhoun: They haven’t been reading Steve’s page.

Natalie Pistunovich: I’ve been reading the documentation. It says there.

Steve Francia: It is on the website…

Mat Ryer: Yeah. Okay, we’re gonna award those points, and let’s find out, at number four on this board - people said, with just one word, the Go language was… Fun! Which was mentioned…

Rob Findley: I knew it!

Mat Ryer: Fast is at number three, nine people… At number two, pragmatic. 12 people said that. It would have earned you 24 points.

Katie Hockman: At least it doesn’t say secure…

Mat Ryer: Yeah… [laughter]

Jon Calhoun: Well, there are just a lot of answers with four or less then…

Mat Ryer: Yeah, we’ll do the data crunching and find out. It sometimes happens there’s lots of answers, and it’s not many people agreeing; only if you had five or more will it make it onto the board, of course… But there we go. Let’s have a quick look at the scores, because these are final scores now.

It’s time for final scores now. Team zero got 160 points, which is very respectable… And I’m saying that to lessen the blow when we find out that team one thrashes you with 225 points. Please celebrate appropriately! [applause]

So there we go… Any surprises? What do we think? Which was the round? Jon, when you were saying that they missed out some answers, what were you thinking of?

Jon Calhoun: Oh, I just felt like half the answers people gave on that last one were ones I would have expected to at least show up a couple times… But it is hard when everybody chooses different words.

Mat Ryer: Yeah, that’s it…

Jon Calhoun: But I did call it, that Katie and Rob were gonna have to carry me… Because I got nothing on that last round.

Mat Ryer: Yeah. It was good though, ain’t it?

Natalie Pistunovich: That’s alright. That’s why you’re a team.

Jon Calhoun: That teamwork. Sorry, Steve. You look upset.

Mat Ryer: How are you feeling, Steve, after…?

Steve Francia: I’m pretty broken-hearted. I thought we were gonna win. Even at that last round, I thought we had it. I was like, “We’re gonna steal it.”

Natalie Pistunovich: We were not efficient enough.

Steve Francia: Well, we weren’t fun enough, that’s really what it was.

Natalie Pistunovich: That’s true. That is actually true.

Steve Francia: Or pragmatic.

Jon Calhoun: I mean, that just means you need to rebrand the go.dev website, and just put “FUN” real big.

Steve Francia: I think we’re gonna have to… What were the – it was fast, simple, pragmatic and fun. I think that’s what’s gonna go on the website now.

Katie Hockman: I think it has to. Legally obligated.

Mat Ryer: That’s what people think of it… But how do you feel? Do you feel like you got to know the Go community a bit more as well, in a way?

Steve Francia: Yeah.

Mat Ryer: Like, do you understand them? Sometimes some of the answers are unusual, aren’t they?

Jon Calhoun: I feel like the last time you played this – the last time you played this, didn’t you have questions that asked about editors, and people were using that? Or I think one question was like “What was the first language you learned?”, so you kind of got to understand people better based on how old they were when they learned to program? This one I don’t feel like there’s any questions that gave that away too much.

Mat Ryer: Yeah. You sort of just have to pick up the general vibes of people, I think, with this game.

Steve Francia: So - interesting fact… In the first Go user survey we had a bonus question, “What was your favorite Go keyword?” And I thought doing all these surveys would help me; that’s the only one it helped me with, but… “go” and “defer” were both high on the list. I remember.

Jon Calhoun: I was something waiting for “else” to be on the list, even though “if” and “switch” weren’t. I was just like, “If that’s the case, it’s just somebody trolling us.”

Mat Ryer: [44:07] Some of the answers in some of the questions – because we’ve asked loads of questions, so we have loads to choose from… And some of them are – like, you wonder if people are trolling, or joking. And sometimes the joke answers - enough people say it that it makes it onto the board as well, because… You know, it’s quite funny, but… It’s interesting to get into the minds of people, I think, a little bit…

Speaking of that, we’ve got a couple of minutes… Steve, what have you been working on lately?

Steve Francia: I’ve been working on a lot of stuff lately, because that’s what I do, I work on a lot of different stuff… But I know – I’ll just kind of talk about some things that we’re working on. A lot of work getting ready for a generics release, which is coming up in the release in February… But the betas should be – you know, all the pre-releases we’re working hard on.

I’m also meeting with a lot of our users. A good part of how I spend my day is meeting with companies and individuals and projects who have adopted Go, and just hearing their challenges and their successes…

Mat Ryer: Oh, nice.

Steve Francia: It’s one of my favorite parts of my job, actually.

Mat Ryer: Yeah. Generics of course coming in 1.18 in February… Katie - also fuzzing is coming. First-class concern.

Katie Hockman: It is. I’m so, so excited that it’s happening. I’m working very hard on documentation right now. We’re kind of in the bug fix, and polish, and document phase… So I think it’s gonna be important for it to land with docs, or it’s not gonna land successfully if people can’t use it. So that’s the goal that I have right now for this project.

Mat Ryer: That makes sense. I love the way that it interops with the existing testing stuff; our knowledge of writing unit tests can come in handy for writing fuzz tests. I think that’s a kind of really nice advantage to the fact that it’s getting first-class support, rather than being a sort of external tool.

Katie Hockman: Yeah, absolutely. Yeah, that was one of the main goals, and I’m glad you like that.

Mat Ryer: Yeah, I do. I really do. Well, thank you so much, it’s been a pleasure. If our audience wants to learn more about Rob and Julie, check out our Go Time back-catalog, and also listen to future shows, because they’ll definitely be on it, hopefully.

Thank you so much to everyone for joining this live feed, this game. A great time was had by all(most); a great time was had by most… And we’ll see you next time. Bye everyone!

Steve Francia: Bye.

Natalie Pistunovich: Bye!

Break: [46:44]

Jerod Santo: I feel like I only really screwed up probably the tech/innovation one, which was the number one answer nobody got… I almost gave it when Jon said “Go”, because that would be focused on like the tech, but it was more broad… I was struggling.

Katie Hockman: What about diversity is not culture? How is diversity and culture not the same? [laughs]

Jerod Santo: Well, yeah… I know, but you just said – yeah, that was definitely specifically mentioned by a few people.

Katie Hockman: I see.

Jerod Santo: And I grouped it into like – it was tough because there were so many… Like, “tech bros”… There were a lot of weird responses, so I kind of like put it in like the people and the culture. But when you said diversity specifically, I was kind of like “It would be too much of a mismatch with just the people.” It was tough.

Katie Hockman: Nah, that’s fair. I’ll allow it.

Jerod Santo: That one was.

Julie Qiu: I feel like I should have gotten the points when I said “fabulous”…

Jerod Santo: Oh, those were – that one I didn’t do any grouping, because that was like the easiest one, right? Because you can actually just like “Group by” and the actual words were… So I didn’t do any grouping of the words. But on the –

Mat Ryer: Maybe we should like each question and then have a regex for the answer next time. So you have to do it in your head live, but…

Jerod Santo: Just do the regex live and apply it?

Jon Calhoun: I would not get any answers then, because I would never compose my regex right the first time…

Jerod Santo: Well, you can just have Mat write the regex, and then we can all criticize it on the air like we did last time with your team selection algorithm.

Mat Ryer: Which worked, yeah.

Jerod Santo: Which worked… [laughs]

Mat Ryer: Which worked.

Jon Calhoun: Yeah, that time you didn’t even give us the opportunity.

Natalie Pistunovich: You are all saying regex, wow.

Mat Ryer: Well, what do you say?

Natalie Pistunovich: Reg ex.

Katie Hockman: I say reg ex…

Mat Ryer: Do you?

Steve Francia: Wait, what is it?

Natalie Pistunovich: Reg ex, regex.

Katie Hockman: I say reg ex, but I realized people say regex. I say reg ex.

Steve Francia: Reg ex. Like Reg A.

Natalie Pistunovich: Like regular expression.

Rob Findley: Do you say gif or gif?

Katie Hockman: I say gif just to mess with people.

Jerod Santo: Do you say gif?

Katie Hockman: I say gif, I switch.

Jon Calhoun: I mean, I get reg ex in the sense that it’s regular expression, but…

Jerod Santo: Yeah, I understand it’s illogical.

Jon Calhoun: …for some reason I don’t do it.

Jerod Santo: …but regex just rolls off the tongue, whereas reg ex - you feel like you’re choking.

Mat Ryer: Yeah, it’s hard to say. I just say regiular expressions… [laughter]

Jerod Santo: This is funny, because…

Natalie Pistunovich: It sounds like something you’d say in British.

Julie Qiu: Do you say Lynux, too?

Jerod Santo: No, of course not.

Julie Qiu: Linux?

Steve Francia: No, his name is Linus, so it’s Lynux.

Natalie Pistunovich: Oh…

Rob Findley: Well, I thought it was based off minux

Jerod Santo: No, because Linus is actually on the record of saying “My name is Linus Torvalds and I call Linux Linux.” [Linus recording 00:50:22.20] He recorded that audio and put it out there.

Steve Francia: Oh, interesting.

Mat Ryer: Oh, yeah.

Jerod Santo: So we have permission.

Steve Francia: Yeah, that was a long time ago.

Jerod Santo: It really was.

Steve Francia: Who created regex? Will they give us permission?

Jerod Santo: Oh, I’ll give you permission to call it regex.

Natalie Pistunovich: This reg ex/regex just gave my next Twitter poll, thank you. All.

Steve Francia: I think the teams were super-nice and fair, and I think if we had one more round, we would have taken it.

Jerod Santo: It was super-tight. This was probably the closest one we’ve had.

Rob Findley: Yeah, it was amazing.

Steve Francia: Yeah, it was close.

Mat Ryer: Yeah, it was close.

Jon Calhoun: Based on the way the score was going back and forth, I wouldn’t have been shocked at all if you guys would have taken the next round, Steve.

Jerod Santo: Well, you were one word away. “Fun” was the word, and you had it in your shortlist…

Natalie Pistunovich: Yeah…

Jerod Santo: So… Great game, guys.

Steve Francia: That was the first thing that came to mind, and then – stupid, I was like “I’ll just look at the website, and see what the website says.” I should have stuck with my guess.

Mat Ryer: Does the website say “fun”?

Steve Francia: No.

Rob Findley: Oh, you were cheating?

Steve Francia: Yeah, I was cheating.

Natalie Pistunovich: Illegal!

Jon Calhoun: You can’t google it…!

Steve Francia: Well, I didn’t google it, I go.dev-ed it.

Jerod Santo: [laughs]

Mat Ryer: Is it still cheating if it doesn’t work?

Katie Hockman: Yes.

Rob Findley: Yes.

Steve Francia: Well, yes.

Jon Calhoun: It’s still cheating.

Jerod Santo: It’s still cheating.

Rob Findley: But Steve did write that, so he shouldn’t have had to google it.

Steve Francia: I did write it. Yeah, I just wanted to double-check myself, because I actually thought it said “fun” – at least one version of it said “fun”; another version said “simple”, but those aren’t on the website today.

Rob Findley: I was kicking myself… I thought for sure that was concurrent.

Jon Calhoun: So whoever did the study group…

Natalie Pistunovich: It’s on people’s minds…

Rob Findley: I almost said “concurrent”, and I didn’t.

Julie Qiu: Oh…!

Rob Findley: It was not there. I was surprised.

Katie Hockman: I knew it was gonna be “fun”. As soon as I said “fast”, I was like, “I hope that can get fun” Because they said “fun” in a previous one, for a similar question. I was like, “They’re gonna say it again.” I thought “fun” was gonna be on the board 100%.

Steve Francia: Oh, we should have said “fun”!

Katie Hockman: [52:12] I was so sure… And then when they said it, I was like, “We’re done. We’re done.” I knew they had it. And then they didn’t, and I was like…

Rob Findley: Yeah, when Steve said said “fun”…

Steve Francia: So close…

Rob Findley: Yeah… I was like, “Oh, man. Fun. Fun is definitely there.”

Mat Ryer: Well, everyone’s got a time machine token that you can play at any point, and we have to rewind…

Katie Hockman: Oh, dang. Okay, thanks.

Mat Ryer: I forgot about that, yeah.

Katie Hockman: You didn’t mention that rule.

Steve Francia: Oh, that’d be fun.

Mat Ryer: And we’d be like [reverse sound] go backwards through everything, and we can get to that question again, and you can answer it differently, and we play it forward.

Jerod Santo: Wow. Can we go back and erase that “verbosity” joke you did?

Mat Ryer: I was trying to hold it up after that… [laughter] And I went too fast.

Jerod Santo: I knew what you were doing immediately, and I’m like, “Oh, he’s not doing this, is he?”

Mat Ryer: Of course he’s doing it.

Jon Calhoun: You just started doing it, and I read Jerod’s 11 minutes.

Mat Ryer: In the edit.

Jerod Santo: I guess I can go back and change it.

Steve Francia: Can we make fun of whoever? Panic is not a Go keyword, is it? But someone said it.

Katie Hockman: Is it not…?!

Natalie Pistunovich: [laughs] The same complaints last time also… The previous game, same questions, same answers.

Jerod Santo: Yeah, it was new last time as well.

Katie Hockman: Oh…

Jon Calhoun: It’s like, when they do the survey, they don’t actually give them a list of keywords… So on any question like that, they can just type whatever they want in.

Steve Francia: No, all the words they said were keywords, but someone in our panel…

Jerod Santo: Oh, someone guessed “panic”?

Mat Ryer: Well, it was on –

Steve Francia: They guessed a non-keyword.

Mat Ryer: It was on the last time, panic…

Rob Findley: I think that’s a good guess.

Mat Ryer: Yeah, yeah. On keywords.

Jerod Santo: Yeah, it actually was on the last time.

Steve Francia: It was.

Mat Ryer: People bundle that in.

Jerod Santo: So they were playing 4D chess. Was that you, Natalie? She was on the last time…

Mat Ryer: People bundle that in.

Katie Hockman: Oh, panic is a function, not a keyword?

Mat Ryer: Yeah, built-in function.

Steve Francia: I don’t think it’s a keyword…

Jerod Santo: I can’t believe “return” wasn’t on there.

Jon Calhoun: I’m guessing that things like “new”, “panic”, and there’s a couple others that people probably think are keywords, even though they’re not…

Mat Ryer: Because they’re built-in functions…

Jon Calhoun: I mean, some of them I wouldn’t know unless I looked at the spec and was like “Okay, what actually is this?”

Mat Ryer: There’s loads of built-in functions as well… See, I did a talk at Gotham Go, Steve, and I remember showing the list of – I showed the list, and you were like, “They’re not them.” And I was like doing my talk, trying to concentrate and be professional. And you’re like “That’s not them…” And I was like, “Oh…” You can see on the video when you ruined it.

Steve Francia: Mat, we know you’re not telling the truth though, because I’ve known you a long time and I’ve yet to see you be professional once… [laughter]

Editors Note:Rust vs Go: Better Together is co-authored byJT and was originally published onThe New Stack.

While others may seeRust andGo as competitive programming languages, neither the Rust nor the Go teams do. Quite the contrary, our teams have deep respect for what the others are doing, and see the languages as complimentary with a shared vision of modernizing the state of software development industry-wide.

In this article, we will discuss the pros and cons of Rust and Go and how they supplement and support each other, and our recommendations for when each language is most appropriate.

Companies are finding value in adopting both languages and in their complimentary value. To shift from our opinions to hands-on user experience, we spoke with three such companies,Dropbox,Fastly, andCloudflare, about their experience in using Go and Rust together. There will be quotes from them throughout this article to give further perspective.

Language Comparison

Similarities

Go and Rust have a lot in common. Both are modern software languages born out of a need to provide a safe and scalable solution to the problems impacting software development. Both were created as reactions to shortcomings the creators were experiencing with existing languages in the industry, particularly shortcomings of developer productivity, scalability, safety and concurrency.

Most of today’s popular languages were designed over 30 years ago. When those languages were designed there were five key differences from today:

1. Moore’s law was thought to be eternally true.
2. Most software projects were written by small teams, often working in person together.
3. Most software had a relatively small number of dependencies, mostly proprietary.
4. Safety was a secondary concern… or not a concern at all.
5. Software was typically written for a single platform.

In contrast, both Rust and Go were written for today’s world and generally took similar approaches to design a language for today’s development needs.

1. Performance and Concurrency

Go and Rust are both compiled languages focused on producing efficient code. They also provide easy access to the multiple processors of today’s machines, making them ideal languages for writing efficient parallel code.

“Using Go allowed MercadoLibre to cut the number of servers they use for this service to one-eighth the original number (from 32 servers down to four), plus each server can operate with less power (originally four CPU cores, now down to two CPU cores). With Go, the company obviated 88 percent of their servers and cut CPU on the remaining ones in half—producing a tremendous cost-savings.”— “MercadoLibre Grows with Go”

“In our tightly managed environments where we run Go code, we have seen a CPU reduction of approximately ten percent [vs C++] with cleaner and maintainable code.” —Bala Natarajan, Paypal

“Here at AWS, we love Rust, too, because it helps AWS write highly performant, safe infrastructure-level networking and other systems software. Amazon’s first notable product built with Rust, Firecracker, launched publicly in 2018 and provides the open source virtualization technology that powers AWS Lambda and other serverless offerings. But we also use Rust to deliver services such as Amazon Simple Storage Service (Amazon S3), Amazon Elastic Compute Cloud (Amazon EC2), Amazon CloudFront, Amazon Route 53, and more. Recently we launched Bottlerocket, a Linux-based container operating system written in Rust.” —Matt Asay, Amazon Web Services

We “saw an extraordinary 1200-1500% increase in our speed! We went from 300-450ms in release mode with Scala with fewer parsing rules implemented, to 25-30ms in Rust with more parsing rules implemented!” —Josh Hannaford, IBM

2. Team Scalable — Reviewable

Software development today is built by teams that grow and expand, often collaborating in a distributed way using source control. Go and Rust are both designed for how teams work, improving code reviews by removing unnecessary concerns like formatting, security, and complex organization. Both languages require relatively little context to understand what the code is doing, allowing reviewers to more quickly work with code written by other people and review code by both team members and code contributed by open source developers outside of your team.

“Building Go and Rust code, having come from a Java and Ruby background in my early career, felt like an impossible weight off my shoulders. When I was at Google, it was a relief to come across a service that was written in Go, because I knew it would be easy to build and run. This has also been true of Rust, though I’ve only worked on that at a much smaller scale. I’m hoping that the days of infinitely configurable build systems are dead, and languages all ship with their own purpose-built build tools that just work out of the box.”—Sam Rose, CV Partner

“I tend to breathe a sigh of relief when writing a service in Go since it has a very simple, easy to reason about, static type system compared to dynamic languages, concurrency is a first-class citizen, and Go’s standard library is both unbelievably polished and powerful, yet also to the point. Take a standard Go install, throw in a grpc library and a database connector, and you need very little else to build anything on the server-side, and every engineer will be able to read the code and understand the libraries. When writing a module in Rust, Dropbox engineers felt Rust’s growing pains on the server-side before Async-await stabilized in 2019, but since then, crates are converging to use it and we get the benefit of async patterns coupled with fearless concurrency.” — Daniel Reiter Horn, Dropbox

3. Open Source-aware

The number of dependencies used by the average software project today is staggering. The decades-long goal of software reuse has been achieved in modern development, where today’s software is built using 100s of projects. To do so, developers use software repositories, which increasingly has become a staple of software development across a broadening range of applications. Each of the packages a developer includes, in turn, has its own dependencies. Languages for today’s programming environments need to handle this complexity effortlessly.

Both Go and Rust have package-management systems that allow developers to make a simple list of the packages they’d like to build on, and the language tools automatically fetch and maintain those packages for them, so that developers can focus more on their own code and less on the management of others.

4. Safety

The security concerns of today’s applications are well-addressed by both Go and Rust, which ensure that code built in the languages run without exposing the user to a variety of classic security vulnerabilities like buffer overflows, use-after-free, etc. By removing these concerns, developers can focus on the problems at hand and build applications that are more secure by default.

“The [Rust] compiler really holds your hand when working through the errors that you do get. This lets you focus on your business objectives rather than bug hunting or deciphering cryptic messages.” —Josh Hannaford, IBM

“In short, the flexibility, safety, and security of Rust outweighs any inconvenience of having to follow strict lifetime, borrowing, and other compiler rules or even the lack of a garbage collector. These features are a much-needed addition to cloud software projects and will help avoid many bugs commonly found in them.” —Taylor Thomas, Sr., Microsoft.

“Go is strongly and statically typed with no implicit conversions, but the syntactic overhead is still surprisingly small. This is achieved by simple type inference in assign­ments together with untyped numeric constants. This gives Go stronger type safety than Java (which has implicit conversions), but the code reads more like Python (which has untyped variables).” —Stefan Nilsson, computer science professor.

“When building our Brotli compression library for storing block data at Dropbox, we limited ourselves to the safe subset of Rust and, further, to the core library (no-stdlib) as well, with the allocator specified as a generic. Using the subset of Rust this way made it very easy to call the Rust-Brotli library from Rust on the client-side and using the C FFI from both Python and Go on the Server. This compilation mode also providedsubstantial security guarantees. After some tuning, the Rust Brotli implementation, despite being 100% safe, array-bounds-checked code, was still faster than the corresponding native Brotli code in C.” — Daniel Reiter Horn, Dropbox

5. Truly Portable

It is trivial in both Go and Rust to write one piece of software that runs on many different operating systems and architectures. “Write once, compile anywhere.” In addition, both Go and Rust natively support cross-compilation eliminating the need for “build farms” commonly associated with older compiled languages.

“Golang possesses great qualities for production optimization such as having a small memory footprint, which supports its capability for being building blocks in large-scale projects, as well as easy cross-compilation to other architectures out of the box. Since Go code is compiled into a single static binary, it allows easy containerization and, by extension, makes it almost trivial to deploy Go into any highly available environment such as Kubernetes.” —Dewet Diener, Curve.

“When you look at a cloud-based infrastructure, often you’re using something like a Docker container to deploy your workloads. With a static binary that you build in Go, you could have a Docker file that’s 10, 11, 12 megabytes instead of bringing in the entire Node.js ecosystem, or Python, or Java, where you’ve got these hundreds of megabyte-sized Docker files. So, shipping that tiny binary is amazing.” —Brian Ketelsen, Microsoft.

“With Rust, we’ll have a high-performance and portable platform that we can easily run on Mac, iOS, Linux, Android, and Windows.” —Matt Ronge, Astropad.

Differences

In design, there are always trade-offs that must be made. While Go and Rust emerged around the same time with similar goals, as they faced decisions at times they chose different trade-offs that separated the languages in key ways.

1. Performance

Go has excellent performance right out of the box. By design, there are no knobs or levers that you can use to squeeze more performance out of Go. Rust is designed to enable you to squeeze every last drop of performance out of the code; in this regard, you really can’t find a faster language than Rust today. However, Rust’s increased performance comes at the cost of additional complexity.

“Remarkably, we had only put very basic thought into optimization as the Rust version was written. Even with just basic optimization, Rust was able to outperform the hyper-hand-tuned Go version. This is a huge testament to how easy it is to write efficient programs with Rust compared to the deep dive we had to do with Go.” —Jesse Howarth, Discord.

“Dropbox engineers often see 5x performance and latency improvements by porting line-for-line Python code into Go, and memory usage often drops dramatically as compared with Python as there is no GIL and the process count may be reduced. However, when we are memory constrained, as on desktop client software or in certain server processes, we move over to Rust as the manual memory management in Rust is substantially more efficient than the Go GC.” — Daniel Reiter Horn, Dropbox

2. Adaptability/Interability

Go’s strength of quick iteration allows developers to try ideas quickly and hone in on working code that solves the task at hand. Often, this is sufficient and frees the developer to move onto other tasks. Rust, on the other hand, has longer compiles compared with Go, leading to slower iteration times. This leads Go to work better in scenarios where faster turnaround time allows developers to adapt to changing requirements, while Rust thrives in scenarios where more time can be given to making a more refined and performant implementation.

“The genius of the Go type system is that callers can define the Interfaces, allowing libraries to return expansive structs but require narrow interfaces. The genius of the Rust type system is the combination of match syntax with Result<>, where you can be statically certain every eventuality is handled and never have to invent null values to satisfy unused return parameters.” — Daniel Reiter Horn, Dropbox

“(I)f your use case is closer to customers, it’s more vulnerable to shifting requirements, then Go is a lot nicer because the cost of continuous refactor is a lot cheaper. It’s how fast you can express the new requirements and try them out.” — Peter Bourgon, Fastly

3. Learnability

Simply put, there really isn’t a more approachable language than Go. There are many stories of teams who were able to adopt Go and put Go services/applications into production in a few weeks. Additionally, Go is relatively unique among languages in that its language design and practices are quite consistent over it’s 10+ year lifetime. So time invested in learning Go maintains its value for a long time. By comparison, Rust is considered a difficult language to learn due to its complexity. It generally takes several months of learning Rust to feel comfortable with it, but with this extra complexity comes precise control and increased performance.

“At the time, no single team member knew Go, but within a month, everyone was writing in Go” –Jaime Garcia, Capital One

“What makes Go different from other programming languages is cognitive load. You can do more with less code, which makes it easier to reason about and understand the code that you do end up writing. The majority of Go code ends up looking quite similar, so, even if you’re working with a completely new codebase, you can get up and running pretty quickly.” — Glen Balliet Engineering Director of loyalty platforms at American ExpressAmerican Express Uses Go for Payments & Rewards

“However, unlike other programming languages, Go was created for maximum user efficiency. Therefore developers and engineers with Java or PHP backgrounds can be upskilled and trained in using Go within a few weeks — and in our experience, many of them end up preferring it.” —Dewet Diener, Curve

4. Precise Control

Perhaps one of Rust’s greatest strengths is the amount of control the developer has over how memory is managed, how to use the available resources of the machine, how code is optimized, and how problem solutions are crafted. This is not without a large complexity cost when compared to Go, which is designed less for this type of precise crafting and more for faster exploration times and quicker turnaround times.

“As our experience with Rust grew, it showed advantages on two other axes: as a language with strong memory safety it was a good choice for processing at the edge and as a language that had tremendous enthusiasm it became one that became popular for de novo components.”  — John Graham-Cumming, Cloudflare

Summary/Key Takeaways

Go’s simplicity, performance, and developer productivity make Go an ideal language for creating user-facing applications and services. The fast iteration allows teams to quickly pivot to meet the changing needs of users, giving teams a way to focus their energies on flexibility.

Rust’s finer control allows for more precision, making Rust an ideal language for low-level operations that are less likely to change and that would benefit from the marginally improved performance over Go, especially if deployed at very large scales.

Rust’s strengths are at the most advantageous closest to the metal. Go’s strengths are at their most advantageous closer to the user. This isn’t to say that either can’t work in the other’s space, but it would have increased friction to doing so. As your requirements shift from flexibility to efficiency it makes a stronger case to rewrite libraries in Rust.

While the designs of Go and Rust differ significantly, their designs play to a compatible set of strengths, and — when used together — allow both great flexibility and performance.

Recommendations

For most companies and users, Go is the right default option. Its performance is strong, Go is easy to adopt, and Go’s highly modular nature makes it particularly good for situations where requirements are changing or evolving.

As your product matures, and requirements stabilize, there may be opportunities to have large wins from marginal increases in performance. In these cases, using Rust to maximize performance may well be worth the initial investment.

I had the privilage of sitting down with my friend Jason Yee as a guest on his podcast.

Listen to the podcast athttps://www.gremlin.com/blog/podcast-break-things-on-purpose-steve-francia-product-and-strategy-lead-at-google/

Transcript

Jason Yee: Hey, everyone. Welcome to Build Things On Purpose. Our slight deviation from the Break Things On Purpose podcast, where we talk with people that have made really cool things and we learn some tips from them about how we can make cool things as well, things that are reliable and that scale well. So joining us today we have Steve Francia.

Steve Francia: Hi.

Jason Yee: So Steve, tell us a little bit more about yourself. What do you do? Where do you work?

Steve Francia: So I work for Google as the product lead for the Go programming language. Previously, I worked at Docker and MongoDB in executive roles and have been involved in open source for 25 plus years. And I also was on the board of directors for the Drupal Association.

Origins of Hugo

Jason Yee: Nice. So just some background for our listeners. That’s actually how I met Steve, through Drupal. He was my boss at MongoDB. But aside from Drupal, one day, Steve came up to me and said, “Hey, check out this thing that I built.” And it turned out to be a thing that I think a lot of you might be using, a thing called Hugo. So Steve, tell us a little bit more about Hugo and why you built that.

Steve Francia: So back when I was at MongoDB, working with Jason, I was running developer experience, which was product engineering, DevRel, documentation, websites, and more; so anything that really our users interacted with. And part of that was creating and guiding our different language and integrations. I’m now working on Go, but back then I was a polyglot and we worked with about a dozen different languages. And interestingly, the need to integrate was what brought me to Drupal. We added some good support there. And as we look to extend our language base, we adopted Scala and Go as our last two when I was there. And I spent a few months learning Scala and then pivoted to Go and needed a project to work on there. And at the same time I was retooling my website, I realized I was spending more time doing WordPress security updates than I was blogging, and that maintenance cost was killing me.

So I thought I’m going to switch to a static site generator and tried Jekyll and a few of the others that existed at the time and really struggled with how much time it was taking to render my blog of a few hundred articles. And I thought there must be a faster way to do this. I was just beginning to play with Go. I’d spent maybe a couple of weeks with it and I thought, I bet Go is faster than Ruby. I bet I could write a static site generator a little faster. And I said to myself I don’t want to write a markdown parser, so if they have one Go, I’ll write the rest. And luckily here, I did a quick search and found a really good markdown parser and just started tinkering around with it and within a couple of weeks, I had something that was maybe, I don’t know, 50 times faster than Jekyll.

And I thought, wow, Go is awesome. It’s easy to write. You can get great performance out of it. And the birth of Hugo came out of that. And it’s an interesting project. Speed was obviously a goal, but I also wanted to make it really easy to use and really flexible. I took a lot of things I’d learned from Drupal, put them into it, things I’d learned from WordPress, put it into it, things I’d learned from running documentation at Mongo DB, particularly with multi-lingual support, and put that into it. And then the open source community embraced it. And we got lots of contributions from all over the world and they were able to extend and polish and improve and really take Hugo further. And today it’s much faster than it was then in the early days, which is amazing because we kept adding more features and usually you add features at the cost of speed or other costs. And in this case, so we were able to continue to keep it fast and even improve the speed. And partly, that was also aided from Go, which over its 15 releases, it just gets faster and faster and a lot of benefits to Go applications is a result of that.

Tips for learning Go

Jason Yee: Yeah. So I’m curious, as things have progressed, I’m sure a lot of that speed has come about too from just learning the way to do things. You started Hugo as a project to learn Go and obviously, when you do that, you do things in the way that you know of at the time, but then you learn better and you’re like, oh, I should have done it in a certain way. I’m curious if you’ve got some tips on what are some of those things that new Go learners should think about?

Steve Francia: Yeah, it’s a bit humbling to have your first project when you’re learning language become the most popular, a very popular project, because all of your words and learning bumps are out there. That said, I’m not shy. I was learning the whole time. I made plenty of mistakes as I went. I would say there’s a few things that I really benefited from and now from the purview of being on the core Go team and having a lot of experience from working with the creators of Go now for almost five years, my first advice is Go is simpler than you’re used to. Don’t fight that simplicity. Embrace it.

And then the second one, which it stems from that, which is everyone comes to go, most people, not everyone, now we have some first programmers using Go, but most people come from another language and they want to come in with their Java way of doing things, or the Python way of doing things, or the C++, or whatever it is way of doing things because that’s what’s in their mind, and Go as a pretty different language. It’s not object oriented, it doesn’t have exceptions, it has concurrency baked in. So there’s some pretty fundamental shifts in Go. And the advice I give is try and learn the idiomatic way of doing things. And the best way to do that is look at the Go standard library. And the standard library is comprehensive and it’s of excellent quality. It’s very usable and it really shows you the Go way of doing things. And I think that’s a great starting point.

In other places, look at other popular packages from well-known maintainers and authors. Between that, you should be able to figure out really the Go standard way of doing things. And of course, I didn’t have the benefit of this, but now, we actually launched a website just about a year ago called learn.go.dev, and there’s a ton of great learning resources from online courses to tutorials, interactive to books. So it’s a great starting point for people new to Go.

Patrick Higgins: I’m curious, Steve, did your perception or thoughts about the language shift much when you started working very closely with the people who wrote it?

Steve Francia: It’s a good question. Did they shift much? Honestly, it was an interesting evolution. To go from a community member to a core team member is just a really interesting shift, and I can’t say that they changed all that much. I already was very impressed with Go and the things they did. Working with them more closely deepened that. So I wouldn’t say it shifted it, but I do find myself just incredibly lucky to be working with the Go team. I’m a bit older. I remember the ‘92 dream team for the Olympic basketball team and it was all the best players. And there was this one time in history where this blip came where you just had this magical moment. And I kind of think of that as the Go team. I knew if I didn’t join it, I would have regretted it the rest of my life, to be able to rub shoulders with the luminaries that created so much of what we consider is modern computing. So if anything, I was already in awe of them, and then sitting next to them and seeing it in person, actually doesn’t happen often, but that impressed me even more. I felt even more humbled to be working with them.

Open source and contributors

Jason Yee: I’m curious similarly. Has going from being a community member and participating in open source to now being a core member and really running the language and the program and the evolution of it, has that changed your perspective on open source and how people get involved?

Steve Francia: I think we’re all learning what open source is more and more over time. And I don’t know that that transition happened, but certainly being in the role I’m in has opened my eyes a lot. I’d say the biggest thing I learned is, I started my career actually in mostly web based open source things. And there’s a unique property about web based things is that they can change regularly. Sometimes in our general broad developer community, we joke about, oh did you know JavaScript framework four months ago? Don’t worry, there’s a brand new one, because it’s kind of constantly evolving. And when you’re close to the surface, you can do that without much pain. But with the language, that’s as low as you can really get. It’s amazing how much more thought you have to take into what you’re doing.

And so I remember as part of Drupal and other communities, it was about getting a big contributor base and more engagement and energy and excitement around it. And with Go, it helped me understand the maintenance taxes that come from that and that our maintainers have refined their skills over decades. And not that we don’t want contributions, we very much do, but we also know that there’s a cost of reviewing, there’s a cost of interacting, and that distracts them from being able to do these things. So with Go, the approach is we don’t want to change much. We actually want to change as little as possible and in a way that keeps stability and a good experience for our users.

And for me, that was kind of a new way of thinking. And it was a new way to think about open source and how do you create a good contributor community when the default answer is no? And it’s no a high, high percentage of the time. And I kind of struggled with that a bit and I know a lot of our contributors do because it’s such a shift. And one thing that helped me with it was to recognize, as a Go team member, the bar was even higher. We actually get told no even more than the community. And so many of our good ideas that we think are good end up on the cutting room floor, so to speak. So I think that was an interesting challenge of how do you figure out how to do that? And we tried a variety of things and some stuck and now Go is actually more contributions from outside than inside the core team. But that was a slow process that evolved over a decade to get there.

Jason Yee: I think that’s fantastic insight. I mean, thinking of this podcast and talking to builders and talking about building reliable systems and applications, that idea of having that default to no and just ensuring that your core is of high quality and is reliable. And that oftentimes does mean you say no to a lot of things, but also balancing that with that contributor experience and ensuring that people have the right guidance and the right experience and are still part of that community despite being told no.

Cool. Well, thanks for being on the show with us. It’s been a pleasure to chat with you. Usually before we go, we give people a chance to do any sort of plugs if you’ve got any pluggables, things that you want people to check out.

Steve Francia: I could give some just general things. It’s not like I’m in a movie or anything exciting coming up. For those of you interested in Go, check out go.dev. We’ve got some great learning resources. We’ve also got some great case studies from major companies like American Express and PayPal and Google who’ve adopted Go and how it’s been transformative to them. And then you can always check me out at spf13.com. We’re on GitHub/spf13. And on Twitter, I’m everywhere at spf13, so just check me out. I’m excited to talk to you.

Jason Yee: Cool. Well, thanks again.

I had the privilage of joining my coworker Julie Qiu as we talked with our friends Carmen, Mat and Jon about the new website we are launching for Go,go.dev.

Listen to the podcast athttps://changelog.com/gotime/115

Transcript

Mat Ryer: Hello, and welcome to GoTime! I’m Mat Ryer. Today we’re talking about Go.dev. It’s a user-friendly hub of curated resources for Go, and we’re lucky enough to have three of the brains behind it joining us today: Carmen Andoh, Steve Francia (also known as @spf13) and Julie Qiu. Hello, everybody!

Steve Francia: Hi!

Julie Qiu: Hi!

Mat Ryer: We’re also joined by Jon Calhoun, a regular. Hi, Jon. How are you?

Jon Calhoun: Hi, Mat. I’m doing well.

Mat Ryer: What’s been going on?

Jon Calhoun: Not too much.

Mat Ryer: Okay, well let’s get started. I wanna hear all about Go.dev, so who wants to give me an intro? What is it, and what’s it for?

Steve Francia: I can share that. It is a new official Go website for our Go community. It’s intended to be a single destination, where the entire community can gather. Today it contains learning resources, it contains a package discovery or a module discovery component, and it also contains different resources to be able to help evangelize Go within your companies, or to new companies.

Mat Ryer: And this is not gonna replace Golang.org, is it?

Steve Francia: No.

Mat Ryer: So they’re gonna coexist, those two.

Steve Francia: They’re gonna coexist, yeah. That’s right.

Mat Ryer: And the difference then being, I guess, the Golang.org is the kind of open source home, it’s the technical home of the project itself.

Steve Francia: We struggled a lot… Creating two websites is not always the best thing. Two websites could create more confusion, and we initially started trying to expand Golang.org to contain all these things, and we really struggled with that because the intent of Golang.org - which if you don’t know, actually gets distributed with the Go release; most of the content of Golang.org - is to be an official place for the Go project (the language, the compilers, the tools). And what we wanna do is expand it to be something that encompassed all of this stuff for the Go ecosystem.

Eventually, after a few months of trying to figure out how to shoehorn these competing goals into this existing site, we realized that maybe they’re best as two separate sites. So the Golang.org is gonna remain the way it is, and the second site is really curated content that’s created by the Go community and for the Go community.

Mat Ryer: Right. So how did it get started then? Was this something that you internally saw that there was something missing, or was this something that the community asked for?

Steve Francia: It’s an interesting answer to that question, and I like the way you framed it.

Mat Ryer: I’ll be the judge of whether the answer is interesting or not, Steve, if you don’t mind… [laughter]

Steve Francia: So we actually started this project over four years ago.

Mat Ryer: Really?

Steve Francia: As a community member, I was talking to the Go leadership at Google about potentially joining, and it was in a new role that they’d never really had someone do before… So as part of that, I wrote a document that was from my community member perspective of the things that were missing, that we needed to address. And if I was gonna join Google, I wanted to join to build those things.

And on that document, it had - and I’ll read it to you - it was “Provide educational resources for Go adoption and best practices, working with partners to create and provide the best training materials. Write the story of the value of Go and communicate that story broadly. Solve the problem of discoverability of libraries and packages.”

The idea behind this wasn’t necessarily one project at the time, but those were all things that started at that point, over four years ago. Fast-forward – and I’ll also say, that document also had other things; the Go user surveys came out of that document, which we’ve just finished doing our fourth one of those. Improved IDE experience, dependency management - those were all things in that document. If you look at the things the Go team has done for the past few years, a lot of them were in there.

So now we fast-forward to me joining Google… I worked with Russ and Samir to obtain the right staffing, by presenting these concepts to the Google leadership. And they did, they gave us the opportunity to expand the team, which led to hiring Carmen and Julie, who then did most of the heavy-lifting of bringing the project forward.

Mat Ryer: Great. Well, thank you very much for doing all that excellent work. The thing you mentioned about package discovery is quite an interesting one, because for a while in the beginning of Go there weren’t that many packages; over time, of course, it’s grown, and so now people actually have a lot of different choices if they’re gonna bring in some dependencies and things. And it is a little bit like the Wild West… So do you see this as being a way to tame that a little bit and find some of the more trustable open source packages out there?

Steve Francia: This is not a Go problem. We think this is a modern software development problem. As you kind of get critical mass, the problem gets bigger, as you’re saying… But it’s a problem that every language is struggling with right now. Some to an extreme, and some – I think Go is actually on the smaller end of that. But we do see this as an opportunity to solve this problem for Go.

Mat Ryer: And will it take into account things like if packages have stopped being maintained, or if they do things that are generally accepted to not be great patterns, and things like that? Is it gonna be opinionated in that way?

Julie Qiu: Yeah, I definitely think it’s something that we’ve talked about and considered adding for the future. Right now, if you think about the Go ecosystem, the thing that’s really out there is GoDoc.org, which provides package documentation… But it’s missing a lot of this information about “Is this package still being maintained? Is this something I actually wanna integrate into my site?” So that’s definitely part of what we wanna do, especially atpkg.go.dev, now that it’s launched, we’ve laid the foundation… That’s all stuff we’re thinking about.

Mat Ryer: Julie, you spoke at – I’ve seen it a couple of times, actually… You do a talk about how to select good dependencies, and what to look for in things. Anyone interested in that should definitely have a search around. It’s a great talk, and you talk about things like “Are there tests in this package?” What are some of the other things that are important when it comes to choosing dependencies, and why is that important?

Julie Qiu: If I had to bucket it, I would say that the three main things to think about are popularity, quality and stability. By popularity, what we’re really wondering is “Are other people using this package?” The reason that that’s really important is because it essentially gives you a little bit of a heuristic of “Are there other people out there that care about this?”

Say the author suddenly decides that they don’t really want anything to do with this package; what are the chances that someone else is gonna step up? What are the chances that they’re gonna look for bugs? What are the chances that if I make a big part of my codebase depend on this, I can count on this being there in the future?

I think quality is things like “Is it a well-documented package? Does the code have tests? Does it look essentially like idiomatic Go code to me?” And you want that, because it gives you a sense of how familiar the package author is maybe with creating Go packages. And essentially what you’re evaluating when you look at third-party packages - is this code that I actually wanna put into my codebase? So if, you know, on a Friday afternoon I’m trying to deploy - which we all admit we do - you wanna know that you’re not gonna suddenly look at code that looks like something you’ve never seen before.

And then the third thing is essentially stability. Obviously, technology changes, the Go ecosystem changes, and so as things are changing, can I count on this author to think about where I am with my project? Something you don’t wanna see is someone had an exported function in one version, and then all of a sudden in the next version it’s not a major release, but that function got taken away… Because that is gonna create a lot of work for you as you are upgrading your codebase. That’s how I would go about thinking about it.

Jon Calhoun: One of our actual listeners had asked the question “Will any of this data that you guys are using to figure out what packages are there - I’m assuming you’ll be gathering some data - be made publicly available?” The specific question they were asking was “When you’re looking at packages, one of the ways you can tell if it’s a good package to use is if bigger projects are using it. So if Docker is using a package, there’s a good chance that they’re gonna step up and make sure it doesn’t die, whereas if it’s a bunch of really small applications, then popularity there might not matter as much as one really big entity.” If you’re planning on exposing that sort of data and making it possible for people to explore what big projects are using these packages…

Julie Qiu: It sounds like that information is – they’re looking for what a package is importing, and then what a package is being imported by. All of that information actually is already available today on pkg.go.dev.

What you would do is for any package that you’re interested, you can click on the Imports tab to see what other packages it’s using; or on the flip side, you can look at the Imported By tab and see who else is using this.

Mat Ryer: That’s cool. And that’s different to GoDoc, isn’t it? That new pkg.go.dev.

Julie Qiu: Mm-hm.

Steve Francia: GoDoc is just documentation, and the intent for pkg.go.dev is to be much more encompassing of these more rich information around each package.

Mat Ryer: Right, yeah.

Julie Qiu: Yeah, there is some information about imports and importers on GoDoc.org, but our goal is to take this information and bucket it in a way that’s something that people care about a lot more.

One thing that you might notice on the Imported By tab is that we tend to group the importers and count them depending on not just like – say Kubernetes has one package, and they’re importing this one thing 1,000 times. We wanna be thoughtful about how much that weighs into the popularity of the package.

Mat Ryer: Oh, I see. Can you explain that a bit more?

Julie Qiu: Yeah. So if you think about it like “Why do I care about popularity?”, essentially what it’s answering is telling me how many people have decided to use this package and integrate it into their codebase. One thing is that you might notice there’s one repository - let’s call it julieqiu.org/foo - and I have a million packages in there, and they’re all importing this one package. So does this third-party package now have a million importers, or should it really have one importer? It’s something that we don’t actually quite have an answer to yet, but that’s the kind of level that we wanna be thinking about it.

You can think about this in sort of like “Maybe I’ll count it as a million importers, but the way that users might wanna see it is that all of it is grouped under one thing”, so that you can answer questions like “Does one big organization use it, or does one really important module use it”, without seeing just a giant list of things that essentially are all telling you the same thing.

Mat Ryer: Right, that makes sense. Something else you mention in your talk, Julie, is about looking at dependencies for packages - how many dependencies another dependency has. So if you’re gonna important a package - say you’ve got two options. It might be sensible to choose the one that has fewer dependencies… But why really is that? Why do we care about that? Because it’s not our problem, is it?

Julie Qiu: Well, the funny thing is that a lot of times it feels like it isn’t our problem, until it is. In my talk I gave this example about this package called pad-left; completely hypothetical package… [laughter] And it might be transitively depended on by millions of different packages. And you personally never end up using pad-left, but if it got deleted all of a sudden from the Go ecosystem and all that code disappeared and you can never find it again, it could actually end up breaking a lot of your stuff and then you now suddenly have to be like “Oh no, how is this happening? I have to find the tree of things. I was depending on this…” So it can cause you a lot of problems, even though on a day-to-day basis it might not seem like this is something that actually matters.

Obviously, getting deleted is a really bad situation, but there are also other things, like security vulnerabilities, or maybe licensing issues, and other things along those lines that you think a lot about when you’re thinking about your own package, but you should really think about it with all of your dependencies, and your transitive dependencies as well.

Steve Francia: I think there’s an interesting thing here, too… We often reduce things to things that we currently have. The question you asked, Mat, was “Is it better to have more dependencies or less?” and there’s not an answer to that question. It’s really an “It depends.” If you have more dependencies, but they’re stable and they’re well-tested, and they’re high-quality dependencies, I will take that every day over a fewer number of lower-quality, less stable dependencies.

So I think really the question is not “How big is the dependency tree?” but “What is the quality of your dependency tree?” And are we really evaluating – anytime you import a dependency, it really becomes a part of your project, and I don’t think we really think about that as much as we should… That as soon as you do this, you’re inviting that code into your home, and now you’re responsible for it. So if you’re gonna invite them in, you wanna make sure that that’s something that you feel comfortable with.

So I don’t think quantity is necessarily the right measurement of that. I think quality is really the right measurement, and then multiplied by quantity.

Jon Calhoun: That’s a good point, because the standard library really is just a set of third-party libraries, it’s just one we know that is maintained at a very high standard… Whereas anything on GitHub or whatever - we don’t know really know what their standards of quality are… So it’s just kind of a gamble at that point. But if you know it’s an organization that has those same levels of standards, then you can kind of import those with a lot more – you can import more of them without as much fear of something breaking.

Mat Ryer: Yeah. This also helps package developers, if we think about what criteria people are gonna use, what they’re gonna look for in packages… If someone out there wants to roll their own package for something, then there’s kind of now a nice little – I mean, Julie, your talk is great for people that also want to do packages. There are some standards, there are some things that the community now is starting to expect… But I wonder, could this make it more difficult for new packages to emerge, if we start to really shine a light on the packages that are tried and tested? Can you see a world where we actually end up making it difficult for new packages to emerge, or is this sort of selection process gonna just be good for everybody?

Steve Francia: I’ll take that one. I’ll start by saying, if a package solves the problem really well, then there isn’t much of a need for another package. The standard library is a great model. When I first started learning Go, I looked at that as the pillar of excellence, and I tried to strive for that in the packages I wrote… And there’s a reason there’s not a lot of competitive string packages, because the Strings package does a really good job. But when there are ones, it’s because they fill gaps that that package doesn’t address.

So if a package is stable and well-tested, and does the job well, then we don’t have a need for an alternative. We need an alternative when there might be a fundamental shift in design philosophy, or there’s things that it doesn’t accomplish, and that’s a very natural thing that happens. We have a similar debate about companies; the larger a company is and the more established, does it stifle new companies being able to emerge?

There’s a big political and philosophical debate around that, but the reality is that over time we’ve seen that startups do emerge, and they’re there to fill gaps, and the larger a company is, and I will translate to packages or libraries - the more established it is, the less it has a chance to migrate and move, and it can’t adapt to maybe new requirements that come through… So when the requirements change, which over time requirements always do, it really opens the door for new packages to emerge and do that. I think it’s a very healthy thing for an ecosystem to have.

Jon Calhoun: I think the JSON package is a good example of this, where the one in the standard library is great, but there have been ones that emerged that sort of solved a slightly different problem. If you don’t wanna build a struct to get something that’s like six levels nested, there’s a couple packages out there that make it really easy to dive six levels in and get one specific piece of information and that’s it, from the JSON. And there’s other ones that maybe they try to be faster… There’s different goals, depending on what you’re looking for, and even though you think “Oh, the standard library has it. Nobody’s ever gonna compete with that”, the truth is people do compete with them because there’s specific goals that they’re going for.

And even if you look at front-end frameworks for JavaScript, you’d think at some point one of them would have just won out and everybody would have stopped… But they all solve different goals, and if something comes along and it’s unique enough and solves a different enough problem, I think we see that that tends to happen, it still tends to get some traction and move up.

Break: [19:59]

Mat Ryer: The Context package, when that happened - that was kind of one of those shifts you talked about, Steve, where suddenly now people expected to be able to cancel things that they couldn’t cancel before… For example like copying. Is there a context-aware copy operation in the standard library? If you do io.Copy(), it just copies the whole thing until the end of the file, right? Is there a cancelable one, or do you have to write that on your own?

Steve Francia: I am not aware of it in the standard library.

Mat Ryer: So use cases like that are – there’s still plenty of opportunity for anyone really to contribute, that’s the thing… So I’d hate for people to be put off because standards are going up; that doesn’t mean you can’t contribute something… And especially like – Steve, your point about “find the thing that isn’t already solved, and that’s where you can innovate.” I think that’s great, and I agree that raising the standards is only gonna be good for – for most people it’s gonna be great, because that is what we care about; we do care about good dependencies that we can rely on, and that are gonna stick around.

Jon Calhoun: One of the goals you guys had mentioned was helping companies understand what other people are doing with Go, and I guess learning from that, deciding whether or not to adopt it. I guess this is something that a lot of us probably don’t see; at least me, because while I want people do adopt Go, I don’t generally go out and talk to big companies and say “Here’s why you should use it.” So is that something that the Go team is actively pushing? Is that a big goal, to make it easier for people to understand that? Can you elaborate on what people are looking for, how you can help them? And if somebody is looking to maybe talk their company into using Go, what you’d recommend?

Steve Francia: We’ve spent a lot of time meeting with different companies, trying to understand what their needs are and what they’re struggling with. I’ll also say, one of our big goals as the Go team is adoption. We want Go to be used as widely as possible. And as part of the adoption journey, which we’re all familiar with that graph that starts slowly, and then there’s a chasm, which is early adopters, and then there’s the big chasm at the end of that, which is kind of mainstream… There’s different stages to it. And as a language growth, the enterprise is really that next big-cap for Go to be able to tap into adoption more.

We really got lots of adoption on startups and hobbyist very early, and so we recognize that the enterprise is important to get Go adoption to really fulfill its potential. As part of that we’re doing lots of research, and we’ve been talking to lots of companies, from all different walks - from retailers, to banks, to multimedia companies… From every different style of company and in lots of different continents.

And through those conversations we’ve heard two things that almost every company asked us, two questions almost every company asked. These are companies that are either thinking about using Go, or they’ve done a prototype with Go, or they’ve adopted it for some projects… So the two questions that everybody asked was “Who else is using Go?” and “What are they using it for?” As we talked to them, we heard lots of different stories which really got us excited. They talked about prototypes that they wrote in Go, and because they tried to talk to their management about it, they had challenges, and they thought Go would be a good solution for those, their leadership, the technical decision-makers wanted to know “Well, who else is doing this, and what are they doing with Go?” and they didn’t have good answers to those questions.

So a lot of those stories stop there. But some of those stories continued, and we had people that felt confident enough that it was a good decision that they kind of went rogue, and they built a prototype in Go, and it ended up being phenomenally successful.

So those pioneers in those companies really provide the things that they wanted before, which were these stories… So we’re really happy that we’re able to tell some of these stories. We’ve been working with these companies for many months to be able to capture these stories that they shared with us, and make them publicly available, and share them broadly. And hopefully, the next round of people answers to those questions, so that when they wanna go to their leadership and answer these questions “Who else is using it? What are they using it for? Are they in our demographic of company or vertical of company?” they’ll have answers to those questions.

It wasn’t just in these internal meetings, we also did different surveys, and this was one of the top things that people asked for in our surveys. Now, if you’re coming from a small company or you might be an individual consultant, this probably sounds foreign to you. But if you’re working at a big company… You know, on our website we’ve launched several case studies from big companies: American Express, PayPal, MercadoLibre… You can go on the website and see them all there. These are larger companies that have more hoops to jump through, more permissions to obtain, and this was an overwhelming thing that they’ve been asking for.

Mat Ryer: Yeah. It’s interesting, if you go to Go.dev, there are a lot of logos, but they’re not just – sometimes you see these on websites and you feel like they’re sort of brags, or something… But these are actually – you can click these and go and read about the actual ways in which people have used it, and what they’re doing there, too.

Carmen Andoh: You sure can.

Mat Ryer: You can, you can.

Steve Francia: You definitely can.

Carmen Andoh: Yup.

Steve Francia: I think they’re very relatable stories, and I think they’re very inspiring. As you click through and read these articles and these different stories… I remember back – I first adopted Go when I was working at MongoDB, very early on. And there was not a lot of these stories that existed yet, but in using it I fell in love with it. It lit a spark, and showed me potential of what a programming language could be… Which led me to work at Docker, which was a big Go user, and then eventually on the Go team at Google.

These stories shared a similar thing. If you’ve been using Go a while, read them; it’ll remind you why. It’ll take you back to that moment when you had the first a-ha and fell in love with the language.

Carmen Andoh: But the other thing that I wanted to point out about these case studies that I think are really useful is when I learn how to code, I am not taught how to influence my manager, or influence my higher-ups on choosing Go. That’s just not something that they teach you in school… And this is just the perfect thing that I can point to people, saying “I wanna choose this technology, and here’s why.”

I think so many people, when I had been in contact with them over the years, like “How can I convince my manager?” or “How can I convince my CTO?” or whoever in the organization, to use Go. Certainly, there’s the rogue tactic that Steve mentioned, but this now doesn’t – you don’t have to worry about going rogue, or taking yourself out of the critical path in order to get it adopted. You can simply go “Here, read the testimonials” and then make a commitment to trying maybe one service at a time, or refactoring one corner of your codebase here and there.

And what’s great about these is that some of them are more detailed than others, and they can give you a blueprint for how you might wanna do it, to certain extents… Whether you wanna go whole hog with Go, or whether you wanna maybe just instrument some of your observability toolset with Go, or you wanna do some of your automation.

So I really, really liked that, and I tell people now that certainly learning how to influence is a vital skill that they don’t teach in school, but this is super-helpful.

Mat Ryer: Yeah, I spoke to somebody at the last London Go meetup who – they were reluctant, because learning a new language sounds like quite a bit thing, especially for people that maybe only know one language; that was this case. But learning Go, especially if you are already familiar with the kind of C base language. Learning Go I think is easier than some other languages, actually, because of its minimalist nature… So I always kind of encourage that.

And I also like this idea of using it to solve a real problem you have, even if you’re not 100% certain of what it’s gonna turn out like. When you learn the context that you have, when you’re trying to learn something, if you’ve got context around a real problem you’re trying to solve, it really focuses the mind. You don’t go down the rabbit holes learning the details of how channels work, or how to do struct packing for optimum memory use. You focus really on the bits that are important in your case… And that was what this person was telling me - their experience. They were surprised how easy it was to pick up and to apply when solving some little problem they had. And I think it was a tiny little problem, but they loved that experience, and then they did a presentation to the rest of the people - anyone that would listen, really - in the company, to show it off. That’s quite a nice way to also evangelize for it, too.

Carmen Andoh: And to add further to that context, I also like the idea – when we talk about adoption, there are different mindsets, depending on where you’re at within your company and where that company is at. Sometimes what I often heard was “I don’t wanna just learn about theory” or “I wanna see what it looks like in practice, from soup to nuts.” And I think that’s the other thing that these case studies also – they have some level of detail that can tell you, hold your hand from end-to-end.

Some people like to just go around and play and find what works for them, but others just need to see what it looks like in practice, and see how that matured over time. I think the case studies is one of my favorite pieces. Well, I like the whole site, but I really sing the case studies praises, for lots of reasons.

Steve Francia: Moving forward with these case studies - we launched with a handful of case studies and articles that were published on external websites as well, and we’re excited to tell these stories more; to tell additional stories, to tell deeper stories, and we’re hoping that some of the listeners today are from companies that wanna show these stories. We’ll give two pieces of advice for that.

One is you don’t need us to tell the story. A lot of these companies, like Capital One, published several stories on their own blog about their journey to using Go. And we link to them here. So feel free to tell your own story; we’d love to link to it and give more exposure to it. Also, we’re happy to meet with you and to learn more about your experience and your story, and the best way to get in touch with us is if you go to Go.dev, on the very bottom, in the footer, there’s a Share Feedback link. Please fill out that link and tell us if you’re interested in working with us on a case study, or writing an article.

The most important thing - that’s an anonymous button, so if you want us to actually get a hold of you, you have to put some identifying information in there, so that we have a way to reach back out to you, or else [unintelligible 00:35:24.27] Which we’ve had a few companies do. “Oh, we’re really interested in the case study, and doing something” and then Submit.

Mat Ryer: Okay… [laughs] So put your name and email in, or something.

Steve Francia: Do it someway.

Julie Qiu: And also, if you wanna just send us a non-confidential email, you can feel free to emailgo-discovery-feedback@google.com. In case you can’t remember all of this, we have an About page on Go.dev. Go.dev/about has all of this information.

Mat Ryer: Thank you. We’ll also put some information in the show notes, too.

Will you have videos on there, and talks, and things from conferences, do you think?

Steve Francia: As we said in our blog post when we launched this - it was really us getting what we felt was like a minimum viable product out to the community, as early as possible. You’ll notice on the website we say it’s for the Go ecosystem, by the Go ecosystem, but it doesn’t have a ton of community resources on there yet. There is intent to add those items and to make it more of a place where the whole community can come together and learn more about conferences, and meetups, and talks, and really be a resource for them.

Mat Ryer: There’s an Event section on the homepage, isn’t there?

Steve Francia: Yeah. And it only gives you those three events… And I think they’re only meetups. It’s not conferences yet. So it’s a start, and we’re really happy that it’s there, but we have so many meetups around the world that – if you look on it today, it says January 11th, it has three meetups, but there are actually more than three meetups on January 11th. So it does give a taste to it, but we really wanna expand that further and really make it so that whether you’re in Melbourne, or Bangalore, or Eugen, Oregon - which happen to be the three on the website today - or anywhere else in the world, it’s gonna give you when your upcoming thing is, when call for papers or participation is due etc.

Mat Ryer: Yeah, that’s great. That’s gonna be really great to have that, because it’s difficult even for those of us that have been in the community for a while to know what’s going on. I think it’s not just gonna be a good resource for new people; I think for everybody.

Steve Francia: It’s also partly solving the problem that kind of crept up on us… If we look back two years, there was – I don’t remember the exact number, but around a dozen (maybe a little more) Go conferences. And this year, in 2020, there’s scheduled to be over 30 conferences throughout the year. That’s three a month. That’s pretty overwhelming. That means there’ll be more weeks with conferences than not this year. So with all of the excitement that’s happening around the community, it’s really helpful to have a place that organizes and gathers that.

We’re not gonna have that delivered in the next month or two, but it is on our roadmap and it’s things that we’re intending to do.

Jon Calhoun: One of the questions that I’ve seen people ask a lot, either on Twitter, or even on our GoTimeFM Slack - this is sort of intended to eventually be a resource for the community, so they’re all asking “Are there plans to make it open source, or to give the community a bigger role in the project?” I get early on it’s usually easier to not do that with a lot of things, but I didn’t know if you could share plans for the future with that sort of thing.

Steve Francia: It’s something we’re looking into. We definitely wanna make sure that whatever we do, it’s the best thing for the community and our users, and serves their needs the best way. We’re trying to make sure that we’re doing that in the best way possible. So there’s ongoing discussion; it’s actually part of our Go developer survey, we ask specific questions around this… So we’re ongoing doing research to try to better understand our users’ needs, and making sure that we’re satisfying them as best as possible.

Julie Qiu: Yeah, and something that we also are planning on doing pretty soon is opening up the Go issue tracker to accepting feedback. We already described that we have two different channels to get feedback - the email, and also sharing feedback in the footer, but obviously, these are all private topics, and we’ve heard everyone sort of saying they wanted a more public forum to be able to have discussions… So we’re actually working on a process for that, and are gonna be sharing that pretty soon. That’s another way that we really wanna be clear that we want people to share their feedback of us, like this is something that we wanna build for the Go ecosystem.

Mat Ryer: That’s great. In your pkg.go.dev, how do you decide what’s a popular package, and how do you decide which packages you’re gonna feature on there?

Steve Francia: So you’re saying on specifically that page…

Mat Ryer: Yes. Because that’s gonna be essentially – I mean, packages listed there are gonna be the ones people are using probably, right? …eventually, if not already.

Steve Francia: We hope so. To some degree, they’re already packages people are using quite often. That’s why they’re there.

Mat Ryer: That’s why they’re called “Popular Packages”, is it?

Steve Francia: Yeah, that’s how we got the name. That’s how we came up with it.

Mat Ryer: It makes sense.

Steve Francia: Believe it or not, there were several meetings to – no, I’m just kidding. We just did that.

Mat Ryer: [laughs]

Steve Francia: So Featured Packages is a little bit of a curated one. They’re largely popular packages as well, but they’re ones that we thought fit a niche, or address needs that people were looking for… And then Popular Packages is just the popular packages from the database, based on import count.

Jon Calhoun: When you’re looking at those curated lists, I know there’s always these – they’re like Awesome Go, or Awesome… You’ll see different lists like that on GitHub, that list a bunch of packages grouped by what they’re for. Some will be graphical user interfaces, others will be like database packages… And generally speaking, they do a little bit of curation, but I feel like sometimes they just throw anything and everything in there.

I guess one of the questions I’d ask is how do you guys draw that line between – you know, you don’t wanna reject people or be a gatekeeper, but at the same time you need to… Like, just having everything listed in one place isn’t necessarily useful… You know, just listing every single package that can connect to a database or something might just be overwhelming to users. So how do you navigate that middle ground?

Steve Francia: If we look back to the beginning of search engines, the early days of the internet, early ’90s, mid-’90s, you might recall that Yahoo! was one of the leading at the time, and they did it by doing the website directory, that was human-curated. And it worked well for a time. In fact, the reason everyone else struggled is you couldn’t really compete with the quality of that.

Then Altavista came out. And Altavista had accuracy and quality, and it was fast. Well, it was fast… It was fast until people started using it; there was a time when it was blazing fast, and everyone was excited…

Mat Ryer: Yeah, but Steve, all software is fast until people start using it. It’s the people using it that ruins it. That’s why we have to care about making things work…

Steve Francia: Well, then Google came around and figured out how to solve that problem too, of making it fast, and quality, and accurate. But I think there’s a lot to learn from that experience.

Awesome Go was and is still a great resource, but at the beginning, when packages were smaller, and there was less of a list, I think it was easier to maintain it and to keep track of it. As that list grows, it’s harder and harder for humans to keep on top of it. So what Julie talked about earlier was these signals, these visual indicators on packages – I think the solution here is not to maintain manual lists, but really to have dynamic things.

If you’re searching for – you know, sometimes you’re searching for things that Awesome Go curated predefined categories, but sometimes you’re searching for things that aren’t in those predefined categories. And no matter what you’re searching for, you really want to know quality… And I think it comes back to those indicators, to really help us. That’s the discovery portion of the site, that is still ongoing, that we’re working on.

Mat Ryer: I once wrote a blog post and made a little repo alongside it to show the code… And I made some changes to it at some point a couple years later, and I started getting people opening issues, saying “You broke our build.” This was just a repo to show off some ideas, it wasn’t ever meant to be imported by anybody, so I was shocked that that happened. Is there a way that package writers and package authors and maintainers can indicate to the tools Go.dev and to pkg.go.dev - is there a way that we can indicate that these things are deprecated, or perhaps shouldn’t be imported, or even to say “If you wanna solve this problem, there’s a better package over here, so go and use that one”?

Julie Qiu: I think to indicate that something isn’t working anymore, you can email us. We’ve gotten requests for people to take down their packages from pkg.go.dev. So that’s something that we do support doing.

I think in the future – some things that we’ve been discussing are like, say when someone archives their repository, for example, or deletes their repository, even if we might have the code for that to provide some kind of flag, so that people know about it.

We don’t currently have anything right now on the side for authors to say “You should use this package instead.” I think that that feature would require some sort of thought about what that user experience would actually look like, or if that’s something that we even want people to be able to do… So those are kind of the avenues right now.

Mat Ryer: Yeah. I mean, I would imagine something like a .go.dev file in the repo root, or something, where it could potentially have some metadata in there where we could communicate that. There are a few examples of that working quite well, where the tooling can notice those things. It’s probably just that - a few things like “Check out this package, these alternatives…” Because even though it might be nice for my ego that people are using some package I’ve written, if for whatever reason there are better packages, which believe it or not, does happen, I just want people to use those packages. I don’t want them to just use mine for the sake of it. So I would be happy to go and put a bit of effort in if that meant that the whole experience quality goes up for everybody.

Julie Qiu: Yeah, I think we’ve also discussed very early on during the brainstorming phase about other types of metadata that would help with that problem, too. For example, keywords would be great. If you could tag this package as like “It’s a logging package”, and so maybe that’s what your package is, and that way you don’t have to say “This is exactly the package you’re looking for”, but you can just have keywords for people to look in the ecosystem… But these are all things we’ve been thinking about and are still brainstorming about, and don’t quite know what it will look like yet.

Mat Ryer: Cool. No, but it’s exciting though.

Julie Qiu: Yeah. There’s a lot of cool places that we can go.

Jon Calhoun: It sounds like the experience you’ve described, Mat – it’s one I’m familiar with too, where you’re kind of doing educational material, and you want them to have something that compiles and runs, but at the same time by making it something that compiles and runs, it also means somebody can import it and use it, and it’s like “Well, this was clearly meant to teach, not to necessarily be the thing that does that.” So you might show somebody how to make an HTTP router, but that doesn’t mean that they should go use that one. There’s some way more stable ones out there that you should check out. So that becomes a little bit trickier, but… Maybe just having a way of tagging things is like “This is a learning resource, rather than something else that could actually help with that.”

Steve Francia: For this specific one – I think you bring up a good example of different needs that we might have, that expand beyond just the static metadata, of like readme and license files that we currently use. For this specific one, if you don’t want someone to import it, change the license to something that is dot-something-that’s-very-importable. It might be a solution to this specific problem.

Mat Ryer: But the tools won’t guard against that, will they? …assuming that everyone checks their license before they import a package…

Jon Calhoun: The other issue I have with that is let’s say I’m teaching somebody how to do something… A lot of the times I want them to have the freedom to take chunks of that code and use it. And if I say “This is some really restricted license”, then all of a sudden they’re like “Well, I can’t use what I learned here without fearing that I’m gonna get sued later for using this code.” And you kind of have to worry about that, where I know most instructors or people who do educational stuff basically just open source everything with an MIT license, because they don’t want people to feel like everything they learned is something that they’re worried about using that code.

Mat Ryer: Yeah. On the other hand, Jon, you’ve just thought up an excellent scam.

Carmen Andoh: Don’t give ideas.

Mat Ryer: [laughs]

Steve Francia: So the license question - I give that answer mostly tongue-in-cheek, because I think everything you said, Jon, is right. But we’ve heard from a lot of – while maybe not every individual is doing this, companies are very concerned with this. License compliance is a huge deal, because it can really get you into a lot of hot water. Every company and individual should be concerned with it, but the larger the company is, the bigger the defensive legal staff needs to be, and the more concerned they are with this. All of the Go tooling certainly doesn’t do this today, but we did build in more license awareness into Go.dev.

Mat Ryer: Yeah, it reports the licensing on all the packages, doesn’t it? And does it exclude things where you don’t recognize the license?

Julie Qiu: Yeah, so it excludes certain content, but not exactly the repository itself. So the way that we make that distinction is based off of whether or not it’s factual information about this repository, as opposed to content that we are taking and editing in some way. For example, what that package imports is not something that we would exclude, or something that imports it… Because that’s just factual information about it. Or the last time it was released. But things like its readme, and its documentation are things that we consider content that we are not able to redistribute.

If you look on pkg.go.dev and you’re thinking about whether or not you should use a package, and you go to the documentation page and we don’t think that its license is something that is redistributable, it will become really obvious really quickly.

Mat Ryer: So therefore on the other hand if you do want things including, then pick a license that is gonna allow this.

Julie Qiu: Yeah. That’s something that we had gotten a lot of feedback about right after launch, because our license policy had been a bit strict… And also, I think we haven’t provided a lot of information about exactly what information you need for your license… But we actually updated our license policy very recently. So if that’s something that you want us to know more information about, we’ve shared that we do license detection by using the license check library, and also a list of licenses and a copy of that content in case you wanted to pick one of the ones that would just fit on the site.

Mat Ryer: Great, yeah. There is actually a Go tool - because I’ve used it - which will check the licenses of all your repos as well. So I’ll dig that out and put it in the show notes too, because that can be quite useful. And it’s actually worth bearing in mind from the beginning, because it’s all very well – usually, what happens is you build the thing, you get it working, and then towards the end of the process someone from the legal team will say “Oh, just make sure the licenses make this all okay.” And then if it doesn’t, you kind of get yourself into a little bit of trouble… Or at least there’s work to do to go and either find an alternative, or you sometimes have to rewrite the little bits and pieces yourself. So yeah, it is worth checking the license, as Steve was alluding to earlier. Check the license before you import.

Jon Calhoun: I’m surprised somebody hasn’t come up with something like goreturns, that you can customize for each company, that basically just does that when you’re saving… Because every company has a different set of policies around what they’ll allow, and it would be kind of nice to just have your code flag it as like “Hey, you can’t import this. It’s not gonna work.”

Mat Ryer: Like a compiler-time error.

Jon Calhoun: Yeah. Because if you just had something, it would just build it into that; it’d be kind of nice to have.

Mat Ryer: Hm. Nice idea.

Carmen Andoh: That sounds like a slick idea, for sure… Especially now, with software engineering in this day and age, and all this reuse, and the risks that carry with that.

Jon Calhoun: Generally, I think people look on GitHub and they think “Oh, it’s open source”, but that doesn’t necessarily – people don’t always put licenses there, and something being open source doesn’t necessarily mean you can use it for what you wanna use it, especially if it’s commercial.

Carmen Andoh: Right. And the average software developer is not a lawyer… So they’re just pulling it in, saying “Hey, let’s see if it works.” Yeah… [laughs]

Jon Calhoun: I’m sometimes not even sure if the lawyers know for sure.

Carmen Andoh: That’s accurately stating the state of affairs in this day and age.

Mat Ryer: What language is Go.dev written in? I caution you to be very careful here…

Steve Francia: Elixir.

Carmen Andoh: [laughs] Steve…!

Steve Francia: What? Oh, are we not saying that?

Carmen Andoh: Redact… Redact…! No… Troll.

Julie Qiu: It’s Ruby on Rails.

Carmen Andoh: [laughs] I thought it was Haskell… It was Haskell, right?! [laughter]

Mat Ryer: So what’s the real answer?

Julie Qiu: It’s Go.

Mat Ryer: It’s Go! We’ll play some celebratory music there.

Carmen Andoh: Of course it’s Go!

Jon Calhoun: Can you talk about more of the technology? Is it an API, or are you using templates on the back-end? Can you talk a little bit about what you’re using to build it all?

Julie Qiu: Yeah, so the entire back-end is written in Go, and then the front-end is just all Go templates. The majority of it is HTML and CSS. I think for a really long time we had absolutely no JavaScript. And even now, it’s pretty limited.

Then the site itself is hosted on the Google Cloud Platform. The high-level architecture is we have a system that we call our data ingestion system, which essentially extracts data from the module mirror, and then transforms it, and then puts it into a Postgres database, which is hosted on Google Cloud SQL. Then the front-end - we also just have a service that is pulling data out of this Postgres database, serving requests… We have Redis, which we use for caching, and… Yeah, that’s a pretty high-level overview of it.

Mat Ryer: Is it Google App Engine, or…?

Julie Qiu: It is, yeah.

Mat Ryer: Yeah. I use App Engine all the time, I love it.

Julie Qiu: It’s very easy for deploying and scaling and all of that… So it’s been kind of nice, especially given that we had a small engineering team working on it.

Mat Ryer: Yeah. And it will scale significantly as well, won’t it? That’s something that’s nice, especially when you’re not really into the operational side of things. You can sort of not worry about it, so yeah, I’m all over that… It sounds great to hear.

Break: [54:53]

Mat Ryer: So, actually we have a new regular part of our show, and it’s gonna get its own jingle as well… It’s Unpopular Opinion.

Jingle: [56:20]

Mat Ryer: So we’re gonna ask “Do you have an unpopular opinion that you’d like to share?” Anyone?

Julie Qiu: I can start…

Mat Ryer: Please.

Julie Qiu: This just comes to mind, because people on the Go team make fun of me for this a lot, but… My unpopular opinion is that the New York City buses are the best way to commute across Manhattan.

Mat Ryer: Oh, that does sound controversial.

Carmen Andoh: Better than cabs, better than subway. Take the busses.

Julie Qiu: It’s so great!

Mat Ryer: Really?

Julie Qiu: Yeah. It’s basically an Uber Black car. It’s like a giant car, it’s come here, it’s picked you up, it’s got Wi-Fi, it’s got views…

Carmen Andoh: [laughs] We’re waiting for New York City mass transit to disrupt…

Julie Qiu: There are new seats on the M14 now…

Mat Ryer: You’re joking!

Carmen Andoh: Nice.

Julie Qiu: It’s so great!

Mat Ryer: That’s a great one. Steve, do you have one?

Steve Francia: My unpopular opinion is that I think Windows is the best operating system… And it was proven unpopular in preparing for this podcast. [laughter]

Jon Calhoun: So for anybody who isn’t familiar, when we do these episodes, every guest records their own audio, just so we have a little bit better quality… And I think Steve is our first guest with Windows – or at least our first guest with Windows who made me help him set up the recording, so I didn’t know how to do it, and had to figure that out.

Mat Ryer: Steve’s the first modern-day programmer I’ve ever met that uses Windows, actually… So Steve, yes, that is an unpopular opinion.

Steve Francia: I use the other operating systems, too. I’m not exclusive to Windows. But I really like Windows 10, I think they’ve done a really good job with it. I like Windows Subsystem for Linux, and I’ve got Bash in my Windows and I really feel very comfortable with it… I do develop on it, it’s my primary development environment, but I also – it’s nice that I can do photography work, and video editing…

Mat Ryer: Minecraft…

Steve Francia: I don’t do Minecraft on it, but I might play the occasional game, and Windows is quite good at that, as well.

Mat Ryer: What’s that little game with the grid, where you find the bombs?

Steve Francia: Oh, Minesweeper.

Mat Ryer: Minesweeper. Let me do that again, and we can edit that in. Minesweeper… [laughter]

Steve Francia: Oh, I like the way it was. I thought that was better.

Mat Ryer: No, but Minecraft’s on everything; I think Minesweeper is only on Windows. And I miss it. That’s the thing I miss from Windows.

Steve Francia: Honestly, I don’t even know if it still is on Windows. Let’s find out.

Carmen Andoh: 1997 is calling Mat, and it wants you back there.

Mat Ryer: I liked XP…

Steve Francia: No, it does not ship with Windows anymore, apparently… I just searched for Minesweeper and it did not…

Carmen Andoh: It wants to party like it’s in 1999.

Jon Calhoun: Apparently, people weren’t productive enough at work, so they had to get rid of it.

Mat Ryer: Yeah. I once dual booted my Mac so I could play the game of Minesweeper.

Carmen Andoh: Wow…

Jon Calhoun: You couldn’t find one online somewhere?

Mat Ryer: No, I didn’t have the internet. [laughter] Yeah, XP was alright… But actually, I know that they’ve put a lot of effort into Windows recently, for developers and stuff. And of course, you can be successful with Go on Windows, can’t you?

Steve Francia: Yeah, Go honestly was the language that let me shift to Windows full-time…

Mat Ryer: Said nobody ever? Steve, you’re the only person in the world where that’s happened…

Jon Calhoun: He’s not the only one.

Steve Francia: I’m not the only one.

Mat Ryer: Guaranteed.

Jon Calhoun: I think Brian Ketelsen uses Windows every once in a while…

Carmen Andoh: Yeah.

Mat Ryer: No, but Go led you. Go was your gateway drug to Windows, you know what I mean? [laughter]

Steve Francia: From my personal experience, other dynamic languages and other languages were a little more cumbersome. And I’m not a Windows, Visual C++ programmer, or .NET programmer. So using the more dynamic open source languages, I always found it was jumping through hoops, and you’d find edge cases that nobody else was hitting… And then Go just worked. And I could cross-compile from my Windows machine for all the Linux, and Mac…

Carmen Andoh: You’re like a walking advertisement for Windows. We’d better call them to sponsor…

Mat Ryer: I can’t believe you just said it just worked. That’s the Apple slogan. [laughter]

Steve Francia: That’s the Apple slogan?

Mat Ryer: It’s the Apple slogan, yeah.

Steve Francia: Well, they should live up to it more.

Mat Ryer: Yeah. [laughs]

Jon Calhoun: So did you ever use Java before then?

Steve Francia: I have spent my entire career avoiding Java.

Mat Ryer: Congratulations.

Jon Calhoun: Okay. I was gonna say, Java was one of the few languages where I didn’t have much issue using different operating systems.

Steve Francia: You had the same issue across all operating systems, you mean…

Jon Calhoun: Exactly. [laughter] But that was part of the reason why I learned Java when I was in college, and it was kind of the language I stuck with then… But then later I learned Ruby, and that one would have been terrible. Because I tried it on Windows and I was just like “Nope. This is not working.”

Mat Ryer: Yeah, met too, actually. Ruby was the reason I got a Mac. I bought a Mac so I could do Ruby on Rails. Visual Studio though, I have to say, was - and I think still is - very good for if you’re doing C# or any of the .NET flavors of things. Visual Studio was just amazing, really… And of course, VS Code, which is Microsoft - I think that is the most popular editor for Go on the Mac for people, still.

Jon Calhoun: Okay, so we have a little bit of time left… Do you guys wanna talk about the last aspect of Go.dev - the learning side?

Steve Francia: I was hoping we’d get to it, because that’s Carmen’s show.

Carmen Andoh: Is it my show?

Steve Francia: Oh, yeah.

Carmen Andoh: Alright…

Steve Francia: And it’s also kind of your show.

Carmen Andoh: It’s also kind of my show. I am both a guest and a host today. Pretty weird. Learn.go.dev - yes, it is what I would call the part of go.dev that I am really excited about, and is ripe for the most community collaboration, contribution and ownership. Some of the original feedback when it first came out was “Why didn’t my site/my YouTube channel make it in?” and to that, I say “Let’s talk.” Because I really wanna be able to do this.

The one thing that we’re finding when we’re doing – I did a lot of research and put a lot of work into wondering “Okay, how can we make this useful?” is finding who are the people that we’re forgetting about… What we’ve found there was 1) zero coding experience. We’re not even starting with Go as a second or third language… So we partnered with Codeacademy to provide that… Meaning “I know nothing about coding at all, and I wanna try Go as my first language.” And Codeacademy - that’s their bread and butter, so we partnered with them, and it was a really good partnership. There’s probably – the data that I can share is that we have roughly 70,000 people since they launched that course, and we made it available free, through a sponsorship.

Steve Francia: That’s a huge number, 70,000 people.

Carmen Andoh: It really is. I’ll share more later, but yeah… I get weekly reports on that. And there’s four modules for free; the whole course is eight modules. You can go to codeacademy.com.

The other gap that was missing was people working in companies that they just – for whatever reason, they didn’t want… The tour of Go wasn’t working for them, or other self-learning sites - Jon, Gophercises - and also other things… They wanted to be handed the problem that they wanted to solve. Like, “How do I do X in Go?” Or “From Java to Go for why?” So we just looked at some of the things that many people were using Go - the specialties, verticals, if you will - and we chose the four most common based on the data that we have via surveys and other research, and we decided to find and provide curated learning journeys for those learners in particular, and we got really good feedback for that. Thank you for taking me step by step.

Because what we found was there was two different psychological mindsets for adopters. If you’ve heard of Crossing the Chasm book - there’s early majority/early adopters, late majority/late adopters, and there’s a different psychology with each one of those. And the psychology that we’re finding with Crossing the Chasm is “I wanna just explore, I wanna learn, I wanna be given the space to kind of take the time to learn it…” Versus the late majority adopter, what we call enterprise, and that is “Just show me how to do it in Go.”

So that’s what the idea behind the curated learning journey is, based on these very specific “I have things that I wanna do.” So plans in 2020 are to continue to partner with more of the community to help find more gaps for those people for whom all the existing things aren’t working. We wanna keep it free, and we wanna be able to make sure that all the different – what we’re finding is that you ask ten people “How do you learn?” and you’re gonna get ten different answers. There’s so many different learning modalities, and we wanna be able to have a variety of learning modalities that appeal to a lot of people.

But the last thing is - and this touched on the events that we talked about earlier - the best outcomes happen when you learn together in-person, in a group. That’s really hard to do, but we’re hoping to leverage maybe meetups or online meetups. In-person doesn’t mean that I’m right next to you, it’s also leveraging tools like VS Code for pairing, and then learning together or going through together and hand-over-hand testing things out… So we’re trying to look into that a little bit more.

So I’ve asked a lot of opinions… Jon has a learning site, and I actually wrote to Jon; I didn’t know that I was doing it in that capacity, because we hadn’t make Go.dev public at the time… But I just wanna ask people’s feedback; I’ve tried to ask a lot of different people’s feedback for various things, and I’m gonna continue to do so, so that we can continue to make learn.go.dev really what we envision it to be, which is a collaborative work of art that is quality, and serves a variety of learners to bring in the next two million.

Jon Calhoun: Can I just add…? I know one of the things, at least from my perspective, that got me excited about seeing that site is that one of the things that’s at least hard for me is to reach people who have limited accessibility. Let’s say they speak another language, English isn’t their first language, or they need transcripts if they’re doing videos, or something like that… I know at least for independent creators, that’s a challenging thing, but I know that as the language grows, sometimes people will learn Go better if they can learn it in Spanish or whatever language is native to them… And I like seeing something with Google behind it - or it seems like Google’s behind it at least - in the sense that I feel like it opens more doors for that reaching a much larger audience, that it would be much harder for somebody like myself or anybody else to really reach.

Carmen Andoh: That internationalization is in our future, and it’s also been the thing that I’ve seen at some of the bigger conferences. We have people like Friends of Go, a company based in Spain, that wrote back and said “Hey, we have this training for Spanish speakers”, and we also have some trainers in a variety of countries, including India, parts of Asia, and then in Europe, that have also said “Can we collaborate?”

So if you wanna go fast, go alone; if you wanna go far, go together… So the name of the game for learn.go.dev is really seeking the feedback that we need to seek, and making sure that we get both representation, as well as quality.

Mat Ryer: Yeah, that’s great. And do you see that being a community aspect of this, too? Will it stay curated completely, or do you ever imagine people being able to vote up things?

Carmen Andoh: We go round and round on that. Some people say “Oh gosh, if we could vote up, vote down, that is gonna be its own quality indicator of itself.” The problem is everything can be gamed… So right now the only thing that can’t be gamed is people whom we can trust to be ethical about curating things, and also making sure that we constantly go back and feed into what the global community needs in terms of learning gaps, whether that’s content gaps, modality gaps, whatnot.

So for the forseeable future, it’s going to be curated. If at such time we could find a way to do voting that we don’t feel can be gamed, or turns into – you know, the thing I wanted to stop and prevent was someone saying “Go vote on my thing, because you’re my friend”, versus “Go vote on my thing because you personally learned from it, or you’ve found it to be very beneficial for you.”

But we’ve gone round and round on it. I remember having a working group or a roundtable at GopherCon in July in San Diego, and then we had about 15 people show up to two sessions, and this was an idea that came up… Someone really wanted to push forward on that. I continued to research it, and look into it, and ultimately said “Not right now”, until we can answer some of the gamifying questions.

Mat Ryer: Yeah. I mean, of course, even if there isn’t the mechanisms automatically or programmatically to vote, people do still have a voice, of course, in any of the communities they’re in. There is a great Go community on Twitter, and there are other communities. Of course, there’s a Gopher Slack… So yeah, I think – I’ve seen a few examples really in the community where although there isn’t an official way for people to share ideas and things yet, having the conversation out in public really does influence things, doesn’t it? So people’s views are of course heard, so therefore you should say it, if people do want to contribute…

Carmen Andoh: I think I will. The one thing that I want to start talking about more publicly is in order for a site to be useful, you’re navigating two things that pull up against each other. One is keeping a 30,000-foot view, to make sure that you aren’t having any blind spots, but you also need to dive deep down into the actual needs of a particular subgroup. So coming up and down and up and down is an incredibly challenging thing, and it’s one I hope to help with.

Steve Francia: Mat, you also mentioned their Twitter, and Gopher Slack… It’s important to recognize that the intent of this site is not to displace those great resources that already exist. So we say it’s “by the ecosystem, for the ecosystem”, but it doesn’t mean it’s gonna replace all the existing ecosystem solutions. The intent here was to fill some gaps that we saw were there. It’s largely a curation site; it’s actually to reference those existing things that are there.

As I heard you describing these voting mechanisms, it sounded to me a lot like Reddit. And the Reddit channel I think is great. I subscribe to the Golang Reddit channel, I read it every day. I always see good news, and new articles, and new talks on it, and I think that’s a great mechanism to get the voice out… And of course, the other things you referenced already. But if you want a voting thing, we have it. It’s the Reddit r/golang. Feel free to use it, it’s a really good resource.

Mat Ryer: Yeah, great. There’s also the Go weekly newsletter, and there’s a Changelog newsletter as well, which is the home of this podcast. So anyone that wants to sign up to that… You really can keep your finger on the pulse of what’s going on that way; it’s great.

Jon Calhoun: I will say, the only thing I differentiate between Reddit and the voting thing is just that Reddit is kind of – it’s not real-time, but it’s time-boxed, in some sense… Whereas I could see some value in voting for learning resources, but I completely agree that the way voting and everything works, it’d be very hard to do that correctly… So I completely get why you’re not doing it. But I do see that as slightly different from Reddit. Because I agree, it’s very similar, but I’ve seen tons of cases where – you know, I have free resources that I give out, and I’ve seen people post them; even though they’ve been posted on Reddit before, they’ll post them again and people are like “I’ve never seen this before”, and it’s like “Okay, clearly nobody is going back and searching these things”, or something’s happening… So there is some difference there.

Steve Francia: It’s also important to recognize, most of the content on the site is static. As Carmen said, we’ve talked about doing internationalization; we’re using a tool that lets us do internationalization with it… And there’s opportunities to – like, we do not have plans to do this yet, but we’ve made sure that the options are there later, if we wanted to add additional curators, maybe localized curators from different areas to help us with this as well.

So there’s an element there where we can open it to some degree and get support from the community, but also keep it tightly curated and a high-quality bar up there.

Mat Ryer: Well, I think that’s all the time we have for today. Thank you very much to our guests, Julie Qiu, Steve Francia, and our regular panelists, Jon Calhoun and Carmen Andoh. We’ll see you next time on Go Time!

Break: [01:14:14.21]

Mat Ryer: Hello, and welcome to Go Time! I’m Mat Ryer. Today we’re talking about Go.dev. It’s a user-friendly hub of curated resources for Go, and we’re joined by two of the brains behind it - Steve Francia (also known as @spf13) and Julie Qiu are joining us. Hello!

Steve Francia: Hi!

Julie Qiu: Hi!

Mat Ryer: And we’re also joined by Carmen Andoh and Jon Calhoun. Hello, you two!

Carmen Andoh: Hi!

Mat Ryer: How’s it going?

Jon Calhoun: Mat, I think you kind of lied. I think Carmen is partially behind Go.dev as well.

Steve Francia: Yeah, we’re actually joined by three of them. You just happen to be regularly joined by one of them.

Carmen Andoh: I’m stealth. I’m stealth.

Mat Ryer: Okay, I’ll do it again. So it’s three of the brains behind GoDev.

Steve Francia: And it’s Go.dev.

Mat Ryer: Okay, Go.dev. This is why we do it. So for anyone listening, this is how the sausages are made… [laughter] I have to do it again now, and make it sound like it was the first time. That’s the hard bit, you all know it…

Steve Francia: Yeah, you don’t call it like GoogleCom. [laughter]

Jon Calhoun: Actually… [laughter]

Steve Francia: [01:17:15.14]

Mat Ryer: Go.dev, okay. It’s clever, because it’s also the domain, isn’t it?

Steve Francia: Yeah.

Mat Ryer: Got it, thank you. Good. Alright, let’s do it again then, everyone. It’s fine, I’m not embarrassed.

Steve Francia: I thought you did a really good job, by the way.

Carmen Andoh: Same here.

Steve Francia: Other than the obvious mistakes, it was really well done.

Mat Ryer: [laughs] Yeah… Yeah. Okay, well there we go. This is why we do iterative development.

I joined the GoTime podcast and told them EVERYTHING about Go’s new branding strategy (and don’t worry, the gopher isn’t going anywhere!)

Listen to the podcast athttps://changelog.com/gotime/79

Transcript

Adam Stacoviak: And we’re live, too… Do you want a little music?

Carlisia Thompson: Yeah…

Adam Stacoviak: Let’s get some music going here. This is our 8-bit, Steve. What do you think about the 8-bit? [music playing] Yes…! Yes! Get it, BMC! Do you like that?

Erik St. Martin: Adam’s just having too much fun with this…

Adam Stacoviak: I’ve got problems, okay? I’ve got problems. Please do this show without me… [laughs]

Break: [00:40]

Erik St. Martin: Welcome back, everybody, to another episode of GoTime. Today’s episode is #79, and on the show today we have myself, Erik St. Martin, and Carlisia Pinto…

Carlisia Thompson: Hi, there.

Erik St. Martin: And joining us today from behind the curtains is also Adam Stacoviak…

Adam Stacoviak: It is me… I have arrived.

Erik St. Martin: And our special guest for today is the product lead on the Go team,Steve Francia. Welcome, Steve!

Steve Francia: Thanks for having me.

Erik St. Martin: Now, we’ve had you on the show before, so I don’t know whether we need like a whole intro, but do you wanna give just a little bit of background about yourself and the role you play on the Go team?

Adam Stacoviak: Maybe what’s changed since the last time we talked to you. Did anything change?

Steve Francia: I’ve gained weight since the last time you talked to me… [laughter]

Adam Stacoviak: Aside from your weight… Maybe along your role. Did anything change in your role?

Steve Francia: No. So I’ve been at Google about 18 months now, a little more… Actually, closer to two years. I’ve been the product lead at Google on the Go project the entire time. I think I’ve settled into that role a little bit more over time, but it’s been the same role. That’s it, there’s not a lot new with me as far as roles and stuff, so… Yeah.

Adam Stacoviak: How excited are you?

Steve Francia: [03:39] It’s an exciting time, it really is. I’ve had some good experiences in my career. I’ve been a part of MongoDB since the very beginning, and took it to when it was the third most popular database. I was an early part of Docker… So I’ve had some opportunities to be a part of something when it took off and it transformed, and Go is going through what I might even call a second surge, in that it’s really hit its stride, and you can feel there’s something tangible about it. This doesn’t happen very often with languages or projects in general… And it’s just a really exciting thing to be a part of.

Carlisia Thompson: Elaborate on that a little more, please. What makes you feel this tangible thing, that Go is going through a second surge?

Steve Francia: All projects kind of go through ebbs and flows, and that’s just the nature of life. When I joined the Go project, we weren’t tracking as close as we are now growth numbers, but it was lower than what we’re seeing now, by a significant amount. In 2017 the Go adoption grew 76%, and that means over 700k developers adopted Go in 2017.

Carlisia Thompson: Are you tracking that by number of downloads?

Steve Francia: No.

Carlisia Thompson: How do you track it?

Steve Francia: We use two different metrics to arrive at that. They’re both external surveys done of the broad developer community, and both of them paint Go as around 7% of developers using it… So that’s how we arrived at it. It’s the O’Reilly survey and the Stack Overflow survey. We found those are the most accurate way of telling broad developers, and between the two, we figured that’s a pretty good check. They do appeal to different audiences, they don’t always get the exact same numbers, but they’re always pretty close to each other.

Adam Stacoviak: I was at a conference recently actually, just this past weekend, atZeit. A small internet company – I guess I shouldn’t say small; it’s sort of maybe an up and coming cloud service, so it’s still in a smaller phase compared to other clouds comparatively… And one of the talks had Go in it; it was more like a front-end developer space, and I would imagine even seeing Go, and there’s Go in there. And if you do a little scroll-back in theGoTime.fm channel there, you’ll see aslide that says “Why not write everything in Go?” I was floored.

Steve Francia: Yeah, on top of just the raw numbers we’re seeing the number of conferences expanding, we’re seeing more participation, we’re seeing a greater diversity of talks, we’re seeing talks from more diverse people as well, and all sorts and types of diversity. We’re seeing an increase of Meetups, and not a day goes by really where you don’t see some interesting project that was written in Go happening. There’s just a lot of excitement happening around the whole ecosystem.

Carlisia Thompson: More conferences…

Steve Francia: Yeah, this year we’ve added five new conferences, if I remember right. So I think we’re up to 15 or 16dedicated Go conferences in 2018.

Erik St. Martin: Wow, that’s just wild how fast it’s grown.

Steve Francia: [07:57] Yeah, crazy to think. I’m excited forGo Europe, which is in Iceland; it’s coming up in I think three or four weeks now. I know this week isGo Singapore… There’s just a lot of conferences happening, and it’s so much that it’s hard to keep up with them all.

Carlisia Thompson: Yeah. So let’s talk about this branding… What prompted Google to take on this project? What was the reason behind it?

Steve Francia: So I’ll say it was mostly me… If you wanna blame someone, you can blame me. But it wasn’t anyone from Google corporate that was saying “Oh, we need to brand Go.” It came mostly out of, I think, two things. When I joined the team, one of the first things that happened - just a little experience - was we sponsored theDotGo conference, andAndrew Gerrand had moved to a new project (he moved toUpspin), so that left me in charge of sponsorships.

So we’re sponsoring DotGo, and they asked us for a blurb to go along with our sponsorship… So I started asking everybody, “Well, what’s our blurb? How do we talk about Go?” Nobody had one. We really didn’t know, and I asked people, and I wrote something, and I got lots of feedback, but… I got lots of feedback, and a lot of it was not consistent. Then came the idea that we really needed a more consistent way of talking about Go.

The idea behind thebrand guidelines that we published actually came out of – in spite of it being quite visual, the genesis of it came from that we needed a better way to talk about ourselves, and what the project was, and we needed it clear, and we needed to have it very digestible. So the branding actually started completely as text, and the visual element was added later to it.

If you look at the brand book that we’ve now published, and there’s ablog post on blog.golang.org on it, you’ll see the first part is the brand, and that makes up the entire first half of the book, and it’s all words… And they’re pretty looking words, right? There’s decorations around them, but they’re just words. And we spent the majority of the time focused on this, and trying to figure it out. So that was my personal experience.

Then I’ve done a number ofsurveys of the Go community, and two interesting things came out of those, as it relates to this. We found that there was a reoccurring theme of people that when they had tried Go, they fell in love with it… But they didn’t know how to communicate its value to their teammates or to their managers. And historically, the best way we’ve actually talked about Go was we’ve had kind of an unofficial slogan of “Try it and you’ll like it!” or “Try it and you’ll love it!”, and that’s reinforced by our website. When you go to the Golang website, what’s the first thing you see? Anyone?

Adam Stacoviak:Try it.

Steve Francia: [11:50] You see “Try Go.” It’s right at the top. Then you see a happy gopher and Download Go, which is also a way to try Go. That’s kind of the way we reinforce it, and that’s good, and for the early adopter audience that we’ve served for a number of years, the idea that you can just try it is very valuable.

As we go to more mainstream programmers, people that might not come with a CS background, the idea of trying a static- compiled language is a bit intimidating, and a lot of them are looking just to find out more about it.

When we heard this very consistent feedback that people when they use Go they loved it, but they didn’t know how to explain its value, we also heard feedback from people that are tech leads, or decision-makers, directors of engineering, CTOs etc. they didn’t know what Go’s value was. In our number of surveys and interviews we found they had heard concurrency and they’ve heard performance, but they weren’t really sure what Go’s value was… And it’s a tough thing, because with Go it’s not a single feature that really produces a value, rather it’s the amalgamation of all the features; when you add them all up it produces an experience that’s really unlike any other in computer science, and it’s that experience and how it scales over time that really produces the value. That’s a very hard thing to convey, and we tried to capture it the best we could with this brand.

Carlisia Thompson: That is a good point, an experience IS hard to communicate. People might have shared experiences, but also specific, distinct experiences, but I think having a guideline that helps them communicate different aspects of the experience could be very helpful.

Steve Francia: That was our intent. To go into a little bit more (if you’d like) of our process going through this - because I think it’s pretty insightful…

Carlisia Thompson: Yeah.

Steve Francia: We worked with a branding agency. We recognized this was not a core strength of our engineering team, branding, and the first thing that he did - the person we worked with, his name is Adam, and his agency isWithin… The first thing that he did was he just set a series of interviews; he interviewed all of the early project members, as well as a bunch of members of the Go team, to just get their feedback on what they thought Go was, and how they talked about Go. These were about 30-45 minute interviews.

Then he took all of that together and came up – he tried to distill it down to really its core essence. Then he worked with myself a lot,Chris Broadford worked a lot on this, as well asRuss Cox, and a bunch of other people. I think those were the primary three.

We just kept trying to distill it down further and further and further. It’s amazing how much time it takes to come up with a small number of words. I believe it’s Mark Twain who famously said “I’m sorry I wrote you a long letter, I didn’t have time to write you a short one.” I’m paraphrasing, that’s not the exact quote, but… It really took a long time to distill it right down to the essence of what we believe Go is.

Carlisia Thompson: [16:03] And I particularly loved the Tone of Voice section of the brand book, because it tries to really narrow it down… Because it’s one thing for you to say one word that tries to encapsulate what the language or what the community is all about; here we have a few words about what Gophers are, and corresponding words about what Gophers are not. I wanna go through the list, for people who are looking at this… Gophers are concise, Gophers are not verbose; they’re genuine, not dubious; they’re friendly, not exclusive; direct, not ambiguous; thoughtful, not reactive; humble, not haughty. Is that how you say that word?

Steve Francia: That’s right.

Carlisia Thompson: So I really like that the effort was made to describe what Gophers are not. It’s really helpful, and it’s really helpful when you are thinking of how to behave in a community, what is acceptable, or how to write code, what are good idioms - you start thinking about these things, and it helps.

Steve Francia: Thank you. I think especially with the growth that we’re going through, we can’t expect our culture to spread through all of this growth unless we codify it, and try and lead… So that’s a bunch of this, around like “Well, we need a single place as a reference to the entire global community”, whether you’re from Australia, you’re from Singapore, you’re from China, or you’re from Brazil, or you’re from Seattle, or anywhere, where you can have a single document that really reinforced what it meant to be part of Go. That was our goal of what we tried to do here.

Adam Stacoviak: I think branding was probably an extremely tough exercise, and the fact that you all started with words and interviews is a testament to the faithfulness to describe exactly what Go is, but then also what a programmer using Go may or may not be like, because a lot of branding is not really at all the visual part of it, while maybe some of the backlash or some of the surprise from the community is based on the visual pieces of it.

It’s the understanding who you are and why you do what you do, to explain who you are, is really the core component of a brand. You can’t show off who you are or visualize who you are unless you know who you are.

Steve Francia: What’s that?

Adam Stacoviak: I guess maybe what are your hopes here? I know that this may have been not a surprise to you, obviously, because you were involved behind the scenes, but I think for many it was like, “Okay, Go is almost nine years old…”, and here comes this - either brand or re-brand; I’m not really sure if this is a re-brand, because I’m not sure there ever was a true brand in place, to this degree… What are your hopes for the community to respond? When you released this, Steve - you wrote the article, the post on the Go blog - what was your anticipation? Were you surprised? What were you most surprised about? What were your hopes for releasing this to the world?

Steve Francia: [19:47] I’ll answer the first question - is it a brand or a re-brand? I’ll say there’s not a lot new here. In a sense, our real goal here was – as I said, I kind of started from that first experience I had maybe two weeks into joining the Go team, of having to write a blurb of who we are. I talked to Robert Griesemer and he gave me some feedback; I talked to Andrew, and he gave me completely different feedback; I talked to Ian, and it was different again. We really wanted to come up with what would be our story, our concise story that represents not only the Go team at Google, but the entire Go community, that we can have one way of talking about it. That really was the primary goal.

The other part was when everything is done kind of ad-hoc, you don’t have a lot of opportunities to make decisions, and I would describe the historical brand as mostly ad-hoc. When we are asked a question, when we need a blurb for this - we wrote a blurb for that; when we needed a website that looked like this, we did that.Renee has been fantastic in providing lots of wonderful Gopher designs, as well as a logo, which - I learned after that blog post launched - a lot of people didn’t know we had a logo before.

Everything was kind of disconnected in how it was designed, and we often designed something for an immediate need, without looking at the holistic picture. With this, we really took the opportunity to say “Look at all these pieces we’ve done over the last 10 years. How can we put them together and make some real decisions about which are the ones that we want to be our voice, or our mission, or our look?”

Now, there’s some new looks here. Definitely, the logo went through an evolution from Rene’s hand-drawn into a vectored image… And Rennee has used a lot of different colors over the years, and we definitely used that as inspiration as we came up with our color palette here. But yeah, a lot of these ideas had been floating around, but most of it was to provide just a single point that people could use as an anchor, and hopefully answer that question when people ask “How do I communicate Go’s value?” They can look at this and say “Well, this is what Go is.”

We’ve written a real clear description, and I’ll read it for those who don’t have it:“Go is an open source programming language that enables the production of simple, efficient and reliable software at scale.” That’s really what Go is, the best articulation we’ve ever heard or we were able to come up with of really what Go is. As we continue through it, our hope is that people use this as a reference, and that it can help unite the community.

Carlisia Thompson: Yeah, I got really caught up on the logo and the visual aspects of the branding, and I totally missed the point… I mean, the point is completely different, and I’m really glad you’re here to tell us and people like me who might have missed the point, too. And in fact, I don’t remember that we had a logo, and that was the question that I was gonna ask - so you just said that we did have a logo, but I don’t remember what it was…

Steve Francia: You are not alone in that, as we learned very clearly from some of the feedback we got. People misunderstood that Go had a logo, and the logo was the Gopher.

Carlisia Thompson: [24:03] Yes.

Steve Francia: So when we said we have a new logo, I think this is really – it was obviously a misunderstanding, but it came out of people’s love for the Gopher. The people have fallen in love with – this is the human side of a very technical project that we all love. I think there’s no one that doesn’t love the Gopher, and the reaction that we got was, I think, mostly stemming from that - people love the Gopher, and the thought of it not being around kind of gave people a shock.

That said, on our blog you can actually see the original logo. Not in the most recent post, but in a post a number of years ago, that we wrote on the Gopher… I’m actually looking it up right now, as we’re talking. So it’s onblog.golang.org/gopher. This goes through the history of the gopher, as well as Renee’s history with Plan 9 and other things, and it also talks about our initial logo, and it has a picture of it there.

Carlisia Thompson: With the black background?

Steve Francia: That’s right, the one with the black background.

Carlisia Thompson: Okay.

Steve Francia: And if you watch some of the old videos, you’ll actually see Brad andRob and others wearing T-shirts with this logo on it.

Carlisia Thompson: That is true, I remember that. I remember those T-shirts.

Steve Francia: So this logo was the official Go logo, although it wasn’t used very heavily. We used it on some of those T-shirts, and it ended up [unintelligible 00:26:06.01] but it’s not on the blog, it’s not in a number of other places. We’ve ended up using the Gopher far more when we created swag.

So that’s the old logo… The new logo actually started from a very similar place, and you can see it ended in a very similar place.

Carlisia Thompson: It’s very similar.

Steve Francia: And this logo… Renee drew it – I might not be accurate on this, but a number of years ago. I wanna say 2008 or 2009. A very long time ago.

Break: [26:46]

Adam Stacoviak: What’s interesting too is this blog post - I was actually gonna ask this question, in hopes of stirring up the [unintelligible 00:27:39.20] and story of the Gopher. I was not aware of this blog post, but this shares that; it has the history of Renee making it for a radio station called WFMU for a fundraiser they had, and it had a second appearance at Bell Labs, with Bob Flandrena’s avatar, and then again for Plan 9 as a mascot, and then I guess when the open source happened for Go, Renee suggested to adopt the mascot, and the Gopher was born then, right around 2009.

[28:15] It’s an interesting process, and you said, in a way, ad-hoc. So this gopher has kind of like made its way through several different forms and several different reasons for even being, to now be the beloved mascot of gophers.

Steve Francia: Yeah, it’s amazing what an impact it’s had on the project, and we owe Renee a huge amount of gratitude for her contribution to it. I think she really provided for us kind of our identity. We don’t call ourselves – in Python they call themselves Pythonistas, and everyone has different monikers. We don’t call ourselves the Go-ers, or anything like that. We’re gophers. And that comes from Renee’s mascot. And evenGopherCon and everything that’s come since, it all really stems from Renee’s mascot. I think she did an amazing job providing an identity for us, and our goal with the visual branding here was to really take Renee’s work and to build on it, and to try and consolidate it down.

Renee did a lot of work with gophers, and colors, and the logo… She didn’t do a lot of work with the website and other things, so our objective here was to really create a holistic presence for Go. You see the brand book, and it has some of the things… As I mentioned in our blog post, we’re also working on revamping our website to follow this new brand, and we’re pretty close to having the blog ready to launch. It should be a few more weeks. And that’s where we’re starting - we’re starting with the blog; we’d like to get the community involved as early as possible, and we hope to be able to take the work that we did on the blog and apply it to the website, and keep going.

As a part of this, we’re also extending our blog to support multiple languages, which is something we’ve never had before, and on follow-on reasoning using the same technology back-end for the website, which will also enable us to have multiple languages. There’s lots of components to our website, and we’re gonna focus more on the static content first, rather than things likePlay, where it’s more interactive… But we’re gonna stage it out, and hopefully have a consistent brand and feel across all of the different Go websites.

Adam Stacoviak: Was Renee involved at all in this process with Adam and the team, to interviewing and kind of self-examining the process?

Steve Francia: Rennee was - she was very involved. In fact, a lot of people were involved at the beginning for the interview, and then we spent a lot of time after their interview just working through everything and trying to consolidate things down, and that was a much smaller group. Then we’d go back to the larger group just for feedback every once in a while.

[31:47] Renee spent less time on the verbal part of the brand, but she spent a considerable part on the visual part of the brand, and she did so over time. She was very involved with it. She helped pick the color pallete, she helped name the colors, particularly the Gopher Blue one… She worked with us on every part of the visual aspect.

Carlisia Thompson: That sounds fantastic. I mean, I don’t know… Whoever was involved, you guys did a really good job. I personally really like it, so I’m just gonna put my bias upfront. I love it, I think it came out really well. Good job!

Steve Francia: Thank you.

Adam Stacoviak: Not that this is that important to dive into, but I think it’s kind of interesting the stark exact opposite response - and I know Hacker News isn’t the best place to have comments, it’s not the best place to meet the most loving programmers; however, there is such abacklash from so many people… I wonder why people feel like they should respond that way.

Carlisia Thompson: I didn’t see that. I mean, I didn’t look, either.

Adam Stacoviak: None of it seems really positive. Steve, I’m sure you had to dig into some of this, or at least be like “Come on - really, guys?” Someone says they’re incredibly sad, the logo is awful, it looks like somebody else’s logo… There’s a lot of just immediate gut responses, it seems, from some people, potentially even the larger community here on Hacker News… But again, we understand what Hacker News is; comments can tend to be not very positive. They seem to be right on point with Hacker News’ way of being somewhat negative about this process, and just bashing rather than uplifting; it drives me crazy.

Steve Francia: So what I saw– first, I wanna say I think a lot of this just comes from the fact of how passionate people are. I think people love the Gopher, I think there’s a lot of people that really love Go, and the thought of something changing has always been hard for people.

The brand is really the essence of something. There’s a visual element, as well as all the text… It really defines what the essence of something is, and people were worried that their beloved language and mascot etc. were changing. I think what we saw was a reaction to – you know, if people didn’t love Go, if they weren’t so passionate around it, we wouldn’t have seen that. So I think it’s a testament to how passionate people are around it.

Also, what we’ve noticed… The language on the blog post - I looked at it after this feedback and I’ve spent quite a bit of time on it… It’s right in the very beginning that it says “Built upon the great foundation that Renee French established, and rest easy, our beloved Gopher mascot remains the center of our brand.” As you scroll down, the Gopher is very present; it’s featured in the video that shows our Go logo design process and all the different – not all, but many of the iterations we went through with the logo. It’s also very prominent in the slide presentation, as well as it’s prominent in the brand book, all of which are featured.

[35:33] So I think we communicated the Gopher was very part of our brand well. Because the Gopher was a consistent part, but not the new part, we didn’t heavily feature the Gopher here, but made sure that it was included… But we focused more on things that were new and different. In spite of that, I think what we saw was some people reacting to some people’s reactions.

Some people misunderstood that the new logo was replacing our mascot, the Gopher, and they started tweeting about that, or posting comments about it, and then people reacted to that post, rather than finding out for themselves that that’s not accurate. So it kind of escalates… When people have a misunderstanding, and then people look at that without going to the source, it always escalates things, and that’s just a bit of a statement of where we live today, and the kind of world – I remember life before the internet, and how hard it was to find information; you had to drive to places, or walk to the libraries…

Adam Stacoviak: And you had payphones…

Steve Francia: Payphones… I remember we had these card catalogs, you had to look up – there were these giant dressers with all these papers in them that told you where to find things… It was very hard to find information, and now it’s very easy, and still people are resistant to doing so.

Adam Stacoviak: I think that’s funny too, because it seemed like the Gopher wasn’t really going anywhere; it also didn’t seem like - unless you read somewhere - visually, it didn’t seem like the Gopher, unless you looked hard, at least just real quickly at this blog post, the Gopher was kind of missing, quickly… From a quick visual glance.

Steve Francia: Yeah, I agree. You have to either press play or just scroll down a little bit, or click on any of the things. Yeah, I agree, and especially when other people are saying it. So I think what we saw was people reacting to reactions, and…

Adam Stacoviak: Misinformation.

Carlisia Thompson: But it’s sort of easy to see how people could have been misled, because like Adam was saying, the Gopher is not on the post itself; of course, if you go into the document, the Gopher is there… So maybe if they didn’t go that far…

Steve Francia: First youplay the video, which I know not everybody wants to play videos. Or if you scroll to the bottom, the last image has multiple Gophers on it… But again, we didn’t anticipate that people would have… I mean, shame on me; I should have anticipated more that people–

Adam Stacoviak: No, no, no, that’s not what we’re saying at all, either…

Steve Francia: I’m gonna say that… If I could have done it again–

Adam Stacoviak: [laughs] Shame on you, Steve.

Steve Francia: If I could have done it again, I would have put the Gopher more probably at the top. And I didn’t anticipate that people would have made the misunderstanding. That’s on me.

Carlisia Thompson: Can you not edit the post?

Steve Francia: I could, but we thought about it, and the reality is the post is pretty clear. The words are clear that the mascot is staying there, we’re not intimidating anything about the mascot going, if you click through the things… And again, as most people reacting to reactions, by the time the post went live, that was the time that people needed to hear that the Gopher was there in the beginning. So the window was really before it was posted, and we missed the window, but you know, I think if you give it time…

First, here’s a thing about change - people are always nervous at the beginning about change. Give them time - and I don’t expect that everyone is gonna love it… It’s a subjective thing; not everybody loves every painting, not everybody loves every color… You know, nothing appeals universally, but I think with a lot of people, give it time and it’s gonna calm a lot of their fears.

Carlisia Thompson: [39:47] One really strong reaction that I saw people having was that the playfulness of Go was there and now it’s not, because this logo is not as playful. Then, of course, it goes back to people equating the logo with the Gopher, and the Gopher is not going away (we’ve covered that), but that brings up a point too, which is when you codified something, it means now that is the right way of doing things, and if there is a right way, there is a wrong way, right? So how do we handle this, how do we know…? Because okay, Google sponsors things, you need to have your blurb, you need to have a logo… But how about us? How will we be using this in the wrong way, or what if we don’t use any of this - would it be wrong? Are we gonna get a call from Google’s lawyers, saying “Hey, you’re not using the proper material”? [laughter] How does it apply to everybody else?

Steve Francia: So I’m gonna answer this in two ways. One, there’s a few things here that are copyrighted, the logo being one of them, and the logo does have guidelines for its usage. So I wanna be clear that the logo needs to be used appropriately according to those guidelines. I wanna be clear with that upfront.

Beyond that, you are welcome to use this or not use this. This is meant as a guide for the community; no one came down from the mountain with stone tablets. We think it’s gonna be a valuable asset. We hope it’s something that the community embraces and uses. We fully expect everyone to continue to do their own thing, as they have. We just finished upGothamGo, and it continued to have its own brand… And I knowGopherCon this year is using a theme of race cars, and we fully expect them to continue their brand.

Carlisia Thompson: I was gonna ask what was gonna be the theme for this year… [laughs] Thank you…

Erik St. Martin: It’s all over the website already… Have you not been on the website?

Carlisia Thompson: Oh, okay… I didn’t know that, sorry. [laughs]

Adam Stacoviak:GopherCon.com, y’all.

Carlisia Thompson: Sorry, Steve, that was such a detour…

Steve Francia: Anyway, yeah. So I think people are welcome to use their own brand. We think this is something that can help inspire the community. We hope the community follows the values, we would like that to happen. We want people that are thoughtful, we want people that are friendly, but each group is welcome to adopt what they want to from this; there is no consequence for not– as long as people follow thecode of conduct, right? That’s independent of this, and that does have consequences.

Carlisia Thompson: So what does it mean when you say that the Go logo is copyrighted? That sounds pretty serious. Does it mean that we have to credit Google when we use it? Does it mean we cannot alter it, or what is it?

Steve Francia: Our logo is more flexible that’s used than most logos, but there’s guidelines within the brand book on what acceptable use is. We talked about what to license it under and spent some time with our open source legal team, and their advice wascopyright the logo is the appropriate thing to do. It lets people use it under fair use rights and under the guidelines that we’ve set forth, but they can’t make modifications, they can’t sell it, they can’t do different things to it because it’s copyrighted.

Carlisia Thompson: But can I place it anywhere without crediting anybody, or do I have to worry about giving credits?

Steve Francia: There’s no credit needed.

Adam Stacoviak: [44:04] The point of a copyright is just to say that it’s their mark and that no one else can use the mark in a trademarked or copyrighted scenario, and as a copyright holder you have to protect your copyright, because otherwise you don’t have a copyright.

Steve Francia: That’s right. And I’ll just say, I encourage people to ignore what I’ve said, butread the document. There’s two pages on what is acceptable use, with lots of diagrams and pictures of what to do and what not to do. We hope the Go community uses this, we hope it becomes – I don’t think it’s gonna replace the Gopher in any sense, but I do think that it’s a nice accent; it definitely reinforces our brand. The Gopher is wonderful, and it’s fun, and it’s playful; it’s not immediately recognizable as the word “Go” is. If you’re not familiar with the Gopher, and Go, but you see the word “Go”, you’re gonna associate that.

Adam Stacoviak: I think of it like maybe on product websites… Like when you go to a service and they support certain languages, what do you they put in place of Go now? They probably use the Gopher.

Steve Francia: They might, or a lot just come up with their own logo or their own thing.

Adam Stacoviak: Right. And what ends up happening is that there’s never a match.

Steve Francia: Exactly. There’s no consistency… So that’s what we’re trying to provide here, is that consistency, so that when you see this mark, you know it’s the language. And yeah, please read the document; it talks about all the different ways to use it. I was at GothamGo, I was the MC for the third or fourth year in a row, and I was thrilled that a number of the speakers used the logo on their decks. It was nice to see that consistency. Not everybody used it, and that was fine. I didn’t expect anybody to, exceptCassandra, who usedthe actual deck that we distribute, but she was also part of the process of creating it…

Carlisia Thompson: So just to clarify for people - on the blog post that is on the Golang website there is alink to download the master slides that you can use, that are already branded with the colors and the logo.

Steve Francia: That’s right, that’s right. And there’s also alink there to the brand book that we’ve been talking about. Those links are right next to each other under the download section.

Carlisia Thompson: And talking about the website, going back a little bit - is the website going to be decoupled from the language repo?

Steve Francia: Yes, the plan is to decouple the website from the language repo, and partly because – there was value in coupling it, but as we need to scale into different languages and different things, we can’t see another way but to decouple them. That said, there will remain documentation as part of the distribution, but the website itself will be decoupled, at least that’s the current strategy.

Carlisia Thompson: Yeah, I hope so, because the website would only be updated once there was a release… [laughs]

Steve Francia: [47:51] Yeah, right now it’s every six months, and… Yeah, part of the new design is also to provide a little more contextual information towards what’s happening now, and trying to keep our community members, our users more informed… And every six months is just not frequent enough.

Carlisia Thompson: Yeah… If you have a typo you wanna fix, you’ve gotta wait six months. [laughs] Or some new information, like a new link you wanna add, you’ve gotta wait six months.

Steve Francia: I’m pretty sure we can fix typos within six months, but our goal is to – it’d be great on our homepage if we had things like upcoming conferences, and keep our global community more informed, and that’s not possible every six months. We don’t have dates and links to the conferences; they are just too dynamic for that.

Adam Stacoviak: What are you doing to move faster on those fronts? You’ve just mentioned being decoupled… One of the things that helps a language succeed, other than obviously being a good language, is its supportive community, which Go does very well, but it does seem like there’s some slowness around these kinds of things, that could be sped up. Not so much that it’s bad, just like, how are you kind of optimizing for those things, to make those things a bit more faster?

Steve Francia: It’s a good question.

Adam Stacoviak: I mean, obviously, Cassandra came on the team recently, so you’ve got community things happening, so there’s some change happening; I’m just curious how it’s playing out.

Steve Francia: Yeah, I would actually defer to Cassandra on that. She’s doing an amazing job of really devising strategies and trying to help this community scale. I’ll say one of the smartest things we’ve done is actually step out of the way as Google, and let the community do what it does. That’s been very productive, it’s been very beneficial.

We’ve also realized there’s a balance there, and especially as we grow, there’s a lot of value in adding support. One of the things we’ve recently done - which I don’t know that we’ve talked about publicly, because it’s not public - is we’ve set up a communication channel for the different conference organizers, so that they’re able to talk to each other and start comparing things and trying to get more consistency. Google doesn’t have any stake in that, it’s not like they have to follow the guidelines or anything we’re setting forth; we’re not doing any of that, we’re just providing a communication channel. But trying to do things like that more often I think is a way to let the community do the brilliant job that it’s already doing, but also support them so they can support each other better, and do it better at scale. But the real answer is probably one that Cassandra could give you better.

Carlisia Thompson: So I get that a concise, clean brand is easier to communicate, so I get that part… I’m wondering if there is a hope that Go will be seen as mature as it is, that we will also have an impact on adoption not from the perspective of people understanding what Go does - that’s, of course, a big part if you’re going to adopt a language - but also because it will seem more serious and mature, and also that Google is investing in the language to the point of even wanting to do this… Is there anything like that in the general thinking for the reason to come up with this branding?

Steve Francia: [51:59] It’s a great question. I’m gonna answer it by pointing us to another part – in fact, it’s the final part that we haven’t really talked about yet, of the brand guide. There’s a section in it calledOur Audience and… We’ve never done this before. Go has had kind of an implicit audience from the beginning, of generally systems programmers with a CS background. And even though we’ve never articulated that, if you read through our material that’s been developed, and our documentation, it’s kind of the implicit audience. We don’t explain programming concepts anywhere, we expect that you know them, throughout our documentation. We often make comparisons to different languages (like C) in the documentation.

As part of this, we set forth that we really – for where we are, and the growth that we’re experiencing, and our goals, we believe that Go could be the next mainstream language, with broad adoption across the industry. And to get there, we recognize that there was three different audiences we needed to focus on, and we’ve articulated them in the brand book. The first one is potential in new programmers. These potential Go programmers and new programmers - meaning people new to programming - this is an audience that we haven’t ever targeted in the way that we want to target now… So this is an explicit declaration that we believe our audience is now people new to Go and new to programming. That has broad impact across all that we do. And we talk about the key messages that we want to target for that audience, and I’ll leave it to the listeners to read what they are in the brand book.

Our second is Technical Decision-Makers, which we use CIOs, CTOs and tech leads. These are the people that are often responsible for choosing architecture, approving architecture, and we wanna make sure that they have the support that they need. As someone who’s been in that role many times, I’m familiar with the – largely, your goal that’s always running through the back of your mind is “What are the risks in doing something?” As you know, in technical decisions there’s always trade-offs, and trying to understand what the risks are of a given trade-off or a given technology is important… So we have specific messages that we’d like to land for that, and this is part of the rebrand.

The third audience is existing Go users. We definitely want to embrace these new audiences, but also embrace our existing audience, and that’s the audience that’s served us well for ten years. We have key messages targeted towards that audience, as well.

So I think as you read through this, you’ll see… This is an answer to your question - part of it is conveying maturity; not just in visual, but in our language and everything else. We really wanna communicate the reality that Go is ready for production use, that you’re not taking a risk to use it.

[56:01] One of the challenges and opportunities of joining Google is you get to learn a lot of information that you didn’t know as a member of the community. Now I’ve got an opportunity to work with many companies who’ve embraced Go, some of which have been vocal about it, and some of which have not… And it’s amazing to see the ones who haven’t, and how Go adoption is much broader than I ever knew as a community member… And how these companies have embraced Go, and how often thousands of programmers are using Go within these major companies, that for their own reasons haven’t been vocal about talking about that yet.

We’re trying to surface that a bit more, and let people know that Go is ready, and Go is mature, and Go is a safe decision to make. So I hope that answers the question… I think that part of it is really – we’re trying to target different audiences, with different messages than we have in the past, and a big part of that is letting decision-makers know the value of Go, and how it’s not a risky decision to make.

Carlisia Thompson: It does answer the question, it makes very good sense… And it also made me very curious to ask you how is the adoption of Go inside Google now? Has that grown in the past year?

Steve Francia: I know we don’t talk about things like this. I’ll say broadly - Google does not share internal language usage, and I’ll just point out what is public already, which is this week we announcedgVisor, which is a new container runtime that works with Kubernetes and Docker. It is a sandboxed container runtime; it was announced a couple days ago. I believe it might have been announced atKubeCon, which is also happening this week… But I think it’s been a part of Google for years; we’ve just released it. It is I think a industry-transformative; it has the power to transform our industry, particularly in cloud. It brings a brand new approach to running containers in a secure and isolated way, and this entire application is written in Go.

I think you’ll see a lot of core Google projects that are being open sourced that are written in Go, and that’s probably the best answer I have for that question.

Carlisia Thompson: Thank you. I know why you can say it’s limited, but we always try to ask anyway. Someday, somebody will slip, I promise. I promise the listeners… [laughter]

Steve Francia: Yeah, as long as it’s not me… [laughter] Yeah, I encourage people to check out gVisor. You can see it atgithub.com/google/gvisor. You can download it, it’s open source. For all those people who are in our–

Carlisia Thompson: I haven’t looked at it yet… What is the equivalent of it out there that I would know?

Steve Francia: There isn’t any…

Carlisia Thompson:Kubernetes? I don’t know. What would it be…?

Steve Francia: [01:00:07.01] So it’s a brand new approach to securing containers… And there’s a post here that goes through it, but in short, historically we’ve used – in spite of how light containers are and how much power and benefit they bring, they don’t provide good isolation. It’s not one of their strengths, it’s not part of the design. So historically, there’s been two approaches that were used to provide that kind of isolation to them. One is to use virtual machines to emulate hardware, and that approach is expensive, but effective.

There’s a second approach, which is a rule-based execution, which is using things like SELinux and AppArmor. gVisor creates a third approach, that takes some of the advantages of each, but it takes a more simple approach. It’s a lot lighter than the virtualized approach, and it’s simpler than the AppArmor approach. Again, it’s a runtime for containers in a secure way, that works with Kubernetes and works with Docker.

Carlisia Thompson: Cool. I see now what you’re saying.

Steve Francia: I encourage people to read the [post](https://cloudplatform.googleblog.com/2018/05/Open sourcing-gVisor-a-sandboxed-container-runtime.html), the readme around it. It’s transformative in the way that it’s gonna make containers… In my mind, it’s really – and I’ve been part of the containers space for a very long time… This really is the project that tackles the biggest gap in what containers can do. With gVisor, I think containers are in a place where they really are the future, and there’s no more gaps. gVisor closes the last gap.

Erik St. Martin: Yeah, I’m actually really excited about it, and I’m kind of sad I haven’t got to play with it yet. Just getting back from Chicago and getting caught up, and about to leave for Seattle, so I’m like, “Nooo….!”

Steve Francia: Airplanes are good places to do work. You’ve just gotta download stuff, because Wi-Fi is not that good.

Erik St. Martin: This is true.

Steve Francia: Yeah, it’s fun to play with, and to look at… You know, written in Go.

Erik St. Martin: So I know we were running short on time… Do we have time for projects and news? Probably not. We might have to skip to #FreeSoftwareFriday.

Adam Stacoviak: We’ve got about two minutes on the clock.

Erik St. Martin: Two minutes on the clock… Alright, how fast can we do this? So gVisor was in the projects and news thing, and Steve mentioned it. Go 1.10.2 and Go 1.9.5 is out… There will be a link in the show notes to this really coolintro to the compiler, that is actually in the Go GitHub repo.

I found a cool project calledRat, we’ll link to that in the show notes. That’s a cool way of like running multiple commands and windowing them side by side, and then annotating them based on kind of patterns that show up in there. So that’s super cool. I think that’s everything… Did I get it in two minutes? [laughs]

Adam Stacoviak: Let’s see… You have…

Carlisia Thompson: Let’s say so.

Adam Stacoviak: Yeah, 35 seconds left.

Erik St. Martin: That should be a segment, once in a while… As fast as you can, 60 seconds or 120 seconds, as many things as you can mention…

Adam Stacoviak: Go in two minutes. I like it.

Erik St. Martin: [01:04:05.26] Alright. So #FreeSoftwareFriday - did anybody have anyone or anything they wanna give a shout-out to?

Carlisia Thompson: No…

Erik St. Martin: I’ve got a good one…Julia Evans - if you’re not following her on Twitter, you should, but she always puts out these amazing little graphic cards, explaining complex things in very easy to digest ways. Speaking of her, she’s releasing a zine with (I think there’s like) 20 or something of them in there, called Bite Size Linux. We willlink in the show notes to where you can pick that up if you wanna give her some love.

Adam Stacoviak: Excellent.

Steve Francia: I’ll give a shout-out to – so we had, as I mentioned, GothamGo just last week, and I saw a brilliant talk fromRon Evans aboutGoCV. Ron Evans - I know he was on podcast very recently (maybe even last episode), but we know him fromGobot and all the work he does with Go and embedded, and as part of that he started working on Go vision stuff - detecting different faces, and it can do different [unintelligible 01:05:30.12] and he gave a really interesting talk.

I’ll give one more - there was another talk by a man namedAnthony Starks about Go SVG. I was blown away by this talk. The amount of work that he’s done withSVG in Go was phenomenal, and the maturity of the libraries that he’s built is just – I was blown away by it. So big shout-out to both of them. I learned about these projects and I just wanna pass them along, because I’m excited to play with both of them.

Erik St. Martin: Yeah, and Ron is an absolute trip to hang out with. So if you’re ever at a conference he’s at, walk up and talk to him, it’s amazing. At GopherCon we always do a Gobot room that he hangs out in.

Adam Stacoviak: I met Ron a couple years back, I wanna say potentially our first year there… I don’t know, I can’t remember, but I just remember thinking like “This guy is fascinating!” Anyways… That’s Ron. Always a pleasure.

Steve Francia: I’m gonna put a link to Anthony’s GitHub account in the Slack channel. He also built this amazingtool to generate slide decks, and he presented with it, and his was by far the prettiest one there. Frankly, for me - I can’t stand XML, I try to avoid it as much as possible, but that’s why I’m glad people like Anthony exist… They make nice libraries so I don’t have to write XML.

Erik St. Martin: Alright, so I think we are about at time, or probably over… But Adam, the producer, is on the show, so he can’t really give us a hard time about that.

Adam Stacoviak: Nope. Nope.

Steve Francia: I wanna say I’m thrilled you all had me on the show, because it gave me a chance to tell the story around the branding, that it was clear that it needed to be told, and the blog post didn’t come close to telling the story of how we created it, and why we created it, and all of the depth in that brand book. I hope that people take the opportunity to really read it. We spent – I can’t tell you how many countless hours. The Go team invested a considerable amount of time in writing that document, because we consider it of the highest value to the project. And to be able to tell that story - I’m very grateful to be able to be on this show today.

Adam Stacoviak: [01:08:22.10] I’ll say you’ve got an open invite… When you have things like this, this important to the Go community at large, I would welcome even collaboration to give you all an opportunity to come on a show like this, that hopefully communicates to the largest Go community we can, in a larger podcast form… So we’d welcome having you back on again in the future.

Steve Francia: I appreciate it. It’s always a pleasure to be here.

Carlisia Thompson: Yeah, keep this in mind, because we could time things. For example, it was pure luck that today was the opening; I think it was really good that you came on the show to talk about this. We weren’t sure that we were gonna have enough things to talk about, but it turned out that we did, and I thought it was very insightful.

Steve Francia: I appreciate it. You’re right, it was a… What do they call it? It was fortunistic. There’s a better word for that…

Carlisia Thompson: Opportunistic.

Steve Francia: When things just work out right, and this was one of them.

Adam Stacoviak: Serendipitous?

Steve Francia: That’s the word that I was looking for.

Adam Stacoviak: There you go. I got your back, Steve, don’t worry.

Steve Francia: I was like… I knew I couldn’t get it. It’s serendipitous that this happened, and you’re right, we need to be proactive about it.

Adam Stacoviak: Yeah, we’re glad to work together however we can to make sure that the Go community at large has the right information to be excited, to be concise, and to be purposeful in their work.

Steve Francia: That’s what our goal is. We’re friendly, genuine… That’s what we’re going for. Concise - yes, but not so much in a 45-minute podcast… But definitely direct and thoughtful, we’re trying.

Carlisia Thompson: Yeah, it looks like you guys are trying.

Erik St. Martin: Alright, so I think we are definitely over now, so I suppose that we should wrap things up. Thanks so much for coming on, Steve. I’m really glad we got to talk about that, and to talk about the real reason that the branding was done… That it wasn’t so much about the logo, and that that was more a by-product of the core thing that you all were going for. Hopefully this clears up a lot.

So thanks, Steve, for coming on the show, thanks Adam for jumping in with us - it’s always fun to have you walk out from behind the curtain…

Adam Stacoviak: I try.

Erik St. Martin: And as always, thank you to all of you, the listeners. Definitely follow us onTwitter. You can hit us up atping to give suggestions for guests or topics, and with that, goodbye everybody! We’ll see you next week.

I joined GoTime to talk about the results of the 2016 Go Developer Survey and other interesting Go projects and news.

Listen to the podcast athttps://changelog.com/gotime/38

Transcript

Erik St. Martin: Welcome back, everybody, to another episode of GoTime. Today’s episode is number 38, and our sponsors for today are Backtrace and the Ultimate Go Training Series. Today on the show we have myself, Erik St. Martin, Carlisia Pinto is also on the show - say hello, Carlisia…

Carlisia Thompson: Hi, everybody.

Erik St. Martin: And standing in for Brian today we have Johnny Boursiquot.

Johnny Boursiquot: Hey, hey.

Erik St. Martin: And our special guest today is a long-time member of the Go community and has a number of well-known projects that I’m pretty sure all of us have used. He recently became the community manager for the Go team… Please welcome Steve Francia.

Steve Francia: Hey!

Erik St. Martin: So how’s things in the Go community management world? Actually, give everybody a little bit of a background on yourself first, for anybody who might not be familiar with you already.

Carlisia Thompson: And tell us your correct title, because I don’t think that’s it.

Steve Francia: That is not my correct title… We can start there. My correct title isn’t all that accurate either, but I’m the Go team technical program manager, with an emphasis on the external usage of Go. But it’s really an interesting role that does have community management as a part of it. Also, a good element of it is product management. Largely, I’m working to be a voice for the Go users to the Go team, and help strategically align the Go project in a scalable way, that meets the needs of all of its users.

Erik St. Martin: So this is from the perspective of people outside of Google itself, and their usage of Go and their needs, as opposed to internal…?

Steve Francia: It’s all-purpose, but it’s not specific to Google’s needs. I treat Google like every other company that uses Go. We definitely are listening to their needs, but I’m not focused on those needs any more than I am any company that uses Go.

Johnny Boursiquot: So do you have a counterpart inside of Google who is focused on what Google needs from Go? Or how does that strategy work out?

Steve Francia: There’s another project manager that’s focused on cloud usage, and he does both internal, but primarily external usage. I don’t know if we have yet, but we’re looking to bring in someone similar to work with internal users and understand them a little better. But for the last few months, I’ve been kind of juggling both, and not well. I have to prioritize all users, versus just one set.

Johnny Boursiquot: I remember when you first joined in this capacity at Google, one of the very first things you were involved in was the whole dependency management conversation.

Steve Francia: Yeah.

Johnny Boursiquot: Is that something that you’re sort of pushing internally, or did you just sort of bring it in as something to be addressed and then move on to other things? How does that relationship between the community and you advocating on our behalf to Google - how does that work, typically?

Steve Francia: [04:02] As someone – we didn’t really go into my background yet, so I’ll speak briefly to it, because it’s a good introduction to this topic. Prior to joining Google and the Go team at Google, I ran engineering in open source at Docker, and before that I ran engineering and lead open source in the developer experience at MongoDB. At Mongo I first discovered Go, we adopted it for a number of our projects there, and I personally fell in love with the language and started working on some side projects, some of which have grown far larger than I ever would have expected them to.

Hugo is one of them, it’s a website generator. When I sat down to write it, I knew how I wanted it to work, but there was libraries that I needed to create it that didn’t exist yet, so I wrote a number of libraries in tandem with Hugo. One of them is calledCobra, another is calledViper. Those have really been broadly adopted through the Go community. So I came in from having a unique perspective of using Go both for personal side projects, as well as in a company environment, and having had those experiences, I was pretty familiar with some of the pains and rough edges, and dependency management was one. I highlighted that one with the team… It wasn’t something that the team wasn’t already aware of.

The team does listen to the users and tries to understand… One of the challenges is that the team works inside the Google infrastructure, so dependency management was something that they didn’t have their own intimate familiarity with, in the same way that the users experience it.

Erik St. Martin: I think also in addition to that though, there’s also a distinction for who’s responsibility is it, right? Is dependency management part of the language or not, right?

Steve Francia: Yeah. Through a series of conversations we’ve tried a couple different things. One was we formed a working group, and I was closely part of this;Peter Bourgon really drove this effort, to kind of address this need. It was a combination of people from the community and the Go team working together on it. Through that we’ve done a lot of diligence, had lots of conversations with different users trying to understand those needs… We’re working on a prototype which has been released, and we’re also looking at – I think we’re coming to the conclusion that for it to really work, it needs to be something that the Go tooling is aware of.

I’m not sure what conversation or experience arrived at that, but that was a critical thing for us to understand, because all the efforts by the community can only go so far. Without the Go leadership understanding the need, and realizing that it’s something that to really be successful we need to make all of the tooling aware of, they could never bridge that gap. So getting the understanding to the team was a critical milestone in this. There’s still a long road ahead to delivering the right solution, but the work that the working group is doing is a huge first step towards that.

Carlisia Thompson: Just to get that straight… Peter Bourgon was leading the design and the specs, andSam Boyer is leading the implementation - is that right?

Steve Francia: [07:57] I wouldn’t frame it that way. I think Peter’s leading the efforts. Peter is the one who really got the group together and ensured that they had meetings regularly and kind of set up the schedule. I’d call him more like a project lead. There’s four people on the working group; I think Sam is definitely one of the active people in that, but there’s four of them. I think they’re all contributing quite a bit. I’m not sure if one of them is the lead of it over another, but I know they all meet regularly and are building stuff together.

Carlisia Thompson: Yeah, we had him talking to us two I think.

Erik St. Martin: Yeah, I think it was two episodes back. Yeah, I think Sam focused on the packaging solver, kind of like the dependencies.

Steve Francia: Yeah, Sam loves GPS and that problem, and he’s really spent a lot of time on it, so it makes sense that he’d be focused on it.

Carlisia Thompson: And I don’t want to leave a question unanswered…Cory LaNou is asking who is the person on the Google Cloud’s side that’s doing the work of advocacy? I think that must beFrancesc Campoy?

Steve Francia: Yeah, Frances is the advocate for all of Go and Google Cloud, as well.

Carlisia Thompson: Got it.

Erik St. Martin: Recently - this was just a couple of days ago - you had published a survey from 2016 on the Go blog. I’d love to chat a little bit about that and maybe some of the things that surprised you, some of the things that you’re proud about, things that you wanna work on in the future based on what you observed from this.

Steve Francia: Yes, so for those who aren’t familiar, the Go team has never done a survey of this kind before, and it was a pretty massive undertaking; to be honest, I’ve never done a survey of this kind before either, but I recognize that there was definitely a need to get data from our users and to listen to them and to collect as much information as we could. So we set out to create a survey and to get our users’ voices heard, and we did. We went through and we created a survey, we refined it through user testing and sent it to the community, and we had a phenomenal response. Over 3,500 people responded to the survey and we gained lots of insights into the different ways that we can address the needs of the Go community.

I will say a lot of the things that we learned were confirmations of the things that we had already suspected, but by doing a survey, it gave us great metrics around knowing… Like, “Okay, we know this is a problem for some users… Now we know this is a problem for 30% of users”, where before it was somewhat speculative how big of a problem different things were.

So a lot of the things were reinforcement, but also giving a lot more accuracy into the extent of some of the challenges that we had. And of course, there were some new things that surprised – I won’t speak for the whole Go team, but there were definitely things in here that surprised me when I saw them.

Erik St. Martin: I think the other thing that doing the survey and having the metrics works well for is being able to basically timeline it out and to look next year and see how much you’ve grown and solved some of these problems. Prior to that, like you said, it’s all been speculation.

Steve Francia: I think one of the great things here is we do establish a baseline, and we’re able to see progress and how the community and user base evolves over time.

Erik St. Martin: Yeah, one of the things I was surprised to see was more than half of the participants use Go at work, and we can only speculate about a couple of years ago, but I’d have to venture a guess that there were a few big companies using Go in 2013-2014, but I’d say most people were probably hobbyists back then… It certainly wasn’t half.

Steve Francia: [12:05] Yeah, if we go back… It depends how far we go back, but there was certainly a point - probably around the first GopherCon - when it was clear that Go was of interest to a large group of people, and yet the adoption wasn’t quite there. And that’s a normal growth curve of any technology - companies won’t adopt something if there’s not people that can do it, that know how to use it, so it really has to start with people’s interest.

I guess we were all fortunate that Go developed the interest, and as we’ve seen it progress, companies are adopting Go more and more readily, so more and more users are being paid to write Go.

Erik St. Martin: What do you think the developer pool looks like right now? Obviously, you can only speculate there, but do you think that people have a hard time finding Go developers right now?

Steve Francia: I think there’s a number of different factors to this. The first one is Go is actually a really easy language to learn and to pick up, and especially to read. This makes it so that a lot of companies aren’t looking for Go developers; they’re transitioning existing developers to Go, and that’s a viable option. We’re seeing that a lot across a lot of companies.

It’s also the case that we don’t have a great marketplace yet to find Go developers, especially ones with experience, because Go is relatively young, so a lot of job requisites… You need to have 5-10 years Java experience, or whatever the language is. It’s gonna be very hard to find a Go developer with five years experience; there’s just not that many out there, as the language is pretty young. So it’s kind of an interesting dynamic… I think in time this is one of the things that will definitely sort itself out, but it’s pretty easy to adopt Go, and at the same time, the language being so young, it’s hard to find people with many years of experience.

Johnny Boursiquot: This is where I think that obviously the makeup of the community is critical as well. I think in my travels to the Go community I find very enthusiastic people within the community. They’re passionate about the language, and beyond that, they’re passionate about building a great community. If you’re attracting people who not only care about the language, but they also care about bringing everybody else, basically attracting other people into the community, you’re gonna help solve this supply versus demand problem that obviously the business is gonna be looking at.

We do a lot within the Go community, whether it’s through meetups or through community events… There’s a lot going on to attract people to the community. I think that’s gonna help a lot.

Steve Francia: Yeah, I think it’s always a chicken and the egg problem here, but I think we’ve got a great community and really passionate people that love the language. And yes, a little more than half are using Go at work, which is great, but slightly higher is the number of people who are programming Go outside of work. These are mostly people who do it out of passion, and I think that just speaks to – these are people that love to program and they found a language that they really love using, and that’s something that other people see and they catch on.

I think there’s some work that we need to do to make Go – around the resources… Not really changing the language, but better resources and more support around our new users, but I think there’s a lot of the core ingredients there that make Go just a wonderful language, and people are gonna adopt it; people are already adopting it at a pretty brisk pace and I think that’s gonna continue.

Carlisia Thompson: [16:20] There is so much to talk about community, and there’s a lot about community in the survey… One thing that caught my attention related to community is a question that says, “What is the biggest challenge facing the Go project today?” and the top answer with about two percent (there were many answers to that) was “community.” I don’t know what that could mean… Do you have an idea, Steve?

Steve Francia: Yeah, so one of the challenges we have with the survey is it’s really easy to present accurate results with multiple choice, or questions with already determined answers. And questions that had open text box answers - it’s much harder to present that data. What we’ve done here is really kind of a simple metric - how often a given word appeared. In this specific question you’re talking about, there really wasn’t anything that could be gleaned by using that approach. There were just too many words and not enough consistency across them.

Reality is I was able to read all of the answers to every question, and there were tens of thousands of comments that people left. In this specific question there really wasn’t a theme that emerged. I don’t think there are things that the users really fear as big challenges the Go project faces.

I think there was a bunch of comments that people expressed, and a lot of them were even comments that said, “Because of this, we don’t really have concerns.” So in this specific question, there’s not a lot you can gain from that chart.

Erik St. Martin: Alright… Because basically if I said “The community needs to come to a consensus on dependency management”, dependency management is actually the thing that should be bumped up, not the word ‘community’, right?

Steve Francia: Yeah, exactly. A good example of a question where this did work well is when we asked people about what would improve the Go documentation. Overwhelmingly, the most common word was ’examples’. In reading through the hundreds of responses that we got to that, it was very clearly the case that users want more examples. With that chart, popular word did demonstrate pretty well what people expressed.

Carlisia Thompson: Yeah.

Johnny Boursiquot: Along those lines… The survey tried to also gauge what other languages are people coming from, that are sort of adopting Go. I’d be interested in your take of whether Go itself is seen as an elitist language, that it attracts a certain kind of developer or a certain kind of individual with previous experience in another programming language, be it dynamic or static. Do you think that Go is a good language for beginners and people who have never programmed before? Do you think there are things that we can do to attract the brand new to programming folks to the language, to the community?

Steve Francia: I heard a few different questions there, and I’ll try and address each of them. For me, one of the big surprises from the survey was often I think of Go - and I think most of us do - as a language that people convert to from a different language… Mostly because Go is such a new language, most people already learned another language and they’re coming to Go. And they bring with them - just like learning any new language - the foundation.

[20:19] I think one of the interesting things that I learned from the survey was one-third of the people who said that they had experience in Go said that that was the language they had the most experience in, more than any other language. This for me conveyed the idea that Go isn’t just a language for people to convert to. It’s a language that people are learning programming through, that they’re coming to for the first time, or it’s a language they’ve spent the most - I won’t say most time in, because we asked expertise, and time isn’t a very accurate measure of expertise, but it’s the language that they felt they had the most knowledge about, and they felt the most comfortable using. I think that was really interesting… I didn’t expect that, and partly, I guess, I come in with my own perspective. I knew a good number of languages before Go, but it’s interesting that a lot of users consider it their language of most experience. In fact, more users were in that bucket than any other bucket.

Erik St. Martin: I’m actually really surprised by that, because I probably come in with the same preconceptions, that most of us have experiences with other languages, we have years of history with those languages, so it takes a long time for our skill in Go to overtake our knowledge in a language we came from. So that’s actually really surprising to hear that. People are getting more experience and expertise in Go than the languages they came from.

Steve Francia: For me what I realized was a lot of people are coming from dynamic languages. JavaScript and Python are the two biggest languages; there’s others in the list, but there are definitely some properties of dynamic languages that differ from Go. If we look at a lot of the documentation, the experience that the Go project has catered to with its early adopters, it wasn’t as much the dynamic languages. For me, that was one thing that I learned through this. The second thing was what we just talked about, that a lot of people are coming to Go for the first time, or that their Go experience has eclipsed their experience in other languages.

Erik St. Martin: I think it’s about time for our first sponsored break, but after that I wanna chat a little bit about the way people are using Go, because I found some of that stuff interesting, too. Our first sponsor for today is Backtrace.

Break: [22:54]

Erik St. Martin: Alright, we are back talking to Steve Francia, and we’re talking about the 2016 survey results and some of the stuff that we find interesting there. Before the break I mentioned the uses of Go. One of the things that I actually found surprising was that web development actually seemed to overtake systems programming on there, because it felt at least in the early days that people struggled with how to do web stuff, because - as we were discussing - a lot of people come from JavaScript and Python and Ruby into Go, so they’re used to having things like Django and Rails and things like that. So I actually find it interesting that web development is the leader in the uses.

Steve Francia: [24:25] I’ll clarify a little bit… We asked two questions, and they’re easy to mix up because they’re very related. One was “What areas do you work in?” and in that one, web development was overwhelmingly the number one option. If I think about that… I work for Google - is that a web development company? It probably is.

Erik St. Martin: That’s fair.

Steve Francia: Google probably checks a lot of these boxes, actually… But the internet is such a prevalent part of what people do… At first I was surprised by that, but the more I thought about it – you know, there’s a lot of companies that are in web development, and this was one of the questions where you could pick as many answers as you wanted, so it does apply pretty broadly.

But there’s another question, “What do you write in Go?” and in this one “web services”, defined as a service returning HTML, was still over 50% of what people used Go to create. Now, this was another one where the total percentage is added up far more than a hundred, because people could choose more than one. But I think it’s illustrative. There’s no question people are creating web services with Go, and in large amounts.

Erik St. Martin: And even though they don’t rank as high on the list, other surprising ones that were in there were embedded devices, people writing Internet of Things devices using Go.

Steve Francia: Yeah… It was interesting the spectrum that – in the options that we asked, a lot of them were well represented. It showed a lot more diversity than I expected. I’ll just speak for myself there, I was surprised by the diversity of the different areas that people worked in and used Go.

Erik St. Martin: Yeah. I’ve heard of some embedded stuff and security stuff, but I didn’t think that it was enough to register. I didn’t think it would show up, I thought it would be lumped into other…

Carlisia Thompson: So when you look at these answers in particular, Steve, do you have a feeling that the answers that are more popular by the areas where you want to invest in, or the opposite, you wanna bring up the areas that are less popular?

Steve Francia: It’s a good question… I honestly don’t think popularity was a big factor for what we were gonna invest in, alone; I think it’s a combination of looking at where our weaknesses are, and comparing that to what the demand is for those things, and trying to pair those together. A lot of this post identifies some of our (I’ll call them) challenges that we have ahead of us.

One of the things that I felt best from this was most of the challenges, the vast majority of the challenges identified were ones that were (I’ll call them) growing pains for a new technology that’s really emerging into the mainstream. Not many of the challenges were really fundamental things. In fact, I would posit that none of them were things that were fundamental to the language or the ecosystem. So it gave me a lot of confidence knowing, “Yes, like everything, we have challenges ahead of us, but to meet those challenges, it’s gonna require effort from us and the community to do it.” But they’re not fundamental things that we can’t fix.

[28:12] I think if we look at the challenges, many of them would apply across all of those industries, or most of those industries. There were not many challenges that we looked at that applied only to one.

Carlisia Thompson: And what challenges are these that you’re thinking about?

Steve Francia: For me, from reading through all this, I think we identified a number of challenges. When we asked people what changes would improve Go most, they identified pretty clearly what I think are two of our biggest challenges. One is the lack of generics. I know sometimes we feel like it’s a broken record, but we recognize it’s a challenge. The Go team’s stance hasn’t changed, it continues to be that we’re looking into a solution there.

Package management was the second highest identified change that would improve Go the most. Now, we look beyond those, just what would improve Go, and we see another picture of people’s user experience. When we asked people what’s the biggest challenge they face using Go, it kind of shed some new light on people’s individual challenges. Some of the things that were identified in that were – there’s a steeper learning curve, and our documentation and tutorials are lacking. As we talked about, examples was a big part of that.

There’s also something that came forward here, which was it’s not the easiest thing for users to convey the value of Go to other people, particularly to their management. I think there’s a lot of things we can do there, but one of the things that I thought of (pretty obvious) was there’s a lot of companies that are using Go for lots of different things that most people don’t have any idea about. I think it would do our whole ecosystem a lot of good to talk to these companies, get them - if they’re willing - to do a case study and post that in a central place.

I think there’s a lot of places where we can point to, you know, “This company is using Go, and how it transformed them. This other company, because of Go, they were able to reduce their costs. Because of Go, this other company, they were able to deliver a project much faster than they would have with their existing systems.”

I think that there’s a lot that we can do to just surface some of the great things that Go is already doing. That will help some of these challenges.

Erik St. Martin: Is there somewhere like a canonical place for case studies for people who do that? I know we commonly see them pop up on Reddit and Hacker News, and reduced from 2,000 servers to two and things like that, but I don’t think there’s a single place that we could point an executive to show them a bunch of case studies.

Steve Francia: There isn’t that I’m aware of today, but I believe that there will be some time during 2017, or at least I’d like there to be. Go is changing - or I’ll say the audience for Go is changing a bit. If you look at our web page and the material around it, it hasn’t changed in a number of years. It’s really catered towards the early adopter, and the early adopter is not our audience anymore. The early adopters adopted it, and now we’re going for the later adopters, the more mainstream adopters, and more of the decision makers. So I think there’s work to be done on adjusting our messaging to match the audience of today, and I think case studies is a part of that.

Erik St. Martin: [32:14] Yeah, and it’s difficult too, even just in the convincing teammates thing. Even people who have been in the Go world for a number of years, it’s “Give me your elevator pitch for why you should use Go”, and it’s really hard to think of just like a silver bullet; it’s all the little things combined that make it so great to work with.

Steve Francia: I don’t wanna misquote our users, but I think what came through from reading all the commentary was people that use Go really love it. I think it was pretty clear, like “If you try Go, you’ll see why”, but it’s hard to convey that until you try it. And I think you articulated well why - it’s not like there’s two things that we can – “Well, Go does this, so you should use it.” It’s really a bunch of little things that come together to really make a great experience.

Carlisia Thompson: I usually tell people that they have to try it and stick to it for a while, so they can get that experience. It doesn’t come right away; it’s not like you write a Hello World little program and you get it.

Erik St. Martin: But there’s a struggle in learning or adopting any technology, and you need to… I think Katrina Owen put it really well during her talk, it’s like “Your need for learning it needs to overcome your need to quit.” You have to have a reason to wanna learn that so bad that you kind of suffer through what you find to be oddities in the language because it’s different than what you’re used to for you to get the comfort and the love for the language. So I think that it’s really hard to just – it’s like convincing somebody to use Vim. I can tell them, “No, it’s great. You’re gonna be super productive in it”, and they’re still gonna look at me like, “Yeah, but the learning curve…”

Steve Francia: Yeah, I think that’s well put, and there’s really two different ways to address that, and if we do it right, we’ll address them both. One is reduce that learning curve. Get rid of a lot of the parts that are painful for people; make it easier to learn. The second one is demonstrate the value that people would receive from learning this. There’s lots of different approaches to doing that, and I think one of them would be highlight or showcase success stories using Go. I think if we can approach it from both sides, that’s definitely something that we collectively as the Go community can help to improve. I definitely know that’s something I’m gonna be focused on over the next year.

Carlisia Thompson: Talking about what you’re gonna be focused on over the next year, can you give us an idea of what’s in the pipeline, the order, the priorities…? What’s the biggest thing for this year?

Steve Francia: For me, my role is really gonna be focused on the user experience and what it means to be a part of our community, and supporting that as much as possible. I can’t give you my full playbook for the year, because honestly, I’m still writing it. I think it’s a very evolving thing, but I can tell you some of the highlights of it.

One area we’re trying to improve is the ability for people to contribute to the Go project, and in additional capacities - not just in programming, but in other capacities. And there’s efforts underway to improve that, and we hope to really increase the number of contributors to the Go project.

We’re also trying to build more open and inclusive - we call them community working groups, where people are in an organized working group and are working towards a solution, or to address a need in Go.

[36:07] This is somewhat new territory for Go, and every community need to figure out how it’s going to do this. That’s in the place that we’re in, we’re trying to figure it out… We’re gonna run a little experiment over the next few months with our first inclusive working group, which you’ll be hearing about pretty soon. With that, we’re hoping to be the prototype that we can use more and more.

Other things that I’m working on is trying to – well, first, just make sure that all of the events around the world are supported. There’s a number of Go conferences which all of you on the call know about, as all of you are responsible for at least one of them, and so am I. So we’re all responsible for at least one of them… So there’s the conferences, and then there’s meetups all over the world. We’re trying to get a program set up to support those and make sure that they have all the things that they need.

Then I’m also working pretty hard on the new user experience, what it feels like coming to Go, from the very beginning of going to our website, to installing Go, to going through other things, whether it’s the tour or the documentation, but what it is to learn Go. I think that’s gonna keep me busy for most of the year, doing those things.

A lot of these things are somewhat interactive and experimental. We’re gonna try things and do experiments. Some of them are gonna work, and we’re gonna double down on the ones that do; some of them aren’t gonna work, and we’re gonna learn why and we’re gonna try and continue to evolve our approach.

Erik St. Martin: One of the things you mentioned was actually contributing, and I wanted to dig into that a little bit… But first, let’s take our second sponsored break. Our second sponsor for today is Ultimate Go.

Break: [38:07]

Erik St. Martin: Alright, and we’re back, talking to Steve Francia. Before we took the sponsored break, we were talking about your goals for this year, and you had mentioned contribution to the project. That was really interesting, to see how many people felt that they weren’t welcome. It really took me off-guard too, because I’ve always thought the Go community was very welcoming. Did you get anything from the comments about why people might not have felt welcome? It’s overwhelming to look at the project and figure out how to contribute, or is it the community?

Steve Francia: [39:42] I’ll say what my opinion is about this; I can’t speak to if the survey responses – because we didn’t ask this specific question as a free text response, but I think one of the things is, if you look at the Go team… This is my personal opinion - I look at the Go team and I see Rob Pike, Robert Griesemer and Ken Thompson and Brad Fitzpatrick and Russ Cox… All of these people - Ian Lance Taylor - just luminaries who had long careers of really successful technologies and books, and it’s easy to be intimidated and feel like you can’t live up to it, or “What value could I add to the efforts?”

I was talking toKatrina Owen about this, and I asked her “How do you feel?” and she said, “I feel like as long as I’m one of the smartest people alive, that I’m welcome to contribute.” I’m paraphrasing her, those weren’t her exact words. I kind of felt the same way, and then I became a member of the Go team, and I thought to myself, “Well, I guess I am smart enough”, but I remember feeling that way before I joined the team. I remember going through this experience of “Well, they hired me… I suppose I am smart enough, and now I’m starting to make contributions to the project.” But I think it is intimidating, and I think there’s also this sense of “They don’t need my help.” And I wanna dispel both of those myths.

The first one is “We do need your help.” There’s a lot of work to be done, and we absolutely do need more people to contribute. The project will not be successful as it should be without your help. The second one, you are smart enough to contribute, and reality is don’t be discouraged when people give you feedback that you need to make changes.

I’ve been fortunate for the last few months to see how the team interacts with each other, and they are constantly giving each other feedback, and it is very normal for people to go through many revisions of something before you get it right. That’s how you learn, that’s how you grow. The team is willing to give that kind of feedback and invest in people so they will learn. I think it’s actually a really great opportunity to be able to make contributions, and even if you don’t feel like you’re ready today, this is how you become ready. Give it a try, get the feedback and try and do your best. There’s also lots of different entry points into the project. I am not qualified to contribute to the compiler or to the linker, and I’m not gonna. But there’s plenty of areas in the project that I do feel that I can contribute. There’s parts of the standard library, there’s definitely parts of the website and documentation that I feel that I can contribute to.

So regardless of your technical experience, there’s different areas that you’re gonna be able to contribute to, and through that you’ll learn the process and you’ll get to know the people, and you’ll be adding a lot of value.

Erik St. Martin: I guess that’s a fair observation too, that a lot of people might feel intimidated and embarrassed when their code review comes up, the way they do… Not everybody perceives the feedback the same way; some people take it more personally, other people see it as a learning opportunity, to learn from people who know and understand the language and the project better.

Steve Francia: This is also one of the few questions – because we were able to segment the data in lots of different ways and try and learn from that… This was one of the few questions where people that were not active Go users - as defined by they didn’t select “I use Go at work” or “I use Go not at work”… So if they didn’t select either of those options, this was one of the questions that they actually scored better on. So non-active Go users felt more welcome to contribute to the project than active Go users.

[44:18] What conclusions can we draw from that? I don’t think we can draw exact conclusions, but I think we can speculate that it’s likely because they aren’t as familiar with the process. You always feel welcome until you’re closer, and then you recognize that “Oh, this is kind of intimidating.”

Erik St. Martin: Yeah, and I think some of the other stuff too is there’s a lot of quick wins and stuff in the GitHub issues. Some of the Gerrit stuff can get confusing, but there’s also a lot of formal papers that go back and forth, and working documents where people will work on… You know, you always see that the big changes come through that way, and a lot of people aren’t used to working in that process either. They’re used to taking a ticket and kind of working on it, as opposed to collaborating on a big document or specification before digging in. So I wonder if some of that also adds to the intimidation of what’s required to be involved.

Steve Francia: Yeah, so for me there’s been a bit of a culture shift joining Google and joining the Go team, because most of my background is startups. I’m really trying to learn this lesson - the Go team really cares about getting things right and doing things the right way; in startups, there’s often pressure to get something now, versus something perfect. I don’t say that the Go team strives – they probably do strive for perfection, but they’re trying to do the best job possible. It is a bit of a shift to think, “Okay, I felt like this was good enough, but they want me to make four more changes”, and at the end of the day, for me, I’m trying to learn the lesson “This is just making it all better.” It makes me look better, having contributed something even of higher quality, but it really is raising the bar for what I’m used to. It’s interesting to get that feedback… When Russ gives feedback on things – I meet with him weekly and I still step back a little and say, “Wow, what can I learn from this?” And I can’t believe I’m actually getting feedback from Russ, or Rob, or whoever it is.

Definitely, part of it is recognize that they’re trying to make you or your contributions even better than they are, so it’s not about rejecting you or your contributions, it’s about helping to make them even better.

Erik St. Martin: Yeah, I think it’s important to take the feedback constructively, that it’s not a personal attack, and it’s really hard sometimes. I remember one of the first contributions I ever tried to make - this was a few years ago - several of the Go team I think were going back and forth on the ticket; they each had their own theory on how it should work, and finally I was like, “Alright, I give up on this…”, because it was like balling back and forth between the two… You know, you just take it in stride; you’re like, “Okay, there seems to be a lot of internal discussion on the implementation of this. This probably isn’t the right ticket”, and I just kind of moved on to another one. But a lot of people will take that personally, that it’s lost time, and it’s that and the other… It’s difficult.

Steve Francia: There’s also an observation that I’ve made over the last few months: if there’s not a right answer that emerges, the Go team leadership is not against postponing it until there is one. So the need to have something versus the need to have the right thing… Again, this for me is a bit of a culture shift. There’s a lot of things where it’s like “It would be nice to have this, but we don’t really know the right way to do it yet. We’re gonna continue to think about it, but we’re okay with waiting until we have the right answer.”

Erik St. Martin: [48:09] That’s one of the things when we talk about the little things that are part of the language and the way the team and the community operates… I think that that’s one of the things we can appreciate, because Go doesn’t have a lot of baggage and weird quirks because of these things that were just kind of rushed, and now there’s tons of code in the wild that requires it, so it can’t be removed or fixed.

Johnny Boursiquot: *coughs* JavaScript *coughs*.

Steve Francia: Yeah, it’s been really enlightening to me to see… So, one of the privileges of my job is to participate in a weekly proposal review meeting, and to see the thought and care that goes into every single proposal, which anyone can make. Anyone can make a proposal as an issue on GitHub, and every single week - or almost every single week - you’ve got the Go project leadership reviewing that. They take time and thought and they talk about every single one. And just to see the care and attention that goes into every one of these ideas that are proposed has been just a real treat for me.

Erik St. Martin: Johnny, were you about to say something?

Johnny Boursiquot: No, I was taking a jab at JavaScript, when you said “rushing things out and paying for the consequences later.” [laughter] But to your point, Steve, it’s hard to interpret tone when you’re getting the feedback. Just today I was watching some feedback between Matt Aimonetti, a well-known member of the community, making a suggestion forgo vet to raise a flag when you don’t have enough members for a SQL when you’re reading information back and assigning it to some sort of struct, or whatever it is… When you don’t have enough of these values. So basically, he’s raising that as “Hey, it would be nice ifgo vet could flag that.”

The Go team members were then sort of chiming in, going back and forth… Although it was very cordial, the back and forth was very to the point. There was no sugar coating, it was all about technical details or implications of taking on such a feature. The things that perhaps Matt didn’t know about that the Go team knows about… It was a very quick back and forth.

From the outside looking in, you’re thinking “Wow, is the Go team mad at him for making these suggestions?”, but I’m pretty sure that’s not how they’re seeing it. It’s really just about giving you the raw technical impact of – that raw feedback. There was no sugar coating about it. I think that’s something that can be very intimidating for somebody who’s not used to working that way. You might be working in an environment where people had to sort of use a lot of buffer words, to make you read in between the lines. It’s really not that way at all when interacting with the Go team, I found.

Erik St. Martin: I think that when people are very busy, as the Go team I’m sure is, they skip a lot of the pleasantries. The Go team’s responses are very succinct and matter-of-fact. People read it the way they mean to read it. So if you come into the process feeling intimidated and then you get a very succint answer, you feel like you’re being shrugged off because they’re validating your fear of not being worthy type of ordeal. Whereas people who are regular contributors are just used to that; it’s just a quick response, so they don’t really read too much into it.

Steve Francia: Yeah, I think you said it well. This is something that I know the Go team is actually working on - the fact is people are taking a step of courage to propose something or to send a patch, and they have a lot of emotion sometimes riding on that, and when you have someone that you admire (I will say) shoot you down - even though that’s not what’s happening; that’s the way it sometimes feels - you definitely react differently.

[52:10] I know as a team, we’ve been working on how to communicate in a way that’s encouraging. It’s a work in progress, but in my 6-7 months here I’ve seen improvement of that; people are not just saying no, they’re saying “Here’s why no” or “Here’s what we need for this to go further.” So to give them a path forward, rather than just a wall.

I think that’s a big thing for us that the Go team is learning - people take our words with a lot more weight than sometimes we realize. We’re trying to be better about understanding people’s feelings. That’s something we’re working on.

But I will say the team itself cares deeply about their users and community, and each other. I’ve honestly never been part of a team that really supported each other as well as this team. I see the way that we talk about the community and the amount of time and attention that we spend on the users, and it’s remarkable to me. That comes across being on the team, of how much they really do care and value each user and contributor, even if sometimes in their messaging it doesn’t come across.

Erik St. Martin: I think even outside community involvement helps too, right? Most in the same respect that teambuilding exercises help with co-workers. You interact with people in a different form and you learn that they’re people, and things like that, and then your interactions with them in the work environment are perceived differently.

I know coming for me personally, getting to see and watch the Go team interact with people at conferences really shows how much they care about what people are using the language for, and that it’s meeting their needs and things like that. So when you see those succinct or matter-of-fact responses, you don’t really think about it much because you’ve seen them as a person. People new to the community may only see them for the prestige of the things that they’ve done and their current roles, so when they see that response, it carries more weight, like you said.

Steve Francia: It’s also the case that the team itself knows each other pretty well, and some of the more active contributors, I think you always need to be reminded of – a lot of our conversations and dialogues are done completely open and transparent, the vast majority of it. And even if we know each other well, we can be short with each other, but lots of people are reading that that don’t know our relationship already, so sometimes we need to be reminded that even if we have a good relationship and we’re interacting back and forth, there’s still a need to be mindful of the people who see that and aren’t aware, or don’t know us already.

Erik St. Martin: I know you’re a pretty busy guy, and I think we’re about out of time. I think we have a couple of minutes though if everybody wants to do #FreeSoftwareFriday.

Carlisia Thompson: I actually don’t have one today.

Erik St. Martin: How about you, Johnny? Do you wanna give a shoutout to a project or a maintainer?

Johnny Boursiquot: Yeah, definitelyGo Buffalo. I’ve been playing around with it to sort of stand up a project that I’ve taken on, and I was quite surprised how easy it was to get going… I mean, obviously, beyond reading just the introductory stuff on the main page (I think it’s gobuffalo.io), it was really quite easy to get going. So kudos toMark Bates, the lead contributor to that. Very good job! I’m looking forward to contributing something back to that.

Erik St. Martin: [56:03] How about you, Steve? Did you wanna give a shoutout to anybody?

Steve Francia: Yeah, for me the one project that I use more than any other project is Fatih’sVim-go project. I’ve been a long-time user of Vim, and one of my projects that’s been popular for a while is my Vim Distribution, which is really just my own personal Vim configuration that happens to be adopted by tens of thousands of people. And that’s really what happened, I’m not being short when I say that. It wasn’t intended to be a project, it was just my Vim configuration. But to see what Fatih has done with the Go integration, it’s just phenomenal… The amount of time and effort that he puts into it; it really benefits me a lot, and as the survey demonstrated, a lot of our users. I was shocked to see how many users were Vim users in Go.

Erik St. Martin: Yeah, I think it was Vim and VS Code that were topping everybody out.

Steve Francia: Well, Vim was overwhelmingly the most used, and VS Code was, for me shockingly, the second most, given how young it is. But it just barely edged out…

Carlisia Thompson: Over Atom.

Steve Francia: … IntelliJ and Atom and Sublime.

Erik St. Martin: Okay, so Vim-go far surpassed number two.

Steve Francia: Yeah.

Erik St. Martin: Fatih’s work on that has just been tremendous. I use it as well. He’s got a Patreon set up too for anybody who uses that. We all love to show support to people who work on these projects and give up their free time.

So one that I actually only recently started using which is really cool, I guess it’s calledusql, for Universal SQL. It’s written in Go, and it allows you to talk to SQLite, Microsoft SQL Server, MySQL, Postgres - all using the same command line tool. And one of the cool things that I liked about it was there’s future plan for things like Cassandra and CockroachDB, and things like that. I thought that was really cool. I’m always struggling to find database tools. I like consistency. I hate to have to learn a new command line tool to interact with each database type…

Alright, so with that, I wanna thank everybody for being on the show. Huge thank you to you, Steve, for coming on the show and talking with us today.

Steve Francia: Happy to do it. Thanks for inviting me.

Erik St. Martin: And thank you to all the listeners who are listening live and will be listening to this. Huge shoutout to our sponsors, Backtrace and Ultimate Go. Forward this to anybody who might like to listen to our weekly podcast. We are onTwitter,ping if you wanna be on the show or have suggestions for topics or guests. With that, goodbye everybody! We’ll see you next week!

Steve Francia: Bye!

Carlisia Thompson: Goodbye, everyone.

Johnny Boursiquot: Bye!

Hugo is going Global! Hugo 0.17, released today, is our best and fastest release ever!Hugo 0.17 is nearly twice as fast as Hugo 0.16 and addsfull support for multilingual websites with i18n support throughout all of Hugo.

Hugo is going global with our 0.17 release. We put a lot of thought into how we could extend Hugo to support multilingual websites with the most simple and elegant experience. Hugo’s multilingual capabilities rival the best web and documentation software, but Hugo’s experience is unmatched. If you have a single language website, the simple Hugo experience you already love is unchanged. Adding additional languages to your website is simple and straightforward. Hugo has been completely internally rewritten to be multilingual aware with translation and internationalization features embedded throughout Hugo.

Hugo continues its trend of each release being faster than the last. It’s quite a challenge to consistently add significant new functionality and simultaneously dramatically improve performance.@bep has made it his personal mission to apply the Go mantra of “Enable more. Do less” to Hugo. Hugo’s consistent improvement is a testament to his brilliance and his dedication to his craft. Hugo is further benefited from the performance improvements from the Go team in the Go 1.7 release.

This release representsover 300 contributions by over 70 contributors to the main Hugo code base. Since last release Hugo hasgained 2000 stars, 50 new contributors and 20 additional themes.

Hugo now has:

• 12,000 stars on GitHub
• 370+ contributors
• 110+ themes

@bep continues to lead the project with the lionshare of contributions and reviews. A special thanks to@bep and@abourget for their considerable work on multilingual support.

A big welcome to newcomers@MarkDBlackwell ,@bogem and@g3wanghc for their critical contributions.

Highlights

Multilingual Support: Hugo now supports multiple languages side-by-side. A single site can now have multiple languages rendered with full support for translation and i18n.

Performance: Hugo is faster than ever! Hugo 0.17 is not only our fastest release, it’s also the most efficient. Hugo 0.17 isnearly twice as fast as Hugo 0.16 and uses about 10% less memory. This means that the same site will build in nearly half the time it took with Hugo 0.16. For the first time Hugo sites are averaging well under 1ms per rendered content.

Docs overhaul: This release really focused on improving the documentation.Gohugo.io is more accurate and complete than ever.

Support for Mac OS Sierra

New Features

• Multilingual support#2303
• Allow content expiration#2137
• New templates functions:
  • querify function to generate query strings inside templates#2257
  • htmlEscape andhtmlUnescape template functions#2287
  • time converts a timestamp string into a time.Time structure#2329

Enhancements

• Render the shortcodes as late as possibleed0985
• Remove unneeded casts in page.getParam#2186
• Automatic page date fallback#2239
• Enable safeHTMLAttr#2234
• Add TODO list support for markdown#2296
• Make absURL and relURL accept any type#2352
• Suppress ‘missing static’ error#2344
• Make summary, wordcount etc. more efficient#2378
• Better error reporting inhugo convert#2440
• Reproducible builds thanks to govendor#2461

Fixes

• Fix shortcode in markdown headers#2210
• Explicitly bind livereload to hugo server port#2205
• Fix Emojify for certain text patterns#2198
• Normalize file name to NFC#2259
• Ignore emacs temp files#2266
• Handle symlink change event#2273
• Fix panic when using URLize#2274
• hugo import jekyll: Fixed target path location check#2293
• Return all errors from casting in templates#2356
• Fix paginator counter on x86-32#2420
• Fix half-broken self-closing shortcodes#2499

I am honored to share that I have joined Google as a member of the Go team and will be primarily based in NYC.

Why I joined

My passion has always been building great products, ecosystems and experiences through open source. The desire to create transformative experiences has led me down some wonderful and life changing roads. I’ve been fortunate enough to combine that passion with employment for most of the last decade.

I encounteredMongoDB soon after it’s inception. Realizing that it had the power to fundamentally improve how people created software, I joined MongoDB to help guide the product and ecosystem responsible for the developer experience (UX, web, docs, eng, advocacy). During my time at MongoDB, we grew from an obscure 30 person startup to eventually becoming the 4th most popular DB in the world. I had been part of a successful fast-growth open source startup that fundamentally changed the way software was written by demonstrating that alternatives to relational databases were viable. I felt like I had reached the peak of my career.

At MongoDB, I also managed our drivers team which consisted of developing client libraries in over a dozen programming languages. It was on this team that I first encounteredGo. Go has the nearly perfect balance of readability, expressibility and simplicity. More importantly, it makes writing software fun again. I soon stopped writing software in any other languages and immersed myself in the Go community. I wrotesoftware,libraries,presentations,blog posts and evenorganized,conferences. As I had before, I recognized that this technology had the potential to revolutionize how software was written at a fundamental level.

Upon leaving MongoDB, I took notice of another small open source startup that started to gain some traction.Docker was going to revolutionize how software is distributed and scaled and I wanted to be a part of it. I joined Docker to lead their open source operations and strategy with responsibility for engineering, governance, docs and advocacy. I helped guide Docker to participate in the establishment of the OCI and CNCF and helped refine the developer and contributor experience of Docker, resulting in one of the most actively contributed to projects in history.

After leaving Docker, I really didn’t know where I wanted to go next. I had spent the last 15 years at startups and wondered about life outside of the startup world. As I contemplated my next path it became apparent that my “burnout” from working at many consecutive fast growth startups was more than burnout. Towards the end of 2015 my health rapidly deteriorated. I was diagnosed with Babesia and Bartonella, two nasty blood diseases which caused anemia and chronic fatigue syndrome. The past year has been spent undergoing intensive treatment and in recovery, unable to work.

Going through a long term illness changes you. You see life through a different lens, perhaps a more mortal one. As my health started to improve, a number of organizations approached me about joining. These opportunities ranged widely from a partner at a VC to a VP Eng at a big bank to a founder of a 2 person startup.

I considered each opportunity from many angles. Which would be the best opportunity to continue to let me recover while also being the best decision for my career? I worried that my health would be a limiting factor and wondered if I should play it safe. I wondered if it was time to act my age and take the “grown up” job where I would have grown up things like an expense account and an executive assistant and would no longer be the only guy on the train in a t-shirt and shorts. I worried that if I took an non-executive role that it would be perceived as a step backwards and perhaps meant closing that path forever. I wondered if I would be able to make an impact without a large staff reporting to me. I also considered the impact each role would have on my family. I wondered if I would be happy working at a corporation instead of a startup.

During this time, an opportunity came to join the Go team at Google. I had a hard time even believing it was happening. Here was a team whose members I’ve looked up to since I first started programming and using UNIX as a teenager. I’m still nervous at times talking to many of the people on the team. I worried that I wasn’t up to the level of everyone else on the team. I even felt guilty thinking that I shouldn’t to be paid to do what I’ve spent the last few years doing in my spare time.

I struggled with the decision, probably much more than I should have. I had a moment of clarity which put everything in perspective. This happened at GopherCon, the largest Go conference, while I was at the dinner for the speakers and volunteers. As I looked around the room I saw so many people who I genuinely admire and love. It put everything in perspective about what really matters in life. I knew that happiness comes from doing things you love with people you love. I realized that I couldn’t take any other role because it would mean leaving this community family I had become a part of. I love Go. I love the Go community. I love open source. If I have an opportunity to take a position that not only combines those three, but also enables me to support them I had to take it.

My Role

I have a fairly unique role on the Go team. To my knowledge it’s the first of its kind at Google. My entire objective is to make the Go user and developer experience phenomenal. As someone who writeswidely usedlibraries andapplications and has led teams at companies developing with Go I’ll bring a unique perspective to the Go team about Go usage outside Google.

In many ways this role is similar to the very unique roles I played previously at MongoDB & Docker where I was responsible for developer experience and open source. All three of these roles incorporate elements of product management, user/developer experience, advocacy, branding & messaging, engineering, management, business development and strategy.

Some things I’ll be responsible for include:

• Refining the Go developer experience for beginners and experts alike
  • Creating educational resources for Go adoption and best practices
  • Defining/refining tooling, websites, etc
• Refining the Go contributor experience (std lib, tools, compiler, etc)
• Increasing the collaboration & communication between the Go team and the community
• Gathering data & feedback from enterprises, users, developers, integrators and provide insights to the Go team
• Supporting the community by working with them to define processes, make connections and organize
• Establishing partnerships with different vendors, products, organizations and enterprises to propel Go’s adoption, ecosystem and usage

I need your help

Of all the things I’ll be doing,listening is the most important aspect of my role.

I want to hear from you. If you have ideas or feedback, no matter how crazy or silly, big or small, email me at:spf@golang.org. I’d love to hear from you!

Some questions I need your help to answer:

• What is missing from the Go ecosystem?
• What needs do you have that Go isn’t satisfying?
• What should the Go community be doing that it isn’t today?
• What questions do you have about Go?
• How can the Go project better support you?
• Where would you like to be more involved?

Finally, a huge thank you to everyone in the Go and open source communities. A special thank you to@gniemeyer for introducing me to Go and patiently mentoring me through my first project and@bepsays for taking on an extra load on Hugo and my other projects as my illness prevented me from actively participating.

I feel extremely fortunate to be able to do what I love. I am in the debt of the giants that have gone before me and created all the languages, tools, books, ideas, etc that make it possible for me to be in this role. I believe strongly that the only way to pay back that debt is to pay it forward and create a better experience, a stronger ecosystem and a welcoming community which we can only do together. I look forward to working with all of you in this new role!

A friend of mine who is a very talented writer recently became intrigued with open source and asked me to help her to understand how to be a good open source community member.

Open source is one of the most unusual things in the world. Is there any other profession where highly skilled professionals donate their free time to give their work away for free? Many spend long hours at their day jobs, just to spend their nights and weekends doing the same thing.

I’ve been involved in open source for nearly 20 years – I’ve started some of my own successful community based projects (Hugo,spf13-vim,Cobra,Viper, Zoop), contributed to many others and been responsible for leading some of the most popular commercial open source projects in history (Docker &MongoDB).

Over the years I’ve learned 3 rules that, when followed, are sure to make you a good open source citizen.

Rule 1. Assume good will

Not only is this a good rule for open source, but it’s also a good rule for life. A lot of open source communication is done online in written formats. Community members come from all over the world and from very different cultures, so while most open source work is done in English, it’s often not a community member’s first language. Far too often I’ve seen these differences can lead to barriers and discord in the community when people assume that others are operating with malicious intent. While it’s true that there are some mean people out there, I have found that it’s always best to assume that people mean well until they prove otherwise.

Rule 2. Attitude of appreciation

Open source is built on on the backs of willing volunteers. Many people want to help out and contribute their time and talents to the best of their abilities. Far too often maintainers of projects have the attitude of “you’re not good enough”. I’ve even seen projects reject great contributions because of a spelling mistake in a comment. If you want to foster a healthy community (or participate in one), you need to cultivate an attitude of appreciation. This attitude manifests in different ways.

With all of my open source projects, as at the Docker project, we’ve adopted a policy of never saying “no”, but instead using contributor errors as opportunities to teach our community members how to make it a “yes”. Sometimes this works by showing them how to write better code, tests, or documentation. Sometimes it’s teaching them a valuable skill. This policy is generally helpful for the project overall, as once someone is taught they often have a desire to return the favor and pay it forward by helping other, less experienced members.

Another way appreciation is manifested is by accepting contributions even when they aren’t quite right. Oftentimes someone has taken a lot of time to contribute to a project, perhaps your project, and they didn’t get absolutely everything right along the way. Perhaps the documentation isn’t quite up to snuff, or the test coverage could be better. Remember that not everyone comes from the same background – if English isn’t their first language they may be embarrassed or unable to produce the quality documentation you need. In these cases, I’ve found it’s best to appreciate what they’ve done, take what they contributed, and carry it the rest of the way for them. Some people worry that contributors will be offended if you add to their contribution, but in my experience they’ve always been very appreciative.

Lastly, one of the most important ways to show an attitude of appreciation is to be responsive and thoughtful to questions, and especially contributions, that people provide. If you aren’t able to do this yourself, perhaps it’s time to ask for help. You’ll find great community members who are happy to support.

Rule 3. Don’t be afraid to jump in… ask questions, contribute.

Open source is made up of volunteers. Volunteers who don’t wait for an invitation to jump in and try to contribute. One of the best things you can do is ask “what can I do to help?”. I promise that most open source communities will not only provide many opportunities, but also the support you need to be successful.

Many people are afraid that their work will be rejected if they submit it, and this fear prevents them from contributing. I guarantee that two things will happen as you contribute to open source: 1) some of your work will be rejected, and 2) you will learn far more from these rejections than any other way. I speak not only from personal experience, but from conversations with many friends who are active contributors. To ensure that your contribution has the best chance of being accepted, discuss it with the project maintainers beforehand, during and after. They will be very open to helping.

Hugo, the fast and flexible static site generator, is really coming of age. I wanted to give a quick update about the progress Hugo has been making over the past couple months.

New Website

Hugo can now be found athttp://gohugo.io. Update your bookmarks.

New Team Members

I want to formally welcome our newest team members.

Tatsushi Demachi has been making excellent contributions hugo, particularly with extensions to the template capabilities. The two biggest additions to the layouts, where and groupBy both came from him.

Anthony Fok is on a mission to improve the Hugo documentation. He’s making improvements across the entire documentation and we all benefit from his efforts.

Nate Finch has joined and injected some much needed support. He’s been helping everywhere, from code contributions, to supporting developers to setting up our new discussion forum (see below).

Hugo doesn’t have a official “team”. We welcome contributions from everyone and have received contributions by over 90 people so far. If anyone is interested in helping out, please do. Once you’ve made a few contributions ask for contributor access. Currently Nate and Steve manage this.

New Discussion Forum

Hugo has a brandnew discussion forum. It became apparent to me that google groups was no longer serving our growing community. We really needed a discussion forum that had a great web experience as well as the ability to continue with the email only interface. I also wanted the ability to easily categorize things into different channels. Lastly I didn’t want people to need to setup new accounts. We decided to go withDiscourse, an open source modern discussion platform. It provided all the features we needed and has been great for our community. We soft launched it and within two weeks the amount of discussions being had has risen significantly. Most importantly, users are helping other users.

Nate contributed a lot of work setting it all up. He wrote up his experience on his blog atdeploy discourse with juju.

v0.12 Release

A lot has happened since Hugo v0.11.0 was released. Most of the work has been focused on polishing the theme engine and adding critical functionality to the templates.

This release represents over 90 code commits from 28 different contributors.

• 10new themes created by the community
• fully themablepartials
• 404 template support in themes
• shortcode support in themes
• views support in themes
• innershortcode content now treated as markdown
• support for header ids in markdown (# header {#myid})
• where template function to filter lists of content, taxonomies, etc
• groupby &groupbydate methods to group pages
• taxonomypages list now sortable, filterable, limitable & groupable
• general cleanup to taxonomies & documentation to make it more clear and consistent
• showcase returned and has been expanded
• pretty links now always have trailing slashes
• baseurl can now include a subdirectory
• better feedback about draft & future post rendering
• a variety of improvements tothe website

What’s next?

The community is really expanding. Alongside the new discussion forum we are also launching a hugo blog where updates like this will reside in the future.

We will also be launching a theme gallery where users can view the various themes available for Hugo.

We’re focused on the v0.13 release. There’s a lot to look forward to in this release. Check thev0.13 Milestone for which tickets we are working on.

I recently had a discussion with a CFO of a technology company. We were meeting because he is trying to better understand the role technical evangelism could play within his company. Ten minutes into our conversation he said, “so evangelism is pretty much rogue sales”. Internally I cringed. I politely corrected him that the two could not be further apart.

Allow me to be a bit philosophical or rather, etymological here. Evangelism is an apt title for what it does. Let’s look back at the origin of the word. The Old English ‘gōdspell’ (a union of two words good and spell. Spell meaning news here. This is a translation of the Greek word ’euangélion’ which also means good news. Breaking it down further, this is ’eu-’ + ‘angelos’. Angelos means messenger and eu- means good. So this is someone who brings good news. Throughout the centuries the words have developed strong religious overtones, the initial terms were more generally used.

Sales comes from the Old English ‘sellan’ which means to give. More specifically ‘sellan’ meant to give up (someone) to an enemy in exchange for money;

So Evangelism means bringing of good news and sales means betraying a colleague for money. Sounds like the definition of things haven’t changed much in thousands of years.

In modern usage, the two roles of sales and evangelism are about as different as the original definitions. An evangelist role is to increase awareness and excitement through sharing his/her own experiences. The goal is not and can never be sales. The entire operation depends on authenticity, an authentic personal experience.

Good sales people are authentic, but an authentic sales person means something completely different. It means being honest about intentions and a sales persons intentions are to make a sale. A sales person rarely speaks from their own experience. Especially in technology, they typically cite other’s experiences in place of their own.

Good evangelists are not motivated by what they can gain from a relationship. Instead they are motivated by a genuine excitement and passion around a technology and want to share that with others.

Some languages including C, C++ support pointers. Other languages including C++, Java, Python, Ruby, Perl and PHP all support references. On the surface both references and pointers are very similar, both are used to have one variable provide access to another. With both providing a lot of the same capabilities, it’s often unclear what is different between these different mechanisms. In this article I will illustrate the difference between pointers and references.

Why does this matter

Pointers are at the very core of effective Go. Most programmers are learning Go with a foundation in one of the languages mentioned above. Consequently understanding the difference between pointers and references is critical to understanding Go. Even if you are coming from a language that uses pointers, Go’s implementation of pointers differs from C and C++ in that it retains some of the nice properties of references while retaining the power of pointers.

The remainder of this article is written with the intent of speaking broadly about the concept of references rather than about a specific implementation. We will be using Go as the reference implementation for pointers.

What is the difference?

A pointer is a variable which stores the address of another variable.

A reference is a variable which refers to another variable.

To illustrate our point, use the following example in C++ which supports both pointers and references.

int i = 3;
int *ptr = &i;
int &ref = i;

The first line simply defines a variable. The second defines a pointer to that variable’s memory address. The third defines a reference to the first variable.

Not only are the operators different, but you use the differently as well. With pointers must use the * operator to dereference it. With a reference no operator is required. It is understood that you are intending to work with the referred variable.

Continuing with our example, the following two lines will both change the value of i to 13.

*ptr = 13;
ref = 13;

You may be asking, what happens if I try to access the ptr directly without dereferencing first. This takes us to our second critical difference between pointers and references. Pointers can be reassigned while references cannot. In other words, a pointer can be assigned to a different address.

Consider the following example in Go:

package main
import "fmt"
var ap *int
func main() {
a := 1 // define int
b := 2 // define int
ap = &a
// set ap to address of a (&a)
// ap address: 0x2101f1018
// ap value : 1
*ap = 3
// change the value at address &a to 3
// ap address: 0x2101f1018
// ap value : 3
a = 4
// change the value of a to 4
// ap address: 0x2101f1018
// ap value : 4
ap = &b
// set ap to the address of b (&b)
// ap address: 0x2101f1020
// ap value : 2
}

So far you could do all of the above in a reasonably similar manner using references, and often with a simpler syntax.

Stay with me, the following example will illustrate why pointers are more powerful than references.

Extending the function above:

 ...
ap2 := ap
// set ap2 to the address in ap
// ap address: 0x2101f1020
// ap value : 2
// ap2 address: 0x2101f1020
// ap2 value : 2
*ap = 5
// change the value at the address &b to 5
// ap address: 0x2101f1020
// ap value : 5
// ap2 address: 0x2101f1020
// ap2 value : 5
// If this was a reference ap & ap2 would now
// have different values
ap = &a
// change ap to address of a (&a)
// ap address: 0x2101f1018
// ap value : 4
// ap2 address: 0x2101f1020
// ap2 value : 5
// Since we've changed the address of ap, it now
// has a different value then ap2
}

You can experiment and play yourself at go play:http://play.golang.org/p/XJtdLxFoeO

The key to understanding the difference is in the second example.

If we were working with references we would not be able to change the value of b through *ap and have that reflected in *ap2. This is because once you make a copy of a reference they are now independent. While they may be referring to the same variable, when you manipulate the reference it will change what it refers to, rather than the referring value.

The final example demonstrates the behavior when you change the assignment of one of the pointers to point to a new address. Due to the limitations of references this is the only operation available.

Stay tuned… Next post will feature another property exclusively available to pointers, the pointer pointer.

For more information on pointers I’ve found the following resources helpful

• understanding pointers and memory allocation
• Pointers in Go
• Pointers

To truly understand what it means to be ‘object-oriented’ you need to look back at the origination of the concept. The first object oriented language, simula, emerged in the 1960s. It introduced objects, classes, inheritance and subclasses, virtual methods, coroutines, and a lot more. Perhaps most importantly, it introduced a paradigm shift of thinking of data and logic as completely independent.

While you many not be familiar with Simula, you are no doubt familiar with languages that refer to it as their inspiration including Java, C++, C# & Smalltalk, which in turn have been the inspiration for Objective C, Python, Ruby, Javascript, Scala, PHP, Perl… a veritable list of nearly all popular languages in use today. This shift in thinking has taken over, so much so that most programmers alive today have never written code any other way.

Since a standard definition doesn’t exist, for the purpose of our discussion we will provide one.

Rather than structure programs as code and data, an object-oriented system integrates the two using the concept of an “object”. An object is an abstract data type that has state (data) and behavior (code).

Perhaps as a consequence of the initial implementation having inheritance and polymorphism, a feature virtually all of the derivatives also adopted, definitions of object oriented programming typically also include those features as requirements.

We will look at how Go does objects, polymorphism and inheritance and allow you to make your own conclusion.

Objects in Go

Go doesn’t have a something called ‘object’, but ‘object’ is only a word that connotes a meaning. It’s the meaning that matters, not the term itself.

While Go doesn’t have a type called ‘object’ it does have a type that matches the same definition of a data structure that integrates both code and behavior. In Go this is called a ‘struct’.

A ‘struct’ is a kind of type which contains named fields and methods.

Let’s use an example to illustrate this:

type rect struct {
width int
height int
}
func (r *rect) area() int {
return r.width * r.height
}
func main() {
r := rect{width: 10, height: 5}
fmt.Println("area: ", r.area())
}

There’s a lot we could talk about here. It’s probably best to walk through the code line by line and explain what is happening.

The first block is defining a new type called a ‘rect’. This is a struct type. The struct has two fields, both of which are type int.

The next block is defining a method bound to this struct. This is accomplished by defining a function and attaching (binding) it to a rect. Technically, in our example it is really attached to a pointer to a rect. While the method is bound to the type, Go requires us to have a value of that type to make the call, even if the value is the zero value for that type (in the case of a struct the zero value is nil).

The final block is our main function. The first line creates a value of type rect. There are other syntaxes we could use to do this, but this is the most idiomatic way. The second line prints to the output the result of calling the area function on our rect ‘r’.

To me this feels very much like an object. I am able to create a structured data type and then define methods that interact with that specific data.

What haven’t we done? In most object oriented languages we would be using the ‘class’ keyword to define our objects. When using inheritance it is a good practice to define interfaces for those classes. In doing so we would be defining an inheritance hierarchy tree (in the case of single inheritance).

An additional thing worth noting is that in Go any named type can have methods, not only structs. For example I can define a new type ‘Counter’ which is of type int and define methods on it. See an example athttp://play.golang.org/p/LGB-2j707c

Inheritance and polymorphism

There are a few different approaches to defining the relationships between objects. While they differ quite a bit from each other, all share a common purpose as a mechanism for code reuse.

• Inheritance
• Multiple Inheritance
• Subtyping
• Object composition

Single & Multiple Inheritance

Inheritance is when an object is based on another object, using the same implementation. Two different implementations of inheritance exist. The fundamental distinction between them is whether an object can inherit from a single object or from multiple objects. This is a seemingly small distinction, but with large implications. The hierarchy in single inheritance is a tree, while in multiple inheritance it is a lattice. Single inheritance languages include PHP, C#, Java and Ruby. Multiple inheritance languages include Perl, Python and C++.

Subtyping (polymorphism)

In some languages subtyping and inheritance are so interwoven that this may seem redundant to the previous section if your particular perspective comes from a language where they are tightly coupled. Subtyping establishes an is-a relationship, while inheritance only reuses implementation. Subtyping defines a semantic relationship between two (or more) objects. Inheritance only defines a syntactic relationship.

Object Composition

Object composition is where one object is defined by including other objects. Rather than inheriting from them, the object contains them. Unlike the is-a relationship of subtyping, object composition defines a has-a relationship.

Inheritance in Go

Go is intentionally designed without any inheritance at all. This does not mean that objects (struct values) do not have relationships, instead the Go authors have chosen to use a alternative mechanism to connote relationships. To many encountering Go for the first time this decision may appear as if it cripples Go. In reality it is one of the nicest properties of Go and it resolves decade old issues and arguments around inheritance.

Inheritance is best left out

The following really drives home this point. It comes from a JavaWorld article titledwhy extends is evil :

The Gang of Four Design Patterns book discusses at length replacing implementation inheritance (extends) with interface inheritance (implements).

I once attended a Java user group meeting where James Gosling (Java’s inventor) was the featured speaker. During the memorable Q&A session, someone asked him: “If you could do Java over again, what would you change?” “I’d leave out classes,” he replied. After the laughter died down, he explained that the real problem wasn’t classes per se, but rather implementation inheritance (the extends relationship). Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible.

Polymorphism & Composition in Go

Instead of inheritance Go strictly follows thecomposition over inheritance principle. Go accomplishes this through both subtyping (is-a) and object composition (has-a) relationships between structs and interfaces.

Object Composition in Go

The mechanism Go uses to implement the principle of object composition is called embedded types. Go permits you to embed a struct within a struct giving them a has-a relationship.

An good example of this would be the relationship between a Person and an Address.

type Person struct {
Name string
Address Address
}
type Address struct {
Number string
Street string
City string
State string
Zip string
}
func (p *Person) Talk() {
fmt.Println("Hi, my name is", p.Name)
}
func (p *Person) Location() {
fmt.Println("I’m at", p.Address.Number, p.Address.Street, p.Address.City, p.Address.State, p.Address.Zip)
}
func main() {
p := Person{
Name: "Steve",
Address: Address{
Number: "13",
Street: "Main",
City: "Gotham",
State: "NY",
Zip: "01313",
},
}
p.Talk()
p.Location()
}

Output

> Hi, my name is Steve
> I’m at 13 Main Gotham NY 01313

http://play.golang.org/p/LigPIVT2mf

Important things to realize from this example is that Address remains a distinct entity, while existing within the Person. In the main function we demonstrate that you can set the p.Address field to an address, or simply set the fields by accessing them via dot notation.

Pseudo Subtyping in Go

AUTHORS NOTE:
In the first version of this post it made the incorrect claim that Go supports the is-a relationship via Anonymous fields. In reality Anonymous fields appear to be an is-a relationship by exposing embedded methods and properties as if they existed on the outer struct. This falls short of being an is-a relationship for reasons now provided below. Go does have support for is-a relationships via interfaces, covered below. The current version of this post refers to Anonymous fields as a pseudo is-a relationship because it looks and behaves in some ways like subtyping, but isn’t.

The pseudo is-a relationship works in a similar and intuitive way. To extend our example above. Let’s use the following statement. A Person can talk. A Citizen is a Person therefore a citizen can Talk.

This code depends on and adds to the code in the example above.

type Citizen struct {
Country string
Person
}
func (c *Citizen) Nationality() {
fmt.Println(c.Name, "is a citizen of", c.Country)
}
func main() {
c := Citizen{}
c.Name = "Steve"
c.Country = "America"
c.Talk()
c.Nationality()
}

Output

> Hi, my name is Steve
> Steve is a citizen of America

http://play.golang.org/p/eCEpLkQPR3

We accomplish this pseudo is-a relationship in go using what is called an Anonymous field. In our example Person is an anonymous field of Citizen. Only the type is given, not the field name. It assumes all of the properties and methods of a Person and is free to use them or promote it’s own.

Promoting Methods of anonymous fields

An example of this would be that citizens Talk just as People do, but in a different way.

For this we simply define Talk for *Citizen, and run the same main function as defined above. Now instead of calling *Person.Talk(), *Citizen.Talk() will be called instead.

func (c *Citizen) Talk() {
fmt.Println("Hello, my name is", c.Name, "and I'm from", c.Country)
}

Output

> Hello, my name is Steve and I'm from America
> Steve is a citizen of America

http://play.golang.org/p/jafbVPv5H9

Why Anonymous Fields are not proper Subtyping

There are two distinct reasons why this cannot be considered proper subtyping.

1. The anonymous fields are still accessible as if they were embedded.

This isn’t necessarily a bad thing. One of the issues with multiple inheritance is that languages are often non obvious and sometimes even ambiguous as to which methods are used when identical methods exist on more than one parent class.

With Go you can always access the individual methods through a property which has the same name as the type.

In reality when you are using Anonymous fields, Go is creating an accessor with the same name as your type.

In our example from above the following code would work:

func main() {
c := Citizen{}
c.Name = "Steve"
c.Country = "America"
c.Talk() // <- Notice both are accessible
c.Person.Talk() // <- Notice both are accessible
c.Nationality()
}

Output

> Hello, my name is Steve and I'm from America
> Hi, my name is Steve
> Steve is a citizen of America

2. True subtyping becomes the parent

If this was truly subtyping then the anonymous field would cause the outer type to become the inner type. In Go this is simply not the case. The two types remain distinct. The following example illustrates this:

package main
type A struct{
}
type B struct {
A //B is-a A
}
func save(A) {
//do something
}
func main() {
b := B
save(&b); //OOOPS! b IS NOT A
}

Output:

> prog.go:17: cannot use b (type *B) as type A in function argument
> [process exited with non-zero status]

http://play.golang.org/p/dt1mTXW-BH

The previous example came directly from aresponse to this post on Hacker News. Thanks Optymizer!

True Subtyping in Go

Go interfaces are pretty unique in how they work. This section focuses only on how they pertain to subtyping which will not do them proper justice. See the further reading section at the end of the post to learn more.

As we wrote above, subtyping is the is-a relationship. In Go each type is distinct and nothing can act as another type, but both can adhere to the same interface. Interfaces can be used as input and output of functions (and methods) and consequently establish an is-a relationship between types.

Adherence to an interface in Go is defined not through a keyword like ‘using’ but through the actual methods declared on a type. InEfficient Go it refers to this relationship as ‘if something can do this, then it can be used here.’ This is very important because it enables one to create an interface that types defined in external packages can adhere to.

Continuing with the example from above, we add a new function, SpeakTo and modify the main function to try to SpeakTo a Citizen and a Person.

func SpeakTo(p *Person) {
p.Talk()
}
func main() {
p := Person{Name: "Dave"}
c := Citizen{Person: Person{Name: "Steve"}, Country: "America"}
SpeakTo(&p)
SpeakTo(&c)
}

Output

> Running it will result in
> prog.go:48: cannot use c (type *Citizen) as type *Person in function argument
> [process exited with non-zero status]

http://play.golang.org/p/lvEjaMQ25D

As expected, this fails. In our code a Citizen isn’t a Person, even though they share many of the same properties, they are viewed as distinct types.

However if we add an interface called Human and use that as the input for our SpeakTo function it will all work as intended.

type Human interface {
Talk()
}
func SpeakTo(h Human) {
h.Talk()
}
func main() {
p := Person{Name: "Dave"}
c := Citizen{Person: Person{Name: "Steve"}, Country: "America"}
SpeakTo(&p)
SpeakTo(&c)
}

Output

> Hi, my name is Dave
> Hi, my name is Steve

http://play.golang.org/p/ifcP2mAOnf

There are two critical points to make about subtyping in Go:

1. We can use Anonymous fields to adhere to an interface. We can also adhere to many interfaces. By using Anonymous fields along with interfaces we are very close to true subtyping.

2. Go does provide proper subtyping capabilities, but only in the using of a type. Interfaces can be used to ensure that a variety of different types can all be accepted as input into a function, or even as a return value from a function, but in reality they retain their distinct types. This is clearly displayed in the main function where we cannot set Name on Citizen directly because Name isn’t actually a property of Citizen, it’s a property of Person and consequently not yet present during the initialization of a Citizen.

Go, Object-oriented programming without objects or inheritance

As we have demonstrated here, the fundamental concepts of object orientation are alive and well in Go in spite of some terminology differences. The terminology differences are essential as the mechanisms used are in fact different from most object oriented languages.

Go utilizes structs as the union of data and logic. Through composition, has-a relationships can be established between Structs to minimize code repetition while staying clear of the brittle mess that is inheritance. Go uses interfaces to establish is-a relationships between types without unnecessary and counteractive declarations.

Welcome to the new ‘object’-less OO programming model.

Discussion

Join the discussion onhacker news andReddit - Golang

Further Reading

• http://nathany.com/good/
• http://www.artima.com/lejava/articles/designprinciples.html
• http://www.goinggo.net/2014/05/methods-interfaces-and-embedded-types.html

I’m pleased to announce the coordinated release of drivers in 9 languages in preparation for the release of MongoDB 2.6. This is the largest driver release in the history of MongoDB, both in terms of code changes as well as in terms of drivers released. Official Drivers for C, C++, C# (.net), Java, Node.js, PHP, Python, Ruby and Scala were all released with Perl following shortly. In the upcoming weeks community drivers will be updated to take advantage of the new features present in MongoDB 2.6. With both community and official drivers MongoDB is supported in over two dozen languages and platforms.

The new drivers support the following features:

Write Operations

• Full support for the new MongoDBBulk Operations
• Seamless Support for the new MongoDBWrite Operations

Aggregation Improvements

• Writingaggregation results to a collection
• Aggregation cursors
• Improvedaggregation sorting
• Aggregation explain

Security Improvements

• x.509 Authentication
• LDAP Support for Authentication
• Support for (server side)parallel collection scanning

General Improvements

• Text Search
• Support forServer Side Query Timeouts
• BetterIndex Creation

A more complete list can be found on theMongoDB 2.6 Release Notes

In addition to these general feature individual improvements were made to each driver. Please refer to the release notes of each individual driver (linked below):

• C 0.94.0
• C++ 0.0-2.6
• C# 1.9.0
• Casbah 2.7.0 (Scala)
• Java 2.12.0
• Node 1.4.0
• Python 2.7
• PHP 1.5.0
• Ruby 1.10.0

One of the great features of golang is that you can compile executables for many different platforms and architectures from a single machine. It’s really nice to be able to provide executables ofHugo for a bunch of different platforms and architectures without having to have all these different machines in a build cluster.

As I’ve been working with Hugo, I’ve wanted to make the experience of cross compiling as easy and painless as possible. My first attempt was following theexcellent guide by Dave Cheney. It provides a bash script that automated the process, but wasn’t very customizable. I started writing another script to adjust the behavior to what I needed when I came acrossgoxc. Inspired by Dave’s script,goxc is a go application that not only cross compiles, but also can compress the different binaries and package them with the readme and license. It’s customizable and easy to use.

Here are the necessary steps to be able to cross compile including the gotchas that are important.

Step 1. Prep Go to be able to cross compile

We need to compile go from source to be able to cross compile. While any host can be used, I use OSX as the host. If you are on a different platform or prefer to build go yourself follow the excellentdocumentation on building Go from source. The following instructions are how I prepare go for cross compilation on OSX.

brew update
brew install go --cross-compile-all

If you already have go installed, use

brew reinstall go --cross-compile-all

After this step please check your $PATH and make sure it’s setup correctly.

I also check thatgo version returns the version I’m expecting.

go version
go version go1.2 darwin/amd64

I also check that the build happened properly and the system has all the right file it needs to be able to cross compile. You should see a lot of platforms and architectures under the /pkg/ directory inside GOROOT.

ls `go env GOROOT`/pkg
darwin_386 freebsd_386 freebsd_arm linux_amd64 netbsd_386 netbsd_arm openbsd_386 plan9_386 windows_386
darwin_amd64 freebsd_amd64 linux_386 linux_arm netbsd_amd64 obj openbsd_amd64 tool windows_amd64

If any of these checks return unexpected results then don’t continue. Please check your steps and make sure that you didn’t miss anything. As a last resource, carefully building manually from source should resolve any issues.

Step 2. Get goxc

go get github.com/laher/goxc

Then prepare goxc to be able to cross compile.

goxc -t

Step 3. Prep the source and dependencies

I like to start with a clean GOPATH so I have the latest of all dependencies.

rm -rf ~/.gopath
mkdir ~/.gopath
GOPATH=$HOME/.gopath
go get github.com/spf13/hugo
go test github.com/spf13/hugo/...

Note, this is not the gopath I use to develop with. I use a temporary gopath when building to ensure that I have the latest versions of each library and dependency.

Step 4. Configuring goxc

For many people the defaults will work. I customize goxc slightly to fit my situation. I prefer to provide the version and include that in the build package. I also like to format the built packages a bit differently. We also don’t want to build the plan9 binary due to lack of watcher support for the OS.

We could use the following command to build each time.

goxc -d="$HOME/Code/GoBuilds/" -bc="linux windows darwin freebsd netbsd" -pv=0.10 -o="{{.Dest}}{{.PS}}{{.AppName}}{{.PS}}{{.Version}}{{.PS}}{{.AppName}}_{{.Version}}_{{.Os}}_{{.Arch}}{{.Ext}}"

Instead of typing this each and every time, I prefer to use the support goxc has for a config file. Creating a configuration file is very straightforward since goxc does it for you. Type the same line but append ‘-wc’ at the end and it will create a config file with these settings specific to your project. For me I prefer to leave out the packageversion setting in the config file. Since I will provide that each time.

goxc -d="$HOME/Code/GoBuilds/" -bc="linux windows darwin freebsd netbsd" -o="{{.Dest}}{{.PS}}{{.AppName}}{{.PS}}{{.Version}}{{.PS}}{{.AppName}}_{{.Version}}_{{.Os}}_{{.Arch}}{{.Ext}}"
cat .goxc.json
{
"ArtifactsDest": "/Users/spf13/Code/GoBuilds/",
"OutPath": "{{.Dest}}{{.PS}}{{.AppName}}{{.PS}}{{.Version}}{{.PS}}{{.AppName}}_{{.Version}}_{{.Os}}_{{.Arch}}{{.Ext}}",
"BuildConstraints": "linux windows darwin freebsd netbsd",
"ConfigVersion": "0.9"
}%

Step 5. Cross Compiling

With the config file in place, building is as simple as

goxc -pv=”0.10”

The goxc program will run for a while first building all dependencies for each architecture and platform. This will take most of the time. At the end it will build your application for each arch and os.

If all goes well the output should resemble the following:

[goxc:xc] 2014/03/01 11:11:55 Parallelizing xc for 13 platforms, using max 7 of 8 processors
[goxc:xc] 2014/03/01 11:11:55 mainDirs : [/Users/spf13/Code/hugo]
[goxc:xc] 2014/03/01 11:11:55 building hugo for platform {linux 386}.
[goxc:xc] 2014/03/01 11:11:55 mainDirs : [/Users/spf13/Code/hugo]
[goxc:xc] 2014/03/01 11:11:55 building hugo for platform {linux amd64}.
[goxc:xc] 2014/03/01 11:11:55 mainDirs : [/Users/spf13/Code/hugo]
[goxc:xc] 2014/03/01 11:11:55 building hugo for platform {linux arm}.
[goxc:xc] 2014/03/01 11:11:55 mainDirs : [/Users/spf13/Code/hugo]
[goxc:xc] 2014/03/01 11:11:55 building hugo for platform {windows 386}.
[goxc:xc] 2014/03/01 11:11:55 mainDirs : [/Users/spf13/Code/hugo]
[goxc:xc] 2014/03/01 11:11:55 building hugo for platform {windows amd64}.
[goxc:xc] 2014/03/01 11:11:55 mainDirs : [/Users/spf13/Code/hugo]
[goxc:xc] 2014/03/01 11:11:55 building hugo for platform {darwin 386}.
[goxc:xc] 2014/03/01 11:11:55 mainDirs : [/Users/spf13/Code/hugo]
[goxc:xc] 2014/03/01 11:11:55 building hugo for platform {darwin amd64}.
[goxc:xc] 2014/03/01 11:11:55 mainDirs : [/Users/spf13/Code/hugo]
[goxc:xc] 2014/03/01 11:11:55 building hugo for platform {freebsd 386}.
[goxc:xc] 2014/03/01 11:11:55 mainDirs : [/Users/spf13/Code/hugo]
[goxc:xc] 2014/03/01 11:11:55 building hugo for platform {freebsd amd64}.
[goxc:xc] 2014/03/01 11:11:55 mainDirs : [/Users/spf13/Code/hugo]
[goxc:xc] 2014/03/01 11:11:55 building hugo for platform {freebsd arm}.
[goxc:xc] 2014/03/01 11:11:55 mainDirs : [/Users/spf13/Code/hugo]
[goxc:xc] 2014/03/01 11:11:55 building hugo for platform {netbsd 386}.
[goxc:xc] 2014/03/01 11:11:55 mainDirs : [/Users/spf13/Code/hugo]
[goxc:xc] 2014/03/01 11:11:55 building hugo for platform {netbsd amd64}.
[goxc:xc] 2014/03/01 11:11:55 mainDirs : [/Users/spf13/Code/hugo]
[goxc:xc] 2014/03/01 11:11:55 building hugo for platform {netbsd arm}.
[goxc:xc] 2014/03/01 11:11:55 specified env vars for 'go': [GOOS=linux GOARCH=386]
[goxc:xc] 2014/03/01 11:11:55 invoking '/usr/local/Cellar/go/1.2/libexec/bin/go build -ldflags " -X main.BUILD_DATE '2014-03-01T11:11:55-05:00' -X main.VERSION '0.10' " -o /Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_linux_386 .' from '/Users/spf13/Code/hugo'
[goxc:xc] 2014/03/01 11:11:55 specified env vars for 'go': [GOOS=linux GOARCH=amd64]
[goxc:xc] 2014/03/01 11:11:55 invoking '/usr/local/Cellar/go/1.2/libexec/bin/go build -ldflags " -X main.BUILD_DATE '2014-03-01T11:11:55-05:00' -X main.VERSION '0.10' " -o /Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_linux_amd64 .' from '/Users/spf13/Code/hugo'
[goxc:xc] 2014/03/01 11:11:55 specified env vars for 'go': [GOOS=windows GOARCH=386]
[goxc:xc] 2014/03/01 11:11:55 invoking '/usr/local/Cellar/go/1.2/libexec/bin/go build -ldflags " -X main.BUILD_DATE '2014-03-01T11:11:55-05:00' -X main.VERSION '0.10' " -o /Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_windows_386.exe .' from '/Users/spf13/Code/hugo'
[goxc:xc] 2014/03/01 11:11:55 specified env vars for 'go': [GOOS=windows GOARCH=amd64]
[goxc:xc] 2014/03/01 11:11:55 invoking '/usr/local/Cellar/go/1.2/libexec/bin/go build -ldflags " -X main.BUILD_DATE '2014-03-01T11:11:55-05:00' -X main.VERSION '0.10' " -o /Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_windows_amd64.exe .' from '/Users/spf13/Code/hugo'
[goxc:xc] 2014/03/01 11:11:55 specified env vars for 'go': [GOOS=darwin GOARCH=386]
[goxc:xc] 2014/03/01 11:11:55 invoking '/usr/local/Cellar/go/1.2/libexec/bin/go build -ldflags " -X main.BUILD_DATE '2014-03-01T11:11:55-05:00' -X main.VERSION '0.10' " -o /Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_darwin_386 .' from '/Users/spf13/Code/hugo'
[goxc:xc] 2014/03/01 11:11:55 specified env vars for 'go': [GOOS=darwin GOARCH=amd64]
[goxc:xc] 2014/03/01 11:11:55 invoking '/usr/local/Cellar/go/1.2/libexec/bin/go build -ldflags " -X main.BUILD_DATE '2014-03-01T11:11:55-05:00' -X main.VERSION '0.10' " -o /Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_darwin_amd64 .' from '/Users/spf13/Code/hugo'
[goxc:xc] 2014/03/01 11:11:55 specified env vars for 'go': [GOOS=freebsd GOARCH=386]
[goxc:xc] 2014/03/01 11:11:55 invoking '/usr/local/Cellar/go/1.2/libexec/bin/go build -ldflags " -X main.BUILD_DATE '2014-03-01T11:11:55-05:00' -X main.VERSION '0.10' " -o /Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_freebsd_386 .' from '/Users/spf13/Code/hugo'
[goxc:xc] 2014/03/01 11:11:55 specified env vars for 'go': [GOOS=freebsd GOARCH=amd64]
[goxc:xc] 2014/03/01 11:11:55 invoking '/usr/local/Cellar/go/1.2/libexec/bin/go build -ldflags " -X main.BUILD_DATE '2014-03-01T11:11:55-05:00' -X main.VERSION '0.10' " -o /Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_freebsd_amd64 .' from '/Users/spf13/Code/hugo'
[goxc:xc] 2014/03/01 11:11:55 specified env vars for 'go': [GOOS=freebsd GOARCH=arm]
[goxc:xc] 2014/03/01 11:11:55 invoking '/usr/local/Cellar/go/1.2/libexec/bin/go build -ldflags " -X main.BUILD_DATE '2014-03-01T11:11:55-05:00' -X main.VERSION '0.10' " -o /Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_freebsd_arm .' from '/Users/spf13/Code/hugo'
[goxc:xc] 2014/03/01 11:11:55 specified env vars for 'go': [GOOS=netbsd GOARCH=386]
[goxc:xc] 2014/03/01 11:11:55 invoking '/usr/local/Cellar/go/1.2/libexec/bin/go build -ldflags " -X main.BUILD_DATE '2014-03-01T11:11:55-05:00' -X main.VERSION '0.10' " -o /Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_netbsd_386 .' from '/Users/spf13/Code/hugo'
[goxc:xc] 2014/03/01 11:11:55 specified env vars for 'go': [GOOS=netbsd GOARCH=arm]
[goxc:xc] 2014/03/01 11:11:59 invoking '/usr/local/Cellar/go/1.2/libexec/bin/go build -ldflags " -X main.BUILD_DATE '2014-03-01T11:11:55-05:00' -X main.VERSION '0.10' " -o /Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_netbsd_arm .' from '/Users/spf13/Code/hugo'
[goxc:xc] 2014/03/01 11:11:55 specified env vars for 'go': [GOOS=linux GOARCH=arm]
[goxc:xc] 2014/03/01 11:11:59 invoking '/usr/local/Cellar/go/1.2/libexec/bin/go build -ldflags " -X main.BUILD_DATE '2014-03-01T11:11:55-05:00' -X main.VERSION '0.10' " -o /Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_linux_arm .' from '/Users/spf13/Code/hugo'
[goxc:xc] 2014/03/01 11:11:55 specified env vars for 'go': [GOOS=netbsd GOARCH=amd64]
[goxc:xc] 2014/03/01 11:11:59 invoking '/usr/local/Cellar/go/1.2/libexec/bin/go build -ldflags " -X main.BUILD_DATE '2014-03-01T11:11:55-05:00' -X main.VERSION '0.10' " -o /Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_netbsd_amd64 .' from '/Users/spf13/Code/hugo'
[goxc:xc] 2014/03/01 11:12:04 File '/Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_linux_386' is an ELF file (arch: EM_386, osabi: ELFOSABI_NONE)
[goxc:xc] 2014/03/01 11:12:04 File '/Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_freebsd_386' is an ELF file (arch: EM_386, osabi: ELFOSABI_FREEBSD)
[goxc:xc] 2014/03/01 11:12:04 File '/Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_darwin_386' is a Mach-O file (arch: Cpu386)
[goxc:xc] 2014/03/01 11:12:04 File '/Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_windows_386.exe' is a PE file, arch: 332 (332='X86' and 34404='AMD64')
[goxc:xc] 2014/03/01 11:12:04 File '/Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_linux_amd64' is an ELF file (arch: EM_X86_64, osabi: ELFOSABI_NONE)
[goxc:xc] 2014/03/01 11:12:04 File '/Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_windows_amd64.exe' is a PE file, arch: 34404 (332='X86' and 34404='AMD64')
[goxc:xc] 2014/03/01 11:12:04 File '/Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_freebsd_amd64' is an ELF file (arch: EM_X86_64, osabi: ELFOSABI_FREEBSD)
[goxc:xc] 2014/03/01 11:12:05 File '/Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_darwin_amd64' is a Mach-O file (arch: CpuAmd64)
[goxc:xc] 2014/03/01 11:12:05 File '/Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_freebsd_arm' is an ELF file (arch: EM_ARM, osabi: ELFOSABI_FREEBSD)
[goxc:xc] 2014/03/01 11:12:05 File '/Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_netbsd_386' is an ELF file (arch: EM_386, osabi: ELFOSABI_NETBSD)
[goxc:xc] 2014/03/01 11:12:05 File '/Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_netbsd_amd64' is an ELF file (arch: EM_X86_64, osabi: ELFOSABI_NETBSD)
[goxc:xc] 2014/03/01 11:12:05 File '/Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_netbsd_arm' is an ELF file (arch: EM_ARM, osabi: ELFOSABI_NETBSD)
[goxc:xc] 2014/03/01 11:12:05 File '/Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_linux_arm' is an ELF file (arch: EM_ARM, osabi: ELFOSABI_NONE)
[goxc:xc] 2014/03/01 11:12:05 Task xc succeeded
[goxc:codesign] 2014/03/01 11:12:05 Task codesign succeeded
[goxc:copy-resources] 2014/03/01 11:12:05 resources: [README.md LICENSE.md]
[goxc:copy-resources] 2014/03/01 11:12:05 Copying file /Users/spf13/Code/hugo/README.md to /Users/spf13/Code/GoBuilds/hugo/0.10/README.md
[goxc:copy-resources] 2014/03/01 11:12:05 Copying file /Users/spf13/Code/hugo/LICENSE.md to /Users/spf13/Code/GoBuilds/hugo/0.10/LICENSE.md
[goxc:copy-resources] 2014/03/01 11:12:05 Task copy-resources succeeded
[goxc:archive-zip] 2014/03/01 11:12:05 Parallelizing archive-zip for 10 platforms, using max 7 of 8 processors
[goxc:archive-zip] 2014/03/01 11:12:11 Artifact(s) archived to /Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_windows_386.zip
[goxc:archive-zip] 2014/03/01 11:12:11 Artifact(s) archived to /Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_windows_amd64.zip
[goxc:archive-zip] 2014/03/01 11:12:11 Artifact(s) archived to /Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_darwin_386.zip
[goxc:archive-zip] 2014/03/01 11:12:11 Artifact(s) archived to /Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_freebsd_386.zip
[goxc:archive-zip] 2014/03/01 11:12:11 Artifact(s) archived to /Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_netbsd_386.zip
[goxc:archive-zip] 2014/03/01 11:12:11 Artifact(s) archived to /Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_freebsd_arm.zip
[goxc:archive-zip] 2014/03/01 11:12:11 Artifact(s) archived to /Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_darwin_amd64.zip
[goxc:archive-zip] 2014/03/01 11:12:12 Artifact(s) archived to /Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_freebsd_amd64.zip
[goxc:archive-zip] 2014/03/01 11:12:12 Artifact(s) archived to /Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_netbsd_arm.zip
[goxc:archive-zip] 2014/03/01 11:12:12 Artifact(s) archived to /Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_netbsd_amd64.zip
[goxc:archive-zip] 2014/03/01 11:12:12 Task archive-zip succeeded
[goxc:archive-tar-gz] 2014/03/01 11:12:12 Parallelizing archive-tar-gz for 3 platforms, using max 7 of 8 processors
[goxc:archive-tar-gz] 2014/03/01 11:12:14 Artifact(s) archived to /Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_linux_386.tar.gz
[goxc:archive-tar-gz] 2014/03/01 11:12:14 Artifact(s) archived to /Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_linux_arm.tar.gz
[goxc:archive-tar-gz] 2014/03/01 11:12:15 Artifact(s) archived to /Users/spf13/Code/GoBuilds/hugo/0.10/hugo_0.10_linux_amd64.tar.gz
[goxc:archive-tar-gz] 2014/03/01 11:12:15 Task archive-tar-gz succeeded
[goxc:pkg-build] 2014/03/01 11:12:18 Task pkg-build succeeded
[goxc:rmbin] 2014/03/01 11:12:18 Task rmbin succeeded
[goxc:downloads-page] 2014/03/01 11:12:18 Task downloads-page succeeded

Addendum

A few people have commented onreddit with additional information.

Some have reported success usinggox. I have yet to play with it butMitchell is known for writing excellent software so I would expect nothing less here.Gox does less thangoxc, but that’s the point.

Cgo has issues when cross compiling. If you depend on cgo then you’re probably going to be better off building on the native platforms. The go tool will disable cgo support by default. To explicitly enable cgo, set CGO_ENABLED=1.

spf13-vim, a completely cross platform distribution of vim plugins and resources for Vim, GVim and MacVim stays true to it’s vim roots while adding modern features including a plugin management system, a curated plugin set with customized configuration, advanced autocomplete, tags, support for dozens of languages and much more.

I recently read a thread where the author asked for feedback on whether or not to use spf13-vim. Responses varied greatly with some people loving it to others claiming it was bloated and overkill. Some suggested everyone should create their own configuration from scratch. Not surprisingly many of these criticisms were accompanied by links to people’s own vim configurations. With so many options out there, why would anyone use spf13-vim. While I can’t speak for anyone else, here are four reasons why I use spf13-vim.

First, a bit of history… spf13-vim started as my personal vim configuration. As long as I can remember I’ve obsessed with user experience and spent an embarrassingly large amount of time customizing each and every single action. As many others have, I put my configuration on github, not with the intent to share it with others, but to have a safe place to keep it for when I setup new computers.

1. Vanilla Vim like

In designing spf13-vim I took extreme caution with every decision I made and made certain to not override any essential Vim functionality . I had invested years in becoming proficient in vanilla Vim and didn’t want to throw any of those muscle memories away. I also wanted to remain completely comfortable in vanilla Vim. At the same time I wanted to smooth over some of the rougher parts and provide additive features. Virtually every one of the vanilla keystrokes and actions remain untouched.

A handful of default keystrokes have been remapped. A few of what I consider some of the less useful behaviors have been adjusted to be more consistent with the overall vim experience. For example, the first thing people learn in Vim is how uses ‘hjkl’ for cursor movement, spf13-vim adds ctrl+hjkl to move around windows and ‘HL’ (shift+hl) to move between tabs. Since these are common actions, it felt decidedly unvim-like to hide them behind commands or multiple keystrokes. These tab movements override Vim’s default behavior of moving to the top ‘H’ and bottom ‘L’ of the window. Something I don’t ever use.

2. Customizability

Continuing with the history, over time people found it and began to use it for themselves. Recognizing this I adding more flexibility to spf13-vim which provided the ability for people to use spf13-vim as a foundation, but add their own customizations to configure it precisely to fit their own needs.

Perhaps you work differently than I do and use the default ‘H’ & ‘L’ functionality. spf13-vim wraps each one of the overrides with an conditional statement enabling users to easily customize it exactly to their needs. Most users find spf13-vim default requires little customization but are happy to discover how easy it is to craft their personalized vim experience.

3. Power of the masses

The strength and heart of open source comes from people recognizing together we can make something better than any of us could alone. As more and more people began to use spf13-vim, many of them desired to contribute back. While spf13-vim started as my personal project, it has grown from mine to ours. I use vim to write in a few languages, and invested time discovering and customizing the best plugins for those languages, collectively the users of spf13-vim support far more languages than any one person would be able to. I love when I edit a file in a language I haven’t used before and someone else has already crafted a customized experience in spf13-vim.

spf13-vim benefits greatly from contributions from it’s completely diverse user base. This ensures regardless of your development stack or purpose, spf13-vim likely meets your needs. With support for many different languages, plugins and uses, vim could become weighted down. spf13-vim makes it trivial to include only the features you would use by defining a simple list.

One of the primary reasons I hear for people abandoning Vim is properly configuring vim is too difficult and plugins tend to be incompatible with each other. With many active and engaged users working together issues and incompatibilities are discovered and fixed by the users together quickly.

The vim plugin community is always evolving. New plugins come out daily. With many different users exploring and experimenting with new plugins this results in vim configuration using the latest and greatest. Without investing countless hours exploring, each user benefits greatly from the combined efforts of everyone. spf13-vim receives many pull requests each week keeping our collective vim experience fresh.

4. The community

The primary reason I love using spf13-vim is the great community. This goes beyond the power of the masses, the spf13-vim users are some of the most patient and kind people I’ve ever encountered. Thespf13-vim mailing list is full of people, sometimes naive, asking for help. I am consistently impressed with the willingness of spf13-vim users to help.

I remember back to when I first learned Vim. It was overwhelming at times and frustrating. After 8 years using Vim full time I still feel this way from time to time. Anyone who has tried to use Vim can likely relate. How wonderful it is to have a group of helpful users available and willing to assist.

When Ispeak at conferences I’m most often recognized for vim configurations. People come up and tell me how happy they are to “use me”. How lucky I am to be part of this great project that bears my name. A big thanks to the talented users (and contributors) of the greatest vim experience.

That’s why I usespf13-vim. Why do you?

While developingHugo I became disappointed with the interface limitations flags alone provide. A quick look at virtually any command line application (ls, grep, less, etc) reveals that most applications overuse flags to do everything and often allow conflicting flags to be applied.

Even though hugo is relatively simple, we already had the ability to stack flags that didn’t make sense. You can set the port using –port but this only has an effect if you also specified –server. Clearly another mechanism is needed.

Modern applications like git, brew and go use sub commands to control actions that the application would perform. Each action in turn has a set of flags associated with it. It’s a great pairing that works well.

I quick something search for existing libraries turned up a few. Mostly based off of the code written for the go tool, which wasn’t intended to be a general purpose library, but people began using it nonetheless.

I was disappointed to discover than none met my needs. Unwilling to be deterred, I decided to build Cobra, a commander for modern CLI go applications.

Nested Sub Commands

A core requirement for Hugo commands was the ability to nest subcommands. A planned feature of Hugo is the ability to install themes, shortcodes and more from a central repository. While a possible interface could look like ‘hugo get –type=shortcode –name’, I prefer the interface ‘hugo get shortcode NAME’.

This preferred interface could be accomplished while using existing libraries, it would be through manual parsing of strings following the command. This made no sense to me. If we already have a mechanism to parse strings on the command line, why not use what we already have.

Cobra supports as subcommands as many levels deep as you want to nest them.

Commands all the way

Existing libraries all define a top level controller object which has builders for each of the commands (of which they only support one level). To me this seemed unnecessary and definitively un-go-like.

In Cobra, everything is a command or a flag. The top level of the application is a command which optional can run an action and optionally have subcommands (at least one of these two is required). Each of the children commands then can in turn have an action and children and so forth.

Additionallycreating a command is as simple as creating a struct. No inflexible NewCommand methods needed.

POSIX/GNU Flags

The go standard flag library is great. I really appreciate it’s simplicity and power. For unknown reasons the authors decided to throw out decades of flag standards and define their own. I’m not a huge fan of the GNU/POSIX style flags, but they work well enough and it’s what most people expect. If there’s ever a place to do things in a new way, this doesn’t seem like it. Cobra has full support for POSIX flag functionality provided by thepflag libary, a fork of the flag standard library which maintains the same interface while adding POSIX compliance.

Cobra has tight integration with this flag library.Flags can be defined globally, for a sub tree or for a specific command.

Extensibility

In each of the existing libraries they had code that had conditional logic to check if the first string was ‘help’, then they ran a different code path. This hard coded logic meant that if you used these libraries you either had to fork them or were stuck with their help routine. Additionally I have a philosophical issue with using conditional logic to handle a specific command. If you are building a commander to handle arbitrary commands, why not use that mechanism to define help.

Cobra’s help functionality is a command and provides a high degree of customization without forking.

Conclusion

Find Examples, Documentation & Cobra athttp://github.com/spf13/cobra

Contributions and feedback welcome.

I’ve recently been getting into go. I’ve built afew applicationsandlibraries.

For this post, let’s explore the ‘gofmt’ or ‘go fmt’ tool further.

Go ships with a basic set of tools common to most languages and development environments. Like most things with go, the tools are simple in design, but powerful in function.

• go build – compile the code
• go install – install (and build) a package
• go get – download and install packages including dependencies
• go test – run test suites and benchmarks
• go doc – generate and view documentation
• go fmt – format and refactor your code
• go run – build and run an app

First thing to note, ‘go fmt’ is just an alias for ‘gofmt -l -w’. When following along, please take note as the two accept different parameters.

Using gofmt to format code

We’ve had decades of endless argument and debate about the correct format of software. Each language has it’s own different idioms and changes and many have multiple differing standards. Golang has done away with these endless debates once and for all by shipping a formatter that ensures that all go code follows the exact same format.

Go fmt isn’t without it’s detractors. People complain that go fmt isn’t customizable and that it puts braces where they don’t want them. A standard isn’t customizable, and it’s this thinking that has caused so much controversy in every other language. Go fmt is great. Not only does it know the correct format, but it understands go code. It properly lines up definitions, properly wraps if statements when they grow to long and ensures that your code completely conforms to the standard.

The best part of this is that all my code complies with the format standard perfectly and I’ve never read the go format policy. I just write code and run go fmt on that code and immediately my code conforms.

Preview which changes gofmt will make

The following command will show you all the changes gofmt will make in diff format.

$ gofmt -d path-to-code

Given a file, it operates on that file; given a directory, it operates on all .go files in that directory, recursively.

Format your code

The following command will make changes directly to your source files.

$ gofmt path-to-code
or
$go fmt -l -w -s path-to-code

Here is an example of the kind of changes gofmt would make

 func (f *Filesystem) Files() []*File {
- if len(f.files)<1 {f.captureFiles()}
+ if len(f.files) < 1 {
+ f.captureFiles()
+ }
return f.files
}

Given a file, it operates on that file; given a directory, it operates on all .go files in that directory, recursively.

Simplify mode

‘gofmt’ can also simplify code where appropriate with the additional -s flag. I have found that simplify is safe to use and only will modify code when it’s obvious and clear.

Here is an example of the kind of changes simplify would make.

- final = append(final, first[start:len(first)]...)
+ final = append(final, first[start:]...)

Using gofmt to refactor code

gofmt is much more powerful than simply eliminating arguments about code formatting. It can also restructure your code. Unlike using traditional unix tools like awk and grep, gofmt understands go code and can be used to restructure your code easily.

gofmt uses patterns to identify changes to make to your code. Patterns are established in the first half the expression followed by a ‘->’ then used by the second half of the expression.

Use the flag -d instead of -w to check what gofmt will do prior to running it.

Examples

To check files for unnecessary parentheses (example from the docs):

gofmt -r '(a) -> a' -l *.go
diff hugolib/summary.go gofmt/hugolib/summary.go
for i, line := range rstLines {
if strings.HasPrefix(line, "<body>") {
- rstLines = (rstLines[i+1 : len(rstLines)-3])
+ rstLines = rstLines[i+1 : len(rstLines)-3]
}
}
diff parser/parse_frontmatter_test.go gofmt/parser/parse_frontmatter_test.go
- if (err == nil) != test.errIsNil {
+ if err == nil != test.errIsNil {

Rename a field in a struct. Notice how it not only changes the definition, but every place that the value is set or referenced.

gofmt -r 'a.Info -> a.Information' -d ./
diff hugolib/site.go gofmt/hugolib/site.go
func (s *Site) initializeSiteInfo() {
- s.Info = SiteInfo{
+ s.Information = SiteInfo{
- page.Site = s.Info
+ page.Site = s.Information
- s.Info.Indexes = s.Indexes.BuildOrderedIndexList()
+ s.Information.Indexes = s.Indexes.BuildOrderedIndexList()
- s.Info.LastChange = s.Pages[0].Date
+ s.Information.LastChange = s.Pages[0].Date
for _, p := range s.Pages {
- p.Site = s.Info
+ p.Site = s.Information
}
- n.Data["OrderedIndex"] = s.Info.Indexes[plural]
+ n.Data["OrderedIndex"] = s.Information.Indexes[plural]
return &Node{
Data: make(map[string]interface{}),
- Site: s.Info,
+ Site: s.Information,
}

After after a few months of work I’m happy to display the newest incarnation of spf13.com.

The past few years this blog has powered by wordpress and drupal prior to that. Both are are fine pieces of software, but over time I became increasingly disappointed with how they are both optimized for writing content even though significantly most common usage is reading content. Due to the need to load the PHP interpreter on each request it could never be considered fast and consumed a lot of memory on my VPS. I have been intrigued by the recent trend of static site generation, and determined that the next version of my blog should be generated by one. I also began looking into the resolutions and devices used by visitors to my blog and they varied greatly. It didn’t make sense to cater the experience to the common one, largely because there wasn’t one. After 5 years and a two engines this site accumulated a lot of cruft. Poorly rendered html from wordpress wysiwyg. Incorrectly automatically cropped thumbnails. I took this opportunity to clean it all andfocus on the content.

Static Site Generator

Determined to use a static site generator I reviewed the commonly used ones. While I didn’t do a thorough investigation, I discovered that all were relatively slow taking minutes to render this blog. Additionally calling it a blog is overly simplifying things, there’s a lot of different content types on this website. Since I was already looking for a good project to write in golang I decided to build my own static site generator called hugo. I also determined to optimize the website for speed, performance and presentation. Like many of the other static site generators it takes a similar approach of using markdown with front matter with the meta data and generates html files for apache, nginx or another web server to serve up. I’m preparing Hugo for it’s initial release and will blog more about it then.

Responsive Design

The most noticeable part of the new design is the responsive layout. Go ahead, give it a try: resize the window and watch as the design adjust to fill the narrowest or largest of screens. Many people using responsive design optimize for smaller screens and ignore higher resolution monitors. Since my readership comprises a wide variety of screens and devices including hi res monitors. This design is optimized for even the highest of resolutions to both place the focus on the content as well as utilize the available space.

Retina Friendly

10gen, my employer graciously provided me with an excellent Retina display mac book. Ever since, it’s been a bit disappointing viewing some websites which suddenly looked unimpressive on this new display. I wanted every image and shape to look crisp and clean on any display. The optimal way to do this is through heavy use of vector based icon fonts which cleanly scale to any size. The logo and all glyphs on this site are rendered using a single icon font. All photographs have been optimized for retina displays and compressed using JPEGmini. It looks great on a retina display.

Fast browsing

In the previous incarnation of this site which ran wordpress, the site performance was adequate. According to pingdom it was faster that 86% of all tested websites, but I was never satisfied. The total page size was 1.5 MB and an average page contained over 82 requests.

Now, the number of requests for a typical page is around 10. Including network transfer time (the majority of load time) the load is around a quarter of a second on a cold load. Given modern browsers and caching subsequent results will be around 100 ms. The page size is under 150kb and is now faster than 99% of all tested websites.

Easy Navigation

Lastly navigation has been greatly simplified. Since most visitors enter through a post rather than the homepage, I put the focus on the content itself. Other than the top level navigation which brings you to the different content types, the rest of the content is accessed through similar content. If you are viewing a presentation or post on MongoDB, you are likely interested in MongoDB and would be interested in similar content which is available via tags and topic links available on the page.

Thank you

I present this new blog to you and hope you find it valuable. Over the next few weeks I’ll be following up this post with a series of detailed how-tos based on the experience of building this site.

Thank you for visiting, and tell me what you think in the comments.

Two times a year the drivers team at 10gen gathers together for a face to face meeting to spend time together working on issues and setting forth our goals for the upcoming six months. In September 2012 we all converged on New York City for the second ever driver days. This time we split up into teams for a hack-a-thon. As maintainers of drivers & integrations in over a dozen different languages while we are on the same team, it isn’t often that we actually work together on the same codebase. The hack-a-thon gave us a chance to do just that. We split up into 5 teams each having members from different languages. Without further ado, here is what we came up with.

Disclaimer.. Each project currently represents exactly one evenings worth of work. Our intent is to pick the best project or two, polish them up and move them to the10gen Labs account on github.

As with all things open source, contributions welcome.

Mongo Contributor Hub

Ever wonder what type of open source MongoDB related projects are being developed these days? We did. So we hacked together a quick Github search & explore interface for any project Github reports as associated to MongoDB! Projects are organized by language, fully searchable and sorted by followers and forks. Built with Nodejs, Express and MongoDB.

https://github.com/TylerBrock/mongo-contributor-hub

Try Aggro

With thirteen challenging questions you’ll learn the ins and outs of aggregation with MongoDB. Will you be able to complete all the challenges and become an aggregation master?

https://github.com/rozza/try-aggro

MongoDB.OData

OData is a highly used protocol with clients in .NET, Java, jquery, and many more. It makes sense to be able to support these clients with a MongoDB backend. With OData v3, the protocol is now rich enough to support the rich document model MongoDB already provides. MongoDB.OData let’s you expose your entites (MongoDB documents), complex types (MongoDB embedded documents), and collections (MongoDB arrays) via OData and includes full support for queries and OData service operations. Support for updating is almost ready.

https://github.com/craiggwilson/mongo-dotnet-odata

Slow Query Profiler

Logging slow queries is essential for any database application, and MongoDB makes doing so relatively painless with its database profiler. Unfortunately, making sense of the system.profile collection and tying its contents back to your application requires a bit more effort. The heart of mongoqpMongo Query Profiler is a bit of map/reduce JS that aggregates those queries by their BSON skeleton (i.e. keys preserved, but values removed). With queries reduced to their bare structure, any of their statistics can be aggregated, such as average query time, index scans, counts, etc.

As big fans ofGenghis, a single-file MongoDB admin app, the initial intent was to contribute a new UI with the profiler results, but one night was not enough time to wrap our heads around Backbone.js and develop the query aggregation. Instead, we whipped up a quick frontend using theSilex PHP micro-framework. With the hack day deadline no longer looming, there should be plenty of time to get this functionality ported over to Genghis. Additionally, the map/reduce JS may also show up in Tyler Brock’smongo-hacker shell enhancement package.

While presenting mongoqp to our co-workers, we learned aboutDan Crosta’s professor, which already provides many of the features we hoped to implement, such as incremental data collection. We think there is still a benefit to developing the JS innards of mongoqp and getting its functionality ported over to other projects, but I would definitely encourage you to check out professor if you’d like a stand-alone query profile viewer.

https://github.com/jmikola/mongoqp

Aggregation Pipeline Web Interface

We built a web app for the new aggregation framework. It allows you to create pipelines using a web interface, making it easy for a user to play around with the new framework without having to use the command syntax. Users can incrementally add pipeline operators to test running aggregations with different operators, and can use the easy interface as an educational tool to learn how the pipelines work. The app also allows you to pipe the results of aggregation framework jobs straight to user-defined output collections and see a history of past jobs along with their run-time. The app is built in Ruby on Rails, using the MongoMapper ODM.

https://github.com/estolfo/aggre-great

There are a variety of reasons businesses either do not have a disaster recovery plan or their current plan is substandard.  The beliefs of the people in charge of developing these processes (business owners and IT department) play a significant role in how effective the overall strategy will be.  This is problematic when the decision-makers have bought into one or more of the common myths surrounding disaster recovery.

Myth – Disaster Recovery is Expensive and Resource Intensive

One of the biggest reasons businesses put off developing a disaster recovery strategy is because they believe it will become too expensive and resource intensive.  As a result, they view it as more of a luxury than a necessity.  The truth is as technology continues to evolve; the costs associated with disaster recovery continue to fall.  Virtualization, standardization, and automation have all played key roles in making disaster recovery more affordable.  They have reduced the number of people required to restore systems which significantly decreases personnel costs.  In fact, a streamlined disaster recovery strategy can require only one person.  Virtualization also reduces the initial capital investment because redundant physical infrastructure is no longer necessary.

Myth – After Planning, There is No Way to Accurately Run a Test

Many businesses suffer from an ineffective disaster recovery plan and don’t even realize it.  This is because they do not believe a full-scale test is possible without significantly disrupting day-to-day activities.  Virtualization allows recovery plans to be tested against significant failures multiple times to ensure the plan is consistently effective, without disrupting day-to-day activities.  Not only are tests easy to run, but virtualization also eliminates the need to transport the IT team to multiple locations.

Myth – Creating and Managing a Disaster Recovery Solution Requires “Special” Skills

A common hesitation, especially among small businesses, is the belief that developing a disaster recovery solution requires a special set of skills.  This myth largely stems from traditional manual data recovery because end-users had to deal with duplicate, silent infrastructures across multiple sites.  Virtualization standardizes the disaster recovery process by encapsulating operating systems, applications, and servers.  This includes all the configuration data.  As a result, the entire process is now much less complex than it used to be.  Additionally, once the solution is in place it can be reliably tested and executed by staff.  Since this is all taken care of via automated processes, no special skills are required.

Myth – Disaster Recovery Plans Are like an Insurance Policy that Never Gets Used

The most common myths which prevent businesses from taking disaster recovery seriously are that it is unnecessary.  They believe disaster recovery is a sunk cost similar to a car insurance policy of someone who never gets an accident.  Even if a disaster never happens, the recovery plan still provides a variety of benefits to the business.  One of the most common uses is as a migration plan template anytime a business switches data centers.  Depending upon the industry, disaster recovery plans may also be a compliance requirement. In order to accurately assess the need for a new orimproved disaster recovery plan these myths must be eliminated from a business’s belief structure.  As long as these myths remain, the odds of successfully implementing an efficient disaster recovery strategy are slim. Tony Spinks believes every company should consider using Disaster recovery services.  These services are critical for keeping businesses running after system failures.  Data Centers offering disaster recovery services provide the redundancy.

The protection of your intellectual property, or any information that you post to your blog, forum or website, can be a tricky subject. While there are those unscrupulous few out there in the cyber world who will purposely copy your words as their own, there are more people that are simply ignorant of the laws, unaware that they are stealing when they copy and reuse your musings. According to a criminal lawyer at an Orlando based firm that we spoke to, there are steps that you can take to make sure that your intellectual property is protected. Here’s what you can do:

1. Obfuscate Your Code

To protect yourself against thieves, use software like Dotfuscator and JavaScript Obfuscator. These types of software programs will obfuscate your coding, making your content more difficult to steal by making a program’s source code difficult to read by humans. When someone tries to copy and paste your blog entry, they’ll be left with unreadable, useless coding. Other helpful software includes vGuard, Jasob and Salamander .NET Obfuscator.

2. Post a Permissions Policy

A page of your website or blog should be dedicated to an explicit permissions policy. This policy will tell others what they can and can’t do with the content that you have posted. The key to a great permissions policy is clarity; people should know exactly what it is that they can do without your permission and when they’ll need to contact you. Once you’ve published your policy, you’ll have something to point to if someone violates it.

3. Contact the Violator

If you find that your content has been used by someone else, the first thing to do is to send a polite email to the violator. 99 times out of 100, the person who used your content has no idea that they’ve done anything wrong. Kindly thank them for finding your content interesting enough to use on their own site, point to your permissions policy, and offer suggestions as to how the person can use your content legally.

4. Demand Removal

If you’ve found the one person with whom a polite email doesn’t work, you’ll need to escalate your efforts. Sit down and draft an email demanding that the offender remove your content from their site immediately. While it’s still suggested that you remain tactful and polite, you may want to be a bit more forceful. Direct the offender to your permissions policy again, letting them know that they are violating copyright laws by allowing your content to remain public on their page.

5. Contact the Hosting Site

If steps two and three haven’t worked with the violator, you’ll need to contact their hosting site. Find a site online that will allow you to search for the person’s domain registration and, once you do, send an email to the hosting service. Let the hosting service know the steps you have taken and that you are now requesting removal of the web site. The powers-that-be at the hosting site will investigate your claim and, if it is found to be with merit, will take the site down.

6. Get Legal Help

At the end of the day, your last bit of recourse may be found in hiring an attorney. A criminal defense lawyer can go to bat for you, helping you to have the offending content removed from cyberspace.

If you find that someone has copied your content for their own blog, be flattered; it means that they’ve found your content useful or relevant. Remember that most people don’t understand that they are violating any laws, and an email is often enough to get your content removed from the offending website. If you follow the steps above, you’ll ensure that your intellectual property remains yours.

Katie Hewatt is a legal researcher and contributing author for theFlorida Law Firm of Katz & Phillips, which deals with Internet crime cases. The Orlando law firm keeps up to date with the latest technology online and the ever changing cyber crimes involved with it.

At OSCON 2012 in Portland I gave a presentation onbuilding your first MongoDB application. Over 150 people were in the audience, a pretty significant number of this type of hands on tutorial. Certainly worth the weeks of preparation that went into developing it. While at OSCON I put the slides online at SlideShare where during the four day conference the amassed over 20k views and within a couple weeks over 30k views. Within a month it had been viewed more than ten times the total attendees at OSCON, one of the largest technical conferences in the world.

How was this presentation so successful that it amassed more views in it’s first week than any other presentation had accumulated over 12 years? Here are the four critical things I did to generate such an amazingly high number of views.

Have an interesting & unique topic

The first two items are focused on the preparation. Your topic needs to be something that people are both interested in and find interesting. To be both it should be unique about something popular. I’m really passionate about building great things and so are a lot of people. Like many people out there I’ve looked into using new technologies to make the process of building applications easier and more enjoyable. This behavior led me to explore NoSQL solutions which led me toMongoDB. MongoDB is one of the most popular technologies right now. It’s claiming a significant lead over other NoSQL technologies and catching quickly to the leaders in the very established relational space. Remember I’m commenting here on popularity and interest. This is easily discoverable by looking at things like google trends or frequency of mentions on niche sites like hacker news. With popularity comes noise. To stand out from the noise you need a unique topic or take on it. In giving this presentation I chose to focus on ‘writing your first ruby application backed by MongoDB’. From skeleton to deployment. To my knowledge this hadn’t been done before and was something that stood out to people.

Make it broad and approachable

To reach the largest group of people you need to appeal to a large group of people. This means giving a presentation that is approachable that many different kinds of interested people could follow along and find value in. Given that this presentation was aimed at first time MongoDB users without much development experience it really resonated with a lot of people. One nice thing about OSCON is that it attracts a really diverse crowd. If  it was appropriate for the audience there, it would work well for the broader Internet audience which OSCON is a microcosm of.

Cater to the online audience

Whenever I create my slide decks I’m always focused on two audiences. The live audience that will see the presentation projected onto a screen and the remote audience that will be viewing it on slideshare via their computers/laptops/tablets etc. Most people ignore that second group, but a good presentation will always reach more people online than in person. If anything it’s the group that can’t afford to be ignored. I ensure that the slides flow well even without my narration. I give them to a few friends without the accompanying talking and see how well they can follow them. I make sure to use good layouts that use the space well and are readable when on the projector from the back of the room as well as when embedded on a web page. It’s important when using slideshare and the other sites that you review the presentation on them as well as embedded as conversion is sometimes destructive, especially if you are using a unsupported font.

Give it a good start

Success begets success. During the live presentation I put the slides up on slideshare so that the attendees could follow along at their own pace. Since the audience was largely working with the code in the presentation it made a lot of sense for them to bring it up on their laptops. With the 150+ audience members all viewing the presentation that gave it a very big initial push. A few of them also tweeted it which helped even more people to view and follow it. Slideshare has a ranking algorithm that tracks when a lot of people view a presentation in a short amount of time and flag it as a “hot” presentation. Within a couple of hours it had 600+ views and a couple dozen tweets on twitter.

That evening I got an email from slide share that my presentation was getting a lot of views. I got a second email that it was experiencing a high volume of tweets as well. It continued to climb up the ranks. The next morning it was selected as the SlideShare presentation of the day.

@slideshare: ‘#OSCON 2012 MongoDB Tutorial’ by @spf13 is a #SlideShare presentation of the dayhttp://t.co/74DqqsJR cc @oscon on Twitterhttp://twitter.com/slideshare/status/225393208581038080"

On Tuesday it had amassed an outstanding 7k+ views

From there it became a presentation of the week. It was featured prominently on the home page where it remained for the next 3 days at which point over 22k people had viewed it.

Once it fell off the home page and popular/week lists and tweets became less regular the number of views were still significant, but had slowed to a few hundred a day. At the time of this writing it’s over 30k views and climbing.

See also my post on “How to deliver a great conference tutorial” where I walk though how to prepare and deliver an effective conference tutorial.