I have received over the years so much spam of this kind by multiple YC-funded companies that I now reflexively send to spam any email that mentions being YC-funded, regardless of how legitimate the email is.
Their brand has been associated with hacking-around and gaining advantage via rule breaking for a while. Didn't their founder application at one point ask "Tell us about a time where you hacked some system for your advantage?" At this point, I think everyone knows they're signing up for dark patterns and questionable practices when they get involved.
I'm always interested to understand - what constitutes a basic ChatGPT wrapper?
Is Legora, which is doing very well, a basic ChatGPT wrapper? Because if you don't view it as one, it certainly started as one.
The part about mapping every error kind to different error code in Zig is debatable. It might be useful in some cases maybe (I don't have the confidence to fully exclude it), but at the very least in my experience I never ever needed that.
In general if you have the (IMO sensible) approach of taking as few dependencies as possible and not treating them like a black box, then for any error you can simply look at the call stack and figure out the problem from reading the code during development.
Outside of that, error codes are useful for debugging code that is running on other people's machines (i.e. in production) for and for reporting reasons.
1. if you're a casual user (ie you don't follow the development) don't try incomplete APIs that not even the creators of fully know how they are supposed to work (because they're still tinkering with them) also you can't expect docs until the design is somewhat finalized (which is not yet, fyi)
2. llms don't help when trying to make sense of the above (a feature that is not complete, that has no docs other than some hints in commit messages, that changes every other commit), reserve llms for when things are stable and well documented, otherwise they will just confuse you further.
If you want to try new features before they land in a tagged release, you must engage with the development process at the very least.
> if you're a casual user (ie you don't follow the development) don't try incomplete APIs that not even the creators of fully know how they are supposed to work
Is the completeness of each API formally documented anywhere? Maybe I missed something but it doesn't seem like it is, in which case the only way to know would be to follow what's happening behind the scenes.
Zig cuts releases. This API is not on a release of Zig yet. It's only available through nightly builds of master. "Casual users" should stick to releases if they don't want to deal with incomplete APIs.
That's not really the issue. The stable API is incompatible with the API that will launch with 0.16. It's not really relevant if I'm playing with incompletely API, I want to know how I can migrate to it. I did not move yet to 0.16, but I wanted to see.
The migration pain will be the same once it launches unless they revert back, which does not seem likely at all.
But the point is: potentially every API is unstable.
> if you're a casual user (ie you don't follow the development) don't try incomplete APIs that not even the creators of fully know how they are supposed to work
From what I can tell pretty much everything can be broken at any point in time. So really the only actual advise here is not to use the language at all which is not reasonable.
> llms don't help when trying to make sense of the above
That has not been my experience. LLMs were what enabled me to upgrade to 0.16 experimentally at all.
> If you want to try new features before they land in a tagged release, you must engage with the development process at the very least.
No, that is unnecessary gatekeeping. 0.16 will become stable at one point and I don't want to wait until then to figure out what will happen. That's not how I used Rust when it was early (I always also tried nightlies) and that line of thinking just generally does not make any sense to me.
The reality is that Zig has very little desire to stabilize at the moment.
The flipside of that is that the incomplete API should be in a separate branch until it is ready to be included in a release, so that people can opt in instead of having to keep in mind what parts of the API they aren't supposed to be using. It doesn't seem like you expect the changes to be finalised in time for 0.16.
This the strongest argument against building a community on top of proprietary services, especially if's a startup / VC money is involved. It's guaranteed to enshittify / sell out to a big company, and your community will crumble.
That being said, I am guilty of helping building Zig communities on Discord, but in my defense none (literally none) of the FOSS alternatives was good enough at the time. And I'm also not really happy with plenty of the newer ones.
I'm now working on my own take of what an open source Discord alternative should look like and I plan to move away from Discord by the end of the year. You can find it on codeberg, it's called awebo, I'm intentionally not posting a link since these are super early days.
"Free" in English has more than one meaning. this has led to an attempt to be more clear by using 'libre' or 'gratis' loanwords to differentiate (see libreoffice, liberachat), but this isn't universally accepted.
I would love to be able to setup in Europe a non-profit equivalent to the Zig Software Foundation.
I haven't looked too deeply into it, but my understanding is that it's not possible to create an equivalent corporation in Italy (where I reside) nor the rest of Europe.
> I haven't looked too deeply into it, but my understanding is that it's not possible to create an equivalent corporation in Italy (where I reside) nor the rest of Europe.
You certainly did not look deep enough. ;)
Ask Mr Google about gGmbH in Germany, for example.
Honestly, I would be incredibly surprised if every single European country does not already have a non-profit structure.
In addition, do not forget that in some countries you might also have the option of being non-profit not through legal-form (e.g. gGmbH in Germany) but via your articles of association, i.e. you set up a "standard" company and then formally declare it a non-profit. This is something your friendly local company lawyer would be need to help with as it requires the correct words to be drafted into your articles if you want e.g. the tax authorities to correctly recognise your status.
Sure we have non profit companies also in Europe, the question if it's possible to create one to support an Open Source project, and which tax benefits donors can get.
My experience with the US tax system is that you need to get approval to get non-profit status, and more in general I do think this has something to do with the price of eggs in the sense that you should obviously be prevented from being able to setup a non-profit company if what you're doing has nothing charitable about it.
I made the mistake of leaving this unsaid, but 501c3 in the US also means that the company is tax exempt, which is the actual concrete thing I was implicitly asking about.
> My experience with the US tax system is that you need to get approval to get non-profit status,
I think in the majority of European cases you don't need prior approval. The UK is most likely the biggest exception where you can become either a non-profit or a charity. And if you want to become a charity in the UK, then yes there are more hoops to jump thorugh including approval from Charity Commission.
But for Germany for example, you can just go setup a gGmbH which is simply a non-profit/charitable form of the standard GmbH. The only difference is what you put in your articles of association and how you register with the tax authorities, but you don't need prior authorisation for either, you just apply for the status with the tax authorities post-formation.
Whether non-profit or charity you get tax exemption on both in Europe. The only difference is in the donor experience in some places (e.g. in the UK to get a personal tax break you have to donate to a charity, not a non-profit).
But as above, I think the UK is the exception to the rule, I suspect in most EU countries it is closer to being non-profit == charity with no differentiation.
> Every project and programmer shouldn't feel they have to justify their choice not to use Rust (or Zig)
You won't find easily Zig programmers that want you to use Zig at all costs, or that believe it's a moral imperative that you do. It's just antithetical to the whole concept of Zig.
The worst that can happen is that Zig programmers want C projects to have a build.zig so they can cross-compile the project trivially, since that's usually not a thing C/C++ build scripts tend to offer. And even then, we have https://github.com/allyourcodebase/ so that Zig users can get their build.zig scripts without annoying project maintainers.
