* Pick a testing framework / runner
* Learn a DSL to manage dependencies
* Learn how to configure the build system to ship static binaries
* Debate code formatting rules
* Build a CI pipeline to build and publish source code packages
* Build a CI pipeline to build and publish documentation packages
* Tune a GC for low-latency + low-memory
Rust often gets accused of being a "kitchen sink" language, but the Rust folks have tried doing the simple thing and it came with severe limitations - Rust 0.x was pretty much indistinguishable from a glorified Go. It even had green threads and GC!
It's no coincidence that they, much like Go, provide a test framework, build system, dependency management, CI, code formatting etc. out of the box. Because these things meaningfully improve productivity.
Rust is certainly a big language, but its features work together toward a coherent philosophy/paradigm, so it isn't really what I think of as a "kitchen-sink language". C++, Java, C#, etc have accumulated features from different languages and paradigms based on what was fashionable at the time rather than based on an overarching philosophy or paradigm.
That said, it isn't that Rust's "bigness" absolved it from limitations--it just opted for different limitations: notably a less productive programming model. That tradeoff makes sense in the context of Rust's charter--to be a maximize for safety and performance--but it's not an optimal tradeoff for general purpose software development (at least not as it exists today where productivity is king).
> It's no coincidence that they, much like Go, provide a test framework, build system, dependency management, CI, code formatting etc. out of the box. Because these things meaningfully improve productivity.
Agreed. I think Rust gets a lot of tooling and ecosystem stuff right (because these don't require it to compromise on its charter).
Git is great with this. You can get by just fine in 99% of cases with git add, commit, and push and those three could be explained even to a child. However, you can also fine-tune your pipeline just the way you like with Git's endless tweaks.
In fact, I claim that Paul Graham is completely wrong in that essay. To see why, think about Lisp and Haskell. When Lisp users look at Haskell, they know they're looking down, and they know why. "How can you get anything done in Haskell? It doesn't even have macros." But when Haskell users look at Lisp, they also know that they're looking down, and they know why. "How can you get anything done in Lisp? It doesn't even have a decent type system."
This situation - both languages certain that they're looking down when they look at each other - shows the problem in Graham's analysis. He assumes that languages can be placed on a one-dimensional axis labeled "power". They can't be, and the Lisp/Haskell issue proves it. That renders Graham's analysis invalid.
Instead, it might be better to think of languages as living in a multi-dimensional tree. Think of the program you're trying to write as having a vector in that multi-dimensional space. (Not so much the program itself, but what it makes it difficult to write.) Pick the language that extends the farthest in the direction of the vector defined by the program.
What Go did is recognize that "ability to get a large team of average programmers to maintain and extend a large codebase for decades" was one of the dimensions of the space. That makes it "Blub" by Graham's definition, but I don't think that's meaningful. Instead, if that's what your program needs, pick a language that does that.
The fallacy in that argument is that effective programming "in the large" requires more features, not less. Sure, there are highly dynamic programming languages that cannot meaningfully support programming beyond the scale of a "personal side project". Ironically for Paul Graham's "Blub" argument, LISP is quite clearly one such language. The same applies to languages such as Python, Ruby or ECMAscript, which would have been among the main alternatives to Go when it was first released.
And one can also fairly argue that Go has in fact made it simpler and easier to "program in the large" compared to C++, Java or C#, which were the other major alternatives to Go around that same time. So Pike's argument is not wrong as far as it goes. It is merely of limited applicability, because the jury is very much still out wrt. more recent and arguably higher-level languages like ReasonML, Kotlin, Dart, Erlang and yes, Rust. It's silly to conflate these languages with the likes of Python or C++, that is indeed the kind of argument that "Blub" was written for!
When compared to say, Ocaml Go definitely lacks some of the niceties of a type system (even now with generics). With ocaml i use recursion in almost every case i need to reduce / map something. Pattern matching + type constructors are VERY powerful and produces very safe code.
That said, i really like Go as a language. It lacks many higher level abstractions, and the coding style is very procedural. It's boring, and stops you from being to clever. Simply put, i get shit DONE in Go without much thinking. sometimes i work for hours in Ocaml to get a semi "easy" function to work correctly. With Go it's just write and things usually work.
Go has very good concurrency primitives for 95% of use cases. Ad hoc concurrency in Ocaml is still a pain (the new effect system WILL make this better) as you need to pick and choose between Ltw or async and then pray libraries support the one you chose.
For me Ocaml is still a language (that i love) for "being smart about it". And good ocaml code is truly beautiful and safe. Go on the other hand is about getting shit done. I can be productive in Go and then refactor later.
I really like that Go has such a good core that comes with the essentials, so you rarely need higher level dependencies (i would not write a databada driver myself).
Go sits in a spot that's well designed and has the right tools and brings good enough safety to the average app.
Unclear to me if this is really the meaningful reason that Paul's company succeeded (I'd say obsession with programming languages can be a counter-indicator for productivity), but it clearly resonated with a lot of people since that essay is arguably the onramp into Paul's fame. A lot of programmers read that essay back in 2001. His popularity as an investor who understood engineers arguably catapulted YCombinator
I also think the whole blub thing becomes less and less relevant with every passing day. Every language has evolved significantly over the last 20 years - when he wrote that article - much less the last 26 years since he started viaweb.
I personally prefer FP languages. I don't think they give me magical superpowers... okay, well, maybe BEAM languages in certain circumstances. But I also know people that work magic with C and do things I could never dream of.
Go is Blub (http://www.paulgraham.com/avg.html). I think the industry is in a place where Blub makes sense! Lots of VC money is floating around, and schools are training a lot of people to hire with that money. Commercially relevant ideas most often succeed by raising a ton of money, then hiring a ton of people to realize the vision. In the Blub essay's terms, a modern company doesn't want to beat the average, they want to reliably hit the average with the 10s or 100s of people they're hiring.
This resembles the conditions at Google when Golang was conceived, a lot more than the "4 people want to max their individual leverages, whilst eating rice and beans to extend their runway" world the Blub essay was inspired by.