7 ms·

In my opinion, coming from Java,C# background and currently working on golang, here's my take. 1. Golang did right design in terms of OOP 2. They didnt compli

In my opinion, coming from Java,C# background and currently working on golang, here's my take. 1. Golang did right design in terms of OOP 2. They didnt complicate the language by accepting everything. 3. At the same time, they made simple things so complex. Simple logics to removing an element from slice/array and even iterating them without screwing up the data. I have been programming for 10yrs and I find myself doing those mistakes without proper IDE/golint, while I can easily code in other languages without much help. I can concentrate on solving the business problem rather than fiddling around the language

ironmagma 6y ago
“Everything should be made as simple as possible, but no simpler.” I’ve often felt Go went too far trying to make everything simple, to the point that it’s wrapped around and made things complex.
- avmich 6y ago
  "Civilization advances by extending the number of important operations which we can perform without thinking of them." --Alfred North Whitehead Go forces writing loop for removing an element from an array even if the programmer knows it's linear time. Ruby gambles that programmer isn't ignorant - or it's not critical - but allows the convenience every time. Designing languages is hard.
  - cratermoon 6y ago
    > Go forces writing loop for removing an element from an array It does not: copy(a[i:], a[i+1:]) // Shift a[i+1:] left one index. a[len(a)-1] = "" // Erase last element (write zero value). a = a[:len(a)-1]
    - z0r 6y ago
      you are right that a loop isn't required, but the point that kind of index / array element juggling is a headache still stands
    - millstone 6y ago
      Your code removes by index. This can be done in one line in Go: list = append(list[:i], list[i+1:]...) but to remove by value you need a loop.
      - c-cube 6y ago
        When I see that, I have no idea if it allocates a new array or if it's in place. Which one is it? At least with a delete function it's clear.
        millstone 6y ago
        In Go it may or may not allocate a new array; it depends on the array's capacity. This means that the resulting slice may or may not alias the original slice. See this playground for an illustration: https://play.golang.org/p/mOpuGVj2ypG https://play.golang.org/p/mOpuGVj2ypG That uses append to delete, and then modifies element 0 in the result. In the first call, only the new slice is modified. But in the second call, both slices are modified, since they share the same backing array. I consider this to be one of the worst mistakes of Go, to design a highly multithreaded language in which variable aliasing is a dynamic property. I am convinced that many Go programs have latent races and bugs, invisible to the race detector, and they have not yet been tripped because they have been (un)lucky with the runtime's capacity decisions.
      - pansa2 6y ago
        It’s crazy that the function you call to remove an element from a list is `append`.
        pests 6y ago
        If you come at it with the thought that you are creating two sublists (on each side, avoiding the index) you then need to merge them back together. That append reads to just recreate the list from the two parts.
      - ziml77 6y ago
        This makes it very unclear what's going on. I had to test it to find that this specific use is special cased to not copy. And very surprisingly you don't even have to assign back to the same variable to get this no-copy behavior! Edit: I didn't do my test quite right. It's not really special-cased. But it's still very surprising to see this happen: Code: s1 := []int{1, 2, 3, 10, 11, 12} s2 := []int{4, 5, 6} s3 := s1[:2] s4 := append(s3[:2], s2...) fmt.Println(s1) fmt.Println(s4) Output: [1 2 4 5 6 12] [1 2 4 5 6]
    - Aachen 6y ago
      Having worked a lot with at least a dozen languages, this is definitely on the cumbersome side of the spectrum. And a sibling comment says it doesn't even do what it says on the tin. In what other language does it take two devs to remove an element from an array?
gameswithgo 6y ago
A lot of the things in Go that seem horrible seem simple if you are used to the slice syntax used in Python and other langs, which I am not.
cratermoon 6y ago
removing an element from a slice is trivial if you don't care about order. Just swap the element you want to remove with the last element and truncate the slice. If you want to maintain order, shift all the elements following the one you want to remove left one and then truncate. The latter can be slow if the slice is large, but it's linear time.
- systemvoltage 6y ago
  OP isn't asking for a solution. OP is talking about not having to implement the solution themselves and having the language provide some shortcuts for doing what you just described.
  - cratermoon 6y ago
    shortcuts for trivial operations is how we got the leftpad disaster.
    - gizmo686 6y ago
      Leftpad was a result of making libraries (comically) small. If you have a bunch of convenience operations, you can put them all together into a single utility library (or even the standard library).
    - justin_oaks 6y ago
      People need those shortcuts so they don't reimplement them over and over. Not having the leftpad as part of the language or standard library is what caused the problem. This is exactly the problem the article talks about.
      - oftenwrong 6y ago
        >Not having the leftpad as part of the language or standard library is what caused the problem. There are a few other comments in this tree making the same claim - is this what most people took away from the left-pad incident? To me, the stdlib lacking left-pad is a fairly distant cause. You could make the same case for any popular library, but that road leads to a bloated stdlib, which forever will haunt us. The more relevant causes, in my book, are: 1. Many builds relied on pulling left-pad directly from NPM 2. NPM allowed left-pad to be unpublished I like to compare this to the usual practice in the Java world: 1. The primary repository in use is the Maven Central Repository. Nobody can unpublish a library from it. This is specifically to avoid pulling dependencies out from under consumers of those dependencies. 2. Most Java shops run their own repository. This serves both to caches requests to the Maven Central Repository, and to provide a fail-safe in case something were to happen to Maven Central. Backing up dependencies is considered as important as backing up your own code. Sometimes vendoring is used as an alternative approach.

ironmagma 6y ago

“Everything should be made as simple as possible, but no simpler.” I’ve often felt Go went too far trying to make everything simple, to the point that it’s wrapped around and made things complex.

avmich 6y ago
"Civilization advances by extending the number of important operations which we can perform without thinking of them." --Alfred North Whitehead Go forces writing loop for removing an element from an array even if the programmer knows it's linear time. Ruby gambles that programmer isn't ignorant - or it's not critical - but allows the convenience every time. Designing languages is hard.
- cratermoon 6y ago
  > Go forces writing loop for removing an element from an array It does not: copy(a[i:], a[i+1:]) // Shift a[i+1:] left one index. a[len(a)-1] = "" // Erase last element (write zero value). a = a[:len(a)-1]
  - z0r 6y ago
    you are right that a loop isn't required, but the point that kind of index / array element juggling is a headache still stands
  - millstone 6y ago
    Your code removes by index. This can be done in one line in Go: list = append(list[:i], list[i+1:]...) but to remove by value you need a loop.
    - c-cube 6y ago
      When I see that, I have no idea if it allocates a new array or if it's in place. Which one is it? At least with a delete function it's clear.
      - millstone 6y ago
        In Go it may or may not allocate a new array; it depends on the array's capacity. This means that the resulting slice may or may not alias the original slice. See this playground for an illustration: https://play.golang.org/p/mOpuGVj2ypG https://play.golang.org/p/mOpuGVj2ypG That uses append to delete, and then modifies element 0 in the result. In the first call, only the new slice is modified. But in the second call, both slices are modified, since they share the same backing array. I consider this to be one of the worst mistakes of Go, to design a highly multithreaded language in which variable aliasing is a dynamic property. I am convinced that many Go programs have latent races and bugs, invisible to the race detector, and they have not yet been tripped because they have been (un)lucky with the runtime's capacity decisions.
    - pansa2 6y ago
      It’s crazy that the function you call to remove an element from a list is `append`.
      - pests 6y ago
        If you come at it with the thought that you are creating two sublists (on each side, avoiding the index) you then need to merge them back together. That append reads to just recreate the list from the two parts.
    - ziml77 6y ago
      This makes it very unclear what's going on. I had to test it to find that this specific use is special cased to not copy. And very surprisingly you don't even have to assign back to the same variable to get this no-copy behavior! Edit: I didn't do my test quite right. It's not really special-cased. But it's still very surprising to see this happen: Code: s1 := []int{1, 2, 3, 10, 11, 12} s2 := []int{4, 5, 6} s3 := s1[:2] s4 := append(s3[:2], s2...) fmt.Println(s1) fmt.Println(s4) Output: [1 2 4 5 6 12] [1 2 4 5 6]
  - Aachen 6y ago
    Having worked a lot with at least a dozen languages, this is definitely on the cumbersome side of the spectrum. And a sibling comment says it doesn't even do what it says on the tin. In what other language does it take two devs to remove an element from an array?

gameswithgo 6y ago

A lot of the things in Go that seem horrible seem simple if you are used to the slice syntax used in Python and other langs, which I am not.

cratermoon 6y ago

removing an element from a slice is trivial if you don't care about order. Just swap the element you want to remove with the last element and truncate the slice. If you want to maintain order, shift all the elements following the one you want to remove left one and then truncate. The latter can be slow if the slice is large, but it's linear time.

systemvoltage 6y ago
OP isn't asking for a solution. OP is talking about not having to implement the solution themselves and having the language provide some shortcuts for doing what you just described.
- cratermoon 6y ago
  shortcuts for trivial operations is how we got the leftpad disaster.
  - gizmo686 6y ago
    Leftpad was a result of making libraries (comically) small. If you have a bunch of convenience operations, you can put them all together into a single utility library (or even the standard library).
  - justin_oaks 6y ago
    People need those shortcuts so they don't reimplement them over and over. Not having the leftpad as part of the language or standard library is what caused the problem. This is exactly the problem the article talks about.
    - oftenwrong 6y ago
      >Not having the leftpad as part of the language or standard library is what caused the problem. There are a few other comments in this tree making the same claim - is this what most people took away from the left-pad incident? To me, the stdlib lacking left-pad is a fairly distant cause. You could make the same case for any popular library, but that road leads to a bloated stdlib, which forever will haunt us. The more relevant causes, in my book, are: 1. Many builds relied on pulling left-pad directly from NPM 2. NPM allowed left-pad to be unpublished I like to compare this to the usual practice in the Java world: 1. The primary repository in use is the Maven Central Repository. Nobody can unpublish a library from it. This is specifically to avoid pulling dependencies out from under consumers of those dependencies. 2. Most Java shops run their own repository. This serves both to caches requests to the Maven Central Repository, and to provide a fail-safe in case something were to happen to Maven Central. Backing up dependencies is considered as important as backing up your own code. Sometimes vendoring is used as an alternative approach.