rvrb

sure, it sounds like there is a difference here. I'm not aware of any stance by the Zig core team on the subject.

I am genuinely interested in a place that this matters for a program, or any practical consequence this has for an end user of the language.

no idea why your response was flagged originally.

there has been a ton of work on making comptime a pure and deterministic execution environment. I do not expect that work to stop. I don't know where you are getting the idea that it is not an important design consideration for the language.

to expand, if two different host platforms cross compiling to the same target platform have different results, I am almost certain that would be considered a compiler bug.

if you're pointing out that a runtime operation and a compile time operation might not agree, I'd be more interested in understanding when that would ever have any meaningful impact on anything. given the compilation is supposed to be deterministic, the difference can easily be addressed by comptime branching on target architecture in the rare case that it matters for your program.

you're right that that is a weak argument against C++ in that use case (biased by my own dislike of the language); but it is also a niche that Zig fits into quite well. so it's weird for the OP to claim it's ok to drop down to C++ when needed while kind of suggesting they don't get why anyone would use Zig

that you understand and think dropping down to C++ is what you need to do when you "need the best performance" is quite enough of a tell to invalidate the rest of your opinion here. if you "need the best performance", you need to ditch OOP and RAII, and you're probably reaching for C. Zig wants to be the better choice there. that's a perfectly reasonable niche for a language to exist in.

if you read the article carefully, jarred is pretty clear about how their specific requirements with Bun cause friction when bridging the manual memory management of Zig with a garbage collected JS runtime. at face value, that makes quite a lot of sense to me, and it's a pretty specific scenario that is not the full on condemnation of memory unsafe languages that your comment is.

hello!! I have been planning to reach out to Synth Library Portland; it's awesome to hear from someone connected to it. I know they recently got kicked out of their Lloyd Center location and were looking for a home. I was hoping to talk to them about this. I will email you

What is your point? I feel I made the one you are making before you even responded the first time.

That Discord communications can be exfiltrated in this specific set of circumstances (again, something I already said) does little to change that Colibri is implemented in the least privacy preserving way possible, short of publishing directly to every news and intelligence agency on your behalf, and does little to make that very clear in the first place.

First, the user knows this when joining a public community.

Second, the moderators can choose to remove someone who has joined the community in bad faith.

Third, it is entirely different than broadcasting every single action taken by every single user in every single community on the entire protocol to anyone with one URL.

Users in a Discord server/local community on tools like Discord naturally expect that their actions within that community are private in so far as they trust everyone in the community (including the operator) to keep it so.

By using ATProto, Colibri fundamentally makes all of your communication within any community completely public to everyone on the internet.

That’s fine for something like Twitter, where the product sets the expectation of such a thing. You can imagine how big of an issue this is when you try to do it in a trusted community model. Add on that Discord is used by kids who likely don’t know this and you can see why this is dangerous.

I consider this not only just a liability but bordering negligence. It is fundamentally broken, at an architectural level

Binary space partitioning