4 ms·

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 beca

by 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
      This is again just too shallow. I suggest you investigate the reasons why it was designed this way before deciding it is bad.
      - Yoric 5y ago
        I'm certain that there is a valid reason. Nevertheless, it feels like a footgun and that footgun will find itself embedded somewhere deep in code I didn't write. If it can explode in my face despite careful testing, I'm not really happy about that perspective. I'm sure that there is a tradeoff somewhere and that you gain something by allowing this in the library. But I'm strongly on the side of developers for whom reliability has a very high priority.
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 Yoric 5y ago

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
    This is again just too shallow. I suggest you investigate the reasons why it was designed this way before deciding it is bad.
    - Yoric 5y ago
      I'm certain that there is a valid reason. Nevertheless, it feels like a footgun and that footgun will find itself embedded somewhere deep in code I didn't write. If it can explode in my face despite careful testing, I'm not really happy about that perspective. I'm sure that there is a tradeoff somewhere and that you gain something by allowing this in the library. But I'm strongly on the side of developers for whom reliability has a very high priority.

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 :)