> Our philanthropy is generally private, but I'm making an exception since I think my public support of Zig has a chance to really help the project due to my background.
I can't quite put words to it, but this statement kind of struck me. There's just a certain basic decency behind it that deserves celebrating.
Same here... except maybe in the opposite direction?
Does it implies that their other philanthropy would not benefit from more public support? So what are they in this case?
Anyway, they do whatever they want with their philanthropy in the end, but I found that was an odd phrasing.
A lot of people use philanthropy as a means to ego boost and raise their public image. This is a phenomenon as old as time, to the point where even the bible has tales about it. The (modern?) countermovement to that is to keep your donations secret, often to the point where it's one of the strings attached to the money, that you can't publicly disclose who made the donation. This is a way to support a cause just for the sake of supporting it. I read the above statement as them usually following this ethos, but making an exception this time around since they believe being public about it will bring more visibility to the cause.
perhaps his other philanthropy donations are not technical and he believes that supporting them publicly would feel like bragging and he personally doesn't like that?
Sorry if this is a silly question, i am a web developer so I dont usually dwelve into systems or low level programming except out of curiosity.
My understanting is that everyone is suggesting to move to memory safe languages when possible, however Zig does not seem to have any.
Since zig is a new language my guess is that the main use would be brand new projects, but sholdn't this be done in a memory safe language?
It seems that the selling point of Zig is: more modern than C but simpler than Rust, so I understand the appeal, but isn't this undermined by the lack of memory safety?
Although it doesn't have the same level of compile-time guarantees, there are runtime checks to ensure memory safety if you use Debug or ReleaseSafe. You can do your development and testing in the default Debug mode and only use ReleaseFast or ReleaseSmall once you need the extra optimization and are confident in your test coverage.
> but isn't this undermined by the lack of memory safety?
Yes, in my opinion, but from Zig's success you can see some people are willing to trade safety for a simpler language. Different people have different values
Though to be fair you can also use zig in old C projects, moving things incrementally. I don't know how many projects do that Vs greenfield projects though
Zig isn't a memory safe language, but it does have memory safety features. Theoretically it's safer than C but isn't as safe as Rust.
For example, you can't overflow buffers (slices have associated lengths that are automatically checked at runtime), pointers can't be null, integer overflows panic.
"Honey, so there is this programming language I really and I wanna talk to you about it"
"Yes?..."
"Well, I want to do a donation since I really really like that language..."
"......... not again .........."
The recent story about them switching to self hosting makes me feel like they are a particularly efficient project that will not waste donation income.
Are you referring to the Zig compiler switching to become self hosted [1], or the Zig website switching to becoming self hosted [2]? (I assume the latter.)
They better sign their packages and check for signatures upon download and installation. At their scale, foregoing S3 means they have to figure out how to deal with bit rot in packages themselves.
They're self hosting docs and Zig releases. There is no central package repository. The decentralization (similar to Golang) is one of the things I like about Zig.
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.
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.
It sounds like something that could support a full time developer for some years.
I hope at some point it can be added to standard linux distributions like debians or red hats through their official yum/apt packages.
So far there is no red hat distro, and there's integration with ubuntu's snapcraft for some reason.
I realize there's dozens of distributions to support, but these are the two most foundational to my understanding, and it just speaks to the maturity and lack of system usage that the compiler is not released/vetted by OS distros.
The language+compiler are on 0.x so packaging it in long term support distros can be more problematic than helpful at this point (source that compiled a year ago is likely broken now and vice versa). Once it has reached 1.x then it won't be much to get it prepackaged everywhere.
Until that point it doesn't really make sense to pull it from the repos of distros that are packaging it right now anyways. E.g. it's packaged on Fedora but you most likely don't actually want to rely on that package for the moment.
That list says it's already in Fedora and openSUSE. The fact that they both have older versions is actually good, since that just means they've been packaging it for a while. Once that list no longer marks outdated versions as red is when zig would have been ready for the long-term supported distributions.
We have local developer environment and we deal quite often with python, go, or some brew packages version not being correctly installed before starting the tools.
I use Zig on Mac, Windows and Linux (but most on Mac). It works without issues (also as a Clang compatible C/C++/ObjC compiler and linker replacement).
I would recommend managing the Zig installation through a tool like zvm (https://github.com/tristanisham/zvm). This lets you easily update to the latest dev version and switch between stable versions (similar to rustup or nvm).
The other install options are working too of course (install via brew - although in the past this was a bit brittle, or download and unpack prebuilt archives https://ziglang.org/download/) but those options are not as convenient for switching between the stable and dev version.
Do you mean using Zig to compile the native libraries for python, go, etc? Sure, the build scripts would need to be updated to use `zig cc`. Zig is already packaged for brew so they could add it as a build dependency.
But it is still pre 1.0 so expect new versions to break old-ish code. I'd say package managers should wait for the 1.0 release.
My donor advised fund has given a lot of money to open source. I highly recommend that people who can benefit from donations of assets create a donor advised fund so they can get tax benefits and then direct it exactly to where they see fit
> Our philanthropy is generally private, but I'm making an exception since I think my public support of Zig has a chance to really help the project due to my background.
I can't quite put words to it, but this statement kind of struck me. There's just a certain basic decency behind it that deserves celebrating.
Same here... except maybe in the opposite direction? Does it implies that their other philanthropy would not benefit from more public support? So what are they in this case?
Anyway, they do whatever they want with their philanthropy in the end, but I found that was an odd phrasing.
A lot of people use philanthropy as a means to ego boost and raise their public image. This is a phenomenon as old as time, to the point where even the bible has tales about it. The (modern?) countermovement to that is to keep your donations secret, often to the point where it's one of the strings attached to the money, that you can't publicly disclose who made the donation. This is a way to support a cause just for the sake of supporting it. I read the above statement as them usually following this ethos, but making an exception this time around since they believe being public about it will bring more visibility to the cause.
perhaps his other philanthropy donations are not technical and he believes that supporting them publicly would feel like bragging and he personally doesn't like that?
If anyone from the Zig foundation is reading this I highly recommend creating a job board, it is basically free money if you have a niche audience.
Sorry if this is a silly question, i am a web developer so I dont usually dwelve into systems or low level programming except out of curiosity.
My understanting is that everyone is suggesting to move to memory safe languages when possible, however Zig does not seem to have any.
Since zig is a new language my guess is that the main use would be brand new projects, but sholdn't this be done in a memory safe language?
It seems that the selling point of Zig is: more modern than C but simpler than Rust, so I understand the appeal, but isn't this undermined by the lack of memory safety?
Although it doesn't have the same level of compile-time guarantees, there are runtime checks to ensure memory safety if you use Debug or ReleaseSafe. You can do your development and testing in the default Debug mode and only use ReleaseFast or ReleaseSmall once you need the extra optimization and are confident in your test coverage.
> but isn't this undermined by the lack of memory safety?
Yes, in my opinion, but from Zig's success you can see some people are willing to trade safety for a simpler language. Different people have different values
Though to be fair you can also use zig in old C projects, moving things incrementally. I don't know how many projects do that Vs greenfield projects though
Zig isn't a memory safe language, but it does have memory safety features. Theoretically it's safer than C but isn't as safe as Rust.
For example, you can't overflow buffers (slices have associated lengths that are automatically checked at runtime), pointers can't be null, integer overflows panic.
"Honey, so there is this programming language I really and I wanna talk to you about it" "Yes?..." "Well, I want to do a donation since I really really like that language..." "......... not again .........."
The recent story about them switching to self hosting makes me feel like they are a particularly efficient project that will not waste donation income.
Are you referring to the Zig compiler switching to become self hosted [1], or the Zig website switching to becoming self hosted [2]? (I assume the latter.)
[1] https://kristoff.it/blog/zig-self-hosted-now-what/
[2] https://ziglang.org/news/migrate-to-self-hosting/
They better sign their packages and check for signatures upon download and installation. At their scale, foregoing S3 means they have to figure out how to deal with bit rot in packages themselves.
They're self hosting docs and Zig releases. There is no central package repository. The decentralization (similar to Golang) is one of the things I like about Zig.
[dupe] / merge later discussion: https://news.ycombinator.com/item?id=41712239
See https://news.ycombinator.com/item?id=41712239
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.
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.
Great to see. Super bullish about the future of Zig.
Badass. Love to see things like this
It sounds like something that could support a full time developer for some years.
I hope at some point it can be added to standard linux distributions like debians or red hats through their official yum/apt packages.
So far there is no red hat distro, and there's integration with ubuntu's snapcraft for some reason.
I realize there's dozens of distributions to support, but these are the two most foundational to my understanding, and it just speaks to the maturity and lack of system usage that the compiler is not released/vetted by OS distros.
The language+compiler are on 0.x so packaging it in long term support distros can be more problematic than helpful at this point (source that compiled a year ago is likely broken now and vice versa). Once it has reached 1.x then it won't be much to get it prepackaged everywhere.
Until that point it doesn't really make sense to pull it from the repos of distros that are packaging it right now anyways. E.g. it's packaged on Fedora but you most likely don't actually want to rely on that package for the moment.
That would be a good reason. The thing is that it is present in many distributions.
https://github.com/ziglang/zig/wiki/Install-Zig-from-a-Packa...
Perhaps the foundational distros are stricter.
That list says it's already in Fedora and openSUSE. The fact that they both have older versions is actually good, since that just means they've been packaging it for a while. Once that list no longer marks outdated versions as red is when zig would have been ready for the long-term supported distributions.
Wow, that's amazing!
Dude even got his wife to chip in!
is zig running well on mac?
We have local developer environment and we deal quite often with python, go, or some brew packages version not being correctly installed before starting the tools.
would that be a good usecase for zig?
I use Zig on Mac, Windows and Linux (but most on Mac). It works without issues (also as a Clang compatible C/C++/ObjC compiler and linker replacement).
I would recommend managing the Zig installation through a tool like zvm (https://github.com/tristanisham/zvm). This lets you easily update to the latest dev version and switch between stable versions (similar to rustup or nvm).
The other install options are working too of course (install via brew - although in the past this was a bit brittle, or download and unpack prebuilt archives https://ziglang.org/download/) but those options are not as convenient for switching between the stable and dev version.
Do you mean using Zig to compile the native libraries for python, go, etc? Sure, the build scripts would need to be updated to use `zig cc`. Zig is already packaged for brew so they could add it as a build dependency.
But it is still pre 1.0 so expect new versions to break old-ish code. I'd say package managers should wait for the 1.0 release.
Lovely! Congrats ZSF and onwards!
My donor advised fund has given a lot of money to open source. I highly recommend that people who can benefit from donations of assets create a donor advised fund so they can get tax benefits and then direct it exactly to where they see fit
Nice to see!
[dead]