
New case studies about Google’s use of Go - theBashShell
https://opensource.googleblog.com/2020/08/new-case-studies-about-googles-use-of-go.html
======
piazz
I played around with Go a while ago, and while I appreciated the approach to
concurrency, I was really put off by both the boilerplate + how primitive the
type system felt. Not having map and filter due to lack of generics meant
writing for loops all over the place just to filter and modify arrays.
Appending elements to slices felt clumsy. The type system didn't feel
expressive, and I often found myself having to resort to the empty interface
escape hatch.

Compare this with Typescript (or Swift, or Rust), which have type systems
capable of modeling nearly any problem domain. Go doesn't have algebraic data
types (sum types) which are incredibly useful in my experience (Swift/Rust
enums, Typescript discriminated unions). I'm honestly not sure why I would use
Go over TS, unless performance was my primary consideration. It feels like Go
was designing to be as inoffensive as possible to a legion of new-grad Google
programmers, and you sacrifice most modern language niceties for it. Please
convince me I'm wrong, because I really wanted to like Go.

~~~
solidasparagus
TS and Golang aren't comparable. I use both and I've never had a case where I
needed to decide between the two. Golang is a high performance, modern
language without the low-level or legacy headaches of comparably performant
languages. Golang was written for an era where network communication and
concurrency are commonly necessities and those use cases feel very natural.
Typescript is JS (a conversation ending advantage in many cases) and so the
concurrency model is amazing in some cases (e.g. when most of the work is
async stuff like API calls) and pretty terrible in others (parallelizable
computational work).

Golang was designed for getting shit done. If you are a big believer in OOP,
then Golang feels underfeatured. But if you don't really care about OOP and
you just want some of the advantages like basic inheritance, type safety, etc,
Golang has everything you need to write performant, effective code quickly
(there are use cases where that isn't true I'm sure, but, for me, Go's type
system has been helpful and not a hinderance). There's nothing wrong with
using the empty interface when you need to (any more than using any in TS,
which you have to do in many applications).

I've found that Golang codebases are easy to pick up. I think everyone has
some part of the Go style that they think is ugly (I 100% find append ugly),
but for me this has mostly been inconsequential stuff - it has never gotten in
the way of me solving business problems with high performance code. The
tooling is the same (at least if you are using modules). It does its job well
enough and then gets out of the way while you create business value.

I don't know your use case so this might not be relevant, but sometimes people
will overuse for loops and slices when they might find it easier in Golang to
pass around channels and use the pipeline pattern[1].

For me, Golang is like Python but with static typing and high performance.
Fast to implement, easy to read, and focused on getting code out the door.

[1] [https://blog.golang.org/pipelines](https://blog.golang.org/pipelines)

~~~
nine_k
I always cringe when people proclaim that they need to "get shit done". It
often pays to be mindful of _what_ is getting done as a result.

~~~
erik_seaberg
I think some people feel productive when they write out a big loop, but to me
it’s wasted effort. I want to write

    
    
      col.filter(_.isReady).map(convertToX).any(_.color == BLUE)
    

and generate whatever fused loops make that work. I don’t want to write and
review loop boilerplate by hand for the same reason that I don’t want to
customize the stack frame layout when I call a function.

~~~
solidasparagus
I've never found it much more painful to write:

    
    
      for i, c in range col {
        if c.isReady && convertToX(c).color == "BLUE":
          return True
      }
    

(which is not to say I don't miss the map/filter syntax - although I don't
miss the bugs related to lazy execution in stuff like LINQ or Spark)

~~~
erik_seaberg
That’s actually pretty good. Most people would use three more lines to create
a temporary and break after setting it, and three to nine more depending on
how many steps require idiomatic Go error handling.

~~~
andykx
Would most people actually do that? That example seems like pretty idiomatic
Go. I imagine junior developers would write that.

~~~
erik_seaberg
I would typically expect

    
    
      anyBlue := false
      for _, c in range col {
              ready, err := c.IsReady()
              if err != nil {
                      return nil, fmt.Errorf("isReady failed: %v", err)
              }
              if !ready {
                      continue
              }
              x, err := ConvertToX(c)
              if err != nil {
                      return nil, fmt.Errorf("convertToX failed: %v", err)
              }
              color, err := x.GetColor()
              if err != nil {
                      return nil, fmt.Errorf("getColor failed: %v", err)
              }
              if color == BLUE {
                      anyBlue = true
                      break
              }
      }
    

which badly obscures what’s going on but demands no cleverness at all (except
that some might forget the “break” and still get the right answer).

~~~
tmerr
If IsReady, ConvertToX, and GetColor can return errors then this isn't that
far off. But then you're not making an apples to apples comparison. You would
have to extend your functional example so that it also handles errors. Unless
it already does, and I am missing something.

~~~
erik_seaberg
What I wrote should be pretty close to valid Scala, which handles exceptions.
I can imagine wanting to skip an isReady failure, which looks like

    
    
      col.filter(c => Try(c.isReady).getOrElse(false))
      .map(convertToX).any(_.color == BLUE)

~~~
tmerr
I see. Then in part the comparison is showing off exception handling, not FP.

Rust is a good example of functional lang without exceptions (panics aside).

In Rust there are many cases where I could use FP but opt not to because it
can make error handling more awkward. For example to collect the result of a
map operation to a vector, and if there is an error along the way you want to
abort the entire operation. In functional this means collecting to a
Result<Vec<T>>. Not sure if I'm just tired today but I can think of how to do
it in 5 seconds with a loop. I suspect functional solution would be uglier.

~~~
steveklabnik
Rust’s collect will do this for you. It’s even an example in the
documentation.

~~~
tmerr
Thanks! I learned something new.:)

[https://doc.rust-lang.org/stable/rust-by-
example/error/iter_...](https://doc.rust-lang.org/stable/rust-by-
example/error/iter_result.html#fail-the-entire-operation-with-collect)

This is easy to miss if you are mainly reading reference docs. I probably read
the getting started guide at a time before there was a section on it.

My other comment in this thread comes to mind
[https://news.ycombinator.com/item?id=24300057](https://news.ycombinator.com/item?id=24300057)

~~~
steveklabnik
I was thinking of the final example in [https://doc.rust-
lang.org/stable/std/iter/trait.Iterator.htm...](https://doc.rust-
lang.org/stable/std/iter/trait.Iterator.html#examples-25) , glad we have it in
both places!

I don’t personally really agree with what you’ve said, but that’s fine.
Different people perceive things differently.

~~~
tmerr
No problems. There are enough dimensions involved in what makes a language
good that Im pretty sure I could rationalize why any language is better than
another, measured along only one of them.

Robustness. Speed. Simplicity. Easiness. Conciseness. Writability.
Readability.

Hard to tell which are independent vs correlated, let alone how they factor
into productivity. And productivity is also a function of the kind of problem
you work on.

------
warent
I absolutely love using Go. The logical flows for my programs are always so
clean and easy to follow thanks to the language. Contrast to C++ in which
spaghetti and magic is basically idiomatic. The only downside I can think of
is that error/crash recovery is pretty tricky, but it's only really a concern
if you're careless with your goroutines.

Whenever I work in Go, I have a lot more confidence in the efficiency of
resource usage, and sense of stability that I just don't get from something
like Node.js, where I'm constantly wondering... are any of these 1000s of
dependencies going to suddenly do something weird like hijack my .env file?
How is my program managing memory and overhead when it needs to interface with
the kernel via a C++ wrapper? Are these machine resources even being
capitalized on by Node.js properly? etc.

I've heard a lot of great things about Rust, and I've touched on it a bit, but
Go is just awesome for its abstractions, ease-of-use, and of course insanely
fast compile times.

~~~
Knut4231
I have a love/hate relationship with Rust. I love the type system as
enthusiast, but as project lead I can't justify relying on so many (partly
immature) third party dependencies for business critical stuff.

~~~
ridv
I had similar feelings when I was hired to write in Go about 3 years ago.
Coming from Java where everything (including the kitchen sink) was available
for import, it took some time to re-adjust my mindset of having to seek out
libraries and thoroughly vet them.

After a while, I kinda started to dig having to do it. You end up having a
more personal connection with the dependencies you pick which makes it easier
to contribute back upstream.

The one downside of being around in this stage of a language's ecosystem
development is you can potentially get some pretty undesirable fragmentation.

A good example that comes to mind is one of the original Go library to
interact with Zookeeper. There's like 6 maintained forks of that library due
to the original author bowing out of maintaining it.

------
mabbo
While I do trust Rob Pike to not let personal biases sway his writing, I do
have to wonder if the case studies weren't selecting because they were
positive. So I'm curious: does anyone have a case study where using Go was a
disaster?

Every language has things it's good at, and things it's bad at. Where does Go
not do well?

~~~
cmrdporcupine
Let me just say that I've been at Google for almost 9 years, and have recently
started looking for work elsewhere and it seems that Go is far more popular
outside of Google than inside it. Which disappoints me because my experiences
with the language internally have biased me such that I have no desire to go
use it elsewhere.

I've said this before, but I think it's a bit dishonest to sell this as a
"Google language." It is an accepted language here, along with Python, Java,
JS/TS, Dart, and C++. But it is by no means dominant.

To put it another way, it seems if the goal is to avoid working in Go I am
better off staying @ Google than leaving. And that's weird, and maybe
revealing.

~~~
tomlu
My current and last positions both involve(d) writing (mostly) Go code, so
it's definitely possible to find Go jobs within Google.

~~~
apta
OP wants to _avoid_ using golang, not to find a job where he can use it.

------
colesantiago
You can see more very exciting case studies of companies using Go here, didn't
know until now Twitch or Facebook (and even Target!) uses Go a lot.

[https://go.dev/solutions/#case-studies](https://go.dev/solutions/#case-
studies)

~~~
zemnmez
All backend systems at save a few minor exceptions are written in Go :)

~~~
saagarjha
This isn't true at all. Google still runs a lot of backend on Java, for
example.

~~~
jeffbee
And their backends in C++ dwarf Java and Go backends combined.

~~~
erik_seaberg
In 2015 they were saying that the core of web search (and the large majority
of Borg cores) was C++ but the rest of google3 was a 50:50 mix of C++ and Java
with a smattering of Python. Nobody I knew was looking seriously at Go.

~~~
jeffbee
I think weighting it by lines of code is pretty misleading. You have to write
a zillion lines to make "hello, world!" work in your new language inside their
full-custom production environment. I prefer to think of language share in
terms of resources committed.

------
nedsma
Go is super productive. My day-to-day responsibilities include development in
.NET and Go. A full day working in Go is like a having a pleasant day off. On
the other hand, .NET is so cumbersome, complex and verbose (I've been using it
since its inception), that I'd rather abandon it for good if possible.

~~~
tigershark
.NET is not a language. Are you using C#, VB.NET or F#?

~~~
nedsma
You're absolutely right. In majority of cases, when people say .NET, they mean
.NET & C#. VB.NET or F# are pretty much always explicitly mentioned as they're
not the default choice for .NET development.

------
candiddevmike
Anecdote of one here, but I think Go's best use case is building monoliths
(queue the irony of it being used for a lot of microservice work). The way the
language works and the readability it provides really removes a lot of the
arguments for breaking apart a monolith, and the performance guarantees it has
around parallelism and goroutines make combining your async task processing
into your main binary trivial. I'd go so far as to say I don't think anything
beats a Go monolith in terms of developer velocity, code quality, and
performance.

~~~
JyB
That's an interesting take. Do you have personal experience that you could
share more detail on? Or even more public projects

~~~
candiddevmike
I would say the most prolific one is Kubernetes. Sure it has some parts broken
out (controller manager, scheduler), but the main API server is a pretty big
Go monolith.

At a far smaller scale, the SaaS product my company built, Domestica
([https://about.domestica.app](https://about.domestica.app)), is a Go
monolith. It has an integrated job/cron queue using PostgreSQL included as
well, all within the same binary. This makes it easy for us to distribute it
as a Docker image to our users who want a private instance
([https://hub.docker.com/r/candiddev/domestica](https://hub.docker.com/r/candiddev/domestica)).

------
andonisus
Efficient user-space threads (go routines) and the way go lends itself to the
reactor pattern is exactly why is has been the language of choice for the
company I work for. We use it to power all of our distributed microservices
which process IoT packets from a stream. The performance and ease-of-use is
heads and shoulders above everything else we tried before (mainly, Java with
Kafka/Storm).

------
sfvisser
> Looking back from 2020, Go has succeeded in both ways: it is widely used
> both inside and outside Google, _and its approaches to network concurrency
> and software engineering have had a noticeable effect on other languages and
> their tools._

Don’t know much about go myself, but I’m interested in examples of this.

~~~
joshuamorton
Arguably opinionated formatters like prettier and black are a response to
gofmt.

~~~
ses1984
Definitely but what about the impact of go's approach to network concurrency?

~~~
warent
For one example, I believe Crystal is inspired by Go in this respect.
[https://crystal-lang.org/](https://crystal-lang.org/)

------
Knut4231
I came to Go because some Kotlin CLI tools used too much memory and were
clumsy to deploy.

I'm staying for the standard lib, tooling and stability.

Nothing gets out of the way better than Go.

~~~
DangitBobby
Well, except for maybe a language that doesn't force you to remove
(temporarily) unused imports and change your variable name to an underscore if
you simply comment out the only section of code that used to refer to it,
making your variable freshly un-used. I find there are some highly
opinionated, unconfigurable aspects of the language that pretty much only
waste time. They actually get in my way constantly.

------
bit_logic
async/await colored functions is a disaster:
[https://journal.stuffwithstuff.com/2015/02/01/what-color-
is-...](https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-
function/) And so many languages and ecosystems have fallen to this. Even C#,
which is surprising since I expected them to know better. There was so much
hype about async/await (nodejs was a big factor for this hype), that many
languages adopted this without fully considering the long term maintenance
nightmare it will create.

Because of this, I'm mostly interested in only Go and Java. Go obviously
avoids the async/await trap with its core feature, goroutines. Java managed to
resist this trap and has Project Loom coming which will give it the same
feature as goroutines, but in a backwards compatible way.

Go is criticized for not having generics, but I appreciate the slower and more
thoughtful way both languages add new features. Javascript, C#, etc. these
languages seem to add whatever FOMO driven new hyped language feature is
popular at the moment. Many complain about Go taking so long to add generics,
just like many complained about lambdas in Java. But evolving a language
should not be done quickly and recklessly.

My focus is still on Java, but I'm occasionally looking at Go to see what
they're doing. It's interesting watching these two languages become more like
each other (generics in Go and fibers in Java).

~~~
jayd16
Async/await solves a different problem than green threads. Async/await works
well when you need to manage scheduling of a single thread (very common in UI
or other cross runtime tasks). Implicit green threads are nice if all you care
about is total throughput across all threads. Its not great for keeping a
single thread responsive.

~~~
eweise
Async / await is just an abstraction over threads. It doesn't dictate how many
threads are used.

~~~
jayd16
I'm not sure what your point is exactly but I would disagree with the
presented assertions none the less.

In C# async/await is essentially sugar around callbacks, which isn't really
related to threads, per se. However, the language has the Task Parallel
Library, and a Task promise type that has a lot of methods around scheduling
and thread targeting. Essentially the TPL does dictate how many threads are
used and is, as far as language design is concerned, inextricable from
async/await.

~~~
eweise
My reply was in response to "Async/await works well when you need to manage
scheduling of a single thread" My point being that it isn't limited to cases
where you only have a single thread.

~~~
jayd16
Ah, agreed. That's a case where it does well, not the only case.

------
scarmig
> Go also powered Google’s development and launch of Kubernetes in 2014.

Wasn't k8s written originally in Java and only ported to Go later on?

~~~
lstamour
I think it's fair to say both statements are true:

> Kubernetes was built on ideas that had been proven out at Google over the
> previous ten years with Borg. And Borg, itself, owed its existence to even
> earlier efforts at Google and beyond.

> Concretely, Kubernetes started as some prototypes from Brendan Burns
> combined with ongoing work from me and Craig McLuckie to better align the
> internal Google experience with the Google Cloud experience. Brendan, Craig,
> and I really wanted people to use this, so we made the case to build out
> this prototype as an open source project that would bring the best ideas
> from Borg out into the open.

> After we got the nod, it was time to actually build the system. We took
> Brendan’s prototype (in Java), rewrote it in Go, and built just enough to
> get the core ideas across. By this time the team had grown to include Ville
> Aikas, Tim Hockin, Brian Grant, Dawn Chen and Daniel Smith. Once we had
> something working, someone had to sign up to clean things up to get it ready
> for public launch. That ended up being me. Not knowing the significance at
> the time, I created a new repo, moved things over, and checked it in. So
> while I have the first public commit to the repo, there was work underway
> well before that.

[https://kubernetes.io/blog/2018/06/06/4-years-
of-k8s/](https://kubernetes.io/blog/2018/06/06/4-years-of-k8s/)

------
enahs-sf
I tried very hard to bring go into my previous employers environment, but it
was all for naught. They are too bought into the JavaScript stack. Case
studies like this would have been super helpful in trying to make my claims.

~~~
lstamour
It's funny, if you'd asked me almost a decade ago which language would compete
with Go, I would not have answered "JavaScript"! Yet, these days I find that's
the trade-off: build something "quick" in TypeScript that's easy to modify but
perhaps a bit brittle and slow(er) to run in production, vs build something
very considerate and optimized in Go but perhaps not something you can easily
change without hiring folks specifically for the backend.

And then you've Java, which is now trying to be the "VM for every runtime" but
is still best at Java itself, for now. I tried running JS-on-Java (graaljs) to
improve the performance of JavaScript from "only twice as fast as Python" to
"within the top 10 on TechEmpower" but found it had too many compromises to
rely on it, it was just another runtime layer I would have to worry about.

I end up wondering if the solution really is to begin by prototyping efforts
in slower-executing languages to start except where existing conditions and
code ecosystems might allow for faster initial results in another language.
(Kubernetes projects should likely use Go, etc.) Which is less about Go and
more about the need to rewrite software later, I suppose.

Then again, these days the problems I end up spending (too much) time on are
"which dependency should I use," or "should I rewrite the dependency," I
rarely ask myself which language is "better" for a task because I end up
having to use languages others are familiar with. Go is not yet universally
one of those languages, but the more I see unfamiliar Go code in the wild, the
more I feel it could be. One of its current strengths is that its simple
syntax and maybe its repetitiveness also makes it quite easy to follow for
newcomers.

~~~
zozbot234
I mean, it's hard to see Go as "very considerate and optimized" given the
existence of modern, highly-efficient programming languages like Rust, D,
perhaps Swift etc. It's obviously better optimized than JavaScript and its
derivatives, or even Java/C#, but that's not saying much.

~~~
lstamour
Rust doesn't have the stability yet that has been a bit of a double-edged
sword for Go. And it's taken 5 years for Rust to get as far as it has. I'll be
much more interested in using Rust in production when there's more of a
"standard library" of options to start with. Right now it has the curse of
being both unfamiliar to programmers and not having very many production-ready
dependencies available in a larger ecosystem. It might be the "right choice"
for the future, but if you don't already know you need Rust, I'm having
trouble seeing how typical software can benefit today from Rust, etc., though
I really do hope my answer changes over the next few years. :)

Swift is definitely something I'd like to explore more, but like Rust, it has
few production-ready dependencies available. Kotlin or other Java derivatives
on the other hand probably have too many -- if your code is written in Java,
I've no idea if it will work great in Kubernetes or if it will expect OSGi or
if it's a giant monolith. Which is to say, modern practices can make the JVM a
surprisingly practical choice, but most software isn't really all that
optimized -- slow and bloated legacy dependencies are both a problem in Java
as in Node.js...

C# meanwhile can be efficient, but rarely is. And it has toolchain issues due
to VS not being open source, and a very small ecosystem of dependencies, plus
a history full of corporate rewrites of core functionality. It has a bright
future, but its reliance on msbuild and Visual Studio limit it compared to
Java. I'd like to suggest C++ but I've spent years learning it and find the
complexity overwhelming in side projects. In practice, I think C++ is only
appropriate for full-time projects with lots of engineers to validate
correctness, etc. The exception I'd make is tiny C++ modules as glue code
between languages, or to other existing C code.

~~~
james_s_tayler
Does C# rely on VS? MSBuild is separate from VS and you can use Rider (yay!)
or VSCode instead of VS.

The ecosystem is definitely growing in the last 5 years too since open source
has been embraced by MS and the community.

The major rewrite of .NET -> .NET Core and then now renaming it back to .NET
again is good in that it's a much better framework now, bad in that it's
turning out like Python 2 vs Python 3. Huge projects just can't upgrade, so
old .NET Framework stuff is sticking around longer than it should.

~~~
lstamour
Generally speaking, C# relies on either third-party implementations like
[http://www.omnisharp.net](http://www.omnisharp.net) or Microsoft
distributions, which on Windows is largely distributed via Visual Studio
Downloads page, including the Tools for Visual Studio package:
[https://visualstudio.microsoft.com/downloads/](https://visualstudio.microsoft.com/downloads/)
Are there other releases of msbuild, for example? Yes:
[https://github.com/dotnet/msbuild/releases](https://github.com/dotnet/msbuild/releases)
But are they separate from releases of Visual Studio? No, as the release notes
indicate. If you want to live on the bleeding edge of .NET development -- and
I do recommend this -- you'll end up in the Preview channel of Visual Studio:
[https://visualstudio.microsoft.com/vs/preview/](https://visualstudio.microsoft.com/vs/preview/)
and if you want to use Visual Studio Code instead, welcome to OmniSharp or
similar "mostly compatible" solutions. It's totally fine until it's not, and
it's definitely not portable or open enough -- yet. I look forward to the day
when Visual Studio is fully open source because they can include subscriptions
on top or something. That'll be the day when VS and VS Code could begin to
merge a bit, at least for development on Microsoft platforms. But that hasn't
happened yet, and they're rebuilding Visual Studio in Eclipse on other
platforms to better support cross-platform development the same way Rider
supports other platforms for JetBrains IDEs. It's a stop-gap until the fully-
open-source versions of VS and VS Tools are finally available. I suspect
they're waiting for .NET 5 or later, at this point...

They're undoing the split between Core and .NET Framework by suggesting that
they'll ship both within .NET 5 using shims or implementations of drop-in
replacements for .NET Framework code to use. Imagine if after dropping Python
2 support there was a mode that scanned for Python 2 code and enabled it
again, on a file-by-file basis, to work with newer Unicode strings using some
kind of translation layer in the runtime. That's kind of what's happening
here, I think, but maybe more lightweight than suggested. Legacy .NET
Framework code still deprecated, but interoperability libraries will ship as
part of the runtime or SDK, will have some amount of shims available. I
haven't followed the details closely enough to say more than this, though. I
last looked into it a few months ago.

~~~
tester756
As far as I know - there will be those frameworks to select:

>net5.0

>net5.0-windows

>net5.0_something

So you can use "pure" "net5.0" on Linux and generally cross-platform software
meanwhile still be able to use old .NET FrameworkX winforms/wpf on
"net5.0-windows".

------
ridiculous_fish
Does Google use Go for any non-server applications? For example in Android,
iOS apps, ChromeOS, Chrome browser?

~~~
jeffbee
Quite an interesting question. The Android GPU Inspector[1] is a desktop
GUI/CLI developer tool that's written mostly in Go, but also has a bit of
client/server architecture internally so I don't know how you would count it.

1: [https://gpuinspector.dev/](https://gpuinspector.dev/)

------
game_the0ry
Go as a new language is a _mega_ success.

K8s, docker, native concurrency, robust std lib, list goes on.

Obviously, not the magical swiss army knife for all engineering use cases, but
successful in a lot of domains and well-liked by developers. Winning.

And its only version 1.XX.

I've never even used go and I am impressed.

Well done, Google. Well done. (golf clap)

~~~
saagarjha
> And its only version 1.XX.

Are there plans for a new version that is radically different, or is it going
to be like Java or macOS where updates continue to change what is usually
considered the minor version?

~~~
game_the0ry
No idea, but I think it is impressive that a language that is still on
"version 1.XX" has been so successful so far.

~~~
mseepgood
A project can use version numbers 1 ... 9999999 or version numbers 1.0 ...
1.9999999. The amount of work that goes into it is the same.

~~~
josefx
See for example Java, which basically dropped the 1. from 1.5 .

------
saagarjha
Important point: this is _Google 's_ use of Go, not _your_ use of Go. Take
note to check whether their results are applicable to you before adding it to
your repertoire of "reasons we should use Go at our company".

~~~
Knut4231
What are you trying to say?

Go is at my employer's (one of the top 3 car companies world wide) techradar
the number one to adopt. New stuff of all kind is done in Go.

So, Go is a huge success outside of Google as well.

Not saying that I'm of any importance for Go, but I'm using Go for personal
projects, at work for CLIs and standard backend stuff (APIs + DB, Redis, etc.)
with great success.

~~~
saagarjha
I love reading about how companies use various technologies and how it works
for them but I am personally weary of dealing with people who bring up these
writeups in language wars without qualification–I'm sure you know the usual "
_Google_ uses it, so it must be good" or " _Facebook_ stopped using it, so it
must be bad" kind of proposition. Actually, I've written many words on the
topic, many more than I have put there; perhaps you've seen it already ;)

But to be clear: I'm saying that reading about other people's experiences with
a language (including yours here) is useful in making your own decisions, but
you must also account for how you and your usecase are different than the one
that was presented.

------
PostThisTooFast
Kinda tired of the proliferation of languages coming out of Google, whether
they actually created them or not.

If Go is so great, why was Kotlin released four years later and made the
standard on Android? It's annoying enough to have to use Swift and Kotlin for
iOS/Mac vs. Android. Now Go? What happened to Dart?

Then there's Rust. What about next week?

~~~
jeffbee
> What happened to Dart?

Dart is one of the three officially supported and approved languages of
Fuchsia.

[https://fuchsia.dev/fuchsia-
src/contribute/governance/policy...](https://fuchsia.dev/fuchsia-
src/contribute/governance/policy/programming_languages)

The only language that came out of Google that people have a right to be upset
about is PromQL. That's an abomination.

------
JamesBarney
I see why go is clearly superior to C++. I see why it's simplicity is great
for bringing new people up to speed. I see why it's concurrency model is
better than many other languages. And I really like their software engineering
philosophy.

Go seems clearly one of the if not the best systems language around.

But how is Go in the line of business web application space? The space that's
historically been dominated by your Python, Ruby, Go , node.js, C#, Java
applications?

I get it's probably more performant, but honestly in C# my primary language I
spend almost all my time optimizing DB queries and almost none optimizing C#
code. I get it's concurrency model is better, but with web apps that usually
isn't much of a problem.

Is Go as better in this space as it clearly is in the systems programming
space? I get it could be used for the LoB use case but is it better, and if so
is it significantly or marginally better?

~~~
saagarjha
> I see why go is clearly superior to C++.

You shouldn't. If anything you should be looking into where C++ does better
than Go and see if Go is improving there–and understanding that there will
always be places where Go is not the best choice or even appropriate.

~~~
JamesBarney
I'm sure Go is not better for every single use case. But it seems to be there
were a lot of high performance systems that would have been written in C++,
like InfluxDb for example that are clearly more reliable and easier to develop
because it was written in Go.

Where do you think C++ outshines Go?

~~~
jeffbee
I think that's an example of a system where the performance demands weren't
high enough to justify using C++. There are lots and lots of applications
where the overall architecture can't take advantage of the speed of C++, but I
think there's no question that the peak performance of C++ far outshines the
abilities of Go.

Taking an example from the article, parts of Google's indexing pipeline are
now in Go, but nobody is suggesting that the search engine would be.

~~~
cdelsolar
Go is basically almost as fast as C++.

~~~
jeffbee
And cat food is "basically" pâté. The Go toolchain lacks virtually all of the
optimizations that a C++ compiler would employ in an optimized build and the
Go toolchain also lacks all of the ways you'd achieve peak optimization for
C++, such as profile-guided optimization and link-time interprocedural
optimization.

These programs are are not even peak optimized but the C++ version still wins
every case by between 10% and 1000%.

[https://benchmarksgame-
team.pages.debian.net/benchmarksgame/...](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/fastest/go-gpp.html)

