It's been amazing following all the progress so far. I'm a proud $5/mo sponsor and look forward to writing something in Zig soon!

Are there any concurrency constructs provided by the language yet? I'm just starting to learn how to do concurrency in lower-level langauges (with mutexes and spinlocks and stuff). I'm coming from the world of Python where my experience with concurrent state is limited to simple row-level locks and `with transaction.atomic():`.

An equivalent article to this would be awesome for Zig: https://begriffs.com/posts/2020-03-23-concurrent-programming...

Edit: I just found this announcement for async function support: https://ziglang.org/download/0.5.0/release-notes.html#Async-...

Yes! Here's a repository where I show some comparisons with Go: https://github.com/andrewrk/zig-async-demo/

This area is still bleeding-edge experimental, but it's very promising.

I need to do a blog post on how async/await works in zig and event-based I/O. It's been a long time coming.

Thanks for all your effort on the project. By far my best experience with zig was writing an OpenGL renderer on windows which then “just worked” when I cloned it ran `zig build` on my Linux machine. Felt like magic.

It is amazing work, I'm so glad you invested your attention in this direction, kudos! I haven't used the language and the compiler yet but just reading the title article I almost jumped from joy, knowing how unexpectedly painful is to target different versions of system libraries on Linux.

I was happily supporting Zig/you at $5/month, but things got tight. I will be back on board next month! Keep up the great work Andy!

Hi Andy, thanks for your hard work on this. I am not a Zig user/sponsor yet but hopefully I will be soon. It's looking better and better every month.

Hijacking your comment to ask a question: how hard is it to add support for a new architecture and/or triple (if I already have support in llvm)?

Grand bootstrapping plan [1] sounds really impressive but still WIP? Is there a commit or series of commits showing recent targets that got support?

[1] https://github.com/ziglang/zig/issues/853

For the 0.60 release, could you please provide a download for Raspberry Pi running Raspbian?

On my RPi 4, 'uname -m -o' returns: armv7l GNU/Linux

Thanks!

This project invites donations. It is labor of love and solves problems that have been around a long time. Kudos!

Why does zig purposely fail on windows text files by default? Do you really expect a language to catch on when you are purposely alienating windows users by refusing to parse \r for some bizarre reason?

And here I was just amazed from the blog post at the Windows support in cross compilation in either direction.

I find it hard to believe that someone could be capable of writing a non-trivial program but not able to change their text editor settings to use \n.

Every compiler handles it fine, I just can't wrap my head around why someone would intentionally cripple their software to alienate the vast majority of their potential users. I understand the problem and how to solve it, but it's such a giant red flag there is no way I'll care about this language. Most people probably don't actually understand why it fails and why a simple hello world program fails.

I'm floored that so many people would ignore this barrier to entry and somehow rationalize such a ridiculous design choice. If you make things straight up break for all windows users by default in your new language, it's going nowhere. No rationalization or excuses will change that reality.

Among programmers, distinction between CRLF and LF is known. Among non-programmers, you may well see people who will try to write code in WordPad, and that doesn't mean compilera should parse WordPad documents as source files. Do you expect people to write code in Notepad? If not, any reasonable programmer's editor supports Unix EOLs. Guide them to use Notepad++ or VSCode with proper options/plugins, case closed. Otherwise, you may as well complain about handling of mixed tabs & spaces in Python, or the fact that C requires semicolons.

Defaults cause zig to error out. This isn't that hard to understand or fix. It isn't even clear when it happens because it's just not something that any other compiler would error on. It isn't about being able to fix it, it about creating an assanine hurdle for anyone trying the language for the first time in windows. No other compiler or scripting language makes someone jump through that hoop. It is completely ridiculous. I still can not believe anyone would defend this decision. Do you want people to use it or not?

I have no issue with that decision at all and find it akin to Go forcing users to adhere to gofmt, and I don't use Zig. A good error message would be nice (EDIT: A zigfmt would be even better).

How many developers who try out new languages are even using Windows? I'd imagine most are on a UNIX-like. Regardless, I don't think it's a big deal either way. You could always make a merge request with a fix if you feel so strongly about it.

Ok. So I'm currently writing something that parses zig code and explicitly not having to worry about \r is a godsend.

To be clear, not needing to ignore a single character is somehow a 'godsend'?

Also tabs. I eventually discovered how to use parser combinators, but I would have made it more frustrating to get started and I'm somewhat conscientious the cognitive burden of these sorts of things can get overwhelming, especially for a project I'm not getting paid for.

Does zig error out on tabs too?

Why not just put this in the compiler like every other compiler in existence?