3 ms·

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 bec

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.
int_19h 5y ago
What is the advantage of this design? Its disadvantages are quite obvious, but what use case do they buy? It would be a different story if append() always returned a new slice and never updated the original data - then, yes, having to assign is the price you pay for immutability and its benefits (as in e.g. F# or Clojure). But this is not the case here - it's the way it is simply because Go designers didn't see it fit to have a proper abstraction for a dynamically resizable list, and punted it all down to slices (a lower-level abstraction) instead, which the users are then expected to apply in correct order.

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.

int_19h 5y ago

What is the advantage of this design? Its disadvantages are quite obvious, but what use case do they buy? It would be a different story if append() always returned a new slice and never updated the original data - then, yes, having to assign is the price you pay for immutability and its benefits (as in e.g. F# or Clojure). But this is not the case here - it's the way it is simply because Go designers didn't see it fit to have a proper abstraction for a dynamically resizable list, and punted it all down to slices (a lower-level abstraction) instead, which the users are then expected to apply in correct order.