19 ms·

New case studies about Google’s use of Go

218 points by 0xedb 6y ago

scarmig 6y ago
> 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 6y ago
  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 6y ago
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.
- game_the0ry 6y ago
  The good news is that this case study means you were probably right to bring it up as a worthwhile consideration, and you will have these case studies to point to next time.
  - enahs-sf 6y ago
    nah, I just quit and started my own company instead. Now I use go on the backend. problem solved.
- lstamour 6y ago
  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.
  - wolco 6y ago
sfvisser 6y ago
> 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 6y ago
  Arguably opinionated formatters like prettier and black are a response to gofmt.
  - ses1984 6y ago
    Definitely but what about the impact of go's approach to network concurrency?
    - warent 6y ago
      For one example, I believe Crystal is inspired by Go in this respect. https://crystal-lang.org/ https://crystal-lang.org/
    - Scarbutt 6y ago
      asynchrony without async/await
  - shadowgovt 6y ago
    Benefits of this for large system projects cannot be understated. The notion that there's a many-to-one mapping between allowed representations of the source code and a canonical representation is very smart because it enables bidirectional preferences; not only can the main source make assumptions about code format independent of individual user preferences, but individual users can have preferences independent of the main source; code that is in a canonical format is easier to apply custom formatting to. In addition, a canonical format makes it slightly easier to do plaintext search indexing, so you can get some of the benefits of having the code parsed into a full AST without needing to do that parsing.
- 6y ago
PostThisTooFast 6y ago
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?
- jasonvorhe 6y ago
  Different use cases. Golang is made for simple deployments, mostly services that need to scale, stuff you'd previously had to use something like C++ or Java for. Dart is mostly relevant if you're building apps with Flutter. Kotlin isn't Google's creation, they just recommend it for developing native Android apps instead of Java.
- jeffbee 6y ago
  > 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/programming_languages https://fuchsia.dev/fuchsia-src/contribute/governance/policy... The only language that came out of Google that people have a right to be upset about is PromQL. That's an abomination.
- vips7L 6y ago
  Google didn't make Kotlin or Rust o_O
- fs111 6y ago
  Kotlin is from JetBrains, not from google
- moocowtruck 6y ago
  also interesting go is not an approved language on google's fuschia
- idoubtit 6y ago
  If you're really wondering why different programming languages exist, the answer is simple: different use cases, and the influence of past languages. Bell Labs did the same by creating C, C++ and AWK. For any of the languages you mentioned, it's easy to find the motivation for their creation, either by Wikipedia or on official pages Why X?. Your uninformed rant sounded a bit lazy and naive (sorry, no offense intended). From the top of my head... Go was meant as a higher-level language than C where Python could not apply (bad performance, weak typing, no compilation, complex syntax); its wide adoption proves that kind of language was missing at the time. Dart was initially meant as an alternative to JavaScript, like CoffeScript, at a time where JS was less standard. Kotlin was not created by Google, and was meant as a light alternative to Java/JVM, with full compatibility, hence the adoption for Android which is JVM based. As far as I know, Swift and Rust aren't specifically tied to Google.
colesantiago 6y ago
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 6y ago
  All backend systems at save a few minor exceptions are written in Go :)
  - saagarjha 6y ago
    This isn't true at all. Google still runs a lot of backend on Java, for example.
    - jeffbee 6y ago
      And their backends in C++ dwarf Java and Go backends combined.
      - erik_seaberg 6y ago
        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 6y ago
        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.
  - zemnmez 6y ago
    This comment was about Twitch :'( I guess you guys thought I was talking about something else
game_the0ry 6y ago
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)
- wolco 6y ago
  Surprised Angular didn't make the short list at least angularjs.
- saagarjha 6y ago
  > 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 6y ago
    No idea, but I think it is impressive that a language that is still on "version 1.XX" has been so successful so far.
    - saagarjha 6y ago
      Version numbers are fairly arbitrary. I use a lot of 0.x software that is basically run as a production release.
    - adonovan 6y ago
      It's success is in part because of that, not despite it. Contrast with Python3, which alienated masses of users by making breaking language changes.
    - mseepgood 6y ago
      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.
andonisus 6y ago
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).
logicslave12 6y ago
Sure they made Go. But where are the innovations in search and information retrieval? Where are new data products? Sure, they innovated on word embeddings. But If they are going to monopolize and control access to information, why are they doing such a poor job at it? I say this with some anger. This company affects all of us, and they are completely mediocre from a product perspective. I welcome the day when NLP gets good enough to where a competitor can rise. Until then, we are stuck with this abomination and arrogance.
- X6S1x6Okd1st 6y ago
  Seems fairly off topic
  - logicslave12 6y ago
    I think it is on topic. I’m tired of this company parading their “technical achievements” while simultaneously constraining humanities access to information
    - X6S1x6Okd1st 6y ago
      Your second statement is a good reason to complain about Google if properly substantiated, but it still is very tenuously linked to developing and promoting Go
- ngrilly 6y ago
  Google Translate, for example, is amazing.
  - logicslave12 6y ago
    You mean a neural network I could pull off github, and if I had enough money to train it, end up with the same results?
    - X6S1x6Okd1st 6y ago
saagarjha 6y ago
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".
- X6S1x6Okd1st 6y ago
  These are case studies from companies that aren't google.
  - saagarjha 6y ago
    Are they? I see links to case studies about Firebase and Google Cloud.
    - dewey 6y ago
      Are you looking at the right page? The first three companies I see there are American Express, Capital One and Cloudflare on the list they link to: https://go.dev/solutions/#case-studies https://go.dev/solutions/#case-studies
      - saagarjha 6y ago
        I’m looking at the pages linked from https://opensource.googleblog.com/2020/08/new-case-studies-about-googles-use-of-go.html https://opensource.googleblog.com/2020/08/new-case-studies-a..., which seems to be about Google’s use of Go.
        dewey 6y ago
        > In the past year, we’ve posted sixteen case studies from end users around the world talking about how they use Go to build fast, reliable, and efficient software at scale. Click on the link about the "sixteen case studies" and you'll see the rest.
        6y ago
JamesBarney 6y ago
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 6y ago
  > 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 6y ago
    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 6y ago
      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.
deleted 6y ago
[deleted]
warent 6y ago
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 6y ago
  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.
  - theshrike79 6y ago
    This is exactly what I've been thinking. Right now you need enthusiasts and a project that can either accept or handle the risks brought on by the immature ecosystem. Later on, Rust will most definitely be a huge thing. It's just not the right choice for everything - even if the community has a habit of pumping out "X - but with Rust" projects.
  - ridv 6y ago
    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.
Knut4231 6y ago
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.
- tmountain 6y ago
  I agree completely. It's so pragmatic. It's not sexy. It just does the damn job, and that's why I love it.
- DangitBobby 6y ago
  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.
mabbo 6y ago
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?
- the_af 6y ago
  I know a case (second hand) where they migrated from a Java backend to Go, then had to roll it all back to Java because it was too hard and error prone to maintain. This is a very successful business, not a startup. No idea why they felt they had to migrate to Go in the first place. I'd rather not mention the company, even though I did not work there.
  - thebean11 6y ago
    Yeesh, I can't imagine migrating a large backend codebase from any language to any language. And we're talking about migrating from Java..which is extremely well supported and probably the easiest language to hire for..
  - nine_k 6y ago
    Concurrency is something that Go makes much easier, or at least more ergonomic, that Java with Runnables and ExecutorPools.
    - Groxx 6y ago
      It makes it easier to start concurrent stuff, but without ready-to-use type-safe abstractions like Java provides I'd say it's far harder to make correct concurrent stuff in Go. And while the race detector is wonderful, especially since it's baked in, it's nowhere near sufficient.
    - apta 6y ago
      I disagree. There is so much boilerplate involved with managing concurrency in golang compared to Java. It's very error prone in practice and difficult to extend and manage. golang has nothing remotely close to `java.util.concurrent`.
piazz 6y ago
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.
- Mr_T_ 6y ago
  You'll be happy with the latest developments: https://blog.golang.org/generics-next-step https://blog.golang.org/generics-next-step
- erokar 6y ago
  I share much of the sentiment. I like the simplicity of Go, but I think they took it too far an ended up with something too dumbed down and lacking in abstractions and expressive power. It feels like a step backwards coming from other contemporary and popular languages like JS/TS, Python, Kotlin, C#.
  - throwaway894345 6y ago
    I agree with this, but I suspect I disagree on the extent to which this is a problem. These things are minor annoyances in my opinion compared to concerns that are largely apart from the actual language itself, such as performance, ecosystem, tooling, deployment story, learning curve, etc. With respect to Python and JS, you can always drop down to `interface{}` for similar expressive power and type safety, but generally people don't do this for the sake of simple for-loop boilerplate. Here are some serious pitfalls with Python (it's the language I know best) that dwarf concerns about language features. JS, Kotlin, and C# share some of these problems. Go doesn't really share any of these problems; it competes well with JVM and .Net with respect to performance, and its tooling story is simply top-notch on the whole (of course, there are individual tool categories where other languages have better offerings). * Python is a super slow language and the proverbial advice "just rewrite the hotpath [with multiprocessing / with C / with Pandas / etc]" falls over for any bottleneck that involves processing a large object graph. In these cases, you can't use multiprocessing because the de/serialization and IPC costs will typically exceed any parallelism gains. You can't use Pandas because the data set isn't matrix-shaped, and even if you can shoehorn it into a dataframe, you'll end up calling back and forth between Python and Pandas/C so much that you'll lose anything you gain from Pandas (and have much harder to maintain code). Similarly with "rewrite it in C/Rust/etc", you'll have to basically rewrite the whole object graph (including all of the inherent classes and methods) into C/Rust/etc and you probably don't want to keep those in sync with the original Python classes, so congratulations, a huge amount of your code is now in C/Rust/etc and you're no longer enjoying any of the benefits you would enjoy with Python (probably iteration velocity). Sadly, performance isn't likely to get better in Python because the community is so heavily invested in C-extensions (because Python is so slow) and the C-extension interface is basically the whole CPython interpreter, such that anything that wants to play in the ecosystem has to be very CPython shaped including many mechanisms that are prohibitively difficult to optimize around. Pypy is making a lot of interesting progress, but compatibility is still a blocker for lots of applications (e.g., anything that wants to talk to a Postgres database--unsupported packages notwithstanding). Python is fine if all you're doing is shelling out to a database or a C library, but anything more becomes expensive quickly ("well how come $BIGCOMPANY is so successful despite using Python?!": probably deep pockets). * When you want to distribute a Python program (e.g,. an internal tool), your options are pretty limited--the executable zip file formats (e.g., PEX files) are pretty nice, but inevitably something depends on an .so file (because Python utterly depends on C for just about everything) that doesn't get included in the zip file. Even in the happy path, you have to have the right version of a Python interpreter installed on the target system. * Correctness is the least of problems with untyped Python or JS, rather the biggest problem is the lack of quality documentation (critical information is typically either missing or outdated). The second biggest problem is that there aren't rails to guide mediocre developers toward sane code--developers tend to not know how to "think in types" and the code is typically far more complex than equivalent typed languages as a consequence. * Python nominally has a static type checker, but it's still very immature (still can't model JSON or even callbacks with keyword arguments). Further, getting it to find the type stubs for a given package is an exercise in frustration and terrible error messages. The only hope is that the Python community seems to be leaning into type annotations, so that should drive improvements in tooling in time (how long? is a different question) * Tests are super slow, largely because Python is super slow. CI bills can get to be really expensive. Not a big deal for well-endowed companies, but this is really hard for companies with meager budgets (this is ultimately true for Python generally IMO, not just WRT CI bills). * Documentation generation is brutal. Developers have to document types and keep them up to date. Consequently documented types are never up to date and many libraries--even the most popular--just punt on documenting types altogether. Then you have to write and maintain your own CI jobs for building and publishing documentation packages. And the documentation is still really reader-hostile on account of the everything-on-one-page, nested-with-no-context structure (e.g., SQLAlchemy has lots of methods and even classes with the same names but minor variances in module path and the only way to tell what you're looking at is to gradually scroll up to the previous `class Foo:` block and then back down to the thing you're looking at. Good luck ctrl+f-ing around). The latter problem would be easily remedied within Sphinx. The typing problem will get better as the typing story improves, but it's improving at only a snail's pace (mypy is still prohibitively difficult and restrictive for many projects). Further, if someone wanted to build a godoc.org clone for Python that automatically discovered, built, and published Python packages, I don't know if it would be possible because Python doesn't have a standard repository structure. * Then there's a long tail of paper cuts. Black (Python formatter) is a welcome relief but it's also really slow. No decent editor plugins (dynamic typing) and PyCharm is relatively expensive and there's still constant friction between it and your preferred editor even after you've learned it. Python has no dead-code elimination so artifacts are frequently enormous--like "too big to fit into a lambda, better use an ECS task and good luck with those startup times" big. Etc etc.
ridiculous_fish 6y ago
Does Google use Go for any non-server applications? For example in Android, iOS apps, ChromeOS, Chrome browser?
- jeffbee 6y ago
  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/
nedsma 6y ago
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.
- rizpanjwani 6y ago
  What kind of development do you do if you don't mind me asking?
  - nedsma 6y ago
    Of course not. Nowadays it's pretty much about implementing HTTP REST APIs and consuming APIs (HTTP, SOAP, gRPC). We have both monoliths and micro services in production.
- tigershark 6y ago
  .NET is not a language. Are you using C#, VB.NET or F#?
  - nedsma 6y ago
    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 6y ago
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 6y ago
  That's an interesting take. Do you have personal experience that you could share more detail on? Or even more public projects
  - candiddevmike 6y ago
    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).
bit_logic 6y ago
async/await colored functions is a disaster: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... 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 6y ago
  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 6y ago
    Async / await is just an abstraction over threads. It doesn't dictate how many threads are used.
    - jayd16 6y ago
      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.

218 points by 0xedb 6y ago

> 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 6y ago
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 6y ago

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.

game_the0ry 6y ago
The good news is that this case study means you were probably right to bring it up as a worthwhile consideration, and you will have these case studies to point to next time.
- enahs-sf 6y ago
  nah, I just quit and started my own company instead. Now I use go on the backend. problem solved.
lstamour 6y ago
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.
- wolco 6y ago

sfvisser 6y ago

> 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 6y ago
Arguably opinionated formatters like prettier and black are a response to gofmt.
- ses1984 6y ago
  Definitely but what about the impact of go's approach to network concurrency?
  - warent 6y ago
    For one example, I believe Crystal is inspired by Go in this respect. https://crystal-lang.org/ https://crystal-lang.org/
  - Scarbutt 6y ago
    asynchrony without async/await
- shadowgovt 6y ago
  Benefits of this for large system projects cannot be understated. The notion that there's a many-to-one mapping between allowed representations of the source code and a canonical representation is very smart because it enables bidirectional preferences; not only can the main source make assumptions about code format independent of individual user preferences, but individual users can have preferences independent of the main source; code that is in a canonical format is easier to apply custom formatting to. In addition, a canonical format makes it slightly easier to do plaintext search indexing, so you can get some of the benefits of having the code parsed into a full AST without needing to do that parsing.
6y ago

PostThisTooFast 6y ago

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?

jasonvorhe 6y ago
Different use cases. Golang is made for simple deployments, mostly services that need to scale, stuff you'd previously had to use something like C++ or Java for. Dart is mostly relevant if you're building apps with Flutter. Kotlin isn't Google's creation, they just recommend it for developing native Android apps instead of Java.
jeffbee 6y ago
> 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/programming_languages https://fuchsia.dev/fuchsia-src/contribute/governance/policy... The only language that came out of Google that people have a right to be upset about is PromQL. That's an abomination.
vips7L 6y ago
Google didn't make Kotlin or Rust o_O
fs111 6y ago
Kotlin is from JetBrains, not from google
moocowtruck 6y ago
also interesting go is not an approved language on google's fuschia
idoubtit 6y ago
If you're really wondering why different programming languages exist, the answer is simple: different use cases, and the influence of past languages. Bell Labs did the same by creating C, C++ and AWK. For any of the languages you mentioned, it's easy to find the motivation for their creation, either by Wikipedia or on official pages Why X?. Your uninformed rant sounded a bit lazy and naive (sorry, no offense intended). From the top of my head... Go was meant as a higher-level language than C where Python could not apply (bad performance, weak typing, no compilation, complex syntax); its wide adoption proves that kind of language was missing at the time. Dart was initially meant as an alternative to JavaScript, like CoffeScript, at a time where JS was less standard. Kotlin was not created by Google, and was meant as a light alternative to Java/JVM, with full compatibility, hence the adoption for Android which is JVM based. As far as I know, Swift and Rust aren't specifically tied to Google.

colesantiago 6y ago

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 6y ago
All backend systems at save a few minor exceptions are written in Go :)
- saagarjha 6y ago
  This isn't true at all. Google still runs a lot of backend on Java, for example.
  - jeffbee 6y ago
    And their backends in C++ dwarf Java and Go backends combined.
    - erik_seaberg 6y ago
      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 6y ago
        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.
- zemnmez 6y ago
  This comment was about Twitch :'( I guess you guys thought I was talking about something else

game_the0ry 6y ago

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)

wolco 6y ago
Surprised Angular didn't make the short list at least angularjs.
saagarjha 6y ago
> 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 6y ago
  No idea, but I think it is impressive that a language that is still on "version 1.XX" has been so successful so far.
  - saagarjha 6y ago
    Version numbers are fairly arbitrary. I use a lot of 0.x software that is basically run as a production release.
  - adonovan 6y ago
    It's success is in part because of that, not despite it. Contrast with Python3, which alienated masses of users by making breaking language changes.
  - mseepgood 6y ago
    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.

andonisus 6y ago

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).

logicslave12 6y ago

Sure they made Go. But where are the innovations in search and information retrieval? Where are new data products? Sure, they innovated on word embeddings. But If they are going to monopolize and control access to information, why are they doing such a poor job at it? I say this with some anger. This company affects all of us, and they are completely mediocre from a product perspective. I welcome the day when NLP gets good enough to where a competitor can rise. Until then, we are stuck with this abomination and arrogance.

X6S1x6Okd1st 6y ago
Seems fairly off topic
- logicslave12 6y ago
  I think it is on topic. I’m tired of this company parading their “technical achievements” while simultaneously constraining humanities access to information
  - X6S1x6Okd1st 6y ago
    Your second statement is a good reason to complain about Google if properly substantiated, but it still is very tenuously linked to developing and promoting Go
ngrilly 6y ago
Google Translate, for example, is amazing.
- logicslave12 6y ago
  You mean a neural network I could pull off github, and if I had enough money to train it, end up with the same results?
  - X6S1x6Okd1st 6y ago

saagarjha 6y ago

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".

X6S1x6Okd1st 6y ago
These are case studies from companies that aren't google.
- saagarjha 6y ago
  Are they? I see links to case studies about Firebase and Google Cloud.
  - dewey 6y ago
    Are you looking at the right page? The first three companies I see there are American Express, Capital One and Cloudflare on the list they link to: https://go.dev/solutions/#case-studies https://go.dev/solutions/#case-studies
    - saagarjha 6y ago
      I’m looking at the pages linked from https://opensource.googleblog.com/2020/08/new-case-studies-about-googles-use-of-go.html https://opensource.googleblog.com/2020/08/new-case-studies-a..., which seems to be about Google’s use of Go.
      - dewey 6y ago
        > In the past year, we’ve posted sixteen case studies from end users around the world talking about how they use Go to build fast, reliable, and efficient software at scale. Click on the link about the "sixteen case studies" and you'll see the rest.
        6y ago

JamesBarney 6y ago

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 6y ago
> 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 6y ago
  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 6y ago
    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.

deleted 6y ago

[deleted]

warent 6y ago

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 6y ago
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.
- theshrike79 6y ago
  This is exactly what I've been thinking. Right now you need enthusiasts and a project that can either accept or handle the risks brought on by the immature ecosystem. Later on, Rust will most definitely be a huge thing. It's just not the right choice for everything - even if the community has a habit of pumping out "X - but with Rust" projects.
- ridv 6y ago
  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.

Knut4231 6y ago

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.

tmountain 6y ago
I agree completely. It's so pragmatic. It's not sexy. It just does the damn job, and that's why I love it.
DangitBobby 6y ago
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.

mabbo 6y ago

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?

the_af 6y ago
I know a case (second hand) where they migrated from a Java backend to Go, then had to roll it all back to Java because it was too hard and error prone to maintain. This is a very successful business, not a startup. No idea why they felt they had to migrate to Go in the first place. I'd rather not mention the company, even though I did not work there.
- thebean11 6y ago
  Yeesh, I can't imagine migrating a large backend codebase from any language to any language. And we're talking about migrating from Java..which is extremely well supported and probably the easiest language to hire for..
- nine_k 6y ago
  Concurrency is something that Go makes much easier, or at least more ergonomic, that Java with Runnables and ExecutorPools.
  - Groxx 6y ago
    It makes it easier to start concurrent stuff, but without ready-to-use type-safe abstractions like Java provides I'd say it's far harder to make correct concurrent stuff in Go. And while the race detector is wonderful, especially since it's baked in, it's nowhere near sufficient.
  - apta 6y ago
    I disagree. There is so much boilerplate involved with managing concurrency in golang compared to Java. It's very error prone in practice and difficult to extend and manage. golang has nothing remotely close to `java.util.concurrent`.

piazz 6y ago

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.

Mr_T_ 6y ago
You'll be happy with the latest developments: https://blog.golang.org/generics-next-step https://blog.golang.org/generics-next-step
erokar 6y ago
I share much of the sentiment. I like the simplicity of Go, but I think they took it too far an ended up with something too dumbed down and lacking in abstractions and expressive power. It feels like a step backwards coming from other contemporary and popular languages like JS/TS, Python, Kotlin, C#.
- throwaway894345 6y ago
  I agree with this, but I suspect I disagree on the extent to which this is a problem. These things are minor annoyances in my opinion compared to concerns that are largely apart from the actual language itself, such as performance, ecosystem, tooling, deployment story, learning curve, etc. With respect to Python and JS, you can always drop down to `interface{}` for similar expressive power and type safety, but generally people don't do this for the sake of simple for-loop boilerplate. Here are some serious pitfalls with Python (it's the language I know best) that dwarf concerns about language features. JS, Kotlin, and C# share some of these problems. Go doesn't really share any of these problems; it competes well with JVM and .Net with respect to performance, and its tooling story is simply top-notch on the whole (of course, there are individual tool categories where other languages have better offerings). * Python is a super slow language and the proverbial advice "just rewrite the hotpath [with multiprocessing / with C / with Pandas / etc]" falls over for any bottleneck that involves processing a large object graph. In these cases, you can't use multiprocessing because the de/serialization and IPC costs will typically exceed any parallelism gains. You can't use Pandas because the data set isn't matrix-shaped, and even if you can shoehorn it into a dataframe, you'll end up calling back and forth between Python and Pandas/C so much that you'll lose anything you gain from Pandas (and have much harder to maintain code). Similarly with "rewrite it in C/Rust/etc", you'll have to basically rewrite the whole object graph (including all of the inherent classes and methods) into C/Rust/etc and you probably don't want to keep those in sync with the original Python classes, so congratulations, a huge amount of your code is now in C/Rust/etc and you're no longer enjoying any of the benefits you would enjoy with Python (probably iteration velocity). Sadly, performance isn't likely to get better in Python because the community is so heavily invested in C-extensions (because Python is so slow) and the C-extension interface is basically the whole CPython interpreter, such that anything that wants to play in the ecosystem has to be very CPython shaped including many mechanisms that are prohibitively difficult to optimize around. Pypy is making a lot of interesting progress, but compatibility is still a blocker for lots of applications (e.g., anything that wants to talk to a Postgres database--unsupported packages notwithstanding). Python is fine if all you're doing is shelling out to a database or a C library, but anything more becomes expensive quickly ("well how come $BIGCOMPANY is so successful despite using Python?!": probably deep pockets). * When you want to distribute a Python program (e.g,. an internal tool), your options are pretty limited--the executable zip file formats (e.g., PEX files) are pretty nice, but inevitably something depends on an .so file (because Python utterly depends on C for just about everything) that doesn't get included in the zip file. Even in the happy path, you have to have the right version of a Python interpreter installed on the target system. * Correctness is the least of problems with untyped Python or JS, rather the biggest problem is the lack of quality documentation (critical information is typically either missing or outdated). The second biggest problem is that there aren't rails to guide mediocre developers toward sane code--developers tend to not know how to "think in types" and the code is typically far more complex than equivalent typed languages as a consequence. * Python nominally has a static type checker, but it's still very immature (still can't model JSON or even callbacks with keyword arguments). Further, getting it to find the type stubs for a given package is an exercise in frustration and terrible error messages. The only hope is that the Python community seems to be leaning into type annotations, so that should drive improvements in tooling in time (how long? is a different question) * Tests are super slow, largely because Python is super slow. CI bills can get to be really expensive. Not a big deal for well-endowed companies, but this is really hard for companies with meager budgets (this is ultimately true for Python generally IMO, not just WRT CI bills). * Documentation generation is brutal. Developers have to document types and keep them up to date. Consequently documented types are never up to date and many libraries--even the most popular--just punt on documenting types altogether. Then you have to write and maintain your own CI jobs for building and publishing documentation packages. And the documentation is still really reader-hostile on account of the everything-on-one-page, nested-with-no-context structure (e.g., SQLAlchemy has lots of methods and even classes with the same names but minor variances in module path and the only way to tell what you're looking at is to gradually scroll up to the previous `class Foo:` block and then back down to the thing you're looking at. Good luck ctrl+f-ing around). The latter problem would be easily remedied within Sphinx. The typing problem will get better as the typing story improves, but it's improving at only a snail's pace (mypy is still prohibitively difficult and restrictive for many projects). Further, if someone wanted to build a godoc.org clone for Python that automatically discovered, built, and published Python packages, I don't know if it would be possible because Python doesn't have a standard repository structure. * Then there's a long tail of paper cuts. Black (Python formatter) is a welcome relief but it's also really slow. No decent editor plugins (dynamic typing) and PyCharm is relatively expensive and there's still constant friction between it and your preferred editor even after you've learned it. Python has no dead-code elimination so artifacts are frequently enormous--like "too big to fit into a lambda, better use an ECS task and good luck with those startup times" big. Etc etc.

ridiculous_fish 6y ago

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

jeffbee 6y ago
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/

nedsma 6y ago

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.

rizpanjwani 6y ago
What kind of development do you do if you don't mind me asking?
- nedsma 6y ago
  Of course not. Nowadays it's pretty much about implementing HTTP REST APIs and consuming APIs (HTTP, SOAP, gRPC). We have both monoliths and micro services in production.
tigershark 6y ago
.NET is not a language. Are you using C#, VB.NET or F#?
- nedsma 6y ago
  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 6y ago

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 6y ago
That's an interesting take. Do you have personal experience that you could share more detail on? Or even more public projects
- candiddevmike 6y ago
  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).

bit_logic 6y ago

async/await colored functions is a disaster: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... 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 6y ago
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 6y ago
  Async / await is just an abstraction over threads. It doesn't dictate how many threads are used.
  - jayd16 6y ago
    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.