
Ask HN: Why is Google in love with purposely-impaired languages like Go, Dart? - nnq
Google seems to invest a lot in R&amp;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 <i>&quot;mediocre by design&quot;</i> in a way, or at least <i>designed to be restrictive</i> and&#x2F;or to impair developer flexibility and productivity.<p>On the languages side Go and Dart seem like the <i>epitome of &quot;Blub languages&quot;</i> in PG&#x27;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&#x27;s C++ programmer...<p><i>Where is this attitude coming from? Is Google&#x27;s philosophy that most programmers, including their own, are either stupid and&#x2F;or irresponsible and shouldn&#x27;t be trusted with powerful tools that can increase their productivity when used right? I mean, software is their business, they&#x27;re not churning ecommerce infrastructure CRUDhorrhea... they should be capable of leveraging powerful programming language features to massively increase developer productivity, right?</i>
======
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!_

~~~
oleganza
> 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!

Seems like Go is manifestation of such process. Because something like Rust is
not for a repeatable process of _producing a lot of software_ by big teams
with variation in experience and headcount. Rust is probably about _fewer
people_ carefully designing _less_ of software, so it can be done once and
stay forever.

Rust is for architecting bridges, Go is for paving streets.

------
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.

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

No. Complexity just makes it harder to read. Go try to read your own code from
5 years ago. I just fail to read even my own code flow every where I used
reflections in Java to make it clever (small code which can handle multiple
scenarios). Yet I can read every golang codebase in github super easily.

> 2\. Google "sets the intellectual trend/fashion"

No. People use what they learn quickly and what gets them productivity. I want
to write a software to solve business problems, not want to write software
because its cool or something.

Go try to read k8s code. And try to image how it would look like in haskell.

It just looks like you are trying to hate google for the wrong reasons.

~~~
nnq
> It just looks like you are trying to hate google for the wrong reasons.

Ok, maybe I was a bit inflamed, actually I'm in a love-hate relationship
Google's languages, both Go and Dart/Flutter, and using them more and more...
_but it happens again and again and again that I just wish there were some
extra features that if we had them, code would be 10x smaller but still
readable :)_

Yeah, it's "over-reacting Monday" I guess :P

------
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?

~~~
codegladiator
> core assumption that less code -> less bugs

This assumption is false. Either the flows are written in code, are you have
to have them in your brain every time you are reading some code which can
handle 10 flows.

> solve problems with less code while at the same time keeping that more
> compact code readable

Less code means less readable.

~~~
nitely
> This assumption is false. Either the flows are written in code, are you have
> to have them in your brain every time you are reading some code which can
> handle 10 flows.

No, it's not. Your interpretation of it is wrong, though. No code means no
bugs, this _is_ true. Now, write a new feature, unless the code is flawless,
the code-base will certainly have more bugs than before, this _is_ true. Now,
write a linked-list, unless the code is flawless, the code-base will have more
bugs than if using the one in the language std-lib. About language features,
writing 5 implementations of a linked-list for each type instead of a generic
one that it's type checked will certainly contain more bugs as it's more error
prone to write the same things 5 times and keep it updated.

> Less code means less readable.

This is ridiculous. Otherwise, we'd all be using assembly. About Go, the lack
of generics and simple error propagation is detrimental to being readable.
Every function can fail, you don't say!. You're manually propagating the error
instead of handling it here, you don't say!. That's what I think every time I
go through some Go code-base.

------
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).

~~~
codegladiator
> the number of bugs tends to end up proportional with the amount of code

This happens when the original code was clever to begin with and someone
(else) came try to fix an edge case and lo and behold.

------
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.

~~~
codegladiator
Yet very few can write an enjoyable novel which others can read.

Try reading documentations to see how the 70k+ vocabulary helped the writer
and reader.

Sigils like $ and # are even worse. I had to maintain an old perl codebase
once (# @_ holds all arguments passed)

~~~
nnq
Never worked professionally on a Perl codebase but I kind of liked it when I
learned a tidbit and feel a bit nostalgic that it went out of fashion :P

~~~
codegladiator
Try reading this Date module (which is very cleanly written compared to the
codebase which I was supposed to maintain)

[https://github.com/mojolicious/mojo/blob/master/lib/Mojo/Dat...](https://github.com/mojolicious/mojo/blob/master/lib/Mojo/Date.pm)

I just find it impossible to glance over it and understand whats happening
even though I know what is supposed to be happening there.

Something similar in golang

[https://github.com/araddon/dateparse/blob/master/parseany.go](https://github.com/araddon/dateparse/blob/master/parseany.go)

~~~
nnq
Hmm, that Perl code seems quite irregular / badly structured, I see some
regexps are inline while others in named variables, no clear docs of what is
the return of functions etc.

Beside that, the extra clarity in Go is from using a static language. Also,
Perl is inexcusable for having no readable function signatures, that's really
a no-go for a modern language :|

 _But for me at least, when I see that wall of boilerplatish Go code, my mind
instantly ADHDs away, while those dense squiggles of Perl make me WANT to
spend time and focus and solve the puzzle of what they do, I have 10x more
chances of paying attention to the Perl code while reading it and maybe even
spotting a bug in it :P ..._

------
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](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.

~~~
tomlock
I know this, but I also know I struggled with C and Go felt delightfully
straightforward.

