4 ms·

> Maybe Mr. Pike actually has some well-deserved reputation when it comes to real-world software and engineering projects that are about handling large scale da

by apta 8y ago

> Maybe Mr. Pike actually has some well-deserved reputation when it comes to real-world software and engineering projects that are about handling large scale data in real time? What are the credentials to back this up? Otherwise, the languages he makes fun of actually are used to deliver large scale systems in real time. Google is built on C++ and Java, so are most of the other top tech companies, not to mention banks and HFT firms.

jstimpfle 8y ago
He is one of the Unix figures at Bell Labs (although a late-joiner, being younger), he designed UTF-8 with Ken Thompson, and worked on the Plan 9 project, before joining Google. That's probably more than most of us will ever achieve.
- apta 8y ago
  Plan9 didn't go anywhere. So other than UTF-8, there's not much to speak of. He's not a reference on programming language design, and it shows. Compare to Leslie Lamport for instance, and the tremendous effect he had on large scale systems and software engineering correctness.
  - jstimpfle 8y ago
    Can you argue your case as well as he does? https://www.youtube.com/watch?v=cQ7STILAS0M https://www.youtube.com/watch?v=cQ7STILAS0M Or are you just being disrespectful?
    - apta 8y ago
      I read the slides, but didn't hear the talk. There is so much conjecture in them. C++ is successful, Java is successful, so are Python, C#, and a whole bunch of other languages. When it comes to complexity, large systems tend to be complex, so you either push some of that complexity into your language, to give you expressiveness and modeling capability, or you simplify your language so much (golang) such that the code base becomes complex and verbose due to repetition, not to mention error prone. Readability? Compare: var a int if foo() { a = bar() } else { a = baz() } to final int a = foo() ? bar() : baz() or even val a = if foo() { bar() } else { baz() } the latter two are shorter by a factor of 6, clearer, and less error prone. This is a feature that both improves readability, and reduces complexity. The funny thing is, the golang code bases I worked with would be quite a bit shorter in a supposedly verbose language like Java, not to mention something like Kotlin. Do you want a practical reason why golang is popular? Because it has Google behind its name. The language that he worked on before he was at Google, which were similar to golang, went nowhere.
      - jstimpfle 8y ago
        There's a name for what you're doing. It's called "cherry picking". And also there's a name for the act of pulling something out of context to support an arbitrary point. Let it be said that I'm not actually a Go but a C programmer, and there might be about 1 legitimate use of this syntactic construct per few thousand lines in my code (you are free to checkout my language project from github and verify my claim). It's not that I don't know the construct, but more that most experiments with it end up being reverted again to the longer form, to preserve the rhyme and rhythm of my code. I won't take sides, but I guess their idea was that like so many other features, this little syntactic sugar construct does not carry its own weight. > I read the slides, but didn't hear the talk You absolutely should hear it! The slides probably do not contain actual experience reports, opinions, and arguments. > the golang code bases I worked with would be quite a bit shorter in a supposedly verbose language like Java that's hard to believe. Any code samples for illustration? (I invite you to cherry pick!).
        apta 8y ago
        > There's a name for what you're doing. It's called "cherry picking". And also there's a name for the act of pulling something out of context to support an arbitrary point. There's also something called "argument from fallacy". Either refute the points I raised, otherwise there's no point bringing up fallacies :) > Let it be said that I'm not actually a Go but a C programmer, I have been using golang at my current employer for several months now. That being said, that's your experience, and it doesn't necessarily mean that everyone else has your use case. The shorter form is (1) more readable, and (2) less error prone - fact. Less code also means less room to make errors. It was pretty laughable on the golang mailing list when someone asked why there wasn't a max/min implementation for all number types in golang, someone replied why do you need it? You can just implement it yourself like so, and proceeded to write a max implementation where the comparison operator was flipped. It's quite ironic really. > but I guess their idea was that like so many other features, this little syntactic sugar construct does not carry its own weight. It does, it reduces the probability of error by making sure that assignment happens only once. They weigh things very arbitrarily, like how one of the golang authors doesn't think compile checked enums are worth it because hey, they're just enums checked by the compiler to ensure coverage. It shows they don't have experience with other languages, or with features that reduce error rates. > that's hard to believe. Any code samples for illustration? (I invite you to cherry pick!). I already listed the lack of a ternary operator or its equivalent, and this extends to other constructs which can be expressions. Java is getting switch expressions in the upcoming release, and in Kotlin, try/catch is an expression, it's quite nice. The most obvious other one is error handling, "if err != nil" checks everywhere, which makes the code base much longer. Others include the lack of map/fold/etc functions. The code base I work with is littered all over the place with functions to do what effectively are maps or maps+filters. Those functions end up being 8 lines or so, whereas they could be fit in 1-2 lines, inline at the call site, without the reader having to jump to the function implementation. This gets tiring very quickly, and makes it take longer to understand the code at hand. Another example is needing to explicitly assign to a temporary variable if you need to take its address to pass it as an argument. a := foo() b := bar() c := baz() qux(&a, &b, &c) as opposed to for example Rust: qux(&foo(), &bar(), &baz()); or Java qux(foo(), bar(), baz());
- ernst_klim 8y ago
  >He is one of the Unix figures at Bell Labs (although a late-joiner, being younger), he designed UTF-8 with Ken Thompson, and worked on the Plan 9 project So his only "serious engineering project" is a toyish academic operating system? No mission-critical software, no application software with millions of installations (except Go compilers).
  - jstimpfle 8y ago
    You're being disrespectful. > No mission-critical software, no application software with millions of installations (except Go compilers). Yes. NOOO software with millions of installations. Except Go compilers. Which doesn't count? (And I don't even know, there might be more). He is an accomplished engineer. UTF-8 is one of the best designs I know. Unix is still around, despite its shortcomings. He's written books and been around some of the gods of software and OS engineering. Regarding Plan 9, I'm not positive that it is a toy operating system. I've never used it. It tried to improve on Unix and might (or might not) have achieved that in many ways. It's named as an inspiration by Linus Torvalds. What do you have to show?
    - ernst_klim 8y ago
      >Yes. NOOO software with millions of installations. Except Go compilers. So the grand experience of Rob being the justification of Go's design is the Go compiler itself? Besides, Go compiler is ridiculous if you compare it to things like llvm, gcc, ghc, CompCert. >UTF-8 is one of the best designs I know. Not a software. >Unix is still around, despite its shortcomings 1) he didn't create Unix and 2) modern unix has pretty nothing in common with the bell labs unix. >I've never used it. So let's draw the conclusion: the enormous engineering background of Pike -- which tends to be a justification of Go's "suitable for real world apps not academic masturbation" design -- consists of writing a simplistic academic operating system nobody used (you included) and UTF-8 which is not even a software? That's big, but I'll stick to Ada or C++, languages with real industrial background.

by apta 8y ago

jstimpfle 8y ago

He is one of the Unix figures at Bell Labs (although a late-joiner, being younger), he designed UTF-8 with Ken Thompson, and worked on the Plan 9 project, before joining Google. That's probably more than most of us will ever achieve.

apta 8y ago
Plan9 didn't go anywhere. So other than UTF-8, there's not much to speak of. He's not a reference on programming language design, and it shows. Compare to Leslie Lamport for instance, and the tremendous effect he had on large scale systems and software engineering correctness.
- jstimpfle 8y ago
  Can you argue your case as well as he does? https://www.youtube.com/watch?v=cQ7STILAS0M https://www.youtube.com/watch?v=cQ7STILAS0M Or are you just being disrespectful?
  - apta 8y ago
    I read the slides, but didn't hear the talk. There is so much conjecture in them. C++ is successful, Java is successful, so are Python, C#, and a whole bunch of other languages. When it comes to complexity, large systems tend to be complex, so you either push some of that complexity into your language, to give you expressiveness and modeling capability, or you simplify your language so much (golang) such that the code base becomes complex and verbose due to repetition, not to mention error prone. Readability? Compare: var a int if foo() { a = bar() } else { a = baz() } to final int a = foo() ? bar() : baz() or even val a = if foo() { bar() } else { baz() } the latter two are shorter by a factor of 6, clearer, and less error prone. This is a feature that both improves readability, and reduces complexity. The funny thing is, the golang code bases I worked with would be quite a bit shorter in a supposedly verbose language like Java, not to mention something like Kotlin. Do you want a practical reason why golang is popular? Because it has Google behind its name. The language that he worked on before he was at Google, which were similar to golang, went nowhere.
    - jstimpfle 8y ago
      There's a name for what you're doing. It's called "cherry picking". And also there's a name for the act of pulling something out of context to support an arbitrary point. Let it be said that I'm not actually a Go but a C programmer, and there might be about 1 legitimate use of this syntactic construct per few thousand lines in my code (you are free to checkout my language project from github and verify my claim). It's not that I don't know the construct, but more that most experiments with it end up being reverted again to the longer form, to preserve the rhyme and rhythm of my code. I won't take sides, but I guess their idea was that like so many other features, this little syntactic sugar construct does not carry its own weight. > I read the slides, but didn't hear the talk You absolutely should hear it! The slides probably do not contain actual experience reports, opinions, and arguments. > the golang code bases I worked with would be quite a bit shorter in a supposedly verbose language like Java that's hard to believe. Any code samples for illustration? (I invite you to cherry pick!).
      - apta 8y ago
        > There's a name for what you're doing. It's called "cherry picking". And also there's a name for the act of pulling something out of context to support an arbitrary point. There's also something called "argument from fallacy". Either refute the points I raised, otherwise there's no point bringing up fallacies :) > Let it be said that I'm not actually a Go but a C programmer, I have been using golang at my current employer for several months now. That being said, that's your experience, and it doesn't necessarily mean that everyone else has your use case. The shorter form is (1) more readable, and (2) less error prone - fact. Less code also means less room to make errors. It was pretty laughable on the golang mailing list when someone asked why there wasn't a max/min implementation for all number types in golang, someone replied why do you need it? You can just implement it yourself like so, and proceeded to write a max implementation where the comparison operator was flipped. It's quite ironic really. > but I guess their idea was that like so many other features, this little syntactic sugar construct does not carry its own weight. It does, it reduces the probability of error by making sure that assignment happens only once. They weigh things very arbitrarily, like how one of the golang authors doesn't think compile checked enums are worth it because hey, they're just enums checked by the compiler to ensure coverage. It shows they don't have experience with other languages, or with features that reduce error rates. > that's hard to believe. Any code samples for illustration? (I invite you to cherry pick!). I already listed the lack of a ternary operator or its equivalent, and this extends to other constructs which can be expressions. Java is getting switch expressions in the upcoming release, and in Kotlin, try/catch is an expression, it's quite nice. The most obvious other one is error handling, "if err != nil" checks everywhere, which makes the code base much longer. Others include the lack of map/fold/etc functions. The code base I work with is littered all over the place with functions to do what effectively are maps or maps+filters. Those functions end up being 8 lines or so, whereas they could be fit in 1-2 lines, inline at the call site, without the reader having to jump to the function implementation. This gets tiring very quickly, and makes it take longer to understand the code at hand. Another example is needing to explicitly assign to a temporary variable if you need to take its address to pass it as an argument. a := foo() b := bar() c := baz() qux(&a, &b, &c) as opposed to for example Rust: qux(&foo(), &bar(), &baz()); or Java qux(foo(), bar(), baz());
ernst_klim 8y ago
>He is one of the Unix figures at Bell Labs (although a late-joiner, being younger), he designed UTF-8 with Ken Thompson, and worked on the Plan 9 project So his only "serious engineering project" is a toyish academic operating system? No mission-critical software, no application software with millions of installations (except Go compilers).
- jstimpfle 8y ago
  You're being disrespectful. > No mission-critical software, no application software with millions of installations (except Go compilers). Yes. NOOO software with millions of installations. Except Go compilers. Which doesn't count? (And I don't even know, there might be more). He is an accomplished engineer. UTF-8 is one of the best designs I know. Unix is still around, despite its shortcomings. He's written books and been around some of the gods of software and OS engineering. Regarding Plan 9, I'm not positive that it is a toy operating system. I've never used it. It tried to improve on Unix and might (or might not) have achieved that in many ways. It's named as an inspiration by Linus Torvalds. What do you have to show?
  - ernst_klim 8y ago
    >Yes. NOOO software with millions of installations. Except Go compilers. So the grand experience of Rob being the justification of Go's design is the Go compiler itself? Besides, Go compiler is ridiculous if you compare it to things like llvm, gcc, ghc, CompCert. >UTF-8 is one of the best designs I know. Not a software. >Unix is still around, despite its shortcomings 1) he didn't create Unix and 2) modern unix has pretty nothing in common with the bell labs unix. >I've never used it. So let's draw the conclusion: the enormous engineering background of Pike -- which tends to be a justification of Go's "suitable for real world apps not academic masturbation" design -- consists of writing a simplistic academic operating system nobody used (you included) and UTF-8 which is not even a software? That's big, but I'll stick to Ada or C++, languages with real industrial background.