6 ms·

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 c

by 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
      > You may want to take context in account when reading comments, they don’t existing in a blank void. Agree. But you do not have to ever understand others point of view because your opinion is a fact and absolute must on any programing language design.
xh-dude 5y ago
Yeah - the tradeoff isn’t about the benefits in places where macros would solve problems, but the problem of having macros. It’s an opinion.
- previx 5y ago
  An annotation in Rust isn't a macro. The Go equivalent would be a directive in a comment. For example: //go:repr c https://pkg.go.dev/cmd/compile#hdr-Compiler_Directives https://pkg.go.dev/cmd/compile#hdr-Compiler_Directives
  - xh-dude 5y ago
    Is the situation for Rust different than as described here: https://github.com/rust-lang/rfcs/pull/208 https://github.com/rust-lang/rfcs/pull/208 “Currently, attributes and macros/syntax extensions are both conceptually macros: they are user-definable syntactic extensions that transform token trees to token trees.” FWIW I definitely admit the point about Go compiler directives sort of cheating into this space a bit - I see them used responsibly for the most part but it’s a valid point. (Go’s struct tags OTOH, are an escape hatch I revile…).
    - adwn 5y ago
      > Is the situation for Rust different than as described here: https://github.com/rust-lang/rfcs/pull/208 https://github.com/rust-lang/rfcs/pull/208 In short: yes. The wording in that quote is imprecise: I suspect that by 'attributes', pcwalton was referring to user-definable attributes like #[serde(rename_all = "...")] and to custom derive macros like #[derive(Serializable)]. It is impossible to achieve the effects of the #[repr(C)] attribute using macros or token tree transformations.
    - previx 5y ago
      If you're asking if macros and attributes are interchangeable terms, no they're not.
adwn 5y ago
> very minimal/low-feature language, that’s fairly low level, even if that means somewhat more awkward or mistake-prone code Do you think this is a good trade-off? If you're using a tool every day or at least regularly, the one-time cost of mastering a slightly more complex tool is amortized over all uses of that tool.
- rob74 5y ago
  You may be using the tool every day, but are you using this "disable field reordering" annotation every day? Also, after you used it, you may remember what "#[repr(C)]" does, but I bet most of the other developers working with the code in the future will have to look it up (unless you leave a comment). So the trade-off is not as cheap as you think...
  - adwn 5y ago
- yashap 5y ago
  I didn’t pass any judgement on whether it’s a good or bad tradeoff, just that it’s in-line with Go’s general approach to language design.

by yashap 5y ago

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
    > You may want to take context in account when reading comments, they don’t existing in a blank void. Agree. But you do not have to ever understand others point of view because your opinion is a fact and absolute must on any programing language design.

xh-dude 5y ago

Yeah - the tradeoff isn’t about the benefits in places where macros would solve problems, but the problem of having macros. It’s an opinion.

previx 5y ago
An annotation in Rust isn't a macro. The Go equivalent would be a directive in a comment. For example: //go:repr c https://pkg.go.dev/cmd/compile#hdr-Compiler_Directives https://pkg.go.dev/cmd/compile#hdr-Compiler_Directives
- xh-dude 5y ago
  Is the situation for Rust different than as described here: https://github.com/rust-lang/rfcs/pull/208 https://github.com/rust-lang/rfcs/pull/208 “Currently, attributes and macros/syntax extensions are both conceptually macros: they are user-definable syntactic extensions that transform token trees to token trees.” FWIW I definitely admit the point about Go compiler directives sort of cheating into this space a bit - I see them used responsibly for the most part but it’s a valid point. (Go’s struct tags OTOH, are an escape hatch I revile…).
  - adwn 5y ago
    > Is the situation for Rust different than as described here: https://github.com/rust-lang/rfcs/pull/208 https://github.com/rust-lang/rfcs/pull/208 In short: yes. The wording in that quote is imprecise: I suspect that by 'attributes', pcwalton was referring to user-definable attributes like #[serde(rename_all = "...")] and to custom derive macros like #[derive(Serializable)]. It is impossible to achieve the effects of the #[repr(C)] attribute using macros or token tree transformations.
  - previx 5y ago
    If you're asking if macros and attributes are interchangeable terms, no they're not.

adwn 5y ago

> very minimal/low-feature language, that’s fairly low level, even if that means somewhat more awkward or mistake-prone code Do you think this is a good trade-off? If you're using a tool every day or at least regularly, the one-time cost of mastering a slightly more complex tool is amortized over all uses of that tool.

rob74 5y ago
You may be using the tool every day, but are you using this "disable field reordering" annotation every day? Also, after you used it, you may remember what "#[repr(C)]" does, but I bet most of the other developers working with the code in the future will have to look it up (unless you leave a comment). So the trade-off is not as cheap as you think...
- adwn 5y ago
yashap 5y ago
I didn’t pass any judgement on whether it’s a good or bad tradeoff, just that it’s in-line with Go’s general approach to language design.