8 ms·

> Readability. I always found the Go code I encountered quite easy to read and understand, both our code and external code. Some of the C++ I encountered, in co

• millstone 8y ago
  I don't get the "Go is easy to read" notion. Here's the recommended way to work with slices: [1]: Delete from a slice: `a = append(a[:i], a[i+1:]...)` Copy a slice: `b = append([]T(nil), a...)` Pop from a slice: `x, a = a[len(a)-1], a[:len(a)-1]` And some of these are discouraged because they leave you vulnerable to memory leaks (?) These are fundamental building blocks and they're really quite bad. I mean when you're using `append` to delete... 1: https://github.com/golang/go/wiki/SliceTricks https://github.com/golang/go/wiki/SliceTricks
  • nemo1618 8y ago
    Deleting from a slice is ugly and awkward because it's slow. Go, like C, confronts you with the real cost of what you want to achieve. A builtin like 'delete(a, i)' looks like an O(1) operation, when in reality it's O(n).
    • janekm 8y ago
      A more developer-friendly language like Swift would give you an ArraySlice type with performant views on arrays, and developer-friendly syntax.
    • edflsafoiewq 8y ago
      In what way does delete(a, i) look like an O(1) operation? It looks like a function call. You can never just look at a function call and see its complexity. You make it sound like deleting an element being ugly is a design choice, but it can't be a choice since there is no alternative. Swap-and-pop is O(1), but it's ugly too.
    • kasey_junk 8y ago
      Yet copy is available.
    • apta 8y ago
      > A builtin like 'delete(a, i)' Ironically, "delete" is built in in golang (how else do you delete an entry from a map)? Yet it says nothing about its cost.
  • joshuak 8y ago
    That is not the recommended way to work with slices. These are novelties, aka tricks. The following is more representative. Delete: copy(a[i:],a[i+1:]) a = a[:len(a)-1] Copy: b := make([]T, len(a)) copy(b,a) Push: a = append(a, x) Pop: x := a[len(a)-1] a = a[:len(a)-1] Enqueue: a = append([]T{x}, a...) Dequeue: x := a[0] a = a[1:] Idiomatic Go would have you not put on one line what is more clear on two.
    • jonahx 8y ago
      > Idiomatic Go would have you not put on one line what is more clear on two. This is the kind of silly aphorism that sounds enlightened until you think about it, and is emblematic of the bad parts of Go dogma. The problem is that excessive LOC actually correlates strongly with poor readability, and all the cleverness in the world won't change that.
      • C1sc0cat 8y ago
        No cramming code into one line is never a good thing when you can make it clearer and easier to read by using 2, 3 or 4 lines of shorter more readable code.
      • networkimprov 8y ago
        This. Code density matters! Excessively low or high density are equally injurious to readability.
        • Barrin92 8y ago
          I disagree strongly, at least as far as my intuition is concerned. it's not code density that matters, it's "context density". Long drawn out functions are usually not hard to read because they are long, but because it's not clear what they are about. It's lack of conciseness on part of the programs logic that makes programmers lose focus, not code density. As an example, think of a few fairly long switch statements or pattern matching logic. It's non-dense code depending on your language, but not hard to understand even if long. In contrast, some convoluted Haskell syntax with weird operators you've never seen is almost mentally incomprehensible. On these terms it's true that Golang is not 'text dense' but it doesn't matter, it stops semantics from being overly complicated, and it encourages simple structures that don't go overboard on condensing information.
  • jonahx 8y ago
    Claiming that Go should excels in readability or ergonomics is pure, Koolaid fever-dream delusion. Is it cleaner than C/C++? Sure. It's still a painfully verbose language full of boilerplate and with zero concern for expressivity or the suppression of detail [0]. Which isn't to say it's overall a bad language. It prioritizes other things over readability -- like speed, enforcing consistency, keeping its primitive set small. [0]: https://golang.org/doc/faq#Does_Go_have_a_ternary_form https://golang.org/doc/faq#Does_Go_have_a_ternary_form (no further evidence is needed)
    • networkimprov 8y ago
      The main rationale for the lack of ternary, "We don't do control flow with symbols" should also disallow this: t && a() || b() Admittedly tho, nested ternaries are tedious to parse by eye.
      • simonask 8y ago
        They're nothing against nested applications of the above, though. :-) t && a() || (u && b() || c()) Personally, I enjoy Rust's choice of letting `if` be an expression.
        • paulddraper 8y ago
          > I enjoy Rust's choice As a Scala user, I agree it really is the best val a = if (t) a() else b()
      • lazarljubenovic 8y ago
        We should also ban kitchen knives because users have repeatedly stabbed themselves in the eye.
    • deleted 8y ago
      [deleted]
    • bnolsen 8y ago
      Speed of compilation, not necessarily speed of compiled code. Missing generics: deadly. Passing around just interfaces? At times clearly not sufficient. Their idea of closures? Looks messy to me. Having a special syntax just for threading stuff? Totally beyond lame! Golang is absolutely not a replacement for c or c++. It's a better replacement for the other languages out there requiring a VM to run anything. In short golang is better at cross platform than these other platforms and is IMHO good for writing good tooling. One of my colleagues said that golang now is sort of like java was in the old, old days. Making the same mistakes and needing necessary features added to become truly productive. In my opinion ternary stuff is short handed eye candy and not a great reason to discount a language. c++'s collections and <algorithm> fundamentally and utterly thrash anything golang claims to have, not to mention the whole stupidity around building garbage collection into a language that wants to be low level.
  • cbaker122 8y ago
    I find Go hard to read because it is so monotonous (and a bit ugly) that I cannot concentrate. For me, aesthetics matter, so my readability preference goes something like {Lisp,ML,Haskell} > C/C++ > Java > Python > Go. C is actually quite high on the elegance level. C++ is only that high when written by people with self-restraint. Rating Java above Python is not a mistake if you consider larger code bases. Also, Python suffers from some of the monotony problems, especially when there are many conditional statements.
• Scarbutt 8y ago
  But then: I’m confident that a C++ translation of the new Go code would be less than half the LOC of the Go version and more type-safe, due to C++’s polymorphic functions and types. A Haskell rewrite would need even fewer LOC, and if I’d been allowed to write it in Clojure I suspect the whole thing could have been expressed in fewer than 1000 lines of macros
  • fwip 8y ago
    Sounds like there's both ups and downs.
• nine_k 8y ago
  > My coworkers won’t have trouble understanding it This very much depends on your coworkers, and on the problems you solve.
  • kccqzy 8y ago
    Indeed if you actually are using Haskell in production, there's no way your coworkers won't be able to understand a simple signature with three classes. They probably aren't Haskell beginners. Please, have some confidence in your coworkers' intelligence and reasoning ability.
    • foldr 8y ago
      The issue isn't understanding the signature per se. The point is that type signatures aren't always enough to figure out what a function does.
      • mruts 8y ago
        That’s a good point, but often a type signature constrains the possible programs to such a degree that there is only one nonsensical program that can be written with that signature.
        • foldr 8y ago
          That's rarely the case for effectful code, which is where you'd typically see multiple monadic type class constraints.