I assume the GP meant "scale of codebase complexity" – which is orthogonal to whether something is "web scale" (ie. everything Google does).

Isn't the Google codebase infamously a monorepo with billions of loc? That seems like it fits "scale of codebase complexity" as well as "web scale"

It's a monolithic repo, but not a monolithic codebase. It contains many many separate projects, libraries, and applications. There's a lot of code reuse, but it's not like you have to wrap your head around the whole thing.

Yes, but much (if not most) of that codebase is in C++.

How do you check out a project like that?

Go was designed for Google-scale and Google-style logs analysis, for which it has been very successful. The fact that it comes with a decent HTTP and RPC server is the inevitable consequence of the fact that every process at that company is expected to present HTTP and RPC control and diagnostic services in addition to its primary purpose.

>Go was designed at Google to be used internally at Google

That's not true, expect in a pedantic way. Google was "designed at Google to be used internally at Google" only in that:

(a) a few people at Google, on their own, designed a language (mostly based on an older Plan 9 language some had helped built) - not at the request of Google execs, nor as an explicit company-mandated project to create a language to solve Google's problems. It was almost on of these "20% spare time" things.

(b) these people added the features that they thought, as far as they were concerned that would be nice for programming Google style stuff. Those were based on their ad-hoc (and quite idiosyncratic) intuition and personal experience, and not some special research into programming at scale, or from involving the company at large at it.

Go was designed at Google, but not "from Google", if this makes sense. E.g. a few googler's building a language on their own initiative and among other work is not the same as Google, i.e. some higher-ups, saying "we need a language of our own that's a match for our developers' challenges" and the company devoting resources for this.

Google has 2 language projects they really put money on, Javascript as V8 and Dart. They built a top notch specialist team, spent lots of money for promotion and branding, built an IDE and developer tools for both, etc.

Apple has had Obj-C and now Swift like that, MS has C#, etc. Those are language projects with a big weight of the companies behind them.

Golang was not like that, but, according to all official accounts and recollections, a grassroots project, by a small team:

"Robert Griesemer, Rob Pike and Ken Thompson started sketching the goals for a new language on the white board on September 21, 2007. Within a few days the goals had settled into a plan to do something and a fair idea of what it would be. Design continued part-time in parallel with unrelated work. By January 2008, Ken had started work on a compiler with which to explore ideas; it generated C code as its output. By mid-year the language had become a full-time project and had settled enough to attempt a production compiler. In May 2008, Ian Taylor independently started on a GCC front end for Go using the draft specification. Russ Cox joined in late 2008 and helped move the language and libraries from prototype to reality."

It was never officially intended to be "Google's development language" or had a major push from Google. Since then, and after the first few years, Google seems to have devoted more money and time to Go, and several Google internal projects have adopted it, but Google is fine with C++, Java, and Python as well.

It seems like you're setting up a false dichotomy. Researchers working at a company are often thinking about solving company problems, even if their particular solution doesn't have management support yet. Getting official approval often involves advocates selling their particular solution to management.

In particular, language designers typically have concrete problems in mind, even if they're inventing a general-purpose language. It's enough to say that Go's designers expected to use their new language at Google, so it needed to work well in Google's environment and solve some problems that weren't currently being solved well in that environment. If it didn't work at Google, then they wouldn't have succeeded at their original goal.

While it's not the most popular language at Google, Go is officially supported for server-side projects (communicating via RPC with many other internal servers), and has been for some time. That's a high bar that few languages meet, and about as official as it gets. If it didn't succeed internally then the Go team probably wouldn't have had consistent management support and stable funding over many years.

The other languages you mention (Dart and JavaScript) are considered client-side only within Google so they mostly don't compete with Go. For example, Node is supported for developer tools and external users, not because Google runs its own servers using Node. (Or at least that was true when I left.)

I don't think it's a false dichotomy. I don't think the teams that originally worked on the development of the Go language were Google production engineers of any sort.

I've been working at Google for 8 years and have yet to touch a Go codebase in production.

It's just not used that frequently.

If we're sharing anecdotes, I didn't write any C++ in over a decade at Google.

But I'm not going to dispute that it's the most-used server-side language, because I've seen the statistics.

How about the statistics you've seen on Go?

I don't remember (other than being up and to the right) and it seems not to be published.

>Researchers working at a company are often thinking about solving company problems, even if their particular solution doesn't have management support yet

Yes.

But it's another thing to have a company's the management, say "we want a team to create a language to solve programming at our scale" and throw full resources and money at it (at C#/Java/V8/Swift scale) and have it adopted by mandate for further development,

(as is often implied),

and another thing to have an independent group of a few devs at a company to sit on their own, and say "you know what would be interesting to try to build? A language to handle what we see as Google scale problems", and then getting some more resources, and seeing some at the company adopting it, as just one more language used along with several other company-approved languages for greenfield stuff...

Uh, Google is unlikely to standardize on a single language. The codebase is too big, the incumbent languages are too well entrenched, and they've heavily invested in supporting multiple languages. I'm not sure anyone claimed that either?

If anything the trend is towards slowly adding acceptable languages, but the bar is pretty high.

It's not that hard to imagine. Dropbox has talked about using Rust over Go for storage because cpu/memory efficiency was considerably better (4x if I recall) in Rust.

Go is pretty explicitly designed (as in there are quotes from the designers) with a low ceiling because Google doesn't want to trust their engineers to have nuanced programming taste.

This is why Go is good. If you care about writing beautiful code, Go might not be for you. If you care about getting shit done, it’s a great language.

Go is good at getting things done..until it isn't and you bump your head on the ceiling.

I know Go and Haskell equally well, and I get just as much shit done in Haskell and don't have to be a copy-paste machine sometimes. There are many benefits of Haskell and like-minded languages besides being "beautiful."

Feels like if the Go designers had the sense to include parametric polymorphism and sums (aka proven features from the 70's whose main "downside" is being weird to Go's target audience), it would be a great middleground.

Eh, in practice I haven’t missed explicit (closed) sum times as much as I thought I would. I started using Haskell many years ago (20-ish?) and have written some medium-size apps with it, and I’m very comfortable with using "switch x := y.(type)" in Go where I would use an ordinary "case y of" in Haskell. The only thing missing here is a compile-time check for completeness.

Missing polymorphism is a valid complaint but it hasn’t had the impact I thought it would.

Meanwhile, some of the programs I had written in Haskell I’ve rewritten in Go, e.g. due to problems with the use of finalizers (causing crashes!) in Haskell. You can chalk this up to poor library design but it simply isn’t a problem in Golang, which seems to avoid the finalizers more than other languages.

I’m going to continue using both Go and Haskell, I’m happy with both.

Emulating sums with interfaces isn't the worst but proper sums with exhaustive checking make it way easier for the consumers of your code to also perform matches in a maintainable way. When I emulate sums, I keep the matching internal and at best I expose a function that is the equivalent of an exhaustive match (which takes a function per case)

I've never run into finalizer issues (or finalizers at all really) in Haskell but I'm sure they exist. What libraries in particular used finalizers that you had issues with? In general though I find resource management much easier in Haskell thanks to bracket, ResourceT, and the (imo very good!) exception handling stuff. Async exceptions in particular are a surprisingly nice feature when combined with threading!

The biggest place lack of parametric polymorphism hurts is in concurrency. I have to hand-roll so much concurrency in Go and I don't really have a good option for abstracting over various patterns.

> I'm going to continue using both Go and Haskell, I'm happy with both.

Yeah same here. I'm glad to have them both in my toolkit.

I'm not asking for specifics but do you use Haskell at work? Is it in academia? I have worked for several large and small corps and no one has used Haskell. Most use C++, a lot use Go, a few use some rust, but none of them were using Haskell. I met people who use Haskell in their spare time because of their love for CS things, but never in production code.

Without specifics..I've been writing Haskell professionally & in production for several years now for multiple companies.

None were academia & most were commercial enterprises (that most people have heard of)

Beautiful is subjective, I know, but I think you can write beautiful code in Go. I like its simplicity and explicitness. Those things make it beautiful to me.

I think OP thinks about different scale.

It's not scale about number of users or data, it's complexity scale.

Last enterprise app i worked on had (provided) something like 10.000 different api calls (and yes mostly because of bad/wrong initial design decisions), and over 50k different possible queries that it could run against database. (my job was to "make database go faster")

Just running unit tests took longer than 6hrs (of course most unit test went out and connected to the database, because why not \s).

It all could be replaced with dozen or so 10k to 30k lines go projects each, that would be a lot easier to maintain and to scale out.

People may also mean different things by scale.

For me, scale means more micro-services. For another person it means a bigger monolith.

Which is probably the reason Google have made tools like a decorator to transform code with generics to valid go code.