Ask HN: Why is Google in love with purposely-impaired languages like Go, Dart?

[nnq]

Google seems to invest a lot in R&D for programming languages and tooling (probably only surpassed by Microsoft, and percentually by dev-tooling-focused companies like Jetbrains), yet nevertheless, all they seem to produce seems to be "mediocre by design" in a way, or at least designed to be restrictive and/or to impair developer flexibility and productivity.

On the languages side Go and Dart seem like the epitome of "Blub languages" in PG's essay lingo. Even modern Java seems flexible and featurefull in comparison with them. Compared to Go, Rust looks like Common Lisp looked like to a Java programmer of old. Compared to Dart, Kotlin and Swift look like Smalltalk probably looked to a 90's C++ programmer...

Where is this attitude coming from? Is Google's philosophy that most programmers, including their own, are either stupid and/or irresponsible and shouldn't be trusted with powerful tools that can increase their productivity when used right? I mean, software is their business, they're not churning ecommerce infrastructure CRUDhorrhea... they should be capable of leveraging powerful programming language features to massively increase developer productivity, right?

[dexterlagan]

"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

[nnq]

> the language that we give them has to be easy for them to understand and easy to adopt

All the respect for Rob Pike, but that makes no sense: learning ANY new language should be even easier for someone fresh out of school, and I imagine they set a high enough hiring bar to be sure that new engineers can adapt to whatever they are thrown at. All programming languages are easy to learn...

The harder part is figuring out process that are repeatable and result in high velocity and code quality, but I'd imagine that this is what an organization like Google is good at!

[wtetzner]

"They’re not capable of understanding a brilliant language"

Wow, way to put down your engineers. What is the famously high hiring bar at Google for?

[LocalMan]

Programming languages are like culture. If you're embedded in one then moving to another sometimes seems like a maze of funhouse mirrors.

I once had the misfortune of changing from an Algol environment to a Cobol environment. After a year I'd gotten over my revulsion and became fluent and productive in Cobol.

It's like saying English has lots of irrationalities to it, which is true. But if it's your mother tongue and you're fluent that doesn't matter.

Go is not impaired. Go involves a set of sophisticated choices for software engineering, not for computer science research. If you're going to have many millions of lines of code and some shifting around in your staff, you don't want tricky code that takes a long time to figure out, or that obscures functionality, or that obscures bugs.

[codegladiator]

Cleverness is not related complexity in any way. Software is going to be complex. Cleverness is just going to make it harder to read/maintain.

I prefer Go over other languages. I like the part that there is no cleverness around it.

But why are you bothered about what google thinks of its engineers ? You can write everything in Haskell, why stop at Java/Rust ?

[nnq]

1. enabling cleverness enables creating tool to manage complexity, and hopefully, to manage it with fewer people needed

2. Google "sets the intellectual trend/fashion", whether we like it or not, their attitude get copied... there was quite a bit of experimentation in the 1995 - 2015 decades, we saw stuff like real macros coming to mainstream programming languages (Julia, Scala, Rust), we saw advanced type systems become liked and used (see even TypeScript which basically supports "poor man's ADTs" now), but the "new wave" which seems inspired by G's language design trends seems to be all about throwing it all away, we're scared s'less of complexity and unmaintainabilty that using anything more that string substitutions for code generation when we really-really-really have to seems heresy.

The trends seems to have creeped even into languages like Haskell where nobody's talking about template Haskell anymore and everyone or adding dependent types or whatever, it's all about focusing on package managers and limiting new features and building more tools... Python has a growth spur with 3.0 - 3.6 but that's also freezing in a way, no bold new additions coming without endless discussions.

[jimsmart]

> they should be capable of leveraging powerful programming language features to massively increase developer productivity, right?

Here you are claiming that leveraging powerful language features can massively increase developer productivity, but you offer no evidence to back up that claim.

[nnq]

- powerful features -> less code to do something -> less bugs because less code

- powerful features -> more general abstractions -> more code reuse -> less new code written -> less bugs

It's not that simple, but it's good to start with the core assumption that less code -> less bugs and what more powerful languages offer you is ability to solve problems with less code while at the same time keeping that more compact code readable.

Or maybe big software-focused companies like G don't see "# of LOC" as a liability and don't try to reduce it while at the same time as trying to do more? Is this the core difference between a large corporation and a small startup that tries to do more with less?

[sullyj3]

I think this is true in the case of the individual developer who has some level of understanding of and ownership over their entire codebase. This is no longer true when you're working in medium to large teams, like google is.

[dexterlagan]

"It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical." – Rob Pike

[frou_dh]

Is your clear faith in industry at large "leveraging powerful programming language features to massively increase developer productivity" substantiated or just taken as a given because it makes intuitive sense?

[nnq]

What makes sense is that the number of bugs tends to end up proportional with the amount of code...

If a powerful language allows you do the same thing with 10x less code, you'll also have up to 10x fewer bugs (in practice maybe only 2x fewer, but that would still be huge).

[karmakaze]

I recently tried out Dart on a project to play with Flutter. It felt pretty much the same as TypeScript/React. I prefer using Flutter/Dart to either of UIKit/Swift or AndroidSDK/* so they're doing something right.

[jart]

New languages help promote economic velocity and prevent towers of babel from rising up. The features of the languages themselves are kind of a red herring that distract folks from the cause of their disenfranchisement. You can build a veritable empire on a 100 million lines of PHP scripts if you've got the resources.

[nnq]

> promote economic velocity and prevent towers of babel from rising up

...could you elaborate what you mean by that?

[rcaught]

Not that reserved keywords are the only measure of a well designed language, but it is interesting to note that Golang has 25 (which most likely contributes to the feeling of fluency earlier than many languages). Java has 50 and C++ has 82 keywords for comparison.

[nnq]

The human brain has no problem handling a 70k+ vocabulary of a natural language, just saying... until a language goes over a few thousand reserved words I'd say there's no adverse effect to them as long as they are clearly named/prefixed etc. in ways that don't conflict with frequently used words (and we know we can have sigils like $ for namespacing, # for separating function names from variable names etc. etc.

[airbreather]

Technically, you only need a very limited feature set to do whatever you want.

For example - https://en.wikipedia.org/wiki/One_instruction_set_computer.

[Jweb_Guru]

Technically, most people like using things like the internet, a monitor, keyboards, etc, and ideally would like computations to finish in a reasonable amount of time and be presented in an understandable format. Bonus points if this can occur on physically realizable machines.

[jonathanstrange]

Because simple is better. K.I.S.S.

[sudeepj]

Yes. To put it in other words "simplicity scales" in terms of number of people. It helps to commoditise things faster and lower the cost (i.e learning, operating, hiring, tooling cost etc).

[tomlock]

I have very little experience in compiled languages. Coming to Go after Python was not only a joy, but I was able to easily implement concurrency and improve the performance of my game of life simulation side project by something like 25x.

So to me it feels like they did something right.

I guess maybe there just sometimes being a way to do something right only one way, makes searching for solutions, easier. I contrast that with another language I love, Ruby, where it can sometimes feel like there are so many ways to do things that the language isn't opinionated at all.

[antisemiotic]

>Coming to Go after Python was not only a joy, but I was able to easily implement concurrency and improve the performance of my game of life simulation side project by something like 25x.

Python is notoriously bad at both these things though, so it's not a very high bar. I think a more meaningful comparison would be to languages like Clojure, Erlang/Elixir, Rust, or any other that has concurrency as one of the top priories, but makes different tradeoffs.