23 ms·
Rob Pike interview
- juskrey 6y ago* in companies that are using Go for cloud infrastructure
- WilliamEdward 6y agoA little biased don't you think?
- vpner 6y agoYou have to be careful with everything Pike says. It's not just limited to Go.
- brobdingnagians 6y agoThis sounds like him trying to do PR to get everyone thinking everyone else is already doing it so they try to catch up. Act like something is true to make it true when everyone jumps on the bandwagon.
- smt88 6y agoI disagree. I've noticed that a lot of infra tools that would have been written in Python 5 years ago are now in Go. I know Docker is written in Go, and I believe the Kubernetes ecosystem uses it heavily, so those are compelling evidence for Pike's argument by themselves.
- searchableguy 6y agoAnd I know many small and medium level go projects being rewritten in rust. Maybe rust is the future. Deno comes to mind.
- throwaway894345 6y agoThese tend to be applications with very high performance requirements, including Deno. It seems to me that the choice between Go and Rust is generally a matter of whether you value iteration velocity more than peak performance or correctness.
- pjmlp 6y agoKubernetes was prototyped in Java and it isn't as if the Go rewrite was without pain. "The clusterfuck hidden in the Kubernetes code base" https://archive.fosdem.org/2019/schedule/event/kubernetesclusterfuck https://archive.fosdem.org/2019/schedule/event/kubernetesclu... Also they are quite heavy users of //go:generate.
- tapirl 6y agoIt is true that the k8s project uses many Java patterns, and this really hurts the readability, but there are also many leaf great packages in Go style in the code base. At least, I think, k8s proves the ability of Go runtime.
- renewiltord 6y agoThrough kube and terraform? Are there other major tools?
- dominotw 6y agodocker. Its the devops language in last 2 places i've worked.
- zapita 6y agoDocker started it. Kubernetes was built around Docker so used the same language. Terraform came later.
- patrickaljord 6y agoJaeger, prometheus, envoy, coredns, etcd, containerd, notary, linkerd, drone.io, helm, linkerd, grafana, traefik, caddy, gitea, rancher, moby/docker etc.
- throwaway894345 6y agoAnd pretty much everything that Hashicorp has built since vagrant.
- takeda 6y agoDidn't check others, but envoy I'm 100% sure is in C++
- patrickaljord 6y agoOops, sorry got that one wrong indeed.
- servercobra 6y agoA few fellow OpenStack developers and I half-jokingly suggested we rewrite some or all the services in Go. Python gets to be a bit hard to deal with at that scale.
- fcantournet 6y agoI used to work at an Openstack shop (small public cloud) We considered this several times, very much not-jokingly. Ultimately the investments never came. At least for Swift the object-server was re-written in go as an alternative implementation.
- servercobra 6y agoHeh ours started out as "We should rewrite Nova and Neutron and then Ironic..." That's awesome that Swift was. I always felt like Swift was one of the more solid services, but maybe that's because I rarely had to deal with it. We actually did write and deploy a small Go rescue agent for bare metal machines in Ironic. I'm not sure if that every got upstreamed though.
- DevopsQuestions 6y agoWhat are the chances of Rust or another language coming to the fore for cloud infra?
- jpgvm 6y agoReasonably high. There is a good deal of frustration with Go from experienced programmers that worked with it for several years and grew tired of the tedium involved. Rust has some obstacles to overcome to supplant Go on a wider scale though. Namely compile time and learning curve - especially in relation to concurrency and async which are key features to replacing Go as it's main draw is it's green runtime.
- bfrog 6y agoGo has no expressiveness to it. You end up either with a large pile of copy pasted code, code generators, or massively error prone runtime introspection. Go blows up the entire idea of Don't Repeat Yourself. The language actively encourages it.
- greyman 6y ago> Go blows up the entire idea of Don't Repeat Yourself. Yes, this is true. I programm in Go professionally, about 50% of my work time (other half is python). But in many cases, I have found that copying the same code to other places doesn't have that much negative consequences as one would believe.
- CameronNemo 6y agoRefactoring becomes intensely burdensome, often to the point that it is avoided at all costs. Not a great situation when you need to iterate on a design.
- jack_h 6y agoSo I'm almost certainly in a different industry (embedded) where EEs tend to prolifically copy+paste code. In the end this always makes it so that a change that should take very little time consumes an entire workweek or more. So I have a seething hatred of this practice from past experiences. I suppose I should say that there's a lot of different types of duplicate code, some of which really don't matter per se. Sometimes two bits of code are basically the same but are completely unrelated and as things change they will diverge, i.e. it was just incidental. Code that is duplicated with a strong functional relationship make changes a nightmare though.
- REALiSTiC 6y agoWhat a wild generalization. I skimmed the article, and I see his point in "Go was designed by people working at Google to make it easier to write Google-relevant software, in particular network-resident servers", but that doesn't mean Docker and Kubernetes (and other tools that enable communicating with/usage of cloud infrastructure) being written in Go made it become the de-facto standard, and especially not "the language of cloud infrastructure". What about ALL the other components NOT written in Go?
- throwaway894345 6y agoI feel like "Go has become the language of cloud infrastructure" is a bit of an inflammatory headline for this forum--I'm sure there are many cloud infrastructure components which aren't written in Go. The ones I think of tend to be AWS services that are written in Java or a handful of odds-and-ends things in Rust like AWS's Firecracker or some of CloudFlare's high performance networking systems. But especially in the open source world, there seems to be a lot of cloud infrastructure written in Go, and it seems to be accelerating. So in a sense I can understand saying "Go is the language of cloud infrastructure", but that framing seems unlikely to yield any interesting conversation. > What about ALL the other components NOT written in Go? Out of curiosity, which components are you thinking about?
- msla 6y ago> Out of curiosity, which components are you thinking about? I could start listing off OS kernels, and then I'll move on to device drivers and hypervisors. "The Cloud" is enabled by the fact we can efficiently separate applications and users running on the same hardware. The software which ultimately enables this is not written in Go... or Rust... or C++... or any other "hyped" language, but it is still an essential part of any cloud service.
- jrockway 6y agoGo certainly has a lot of mindshare in this space, and that can't be ignored. Some components of my production infrastructure I've used over the last year: cert-manager, concourse-ci, docker-registry, cilium, coredns, loki, grafana, prometheus, jaeger, influxdb, kubernetes, open-policy-agent; all those are Go. It's at the point where if you're in the business of writing software to run software, you're kind of surprised if you show up at some Github repo and it's not written in Go. But, the joy of 2020-era design is that nothing is forcing you to use Go. Everything is coupled with network APIs these days, so you can generate your protocol buffers for whatever language you want and write your chunk in that. You don't have to look at the success of Go in this space, think "but I don't like it", and leave the field. You can do whatever you want. But, I do think it's accurate to say that Go has a lot of mindshare in this sphere of the Universe. It is what it is.
- wdroz 6y agoBecause of kubernetes, the "language" of cloud infrastructure is YAML...
- batiste 6y agoLord I hate YAML. 10 years after seeing for the first time I still haven't memorised the intricacies and feel unsafe modifying any file.
- linuxftw 6y agoJust take the time to learn it, it's really trivial once you take the time to learn the basic types. You have lists, dictionaries (maps), and primitives. It could not be easier.
- dnautics 6y agoI think the real problem is that yaml encourages you to make things declarative (which is 99% of the time a good thing) but sometimes hiding complexity is the wrong thing, and so when you have clashing declarations, the imperative resolution path is not necessarily explicit, and hidden behind an operations layer that you can't really see or reason about. For some reason YAML seems to be an attractive option to try to implement things that really should be imperative in a declarative sense. Other configuration languages are either semi-imperative (like the hashicorp stuff) or don't do that (I haven't seen TOML configs that do some of the thing that YAML does). My best guess is it's purely cultural, because that trend started with ansible, which, not to denigrate - in many ways did very good things. The trouble is that 1% of the time always hits at a very inopportune time.
- linuxftw 6y agoMarkup languages are by their nature declarative. Take HTML, for example. You're providing a set of instructions for some other, smarter program to create some output based on your declarative input. YAML is no different. You encode some configuration, something else makes it so. Ansible kind of muddied things up because it looks like you're doing imperative things in YAML, but actually, you're doing declarative things and Ansible is interpreting your YAML in some particular way.
- gorgoiler 6y agoGo is the language that made me realize I’m not much of a production quality software engineer. Normally I would be quite happy riffing with ideas in Ruby or Python, and just running my code and iterating trying to figure out what to do. When I tried this in Go, every time I wanted to change the shape of my code to try doing things slightly differently I had to do a lot of work to get the code to compile again. I feel like a professional coder wouldn’t hit that road block because they’d have a better idea what they were doing in the first place. I have scurried back to Ruby with my amateur tail between my legs, but I hope to try Go again some day and find a style that’s a bit more forgiving of my not-Staff-SWE skills.
- bluntfang 6y agothis is a toxic mindset. just because the tooling is poor doesn't make you an amateur. if you're getting paid, you're doing great. keep it up and use the tools that work to get the job done.
- nostrademons 6y agoThere's a software lifecycle. At the beginning of a software project, nobody knows anything about what to do, because (if the market niche isn't already filled) nobody has done it before. Python and Ruby are great for that. Then as the software grows up, the requirements become more well-known, and more people start using it, you need to transition to more maintainable code that runs more quickly. Go is ideal for companies in that growth stage - it runs fast, it's easy to communicate what the code does, it doesn't allow a lot of tricks that can trip up other developers, and it encourages relatively robust code. Once you get to the massive scale stage like Google you probably need to be in C++ anyway, but by definition growth companies are where a lot of the action is.
- kerng 6y agoAgreed, for creative coding endeavours other languages are better suited, especially when doing rapid prototyping and refacturing. Sometimes even simple bash scripting allows for quicker results.
- save_ferris 6y ago
- pitterpatter 6y agoClearly doesn't know Azure is held together with tape made of C# and powershell :P
- vmchale 6y agoalso hdl, no?
- rootsudo 6y agoReally? Outside Google, I'm not aware of major orgs that use GO. I see the same .net C# stack, python, Ruby...... Java and PHP.
- kjksf 6y agoHow hard are you looking? Facebook, Dropbox, Uber, Apple and literally thousands of other companies, big and small, use Go.
- threatofrain 6y agoWhat people want to know is the trajectory of current relationship that a company has with a technology, otherwise I'll tell you that Facebook is a Haskell company and Amazon is a TLA+ company.
- lostmsu 6y agoUse - maybe. Is it the most used lang in these companies? Probably not.
- nemothekid 6y agoFor Dropbox and Uber, it is.
- cletus 6y agoI have huge respect for Rob Pike but there's a bit of revisionist history going on here. Go was originally envisioned as a systems programming language. It was often called "a better C". This exposed Rob Pike's lack of experience in the area (IMHO) because anyone who had done any systems programming at all knew that garbage collection made any systems language a nonstarter. Where Go succeeded was completely unintentional (as as often the case): it was (and is, IMHO) a better Python. Go hasn't attracted C, C++ or even Java programmers. It attracted Python refugees. So it's no accident the touted use cases ("cloud infrastructure") are orchestration problems. But at the same time, "cloud infrastructure" here refers to what, exactly? Kubernetes? Etcd? I think those could've been written in anything. More to the point, users of those don't really use Go as a result, right? I think even Google found that internally Go was cannibalizing Python usage and little else. Lots of Go newbies bemoan the lack of generics. I was never one of them. It's not the problem people think it is (IMHO). I'll be interested to see what this solution is even if simply means we can stop having having this conversation about Go not having generics. That alone is a win. So I think there's two areas where Go screwed up. two big and one small. The small one is the lack of IDE support. You don't need to write an IDE. You just need to have sufficient integration into Jetbrains IDEs (at a minimum). The first big problem--and it still is a problem--is the dependency management, in that there wasn't a solution to this out of the gate (unlike, say, Rust and Crate). Like I was shocked the first time I saw import 'github.com/some_random_user/...' I dare you to go look at any even moderately sized Go project and unravel the levels of dependencies (including repeated dependencies, which may or may not impact binary size, I'm not sure). It's kind of a mess. The second is, oddly, on concurrency or rather multi-core and multi-CPU utilization. Aren't we still in the GOMAXPROCS environment variable era? Really? EDIT: adding this quote from Rob Pike in 2012 [1] as it's a first-hand account of Go's original design goals: > I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++. [1]: https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
- empath75 6y ago> Kubernetes? Etcd? I think those could've been written in anything. Kubernetes was originally written in java and was transpiled to go.
- vmchale 6y agothe language of choice for people who enjoy writing a sort function five times.
- adtac 6y agohalf the comments don't make any sense anymore because of the title change
- leetrout 6y agoYes. It was a drastic title change- I wish mods (dang?) would note the change when it happens. For others the original title was the title of the page: Rob Pike interview: “Go has indeed become the language of cloud infrastructure“
- mseepgood 6y agoIt shows that lots of people only read the title, not the content.
- zerpelin68 6y agoIt's funny how everything that bell labs alums have touched has influenced computing in a way that isn't publicly acked and how the network and namespace ideas in plan9 and inferno have become foundational to cloud native infra. Pikes assertions in a couple cases are just wrong or exemplify naivete however. He is surprised by how a language designed to be opaque to casual examination, statically compiled and used in a majority of high profile cloud native applications (where the install is often download and run a go binary as part of an un-examined curl | sh pipeline) is happily used for malware? Also interesting how designers of languages who are formerly avid critics of PL become reticent and opposed to negativity as authors. Finally he touts the 'hard' problem of concurrency that GO offers an unanticipated solution for as if OpenMP hasn't been around as a functional approach since 98 for concurrent programming in the HPC and scientific domains.
- 5cott0 6y ago> a language designed to be opaque to casual examination Is this really the case? I thought the prevailing wisdom is that Go was designed to be as simple as possible so newbs can pick it up faster. I find Go to be quite easy to read and follow along with even though I've never written a line of it. Rust on the other hand...
- zerpelin68 6y agoopaque to casual examination means that you simply cannot read the code. You would think that a statically compiled binary blob wouldn't be handled as if it was a perl script, but it is.
- theshrike79 6y agoAnd Perl isn't opaque to casual examination? :D
- deleted 6y ago[deleted]
- vpner 6y ago> Although it's far from certain, after over a decade of work it looks like a design for parametric polymorphism, what is colloquially but misleadingly called generics... What exactly is misleading about generics? The psychology of thought leaders is fascinating. The term generics is colloquially understood to mean parametric polymorphism and here's Pike redefining the term to draw some distinction that doesn't really exist just to remain self-consistent. Come to think of it, this is a really common pattern. If you've made remarks that you must now backtrack then refine terms until your old writing doesn't seem to contradict your current stance because you can just say people were using the terms wrong and you were right. Some results for searching "generics": https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/generics/ https://docs.microsoft.com/en-us/dotnet/csharp/programming-g..., https://www.typescriptlang.org/docs/handbook/generics.html https://www.typescriptlang.org/docs/handbook/generics.html, https://docs.swift.org/swift-book/LanguageGuide/Generics.html https://docs.swift.org/swift-book/LanguageGuide/Generics.htm..., https://doc.rust-lang.org/rust-by-example/generics.html https://doc.rust-lang.org/rust-by-example/generics.html. If you search for "Wadler generics" then a book about generics in Java is the first result: https://www.amazon.com/Java-Generics-Collections-Development-Process/dp/0596527756 https://www.amazon.com/Java-Generics-Collections-Development....
- steveklabnik 6y ago(Also, once Rust gets specialization, our generics will no longer be parametric.)
- vpner 6y agoI don't think Go's proposed system is parametric either. It's not clear to me how their contracts actually map to generics so I have no idea if Pike is telling the truth or just "thought leading".
- AnimalMuppet 6y agoYou know, Pike was at Bell Labs for a few decades when it was the premiere computer science research place on the planet. It's possible that he has a more technical definition of generics in mind here. (Or he could be being evasive. What's quite unlikely is that he doesn't know the real definition of generics.)
- _wldu 6y agoGo is C for the cloud.
- tapirl 6y agoGo is a C framework.
- qppo 6y agoThis interview was refreshing to read and the comment section far too toxic for the content.
- ppipada 6y agoGenerally speaking, hackernews comments related to Go have become toxic since last year or so. For some reason people seem to actually display hate.