Yeah, Rob Pike and Brian Kernighan definitely lacked experience in C and systems programming.
Rob Pike is probably most famous for his involvement in Plan9 (prior to this). I honestly don't know what this experience entailed.
[1] http://doc.cat-v.org/plan_9/4th_edition/papers/
EDIT: In the past half hour, the original website went down, I don't think it is related to my link. Here is a different link with the same contents:
Please, kid.
What he seems to lack IMHO is sufficient curiosity about computing innovations not produced by him or the prestigious institutions he has worked for (Bell Labs, Google).
For example, someone might dismiss IDEs as being unnecessary because technically the same job can be done without them by a superior human being, so the solution is to just be a superior human being.
Or as another example, someone could completely dismiss syntax highlighting as being useless for the superior, implying that the solution to the problem syntax highlighting solves is to just also become a superior human being.
There are multiple layers to any solution, and if one of them is missing, the others are kind of shaken out of balance.
Rob Pike worked on Unix, helped design and implement Plan 9 and Inferno, and co-designed UTF-8.
Personally, I prefer acme; it's my daily driver editor.
You don't write an UNIX derivative with a lack of system programming experience.
I think he meant Ken Thompson.
It's succeeded at basically the same niche that it was intended for. The difference, as another commenter points out, is Rob Pike's ignorance of how the world outside of Bell Labs & Google had changed. In the 80s you would've built networked microservices in C. In the 2010s you built them in Python or Node.JS. Hence if you have a new language that's a success in the microservice application-server market, it will end up cannibalizing Python and Node.JS, not C. Python cannibalized Java in the 2010s and late 00s, and Java cannibalized C in the 2000s and late 90s.
Go is still inferior to Python in prototyping, in web development, and in data-science. (I used it for the former 2 while still at Google, and decided it wasn't an upgrade.) But it's superior for production microservices, and that's an increasingly large market these days.
I was (2010-2017 to be exact) so I remember how this was communicated but internally and externally. This HN submission [1] to HN from 2011 reflects my recollection of that messaging that Go was a better C.
Even better, Rob in his own words [2]:
> 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++.
> Go is still inferior to Python in prototyping, in web development, and in data-science
On the data science point, I certainly agree that nothing looks likely to displace numpy/scipy anytime soon. Python's much-maligned GIL does simplify C module extensions and, I believe, was a key contributor in Facebook choosing to move to Mercurial many years ago (long before my time).
I wrote a fairly significant internal app at Google in Python and essentially swore I'd never do it again. The way I like to put it is that I don't want to write unit tests for spelling mistakes. I haven't used Go for Web development but I'd already choose it over Python just for static typing.
As an aside, I found the protobuf integration in Python to be basically terrible. Perhaps it's improved in the last 7+ years though.
[1]: https://news.ycombinator.com/item?id=2535206
[2]: https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
Unless you want to bucket all systsme programming in to one bucket, I will say this
#1 If your goal is to make the most efficient and fast code (garbage collected or not), it is not clear gc-less languages are always better. Sometimes, not free-ing the memory at the first possible time will actually be good for you overall.
#2 If you are writing anything with serious mem usage in Go, you will optimize for allocations using sync.Pool or some other form of reuse. I am sure well written C++ code would have to do the same tricks. reduce >> reuse >> recycle. Both GC and free() are recyclers. Sure, one could argue GC could provide more control.
I 100% agree there are cases C/C++ or Rust would be better for 20% of the trickier situation, but let us not base it all on the presence of garbage collector.
Heck, some of my Java code works faster than even my Go code. I don't blame Java for having a garbage collector.
Which is why languages like C++ let you write and use your own allocators. There are lots of reasons to do this (eg word alignment).
And while I agree that it's certainly possible that delayed freeing may be beneficial I'm not convinced it's a problem in practice, at least when you compare it to how often common GC problems are (eg memory leaking (admittedly also a problem with manual allocation), out-of-control process memory growth and STW pauses).
#2 If you are writing anything with serious mem usage in Go, you will optimize for allocations using sync.Pool or some other form of reuse.
True, and I mentioned this in another comment: the idea that you can get around many GC issues by using object and memory pools.
> Heck, some of my Java code works faster than even my Go code.
Why should that be surprising? The JVM at this point has >25 years of engineering effort into it and (IMHO) it doesn't get half the credit it deserves from the devotees of the latest flavour of the month.
You're aware that the Go allocator is written in Go, right?
You don't know what you are talking about. Someone who has written operating systems, windowing systems, editors, many many tools & library functions, and well regarded books on programming doesn't exactly lack systems programming experience.
This is quite funny.
I remember when Go was released its creators were all like "GC is good enough now" and then Rust came around the corner blowing that whole premise out of the window.
The way I like to put it is Go devotees operate under 2 rules:
1. Whatever your complaint about Go is, it's totally not a problem (eg stop-the-world GC pauses, a longstanding issue that any experienced Java engineer could commiserate at length about);
2. Even if it is a problem--which remember it is not--it's totally fixed in Go 1.(N+1) where 1.N is the current version.
> eg stop-the-world GC pauses, a longstanding issue that any experienced Java engineer could commiserate at length about
This is a really interesting example, because it shows the lack of nuance in the anti-GC position. By your logic, because Java's 100ms GC pause times have been problematic (and yes, I'm aware that Java's upcoming GC will boast significantly improved pause times and that it's theoretically possible to tune a Java GC for low pause times even if no one has managed it in production) Go's 5us pause times will be equally problematic. Because a pause is a pause, right--why should we muddy the waters with considerations like "duration"?
Single- or double-digit microsecond pause times completely change the conventional wisdom about the kinds of applications GC is suitable for. There are still lots of hard real time applications that Go's GC won't be suited for, but there are many soft real time applications for which Go would be fine (or at least the issues will be libraries or support for target architecture/platform and not GC).
I wouldn't call my position strictly anti-GC. I would simply say that GC isn't the panacea it's made out to be and it is at least in part a false economy for at least three reasons:
1. You may need to tune your VM/GC parameters (as you mention). There's a cost to this;
2. GC can make it harder to identify memory leaks (which are still a problem through, for example, dangling references). I've worked on C++ systems where we instrumented many things including process size, which was basically just a flat line. As soon as it wasn't, you knew there was a problem. And this was for a server that read about ~6GB/second off a NIC.
3. Crashing a program due to accessing unallocated memory tends to give a more immediate signal of a problem, which is more often than not better for development.
And in my opinion, it is a better Java. It succeeds in the niche where Java is used today: big softwares, shared by numbers of teams, working on different timezones and in different languages, and with varying degrees of skill.
Go is so stubborn it takes the fun out of programming and ironically that's a good thing: when code can't be tied to anything personal, it is much more easily shared with anyone who works on it. I have found that writing Go itself is definitely tedious, sometimes boring, and the fun is not there; _however_, fun is had when you have a working binary that is statically compiled, reasonably devoid of bugs and surprisingly performant. You take joy in actually using pieces of software, not in fine-tuning your formatting rules.
The language itself is boring, but it's the same boring for everyone and it happens to be working well so you tend to focus more on the solution than on the intricacies. This, IMO, is the success of Go
Better Java 14, definitely not.
I stop copy pasting code and using code generators around 15 years ago.
I've said this before, but even back in early 2014 Rob Pike had said that he regretted the term "systems programming" because people misunderstood him to mean it as a language for writing operating systems, when what he meant was a language for writing servers, although that later evolved to cloud infrastructure.
He answers this at 6:50 here, https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Pa...
What exactly do you mean by systems programming? Many successful databases (Cassandra, Kafka, ElasticSearch) are built on the JVM.
If it is not user visible but exists to manage app access to hardware resources, it's a system. So a memory management system would not be an app. Neither would power management or IO or a scheduler. But these systems might have administrative apps that admins login and use (like Microsoft's "Control Panel" app -- to control settings for the system code. Similarly some apps might have their own memory management system. But the principle still applies.
I understand there is definition creep as more and more layers sit between the user and the hardware, so todays application code might, in some cases, be viewed as tomorrow's system code, but this is the original meaning.
What I mean is things that are basically kernel-level or embedded.
https://www.ptc.com/en/products/developer-tools/perc
As does Go actually,
> Go was originally envisioned as a systems programming language.
Already with the release of Go 1 it was quite clear that Go has its best fit as a Server language. I don't think the usage of a language can really be planned. But looking at the previous works of the language authors, it's clear that they worked on solutions for distributed systems.
Also I think like 10 years ago people would have written stuff in C++ that today nobody would even remotely consider writing in it.
CLIs as well. Before Go, how did you build a native CLI in a garbage collected language?
Something like Java, .NET, OCaml, Haskell, D, Scheme, Common Lisp?
Yes, it isn't a typo regarding Java and .NET, there are AOT compilers for them since around 2000.
There are a significant number of systems that demonstrate otherwise: LISP machines, SmallTalk, Oberon.
Kubernetes was originally written in java and was transpiled to go.
Also a better NodeJS and PHP.
† I say this because we already have an alternative to GNU Coreutils for memory-constrained embedded systems, in the form of Busybox. If Coreutils had to "serve two masters"—be both powerful at scale on big multi-core systems, and functional on tiny embedded boxes—then Go would make less sense. (Rust would be pretty good for that, though. See e.g. ripgrep.)
> More to the point, users of [Kubernetes] don't really use Go as a result, right?
Yeah, they do actually. The vast majority of tooling in the Kubernetes space is also written in Go. I don't know about etcd.
> 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).
I might be missing what you're saying here, but Goland has been around for a decent while now, and the full IntelliJ plugin has as well. Before that, Atom or vi with some plugs I've since forgotten the name of worked well enough.
I agree with your overall points though, especially on dependency management.
Right. That's true now (and, like you say, has been for some times) but was not the case for years. I was responding to this point in the interview talking about initial development, not the current state of the world, just to clarify.
Visual Studio Code with the Go extension is very good.
Very interesting, can you elaborate with an example?
I also found there are subsets of Go aimed at filling this use case because of the GC issue [4] (eg Emgo [5], TinyGo [6]).
The Fuchsia Language Policy [7] also points to this. Fun fact: the networking stack in Fuchsia was written in Go because of Dave Crawshaw, who was (and I assume still is) a big Go advocate. I got into an argument with him once about stop-the-world GC pauses in Go. Anyway, the Fuchsia project has largely been unhappy with this ever since because there is an overhead to using Go that essentially you can't get rid of. Using memory and object pools can solve many but not all problems. And at some point I suspect they'll replace the networking stack with something not written in Go.
[1]: http://www-cs-students.stanford.edu/~blynn/c2go/
[2]: https://news.ycombinator.com/item?id=2535206
[3]: https://news.ycombinator.com/item?id=2535386
[4]: https://github.com/golang/go/issues/29147
[5]: https://github.com/ziutek/emgo
[6]: https://github.com/tinygo-org/tinygo
[7]: https://www.reddit.com/r/golang/comments/f92nkc/golang_is_no...
Honest question: other than parallelism and performance, what are the main reasons someone would switch from Python to Go?
IMHO Go is still inferior to Python for solo-developer projects.
My personal view is that dynamically typed languages are largely falling out of favour with Javascript being the one glaring exception (and even there if I were starting a project today I'd use Typescript).
On the single deployment binary issue, let me just underline that point with one word: virtualenv.
can you expand ?
Given that the language is relatively easy to grasp and that the standard library covers all the basic needs of a server application, that alone is a huge win.
Python still has more and better libraries for certain tasks though.
Go makes it easy to produce binaries for any target platform that execute without requiring a working Go installation.
This ease of packaging makes Go my default language when I'm writing developer tooling - for example, if I know that team-mates are going to have to run tools that I write but I don't want to make assumptions about their development environments.
There is one caveat: This only works well if you avoid platform-specific functionality (e.g. syscall package) and CGO.
I suppose the static analysis is quite cool too...
Are you aware that Jetbrains makes an IDE for Go, called GoLand?
Jetbrains wrote their own Go IDE, goland. The rest of us use an LSP client that talks to gopls. I have used that for about a year and it does everything that I would want an IDE to do; accurate context-sensitive completion, an easy way to peek at signatures and documentation, jump to definition, accurate renames, import organization/cleaning, etc. I am continually surprised at how good a job it does when I'm 8 nested protos deep and it can still complete struct keys and values (i.e. you can type "&Foo{ B" and it will complete it to "&Foo{ Bar: &Bar{}").
> 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).
I am pretty happy with go's approach to dependency management in the Go module era. You can tell the Internet "a little duplication is better than a little dependency," which Go does, but they will do it anyway. I like that I have tools that can just vendor all my dependencies (mostly so that CI builds can be completely stateless and free from network communication), and that every module I use is declared in go.mod file that the toolchain itself keeps tidy and accurate. The mechanics of an upgrade are a breeze -- find the module and update the version number next to it. If I want to edit some module I depend on, I can just use gohack and it checks out the source code in a convenient location and edits go.mod to make go pick up that version of the code instead of the Internet's version. And, you can at least figure out why you have a certain dependency with "go mod why". Finally, I love that "go doc xxx.Foo" is aware of what modules my module uses, so that I always get the right symbol. I would kill for "typescript doc xxx" or "clang doc yyy". (Seems like other people prefer 80 browser tabs with random websites loaded to do the same thing. I like my command-line, or at least some IDE integration.)
I have used other approaches to dependency management and they haven't made me as happy as Go's. npm is slow and fills my entire screen with garbage, only to eventually inform me that "module A depends on module B which depends on module C which has a SEVERE SECURITY VULNERABILITY!!!!!!! and there's nothing you can do except whine on Github!" I like Bazel's WORKSPACE approach, allowing me to specify the exact sha256 of the compiler toolchain I want to use, and every version of every transitive dependency. Somehow I feel like nobody is that serious about dependency provenance, though, and they invent a lot of clever workarounds to avoid maintaining that file. But at least you can be correct and in control if you want to. (With go projects, the biggest problem I've had is keeping protoc, protoc-gen-go, and the Go proto library in sync. Go doesn't handle non-Go things, and that really sucks. You have manually manage that stuff, and people mess it up. Or use Bazel, which I've tried and came to the conclusion that nobody else has ever done.)
So all in all, I think Go's IDE support and dependency management meet my needs. I dare say I think they're great! All of this stuff is relatively recent, though, so there are probably a lot of people stuck with their code in ~/go/src/github.com/me/my-app that manually run "goimports" from time to time. That sucks. But there are better tools available!
Yeah, I should clarify: I was responding to Rob's point in the interview where he was talking about tooling and IDE integration from the outset rather than the current state of the world.
As for Jetbrains writing their own IDE... well, yes and no. Sure there's a separate product from a user perspective but IntelliJ has had a Go plugin for several years. You'll probably find Goland (just like all the other little-IntelliJs like AppCode, PyCharm and RubyMine) are little more than stripped down versions of IntelliJ's code base with a different default set of plugins. My point is that Goland wasn't a "new IDE from scratch" level of investment by Jetbrains and that a third-party plugin could've been largely equivalent.
You're right that go didn't have amazing tooling from day 1, but the tools it did have were enough for me to change my workflow. I never cared about autoformatting (too many knobs to turn) before gofmt, and now I can't live without autoformatters.
Coming from a dynamic language background, I also never really got tools that claimed to provide completion to work, so I ignored them for most of my career. I worked on a Java project at Google and Emacs worked fine. Now there is LSP, and I first tried it with gopls, and it worked perfectly. Now I can't live without it, and try to avoid having to work in languages that don't have a good LSP implementation. (I am also very annoyed by the multitude of C/C++ projects whose crazy bespoke build systems manage to make clangd not work. That's the reality of tools coming along late; sometimes it's too late to have an impact because people have gotten by without the tool and are happy to continue with that.)
I have also used a little Goland. At my last job, we replaced a lot of PHP and Expect scripts with Go programs, and it was quite the journey to keep people happy with their existing IDEs. (Everyone had the Jetbrains you-get-everything pack, so at least Goland was free.) Goland is really a from-scratch implementation of editor support for Go. They had no other choice... but it makes different decisions from the open source tools which is quite the pain point. (I remember it importing opentracing-go as a plain "github.com/whatever/opentracing-go" and let things in the file refer to that as opentracing.Whatever. goimports wrote it more explicitly as 'opentracing "github.com/whatever/opentracing-go"'. I still don't know how that works, but apparently it did, and so diffs would always oscillate between the two until we convinced Goland to just run goimports.
What I like about go's tool support is that it's done a good job of adding features for people that want them, and letting those people use the tools without upstream dependencies knowing about those tools. I started using go modules before it was particularly popular in the community, and it didn't cause much trouble. (People sure liked to force push to their version branches, though, causing go.sum checks to fail. And people would always blame the Go team for that, unfortunately.)
I have a hunch that not many people are using gopls, but it works perfectly on codebases where I know the authors never used it. That is a pretty big deal and is better than what a lot of other languages do. "We have this new thing... restructure your codebase to try it out." It's nice for new codebases, but even nicer when you don't have to do that.
So all in all, I am very satisfied with the tooling situation.
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-exponenti...