Hacker News Reader

Comment by zero_k | Hacker News Reader

Honestly, I'm very excited about zig. Lean and mean, and it's written by someone who isn't sitting in an ivory tower, not caring about actual usability. It wasn't designed by a team of PhDs (like, e.g. Haskell), while it's clearly inspired by very useful ideas in e.g. Rust, Haskell, etc. I think it'll be very exciting to write code in zig.

View on HN

Similarly excited about Zig. While its memory safety guarantees may not be as comprehensive as Rust's, I hope we'll one day see Zig in the Linux Kernel. I suspect the old-time kernel C programmers may have an easier time with Zig than Rust.

IIRC the zig compiler compiles C. There is some work being done on making zig compile the Linux kernel (I think someone already succeeded).

zig currently uses LLVM but it wants to move away from that:

https://www.reddit.com/r/Zig/comments/18x1wce/is_it_true_tha...

Once zig compiles Linux there are basically 3 compilers that can do so gcc, clang (llvm) and zig (less and less llvm).

I expect there to be good tools to port C code to zig (much hard for C->Rust), especially with the advancements in LLMs lately. I would not be surprised if that would result in a zig-linux code base in the coming 5 years. Sure the C based kernel may be the hot bed for innovation for years to come.

Qurious: will zig still compile C after it moves off LLVM?

Yes, but the LLVM integration will be moved to a package so you only need to include it if you want to do that.

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

> 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-161..., 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.

> 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.

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#_lang...

> 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.

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.

> 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.

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.

> It's not like the Zig compiler will refuse to compile unformatted code, either.

I mean... the use of tabs or LF+CR / CR line endings was a compiler error, last I checked. So, yes, it is exactly like that. And this was a deliberate choice to introduce friction for people who don't hew to the author's stylistic preferences.

> However, once it appeared, it spread through the ecosystem very quickly.

Uh huh, sure, a trendy hipster linter that appeared in 2019 is now so standard that Python code is nigh unthinkable without it. We marvel in the museums at what Python used to look like! There will definitely not be another trendy hipster linter in a couple of years with totally different opinions! :P

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.

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.

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.

I think you misunderstand my objection.

I have no problem with style guides or linters. I have a problem with a compiler that deliberately emits compiler errors on the use of \t, just as an example, because the author likes to throw Lego bricks under your feet if you refuse to obey his stylistic preferences.

I could explain where style guides can become a problem - usually in extremely low level code, emulation, legacy interop, etc. - and therefore need to be relaxed or ignored, but this would divert us onto a discussion of stylistic preferences, and that's not my chief concern here. My concern is the contempt for people's different needs and use cases, including edge cases, which is indicative of immaturity.

> 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.

That's a rather patronising comment. I feel no frustration closing low effort PRs, and I'm honestly somewhat amused by this idea of living in terror of a 'barrage' of "I linted your code for you!"s.

You characterized Zig as "not a language for grown-ups" because it enforces a consistent syntax. I was expressing the opposite opinion. You seem to be objecting to a whole bunch of things that I didn't say. I'm just a guy who likes consistent code formatting and good faith arguments.

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.

You can turn `zig fmt` off in both.

Reply on news.ycombinator.com