Ask HN: Why is Google in love with purposely-impaired languages like Go, Dart?
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?
40 comments
[ 6.5 ms ] story [ 73.3 ms ] threadSo 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.
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.
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!
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.
The main thing is that they are so huge, they can afford such experiments. I don't put much faith in that approach outside of a huge organization, and the jury is still out internally.
And given their shift to no brainteasers and no degree, and diversity and other non skill based focus, and sheer number of employees, the bar may not be set where you think it is these days. Hell it might not be much harder than stating your political beliefs (assuming you have the right political beliefs) based on recent cultural evidence.
Wow, way to put down your engineers. What is the famously high hiring bar at Google for?
Here you are claiming that leveraging powerful language features can massively increase developer productivity, but you offer no evidence to back up that claim.
- 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?
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.
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.
...could you elaborate what you mean by that?
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)
https://github.com/mojolicious/mojo/blob/master/lib/Mojo/Dat...
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
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 ...
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 ?
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.
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.
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
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).
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.
For example - https://en.wikipedia.org/wiki/One_instruction_set_computer.
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.