alexrp
We have a roadmap to 1.0.0 -- it's literally right there in the release notes -- and we're going to execute on that and then tag it. Ignoring that (and SemVer) and declaring that we should actually stabilize right now is a bit unreasonable.
> For comparison, Elixir started in 2012, and got its 1.0 in 2014, two years later. Zig stable has been ‘a few years’ for literally a decade.
This is a wild comparison to me, and I say this as someone who actually used Elixir for a time fairly early in its development (and still like it!). Zig has a vastly larger and more difficult problem space to deal with than Elixir.
Sorry, would you mind clarifying what you mean by this? I'm only aware of the one incident?
Who did you email, when, and did you get a response? We've all been very busy leading up to the release, and most of the team is also currently traveling for SYCL.
Regarding sending a message, consider our side: We're tired of having our time wasted on slop, so we don't also want to have to write formal block notifications to people we block on suspicion of using LLMs. I'm fully aware that this can lead to an unfortunate situation like this, however. For what it's worth, this is why we want to move to an invite tree for Zig development; it'll allow us to create a high-trust environment where this kind of suspicion is unnecessary.
Regarding whether you should post the root cause analysis: Per the current policy, the answer would have to be no.
I do personally have more nuanced thoughts on this, and I started typing them out... but then I realized that my reply was getting dangerously close to blog post length, so I decided to restrain myself and commit to turning it into an actual blog post later. In a nutshell, though, the problem is that even if there is such a thing as responsible use of LLMs for bug analysis, the only way we can currently be confident that someone possesses the required qualities for that is by working with them for a while.
To be clear, we do not block people for merely having LLM-related projects. Obviously we have opinions about LLMs in a broader context, but in terms of rules enforcement, we only care about LLM usage taking place within official Zig spaces.
It's possible you were blocked in error. LLM detection is not foolproof, so unless it's an open-and-shut case, our usual approach is to just unblock if people reach out to us by email.
Yes, I'm a core team member.
To clarify, do you mean someone who isn't part of the core team?
It would be a bizarre approach in Scandinavia because the consensus here is that companies must pay their employees a decent baseline salary -- which unions negotiate across the whole sector -- so there's no expectation of a tip by default.
But for much of the rest of the world, it's not a given that working conditions are as good.
I really didn't think that part had to be stated explicitly; I genuinely don't know why someone not invested in Zig would even feel the need to go debate on the Zig issue tracker. But even setting that aside, this is far from the first time that the core team has made it clear that we don't want the internet peanut gallery to brigade the issue tracker.
> as evidenced by real comments being deleted from that issue.
Which real comments were deleted?
I think it's reasonable for any open source project to only be interested in the opinions of its actual users, especially when obvious social media brigading is taking place.
If I -- having written precisely 5 lines of Rust in my life -- showed up on the Rust issue tracker and started expressing my opinions on the future direction of the project and debating a proposed feature, I would absolutely expect people to be annoyed about the noise I'm generating.
I can't speak for Andrew, but I didn't read this as a "diss" at all.
I promise you, hand on heart, that literally no one on the Zig core team is wasting their time on thoughts like this.
> and their flagship project has now abandoned it.
Quoting Andrew:
> So, when the Anthropic aquisition finally happened, we at ZSF breathed a sigh of relief. When the donation silently stopped, our bank account was ready for it. When they neither canceled their monthly meeting with us, nor showed up, we were not surprised. The relationship was over.
I advise you to take this paragraph at face value. Again, I promise you that it is the truth.
I'm not sure what point you're making here. Did you assume we had the page file disabled or something?
> This is a feature, not a bug.
OOMing when there's tens of gigabytes of unused memory is a feature...?
We test FreeBSD, Linux, macOS, NetBSD, OpenBSD, and Windows in Zig's CI fleet. Of these, Windows is the only OS that we've had to configure with swap double the size of physical RAM to not hit completely unjustifiable OOMs.
By "unjustifiable", I mean that we're not even close to actually running out of physical memory (let alone swap), but the MM seems to be doing a horrible job of making unused memory actually available to processes.
It's possible there's a relevant configuration knob here that we're just not aware of... but the point is, the default behavior does in fact suck.
I can't speak to their managed Jenkins offering, but FWIW, we've had no major trouble running Zig's CI on 3 s390x-linux VMs, each with 8x z15 vCPUs and 32 GB of RAM.
They are definitely over-provisioned, though, so we have the job timeouts set ~3 hours higher than they ideally should be to deal with load spikes. But after we dialed those timeout values in, it's been smooth sailing from there. I'd even say it's one of our most stable CI platforms now.
I did reach out to Bruce Gilkes about the over-provisioning and he informed me that they are planning an upgrade to z17 later this year, so hopefully that'll improve the situation.
> What does an open source project get from this? ... So besides the bragging rights (I guess?) and discovering latent bugs exposed by the exotic architecture, what's in it for a project to deal with this extra architecture
The way I look at it, if Zig is going to be a serious C competitor, it must run in all the places that people run C in. Plus I just find it fun to do porting work since it involves a whole bunch of learning.
The only thing I can say is that they seem to have significantly improved the thermals; IME, the Pocket 4 only gets moderately warm to the touch during full CPU load, and that's even with the quiet fan mode.
Battery life on it is comparable to the MicroPC 2, but for the netbook form factor, it should really be compared to the Pocket 4. Similar story for the RAM, as well as the odd screen refresh rate.
Minor points: I do also appreciate the Ethernet ports on the GPD devices, and their approach to touchpads (buttons and placement in particular).
I guess my issues basically all boil down to the Minibook X not having enough functionality for the form factor when compared to GPD. That's mostly understandable for the price, but my point is just that if you're willing to fork over some more cash, you can get a whole lot more laptop in the same form factor (Pocket 4) or slightly better specs in a smaller form factor (MicroPC 2), and at least for me, that's the only way I could even have seriously considered these form factors for my work.
(Just to be clear, I have no particular brand loyalty to GPD; they're just the only player in town for high-end netbooks/UMPCs at the moment.)
Can't speak to this as I don't RE for security purposes, but:
> no plugin support and rather limited IR.
this I'm profoundly confused by. BN has multiple IRs that are easily accessible both in the UI and to scripts. And it certainly has a plugin system too.
I've used IDA, Ghidra, and Binary Ninja a lot over the years. At this point I much prefer Binary Ninja for the task of building up an understanding of large binaries with many thousands of types and functions. It also doesn't hurt that its UI/UX feel like something out of this century, and it's very easy to automate using Python scripts.
> I thought it was stable enough initially but they completely broke fuzz testing feature and didn’t fix it.
From the 0.14.0 release notes:
> Zig 0.14.0 ships with an integrated fuzzer. It is alpha quality status, which means that using it requires participating in the development process.
How could we possibly have been more explicit?
Fuzzing will be a major component of Zig's testing strategy in the long term, but we clearly haven't had the time to get it into shape yet. But we also didn't claim to have done!
> Also some things like stack traces were broken in small ways in zig. It would report wrong lines in stack traces when compiling with optimizations. Also wasn’t able to cleanly collect stack traces into strings in production build.
I mean, to be fair, most compiled languages can't give you 100% accurate source-level stack traces in release builds. But that aside, we have actually invested quite a lot of effort into std.debug in the 0.16.0 release cycle, and you should now get significantly better and more reliable stack traces on all supported platforms. If you encounter a case where you don't, file a bug.
> And recently saw they even moved the time/Instant API to some other place too. This kind of thing is just super annoying with seemingly no benefit. Could have left the same API there and re-used it from somewhere else. But no, have to make it “perfect”
I acknowledge that API churn can be annoying, but it would be weird not to aim for perfection prior to 1.0.
> You mean like how Rust tried green threads pre-1.0? Rust gave up this one up because it made runtime too unwieldy for embedded devices.
The idea with making std.Io an interface is that we're not forcing you into using green threads - or OS threads for that matter. You can (and should) bring your own std.Io implementation for embedded targets if you need standard I/O.