5 ms·

He was basically saying A is an old problem, the new problem is B. However, there's no obvious way to solve B, so we don't solve B. But why not solve A then? U

He was basically saying A is an old problem, the new problem is B. However, there's no obvious way to solve B, so we don't solve B. But why not solve A then? Unless.. A is not a problem anymore nowadays. (Is it, though?) But if A is not a problem anymore, he could have just said struct field ordering was an old problem and not a problem anymore in 2010s, without mentioning the other problem. Meanwhile the blog post suggests that struct field ordering is still a problem even in 2020s.

dllthomas 5y ago
The solution to A will break manual attempts to address B.
- deleted 5y ago
  [deleted]
- masklinn 5y ago
  The solution to A being opt-out makes addressing B not an issue.
  - dllthomas 5y ago
    Yeah, for sure. I didn't mean to imply that it wraps up the whole argument, merely that it was the step in the original reasoning that the parent was missing.
bsuvc 5y ago
If Go tries to automatically solve A, it prevents a developer from solving B because there is no way to control field order. By Go doing nothing, a developer can manually solve both A and B.
- adwn 5y ago
  > By Go doing nothing, a developer can manually solve both A and B. In Rust, you can annotate a struct declaration with "#[repr(C)]" to prevent the compiler from reordering fields. I don't see why the Go compiler couldn't offer something similar.
  - yashap 5y ago
    Go’s philosophy seems to be a very minimal/low-feature language, that’s fairly low level, even if that means somewhat more awkward or mistake-prone code. Go’s current approach seems more Go-y than an annotation like this.
    - masklinn 5y ago
      > Go’s philosophy seems to be a very minimal/low-feature language, that’s fairly low level, even if that means somewhat more awkward or mistake-prone code. And that’s why it tells you to fuck off when you have an unused variable, a non-solution to a non-problem.
      - geodel 5y ago
        Yeah, keeps the code cleaner, no unwanted variable and imports as I have tonnes of these in my Java codebase. One can use IDEs to fix it but I am not gonna generate 1000 files changed PR for this and apparently neither did last 5-6 people who worked this project. Maybe you have not worked in these enterprise type projects where Java/Go is most likely used. In these places anything that is not build failure / compiler error is not an issue to be fixed now or ever.
        masklinn 5y ago
        > Yeah, keeps the code cleaner You may want to take context in account when reading comments, they don’t existing in a blank void. > One can use IDEs to fix it but I am not gonna generate 1000 files changed PR for this and apparently neither did last 5-6 people who worked this project. That really has nothing to do with the subject at hand, and linters exist (in fact for most actual errors go requires a linter because the compiler is so anemic); for projects which are already in the pits, incremental linting is a thing (where linter errors are only a hard CI failure when they’re part of the PR’s diff).
        geodel 5y ago
- cafxx 5y ago
  This is a strawman argument. It presents the two options as mutually incompatible, whereas they are not (as demonstrated by other languages that allow to do both).
- Someone 5y ago
  But if I understand things correctly, go, the spec, doesn’t provide the developer a way to control field order. It’s only the (main) implementation that currently happens to keep field order matching the order in the source code. So, currently, there is no way to force memory layout, other than, as https://github.com/golang/go/issues/10014#issuecomment-263460055 https://github.com/golang/go/issues/10014#issuecomment-26346... says “defining the type using [n]byte and modifying the fields using the encoding/binary package. On many processors the performance will be approximately the same.” Seems unsatisfactory to me.
  - usrbinbash 5y ago
    > But if I understand things correctly, go, the spec, doesn’t provide the developer a way to control field order. The spec doesn't, but the actual compiler implementation does. If the compiler is not allowed to re-order fields, they remain in the order the programmer specified in the code. That's why the fix in the article works in the first place.
    - Someone 5y ago
      But the compiler isn’t “not allowed to re-order fields”. The spec allows it to do that. This fix works for the current compiler, but may not do so for next week’s. Technically you could say it wouldn’t even be a breaking change if a compiler update changed that (practically people would have reason to be angry if they slipped something like that in without creating a major version and adding warning flags to the release notes)

dllthomas 5y ago

The solution to A will break manual attempts to address B.

deleted 5y ago
[deleted]
masklinn 5y ago
The solution to A being opt-out makes addressing B not an issue.
- dllthomas 5y ago
  Yeah, for sure. I didn't mean to imply that it wraps up the whole argument, merely that it was the step in the original reasoning that the parent was missing.

bsuvc 5y ago

If Go tries to automatically solve A, it prevents a developer from solving B because there is no way to control field order. By Go doing nothing, a developer can manually solve both A and B.

adwn 5y ago
> By Go doing nothing, a developer can manually solve both A and B. In Rust, you can annotate a struct declaration with "#[repr(C)]" to prevent the compiler from reordering fields. I don't see why the Go compiler couldn't offer something similar.
- yashap 5y ago
  Go’s philosophy seems to be a very minimal/low-feature language, that’s fairly low level, even if that means somewhat more awkward or mistake-prone code. Go’s current approach seems more Go-y than an annotation like this.
  - masklinn 5y ago
    > Go’s philosophy seems to be a very minimal/low-feature language, that’s fairly low level, even if that means somewhat more awkward or mistake-prone code. And that’s why it tells you to fuck off when you have an unused variable, a non-solution to a non-problem.
    - geodel 5y ago
      Yeah, keeps the code cleaner, no unwanted variable and imports as I have tonnes of these in my Java codebase. One can use IDEs to fix it but I am not gonna generate 1000 files changed PR for this and apparently neither did last 5-6 people who worked this project. Maybe you have not worked in these enterprise type projects where Java/Go is most likely used. In these places anything that is not build failure / compiler error is not an issue to be fixed now or ever.
      - masklinn 5y ago
        > Yeah, keeps the code cleaner You may want to take context in account when reading comments, they don’t existing in a blank void. > One can use IDEs to fix it but I am not gonna generate 1000 files changed PR for this and apparently neither did last 5-6 people who worked this project. That really has nothing to do with the subject at hand, and linters exist (in fact for most actual errors go requires a linter because the compiler is so anemic); for projects which are already in the pits, incremental linting is a thing (where linter errors are only a hard CI failure when they’re part of the PR’s diff).
        geodel 5y ago
cafxx 5y ago
This is a strawman argument. It presents the two options as mutually incompatible, whereas they are not (as demonstrated by other languages that allow to do both).
Someone 5y ago
But if I understand things correctly, go, the spec, doesn’t provide the developer a way to control field order. It’s only the (main) implementation that currently happens to keep field order matching the order in the source code. So, currently, there is no way to force memory layout, other than, as https://github.com/golang/go/issues/10014#issuecomment-263460055 https://github.com/golang/go/issues/10014#issuecomment-26346... says “defining the type using [n]byte and modifying the fields using the encoding/binary package. On many processors the performance will be approximately the same.” Seems unsatisfactory to me.
- usrbinbash 5y ago
  > But if I understand things correctly, go, the spec, doesn’t provide the developer a way to control field order. The spec doesn't, but the actual compiler implementation does. If the compiler is not allowed to re-order fields, they remain in the order the programmer specified in the code. That's why the fix in the article works in the first place.
  - Someone 5y ago
    But the compiler isn’t “not allowed to re-order fields”. The spec allows it to do that. This fix works for the current compiler, but may not do so for next week’s. Technically you could say it wouldn’t even be a breaking change if a compiler update changed that (practically people would have reason to be angry if they slipped something like that in without creating a major version and adding warning flags to the release notes)