6 ms·

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

• tomlock 7y ago
  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 7y ago
    >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 7y ago
      I know this, but I also know I struggled with C and Go felt delightfully straightforward.
• dexterlagan 7y ago
  "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 7y ago
    > 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!
    • codegladiator 7y ago
      The hardest path is finding someone else (hiring) to read and understand the intentions behind your code.
    • oleganza 7y ago
      > 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.
    • hackerpacker 7y ago
      well, when they convert the bulk of their stuff to go, if the plan works, and the theory is correct, then they can hire something more like a laborer instead of an engineer. 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.
• dexterlagan 7y ago
  "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
• jimsmart 7y ago
  > 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 7y ago
    - 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 7y ago
      > 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 7y ago
        > 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.
• jart 7y ago
  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 7y ago
    > promote economic velocity and prevent towers of babel from rising up ...could you elaborate what you mean by that?
• rcaught 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
        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 7y ago
          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/Date.pm 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 https://github.com/araddon/dateparse/blob/master/parseany.go
• codegladiator 7y ago
  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 7y ago
    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 7y ago
      > 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.
• frou_dh 7y ago
  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 7y ago
    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 7y ago
      > 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.
• airbreather 7y ago
  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 7y ago
    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.
• LocalMan 7y ago
  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.
• jonathanstrange 7y ago
  Because simple is better. K.I.S.S.
  • sudeepj 7y ago
    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).
• karmakaze 7y ago
  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.