I have done this as zig makes many breaking changes often, not because new features come out all the time (almost all of the things showcased on the site if not all were around back in 0.6). I do not want to teach people things that are already for the most part outdated. Things move very fast, especially in the standard library.

edit: to clarify I am the maintainer/owner of ziglearn

nod From my other replies, it would be of assistance to state that this on the guide right at the Install section, as I did have a choice which zig to use and chose the simple package from my repo given no further direction. (BTW: could you explain why I should install ZLS in step 4? Since we're here.. :) )

With a line of text that I must use the latest dev/git code (etc.), my choice would have then gone the other direction to just download a binary. The number of websites which "just download a binary" when a suitable package is already available in the repo are a very high number (for Arch), so this thought process is standard for a guy like me.

I pushed some changes to reflect this

Nice, thanks. The description added to (4) in the Install clears up what that's for nicely (along with the primary changes, very clear).

I think most people actively involved in the community are compiling Zig from master branch or downloading the nightly builds. Zig releases are tied to LLVM so there's usually 6 months between releases, which is way too much time to stay without new features, given the speed of improvement of the language.

I think yours is a fair point, but that's how things are. If you prefer using a tagged version and not have to be too involved in the latest developments of Zig, please consider waiting until 0.8.0 at the very least.

The site specifically instructs you to visit the releases page which only offers 0.6.0

This is just not true, the master build is literally the first thing you see on the download page.

Don't get me wrong, it should be clarified on the ziglearn website anyway.

>This is just not true, the master build is literally the first thing you see on the download page.

"Literally the first thing" that I see on the download page is:

>Releases

>You can also [install Zig from a package manager.](https://github.com/ziglang/zig/wiki/Install-Zig-from-a-Packa...)

Going by the AUR package script and the table in the wiki itself, those instructions will install 0.6.0. This is also what gravitas said in the OP of this thread.

Anyway, I see ziglearn.org has now been fixed to make it clear, with https://github.com/Sobeston/ziglearn/commit/10b14426e26ffcdb... , so all's well now.

I knew we should have added a <blink> tag

Note that tagged releases in zig are just "the first state that worked with the new LLVM version".

Imho it would be unreasonable to even try keeping backwards compatibility in a language that tries to find the global maximum

> but geez this is a Hello, World sample that fails This is because the 0.7.0 release cycle changed a lot about logging: std.debug.warn was used as a general purpose log function in 0.6, but is now deprecated to move people to use the std.log namespace now

> It'd be nice if your getting started guide only used features from the tagged latest version at least...

The problem here is that package manager maintainers only package tagged versions which isn't really a good thing for zig. Your version is kinda outdated as soon as you downloaded it. Most projects won't break anymore on a daily basis, but there is still changes, bug fixes and additions.

I'm currently waiting for some PRs to be merged, so i can continue my own projects. You won't get this when sticking to tagged releases (and it will make updating your projects way more painful than keeping them up-to-date on a daily basis)

But yeah, ziglearn could note that using a tagged version has these problems and that zig is moving so fast that sticking to a tagged version will yield outdated code very quickly

> Imho it would be unreasonable to even try keeping backwards compatibility in a language that tries to find the global maximum

What does this mean? I can't think of any way to interpret "find the global maximum" that applies to Zig but not other languages.

Similarly, I rolled back to the official docs from Master and the hello.zig from there is similarly nonop using the tagged 0.6.0 build: https://ziglang.org/documentation/master/

Please, please - make a Hello, World which is not so intrinsically tied to random features on Master to just work across all the iterations. Hello, World is supposed to be the simplest, non-breaking easy to compile no esoteric compiler feature thing in any programming language in the world.

My friend Jeff Fowler wrote an excellent blog post diving deep, deep into this topic.

https://blog.jfo.click/hello-hello-world/

Use std.debug.warn and you'll be fine with 0.6.0 and master. Right now there's no strict and methodical update path from one version to the next, but generally speaking changes to the language get special-cased into zig fmt.

For example the current `anytype` type has replaced `var` and running zig fmt on a project I hadn't updated yet changed all references.

That said, Hello World, when taken seriously, it's not that simple of a program and I'm working on a talk for Zig SHOWTIME[1] about it, titled "Advanced Hello World in Zig".

The TLDR is that Zig never had an easy builtin print function because it's important to let the programmer be precise about whether they want locking (or not) or buffering (or not). That's why the easy print function is in the debug namespace.

[1] https://zig.show

Thank you (for both replies) and to everyone else, this makes it crystal clear what's going on - there's a lack of "hey everyone, this is very unstable at the moment and the basic internals are changing, using anything except the latest Github builds is highly discouraged" which might really help when added to the various places above.

I'm a toe-dipper -- I need to run and play with some sample code (basic Hello, World stuff) to see if I like the ergonomics and wish to continue looking deeper, when an article is posted on HN and piques my interest to go try out (zig) the easy route is taken - install what Arch has as the latest and just test it out with the basics. ("The learn guide says I must have 4 spaces, what if I use 2? yeah OK that still works")

I think your point was fair and your approach is just as well. The reality is that we don't have a gigantic amount of resources right now. We don't have Google or Mozzilla backing the project, so most information out there is contributed by community members on their free time.

Take a look at other content by Andrew (https://andrewkelley.me) or from Zig SHOWTIME if you want to lazily evaluate Zig :)

For a while there was a link to TIO (tio.run) on the zig homepage where you could play with it online. But for some reason it has been removed.

The version that tio has is very old at this point. Godbolt stays up to date.

There wasn't any incentive to update it once Zig removed it from the homepage.

This comment breaks the site guidelines. Please don't cross into personal attack in comments here, or generally be unkind or snarky.

If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and sticking to the rules when posting here, we'd be grateful.

This reply is rude and uncalled for, you created an account 28 minutes ago just to act like a condescending jerk?

    $ pacman -Q | awk '{print $2}' | egrep "^0\." -c
    257

> it's important to let the programmer be precise about whether they want locking (or not) or buffering (or not)

Or whether the function accepts naked types as parameters or error unions!

The debug namespace is indeed the right place for a wholly generic print. The first day I took Zig out for a spin, std.debug.warn briefly confused me by eating errors and printing their name instead of (as I expected for a short minute) giving a runtime error.

This is a good design decision for the debug namespace, but you don't want a regular call to print() to take an unwrapped error without complaint!

Reminds me of Bjarne Strostrup's old article on learning c++ as a new language - and how a simple program in c isn't that much simpler when you start to poke at the details:

https://www.drdobbs.com/learning-standard-c-as-a-new-languag...

https://stroustrup.com/new_learning.pdf

Hi, I don't necessarily disagree with you, however master builds are available for download for tier 1 targets on zig's website.

The ziglearn website explicitly points to the website for this reason, although I agree it should probably include some warning about using the latest tagged release and how some of the tests will break.

The fact that debug.warn was renamed to debug.print during this release cycle makes this extra unfortunate, since it affects the hello world program.

Anyway, thanks for pointing this out, I will make sure to PR ziglearn to clarify this.

Ouch, my first foray into Zig several months to a year ago also ended when my compilation of a copy-pasted version of the very first Hello, World code sample failed. (Copy-pasting of the second example did work, but still) Sad to see this hasn't changed in so long. Good documentation, especially for just starting out, is crucial for language uptake.

Zig purposely does not parse carriage returns or tabs. When this is brought up, people tell you to use a separate program to format it before compiling and don't seem to acknowledge that this is not a problem with any other language.

The result is that by default you get errors on windows with hello world programs. People will tell you to just change your defaults in your text editor to not write carriage returns. There seems to be a lot of rationalizations from a very unpragmatic choice.

> When this is brought up, people [...] don't seem to acknowledge that this is not a problem with any other language.

This was a deliberate design decision by andrew for all zig pre-1.0 to supress discussions about coding style (use CR, LF, CRLF, LFCR as a line ending? tabs vs. spaces? ...) as it's considered bike shedding

Zig 1.0 won't have this restrictions anymore. More information can be found here:

https://github.com/ziglang/zig/wiki/FAQ#why-does-zig-force-m... https://github.com/ziglang/zig/issues/544

Why not do that with a formatting tool that applies to the compiler source instead of purposely breaking hello world on windows?

Same answer as to why you don't configure your text editor to just not emit useless and outdated CR from past century - he has better things to do. And no, really, check out Zig repo's issue tab, he really has better things to do with his time on a project that's still evolving.

You're demanding 1.0+ usability from a language that's has yet to stand up on its own feet and is currently, unsurprisingly, 0.6.0 and won't be 1.0 any time soon because there's a massive amount of work that needs to be done.

This also isn't C and it wasn't developed/maintained for past 50 years.

Ignoring two different ascii bytes is not "1.0+ usability". The idea that it is a matter of work is an insane rationalization. Someone else said it is to prevent 'bike shedding'.

None of the backwards rationalizations people give actually makes sense, especially since it literally breaks any "hello world" program on windows. It's insane that people would try so hard to make excuses for such a basic disregard for new people.

Think about the reverse. Let's say tabs are treated as spaces and carriage return bytes are ignored. Who would ever argue that something should be changed to break these things?

I don't know how repl.it chooses the languages it supports, but it would be great if zig could get on that so there could be a zero-download way to get started in the language.

https://godbolt.org/ hosts zig, try zig trunk.

Wow, I've never seen this site before but it looks amazing and I can't wait to play around with it. Thank you!

All your comments are toxicity-laced. Calm down, my dude.