4 ms·

I'm willing to cop the slack from the Zig brigade for this take, but I'll get excited for Zig again when I'm allowed to turn `zig fmt` off in e.g. vim or VS Cod

by troad 2y ago

I'm willing to cop the slack from the Zig brigade for this take, but I'll get excited for Zig again when I'm allowed to turn `zig fmt` off in e.g. vim or VS Code. It leaves me with a sour taste in my mouth when stylistic preferences are made mandatory; it is disrespectful of the coders for whom the language is a tool. It can also be a canary for deeper issues around community engagement and openness to different viewpoints (a problem for Zig, e.g. [0]). A business with code uniformity requirements is more than capable of running a linter, and for my weekend projects, I don't give one toss about anyone's stylistic preferences but my own. Either Zig is a language for grown-ups, or it isn't. And if I'm going to be forced to code a certain way, why not just use Rust and get free memory safety out of it too? [0] https://github.com/ziglang/zig/issues/16270 https://github.com/ziglang/zig/issues/16270

hiccuphippo 2y ago
You can turn `zig fmt` off in both.
cornstalks 2y ago
> I'll get excited for Zig again when I'm allowed to turn `zig fmt` off in e.g. vim or VS Code. But you can turn it off, can't you? > deeper issues around community engagement and openness to different viewpoints (a problem for Zig, e.g. [0]). Two things: 1. People who link that issue often forget about Andrew's comments (https://github.com/ziglang/zig/issues/16270#issuecomment-1615388680 https://github.com/ziglang/zig/issues/16270#issuecomment-161..., https://github.com/ziglang/zig/issues/16270#issuecomment-1616115039 https://github.com/ziglang/zig/issues/16270#issuecomment-161..., example: "I'm not going to simultaneously shoot myself and valuable community members in the face by yanking a load-bearing feature out from underneath us, without any kind of upgrade path."). I can understand some people disagreeing but it's not that big of an issue. 2. Personally I'm happy Zig has a BDFL. Even though that #16270 issue has some controversy, it's clear Zig has a consistent direction and goal. It's not design-by-committee and doesn't get stalled for years on the tiniest of issues while the community bikesheds for eternity.
- troad 2y ago
  > But you can turn it off, can't you? Can I? How? There is no setting I can see in e.g. VS Code to disable format-on-save. (Not trying to sound snarky here, I'm legitimately open to advice on this.) > it's clear Zig has a consistent direction and goal. It's not design-by-committee and doesn't get stalled for years on the tiniest of issues while the community bikesheds for eternity. Anyone can have direction. 'There, towards the copse of stinging nettles!' The tricky part is figuring out a good direction, which sometimes requires pauses and stakeholder engagement. You know, that thing that the 'move fast and break things' crowd loves to deride as 'bikeshedding'. :) In as far as Zig's direction appears to be 'we will rewrite LLVM, but better-er!', I do worry. I'd hate for Zig to end up like Elm.
  - cornstalks 2y ago
    editor.formatOnSave will control it for all files. You can also use editor.defaultFormatter to change which formatter is used. You can set these for all languages or for specific languages[1]. Regarding competing with LLVM: I'm happy to see others try. Cranelift is a nice example of finding a niche that LLVM isn't filling, and I'm glad people didn't prematurely give up simply because LLVM already exists. Zig's goal is definitely ambitious, and there are risks. But in principle I'm happy to see someone pursuing these lofty goals because that's what ultimately creates incremental progress in the industry. If Zig fails... well, I'd still be happy they at least tried. [1]: https://code.visualstudio.com/docs/getstarted/settings#_language-specific-editor-settings https://code.visualstudio.com/docs/getstarted/settings#_lang...
    - troad 2y ago
      > editor.formatOnSave will control it for all files. You can also use editor.defaultFormatter to change which formatter is used. You can set these for all languages or for specific languages[1]. Ah, I see. The Zig module silently overrides the user's editor.formatOnSave setting by default; this is what I was missing. I need to specifically override Zig's override: "[zig]": { "editor.formatOnSave": false }, Thank you! > Regarding competing with LLVM In theory, I have no problem with this either, but in practice, this is a big gamble for Zig as a whole. A language lives and dies on perceptions, and currently Zig's killer feature is that it is an easy slot-in incremental replacement for existing C/C++ codebases. This plan intends to break that by default. (I realise AK has walked that back somewhat, it will remain an option, etc - but considering this whole thread is people telling me formatting must be strictly mandated, surely you'll grant the power of defaults and the risk in breaking them.) Ultimately, I am open to being proven wrong, but I've seen some of the same patterns in Zig that have broken other newlangs. Killer features that go under-appreciated by the leadership, a focus on purity at the expense of practicality, 'trust the plan', etc. My fear would be that the hype tide will go out, as it always does, and Zig will be left without any obvious niche, somewhere mid-LLVM-rewrite. But hey, we'll see. I wish AK the best of luck with it.
int_19h 2y ago
The primary justification for "you can have any color as long as it's black" approach to coding style & formatting is precisely that the language is a tool, not an art project. Having a single standard well-defined style does wonders to prevent bikeshedding when teams adopt the tool, which is why this approach is increasingly popular (e.g. Black in Python). And I don't think you can meaningfully compare this to constraints imposed by Rust, which aren't about where to place a curly brace etc, but about not being able to (easily) model some data structures and algorithms. You could argue that both represent a form of tax on your freedom as a developer, but even if so, it's an orders of magnitude difference.
- troad 2y ago
  > The primary justification for "you can have any color as long as it's black" approach to coding style & formatting is precisely that the language is a tool, not an art project. Having a single standard well-defined style does wonders to prevent bikeshedding when teams adopt the tool, which is why this approach is increasingly popular (e.g. Black in Python). I have no problem with standards. There are times where standards are useful. The thing about standards is that they can also be ignored where appropriate. It's notable no one is seriously pushing for Black to be made mandatory for Python, for extremely obvious and sensible reasons. Also, 'increasingly popular' is doing some heavily lifting in that argument. The vast, vast, vast (vast!) majority of Python code will never ever use Black, and that is fine. A language, as we agree, is a tool, and it is a poor tool indeed that refuses to lend itself for use in creative ways. > And I don't think you can meaningfully compare this to constraints imposed by Rust, which aren't about where to place a curly brace etc, but about not being able to (easily) model some data structures and algorithms. You could argue that both represent a form of tax on your freedom as a developer, but even if so, it's an orders of magnitude difference. Very different - Rust's constraints actually serve a purpose beyond merely enforcing stylistic conformity. If I am to take on the added cognitive load of coding a certain way, I might as well actually get something out of it.
  - int_19h 2y ago
    It's not like the Zig compiler will refuse to compile unformatted code, either. And the vast majority of Python code was written before Black was a thing. However, once it appeared, it spread through the ecosystem very quickly. At this point I wouldn't be surprised if most people using Black don't even know that they do so simply because they write their Python in VSCode, which suggests Black (and will install it for you) if you try to do Format Document or enable format-on-save.
allknowingfrog 2y ago
In my experience, grown-ups appreciate the reduction in cognitive overhead that a consistent syntax introduces. You're welcome to decide that Zig isn't for you, but characterizing the project as "disrespectful" and immature seems extreme.
- troad 2y ago
  You're implying I'm not a grown up, but characterising a language created in 2016 - current version zero point something something - as immature is 'extreme' to you? C'mon now. Zig is immature. That's not some conclusive judgment against its utility now and forever, it is simply a function of the amount of times the Earth has orbited the Sun since its creation. Given how Zig is positioning itself vis-a-vis C, Rust, etc., it is somewhat baffling to me how little respect it seems to have for the opinions and capabilities of its end users. People who want their hands held have better choices than Zig, and people who want the freedom to code how they wish... also have better choices than Zig. I think Zig is onto something, but hype cycles always fade, and if Zig hasn't matured by that point, there won't be any obvious niche for it to occupy.
  - rc00 2y ago
    Formatting is a very weird thing to get hung up on, particularly when a language like Go is reaching mainstream (if it already isn't there). It's fine not to like the chosen formatting or the decisions made upstream but that comes with the territory. It just means that languages like Go, Zig, and others following this trend are probably not for you and that's okay. > how little respect it seems to have for the opinions and capabilities of its end users I think you misunderstand the objective here. As I understand it, it means that all code written in the language looks the same. This significantly improves readability and as we all (should) know, code is read much more than it is written. It's not about deducing the capabilities of the end users but more about reducing the cognitive load while having to read or write in the language itself. If you still decide to write in one of these formatting-defined languages, it would probably be best to keep the repository and/or project private to avoid the barrage of "ran fmt on the code" pull requests sure to crop up. It would save all parties from a lot of frustration.
bbkane 2y ago
Coming from Python, and now mostly developing in Go, the uniform style in Go has really helped me familiarize myself with new codebases, especially in contrast with Python's variety of styles.

by troad 2y ago

hiccuphippo 2y ago

You can turn `zig fmt` off in both.

cornstalks 2y ago

> I'll get excited for Zig again when I'm allowed to turn `zig fmt` off in e.g. vim or VS Code. But you can turn it off, can't you? > deeper issues around community engagement and openness to different viewpoints (a problem for Zig, e.g. [0]). Two things: 1. People who link that issue often forget about Andrew's comments (https://github.com/ziglang/zig/issues/16270#issuecomment-1615388680 https://github.com/ziglang/zig/issues/16270#issuecomment-161..., https://github.com/ziglang/zig/issues/16270#issuecomment-1616115039 https://github.com/ziglang/zig/issues/16270#issuecomment-161..., example: "I'm not going to simultaneously shoot myself and valuable community members in the face by yanking a load-bearing feature out from underneath us, without any kind of upgrade path."). I can understand some people disagreeing but it's not that big of an issue. 2. Personally I'm happy Zig has a BDFL. Even though that #16270 issue has some controversy, it's clear Zig has a consistent direction and goal. It's not design-by-committee and doesn't get stalled for years on the tiniest of issues while the community bikesheds for eternity.

troad 2y ago
> But you can turn it off, can't you? Can I? How? There is no setting I can see in e.g. VS Code to disable format-on-save. (Not trying to sound snarky here, I'm legitimately open to advice on this.) > it's clear Zig has a consistent direction and goal. It's not design-by-committee and doesn't get stalled for years on the tiniest of issues while the community bikesheds for eternity. Anyone can have direction. 'There, towards the copse of stinging nettles!' The tricky part is figuring out a good direction, which sometimes requires pauses and stakeholder engagement. You know, that thing that the 'move fast and break things' crowd loves to deride as 'bikeshedding'. :) In as far as Zig's direction appears to be 'we will rewrite LLVM, but better-er!', I do worry. I'd hate for Zig to end up like Elm.
- cornstalks 2y ago
  editor.formatOnSave will control it for all files. You can also use editor.defaultFormatter to change which formatter is used. You can set these for all languages or for specific languages[1]. Regarding competing with LLVM: I'm happy to see others try. Cranelift is a nice example of finding a niche that LLVM isn't filling, and I'm glad people didn't prematurely give up simply because LLVM already exists. Zig's goal is definitely ambitious, and there are risks. But in principle I'm happy to see someone pursuing these lofty goals because that's what ultimately creates incremental progress in the industry. If Zig fails... well, I'd still be happy they at least tried. [1]: https://code.visualstudio.com/docs/getstarted/settings#_language-specific-editor-settings https://code.visualstudio.com/docs/getstarted/settings#_lang...
  - troad 2y ago
    > editor.formatOnSave will control it for all files. You can also use editor.defaultFormatter to change which formatter is used. You can set these for all languages or for specific languages[1]. Ah, I see. The Zig module silently overrides the user's editor.formatOnSave setting by default; this is what I was missing. I need to specifically override Zig's override: "[zig]": { "editor.formatOnSave": false }, Thank you! > Regarding competing with LLVM In theory, I have no problem with this either, but in practice, this is a big gamble for Zig as a whole. A language lives and dies on perceptions, and currently Zig's killer feature is that it is an easy slot-in incremental replacement for existing C/C++ codebases. This plan intends to break that by default. (I realise AK has walked that back somewhat, it will remain an option, etc - but considering this whole thread is people telling me formatting must be strictly mandated, surely you'll grant the power of defaults and the risk in breaking them.) Ultimately, I am open to being proven wrong, but I've seen some of the same patterns in Zig that have broken other newlangs. Killer features that go under-appreciated by the leadership, a focus on purity at the expense of practicality, 'trust the plan', etc. My fear would be that the hype tide will go out, as it always does, and Zig will be left without any obvious niche, somewhere mid-LLVM-rewrite. But hey, we'll see. I wish AK the best of luck with it.

int_19h 2y ago

The primary justification for "you can have any color as long as it's black" approach to coding style & formatting is precisely that the language is a tool, not an art project. Having a single standard well-defined style does wonders to prevent bikeshedding when teams adopt the tool, which is why this approach is increasingly popular (e.g. Black in Python). And I don't think you can meaningfully compare this to constraints imposed by Rust, which aren't about where to place a curly brace etc, but about not being able to (easily) model some data structures and algorithms. You could argue that both represent a form of tax on your freedom as a developer, but even if so, it's an orders of magnitude difference.

troad 2y ago
> The primary justification for "you can have any color as long as it's black" approach to coding style & formatting is precisely that the language is a tool, not an art project. Having a single standard well-defined style does wonders to prevent bikeshedding when teams adopt the tool, which is why this approach is increasingly popular (e.g. Black in Python). I have no problem with standards. There are times where standards are useful. The thing about standards is that they can also be ignored where appropriate. It's notable no one is seriously pushing for Black to be made mandatory for Python, for extremely obvious and sensible reasons. Also, 'increasingly popular' is doing some heavily lifting in that argument. The vast, vast, vast (vast!) majority of Python code will never ever use Black, and that is fine. A language, as we agree, is a tool, and it is a poor tool indeed that refuses to lend itself for use in creative ways. > And I don't think you can meaningfully compare this to constraints imposed by Rust, which aren't about where to place a curly brace etc, but about not being able to (easily) model some data structures and algorithms. You could argue that both represent a form of tax on your freedom as a developer, but even if so, it's an orders of magnitude difference. Very different - Rust's constraints actually serve a purpose beyond merely enforcing stylistic conformity. If I am to take on the added cognitive load of coding a certain way, I might as well actually get something out of it.
- int_19h 2y ago
  It's not like the Zig compiler will refuse to compile unformatted code, either. And the vast majority of Python code was written before Black was a thing. However, once it appeared, it spread through the ecosystem very quickly. At this point I wouldn't be surprised if most people using Black don't even know that they do so simply because they write their Python in VSCode, which suggests Black (and will install it for you) if you try to do Format Document or enable format-on-save.

allknowingfrog 2y ago

In my experience, grown-ups appreciate the reduction in cognitive overhead that a consistent syntax introduces. You're welcome to decide that Zig isn't for you, but characterizing the project as "disrespectful" and immature seems extreme.

troad 2y ago
You're implying I'm not a grown up, but characterising a language created in 2016 - current version zero point something something - as immature is 'extreme' to you? C'mon now. Zig is immature. That's not some conclusive judgment against its utility now and forever, it is simply a function of the amount of times the Earth has orbited the Sun since its creation. Given how Zig is positioning itself vis-a-vis C, Rust, etc., it is somewhat baffling to me how little respect it seems to have for the opinions and capabilities of its end users. People who want their hands held have better choices than Zig, and people who want the freedom to code how they wish... also have better choices than Zig. I think Zig is onto something, but hype cycles always fade, and if Zig hasn't matured by that point, there won't be any obvious niche for it to occupy.
- rc00 2y ago
  Formatting is a very weird thing to get hung up on, particularly when a language like Go is reaching mainstream (if it already isn't there). It's fine not to like the chosen formatting or the decisions made upstream but that comes with the territory. It just means that languages like Go, Zig, and others following this trend are probably not for you and that's okay. > how little respect it seems to have for the opinions and capabilities of its end users I think you misunderstand the objective here. As I understand it, it means that all code written in the language looks the same. This significantly improves readability and as we all (should) know, code is read much more than it is written. It's not about deducing the capabilities of the end users but more about reducing the cognitive load while having to read or write in the language itself. If you still decide to write in one of these formatting-defined languages, it would probably be best to keep the repository and/or project private to avoid the barrage of "ran fmt on the code" pull requests sure to crop up. It would save all parties from a lot of frustration.

bbkane 2y ago

Coming from Python, and now mostly developing in Go, the uniform style in Go has really helped me familiarize myself with new codebases, especially in contrast with Python's variety of styles.