3 ms·

> you're left with a mountain of bugs and general technical debt to be addressed Unless you can elaborate more, this is pretty meaningless. I could make the sa

by vlunkr 5y ago

> you're left with a mountain of bugs and general technical debt to be addressed Unless you can elaborate more, this is pretty meaningless. I could make the same statement about Rust or literally any language and it would be just as substantial.

Yoric 5y ago
I haven't done any serious go, so I cannot debate this in depth. However, seen from a distance, it feels like: - people who code in Rust and hate it do so because they keep fighting the borrow checker; - people who code in go and hate it do so because their code is buggy. Now I code regularly in Rust, I enjoy it very much and I very much understand why some people dislike the borrow checker. I prefer Rust but I very much understand why some of these developers may prefer go (or Python, or TypeScript, etc.). On the other hand, I don't code in go (sufficiently) to know whether go is as full of gotchas as developers who hate go make it look.
- lanstin 5y ago
  Given that the data seem to suggest more code is written in Go, perhaps it's just that code is in general buggy and that is a hateful thing, but it means the language isn't getting in the way also.
  - Yoric 5y ago
    > Given that the data seem to suggest more code is written in Go, perhaps it's just that code is in general buggy and that is a hateful thing Maybe? I'm not convinced. If that was the case, I assume that I would have seen someone accusing Rust of shooting them in the foot. Again, while Rust is my current favorite language, I make no claim that Rust is perfect by any metric. > but it means the language isn't getting in the way also. Probably? I don't practice go sufficiently to be a judge of that. I know that the Rust community would definitely assume that the compiler (or at least clippy, the standard linter) should get in the way of anything that is obviously (or not-so-obviously) going to cause a bug sooner or later.
- int_19h 5y ago
  I don't know about full, but when the correct way to add an item to a collection is: slice = append(slice, item) Note that you must have the assignment for this to work correctly. But if you don't, it'll work correctly some of the time - whenever the backing array doesn't have to be reallocated. Now, yes, the linters do catch it. But it's hard for me to consider a language mandating such a pattern as well-designed.
  - philosopher1234 5y ago
    This strikes me as very shallow. I would grant that this is an unusual pattern, but I don't think it follows that the language as a whole is poorly designed because of that. It's simply a different design, not necessarily a worse one.
    - zozbot234 5y ago
      It seems weird enough for a language that's supposed to be "simple" and "easy to learn" in the first place. Note that a lot of the not-so-intuitive complexity in the Rust borrow checker is intended precisely to avoid having code be affected by lower-level details such as storage reallocation.
      - philosopher1234 5y ago
        I agree, it is not the easiest possible api to learn, so perhaps there was a trade off made. Concluding the language is bad because you don’t understand a decision is lazy.
    - Yoric 5y ago
      Well, if a call such as `append(...)` (without the assignment) can either succeed or fail silently depending on side-conditions, this specific example seems to suggest that a developer cannot trust the result of tests. That... doesn't feel me with much confidence in the language (or, well, its stdlib).
      - philosopher1234 5y ago
- vlunkr 5y ago
  > people who code in go and hate it do so because their code is buggy. My experience is that these people hate go because it's less expressive and more repetitive. See `if err != nil` as an example.
  - Yoric 5y ago
    I haven't heard much from these people, but perhaps their anecdotes are simply less funny than bugs in go :)

by vlunkr 5y ago

Yoric 5y ago

I haven't done any serious go, so I cannot debate this in depth. However, seen from a distance, it feels like: - people who code in Rust and hate it do so because they keep fighting the borrow checker; - people who code in go and hate it do so because their code is buggy. Now I code regularly in Rust, I enjoy it very much and I very much understand why some people dislike the borrow checker. I prefer Rust but I very much understand why some of these developers may prefer go (or Python, or TypeScript, etc.). On the other hand, I don't code in go (sufficiently) to know whether go is as full of gotchas as developers who hate go make it look.

lanstin 5y ago
Given that the data seem to suggest more code is written in Go, perhaps it's just that code is in general buggy and that is a hateful thing, but it means the language isn't getting in the way also.
- Yoric 5y ago
  > Given that the data seem to suggest more code is written in Go, perhaps it's just that code is in general buggy and that is a hateful thing Maybe? I'm not convinced. If that was the case, I assume that I would have seen someone accusing Rust of shooting them in the foot. Again, while Rust is my current favorite language, I make no claim that Rust is perfect by any metric. > but it means the language isn't getting in the way also. Probably? I don't practice go sufficiently to be a judge of that. I know that the Rust community would definitely assume that the compiler (or at least clippy, the standard linter) should get in the way of anything that is obviously (or not-so-obviously) going to cause a bug sooner or later.
int_19h 5y ago
I don't know about full, but when the correct way to add an item to a collection is: slice = append(slice, item) Note that you must have the assignment for this to work correctly. But if you don't, it'll work correctly some of the time - whenever the backing array doesn't have to be reallocated. Now, yes, the linters do catch it. But it's hard for me to consider a language mandating such a pattern as well-designed.
- philosopher1234 5y ago
  This strikes me as very shallow. I would grant that this is an unusual pattern, but I don't think it follows that the language as a whole is poorly designed because of that. It's simply a different design, not necessarily a worse one.
  - zozbot234 5y ago
    It seems weird enough for a language that's supposed to be "simple" and "easy to learn" in the first place. Note that a lot of the not-so-intuitive complexity in the Rust borrow checker is intended precisely to avoid having code be affected by lower-level details such as storage reallocation.
    - philosopher1234 5y ago
      I agree, it is not the easiest possible api to learn, so perhaps there was a trade off made. Concluding the language is bad because you don’t understand a decision is lazy.
  - Yoric 5y ago
    Well, if a call such as `append(...)` (without the assignment) can either succeed or fail silently depending on side-conditions, this specific example seems to suggest that a developer cannot trust the result of tests. That... doesn't feel me with much confidence in the language (or, well, its stdlib).
    - philosopher1234 5y ago
vlunkr 5y ago
> people who code in go and hate it do so because their code is buggy. My experience is that these people hate go because it's less expressive and more repetitive. See `if err != nil` as an example.
- Yoric 5y ago
  I haven't heard much from these people, but perhaps their anecdotes are simply less funny than bugs in go :)