1. 14
  1.  

  2. 7

    This great video, Rob Pike correctly asserts what is the problem with C++ and Java, even though I disagree that Go is a great solution to those problems. ML family languages have more expressiveness and the result is that your code gets much shorter. In Go you still operating on low level primitives that make your code error prone and verbose.

    I could not find better example but this in this form is a good one:

    Spiral print in Go:

    https://gist.github.com/itsanna/785ce6936e7a212eabb87e0940424c4c

    Spiral print in Haskell:

    https://twitter.com/lix/status/1259424867239317504/photo/1

    Obviously there are other things like IO for example that are usually even harder to deal with but if we cannot solve simple problems in a concise way how are we going to solve complex problems?

    1. 2

      A fair amount of opening rhetoric… Yes, badly written/abstracted C++/Java, is bad.

      But it’s an unfair comparison, Go’s competitors would be C#, Rust, Kotlin, Javascript, Python etc. Shouldn’t we do honest comparisons?

      His point on “languages shouldn’t need tools, to be successful” is also disingenuous, Go comes with these tools built into its compiler… What’s the difference between having tools in your editor vs your CLI tooling… it’s still a tooled environment. No?

      Language war style arguments really don’t sit well with me these days. It’s the hammer arguing with the spanner kind of thing. There is some cross over (they can both bang things) but they have specialties, and we don’t need to do dishonest comparisons with the hand drill to highlight those specialties.

      Edit: (Apologies I just noted the date on the talk, still, C++ isn’t an appropriate comparator, but Kotlin/Rust probably aren’t candidates)

      1. 3

        I’ve used a lot of different languages. It’s really hard to emphasise sufficiently how far ahead the go tooling is for the problems it targets, and how little churn it generates.

        Maintaining the “here is how to set up the tooling” document has been expensive in almost every job I’ve had.

        1. 1

          Some counterexamples I can stand behind:

          • C# (or .NET in general) - Visual Studio is pretty self-contained.
          • Rails (similar to go really) - tooling just comes with, and works. (I’m purposefully treating this separately to stand-alone ruby)
          • Typescript is often a .vscode file with vscode

          None of the above is particularly hard to maintain in terms of documentation. These are the modern equivalents that Go should be compared to. I agree with you if you talk about Java or C/C++ you can have quite an intricate build and tooling systems that are hard to maintain… that’s why I don’t think they are fair comparisons.

          I found a much better talk by Rob Pike on go from 5 years later, where he talks about the actual complexity/simplicity of the language without too much stone-throwing. (https://www.youtube.com/watch?v=rFejpH_tAHM)

      2. 1

        Short and sweet for a conference talk. I’d like to know which other languages besides Go he would hold up as good examples of the best of both worlds. At this point when I see Rob Pike speak, I think it’s just another Go talk, but I think his insights could be more broadly valuable if he didn’t just push one solution.

        1. 2

          When this talk was recorded in 2010, I’m not entirely sure if there were any. Or at least none that were widely known and mature. Since then much has changed, and now we not only have things like Rust, Zig, Kotlin, TypeScript, and whatnot, the dynamic languages such as Python and Ruby have also evolved to (optionally) accept typing.

          In my first decade of programming comparativly little changed; the languages I used in 2000 were the same as the languages I used in 2010. But in the second decade there have been loads of changed and new things in this space.

          Hell, even ol’ C has seen quite a few changes in the compiler space with LLVM/clang, whereas before your only realistic option was gcc (which few really liked).

          1. 1

            You know, what happened here is I missed the fact that this was from 2010. I locked in on the puzzle of how “public static void” was going to be used as context in a Rob Pike talk and I glossed over the rest. Thank you for the details.

        Stories with similar links:

        1. OSCON 2010: Rob Pike, "Public Static Void" via inactive-user 6 years ago | 1 point | no comments