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