The case of Java demonstrates they were mistaken: their estimation of their own understanding was grossly outsized. I don't know enough about Go to say whether that is true of Go's designers.
"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike" [1] (emphasis mine)
You and I: we're not smart enough to use modern language features. And it just so happens that the language features and practices that we can handle are the ones that Rob Pike likes and settled on as good in the 70s and 80s. Anything from the last 25 years, we're not capable of understanding.
Honestly, part of many bonuses of leaving Google at the end of the month (after 10 years there) is that I hopefully will have the choice not to use Go and its heaps of insulting boilerplate... but I also hopefully won't have to deal with that kind of arrogance.
[1] http://nomad.uk.net/articles/why-gos-design-is-a-disservice-...
Obviously not trying to state anything deep here by over-analyzing that one point in his quote, but kinda funny his statement implies researchers write decent code.
Often I question the result of a paper due to how bad the code is. Many paper results cannot even be replicated by writing your own code following the papers description.
I agree more fundamentally with the fact that most people write low quality code if there aren't structures/patterns already in place to protect them from themselves. From that perspective, I agree with his point. Though I'm not a big fan of the implementation of the idea
Obviously it's a massive company and I saw maybe 5% of it, but I joke with my friends that I had to leave goog to get real exposure to Go and borg/k8s.
And yes, I do think generally Go is used more outside Google than it is inside. It's not a language made for Google -- despite what Pike is saying -- it's a language made by some people who happen to work at Google to scratch an itch they've had since they worked at Bell Labs.
The most used and deployed code at Google is written in C++, not Java or Python, and while we have a sane subset of it in our style guide it is by no means dumbed down to the level that Pike seems to imply we need it to be.
Google has done fairly fine deploying C++ into production for a couple decades. I haven't found Go superior at all so far, more insulting than anything. And tedious and opinionated in all the wrong ways.
For instance, I'd consider Go being very “idealistic” since it was designed mostly from the vision of a small group of people with a clear mantra: “simplicity”. But of course, Rob Pike would never have advertised his language this way.
On the other hand, one could argue that Rust is pretty much is the “realist” camp, since it was initially designed in a very different shape from what it later became when early adopters started using it (the Servo team at Mozilla in the beginning, and then other groups: for instance the Fushia team at google at an impact on the design of the async part of the language).
He's done great things. Think about the caliber of people that man worked with every day. And then he goes to Google and sees thousands of 'ordinary' people slinging C++ and doing web work. We become products of our environment. There's a lot of gap between him and you. And that's ok. You'll go on to do another 10 years at another big tech company and live a good life.
I'm way below your caliber and I see some arrogance in your words. I think both of you are arrogant because you unconciously became a product of the environment. I'm just a nobody that fails 9/10 interviews, including Google 2 months ago. It takes luck for me to get hired anywhere and I find it hard to relate to the middle class people I work with because I've been so poor. But I bet you I come off as arrogant to tradesmen, cashiers, janitors, and many others. Just let it go.
Greatness by association is not a solid concept. It shows how lucky a person is to be surrounded by great people but in itself does not count as an evidence of his greatness. But on the other hand, great research minds tend to cluster, thus his priors are above average.
This feels like an odd and unfair comparison.
I have nothing but respect for Pike and what he’s accomplished.
I don’t dislike him in some anti-cult-of-personality. I’m not ignoring good work he’s done just because it doesn’t fit my world view.
But I CAN criticize his individual work for being limiting or lacking ergonomics that I like.
And it’s entirely fair to look at Pike’s personal motivation for making the decisions he made, because it has an impact not only on what Go is currently, but also what it’s likely to be (or likely to not be) in the future.
If Go were created with the intention to be, say, a cleaner C++ with garbage collection, then I’d be all over it. I’d know that even if I don’t fully like it’s implementation today, it might eventually “get there”.
But instead it was created as an admittedly dumbed down language for people that Pike personally decided needed a dumbed down language, so I know that it’s never going to be what I want it to be.
That’s not an attack on Pike as a person. It’s not me blindly following a media campaign trying to destroy someone.
It’s me saying that I benefit greatly from generics and more robust error handling, and Go is not likely to have those in the capacity that I want because the whole motivation behind the language was to avoid those things at all costs.
None of which takes away from Pike’s career in its entirety.
I'm not sure if Pike himself holds these opinions, or if that quote was just a slip, but it's not nice. TLDR Pike is a 'great' man, with smarts well beyond me, but that's not of a lot of relevance to the code that we (code mechanics / producers) have to write every day, and I found Go tiring and insulting to work with.
Most recently I converted my ancient (1980s era) disassembler into D.
Gosling and others have written plenty of code in Java themselves, plenty of Solaris tooling was migrated to Java (a fact that Bryan Cantrill has complained often in his talks), and it replaced their OpenSTEP efforts, with Java EE being a rewrite from Distributed Objects Everywhere, originally written in Objective-C.
That Gosling did not fully understand features cribbed from other languages is evident from how broken the Java version of those features are.
https://cs.gmu.edu/~sean/stuff/java-objc.html
As for your reference to Guy Steel, he was just one person on a large team, which besides the point above was full of ex Smalltalk and SELF people as well.
Maybe learn properly about the Java history?
The most popular python and ruby implementations are written in C, right?
Swift is written in C++
It seems not sooooo unusual.
There was a time when doing that helped convince people the language could do practical things, and might be useful because you might not have had a compiler you liked for your dev environment. Nowadays, though, there is so much support for coding compilers in an existing langauge that building one in the immature language means wasting a lot of time, and furthermore makes your language hard to change because maybe the compiler is using something you want to change. There are more impressive things to write in your new language that might be actually useful.
Thus, rustc is (mostly) not coded in Rust. Rust's demonstrator project was the guts of a browser, instead. Notably, that project was coded in a language substantially different from Rust both today and at the time.
That's false. All of the original developers started writing side projects in Go extremely early on and all of them still write tons of Go including on their side projects. They don't have their ego tied up in their choice of programming language.
Rust is a clear replacement of C++, but with the flavor of OCaml and even Haskell added to it. It requires thoughtful planning, a good grasp of what you are building, how it should work, down to the lower levels, and significant knowledge of the CS fundamentals. Relatively few parts of the industry appreciate such an approach, but where it's needed and productive (see e.g. control software, system-level software, well, web browsers) it shines, and has no serious competition.
Possibly architectural progress in libraries will one day make writing web services in Rust ergonomic enough to compete with Typescript, much like auto-ptr / unique-ptr made writing C++ less painful.
I'm personally patiently waiting for OCaml multicore, which should have the best from both worlds, except the large communities.
> It also does not have the 100B$ garbage collectors of the JVM, which are a deal breaker, at least for me.
Can you expand a bit on that? I was under the impression that even with all that investment, Java code tends to be slower and more memory hungry than equivalent Go code.
They’re adding value types of course, but I haven’t looked at how exactly they’ll work.
Java also tries to optimize out method dispatch, so we can use it freely where Go might tend to avoid it.
There's some other tricks like tagged pointers, purgeable data it doesn't reliably have either.
I’ve read that games and simulators schedule realtime asset loading pretty carefully; what other problems are solved using large constant data?
Or is it ok to use cgo to work around Go's shortcomings, but not JNI for Java's?
I don't remember how good the Java interfaces look though, eg if you worked around no constant data by defining your arrays in C and passing them back, would they be bounds checked arrays?
If one is dumb enough to use C style arrays instead of C++ bounded checked ones, yes that is a problem, again just like C arrays defined in CGO.
I'm talking about defining a 'const int[]' in C and having it appear as an 'int[]' in Java. I think that's even less likely to happen if you define a const std::vector.
Actually I've never even seen someone define constant data in C++ using a vector, but this fits my experience of C++ developers telling me I'm stupid when I do the only thing I've ever seen anyone actually write.
Go doesn’t need a good GC as much because it can rely on value types sometimes. But for general enough workloads a superior GC can triumph.
Also, Java is memory hungry only in that doing GC when it is not absolutely needed is useless work. The JVM is actually quite power efficient due to trading off memory for better throughput — so especially in server environments with huge (up to multi-TB) memory which the JVM is free to use, it can be ridiculously fast. So no, java is not slower than equivalent Go program though correctly comparing languages is nigh impossible.
Yes they are Windows only, but lets be honest most pure .NET shops aren't moving away from Windows, as .NET cross platform has left part of the commercial ecosystem behind and no one is willing to port those stacks into cross platform ones.
YMMV though, as everyone uses Scala differently. A lot of Scala code goes in a more abstract direction, but if you use it in a more imperative Kotlin-esque way it's a very nice language.
This image of Rust as lower level than Go isn't one I agree with, but I can certainly see how people end up there. Go has it's garbage collector and userspace threading model, one gives up a lot of control to a runtime that you don't have to in Rust.
But as the author mentions if we're after good enough speed these details aren't important. So I don't most of the time care if there's a GC or not.
What I care about is the code I have to write, and Rust IMHO offers me nicer abstractions and more features.
The Go world in their desire for simplicity, use a for loop for everything, but in Rust we have the excellent iterator trait. The Go world offers me product types, the Rust world offers product and sum types. The Go world offers some mechanisms for codegen, but it is a far cry from Rust's macros.
Go I consider a modernized C, that is notable more for what you can't do than what you can, and how fast it can be learned - owing to a minimal and already familiar feature set.
I confess that I have a bit of a chip on my shoulder, I have for the last few years been working as a Go developer and in the last few months it's started really started to grate me how much work things are. I really miss things like '#[derive(...)]'.