HackerLangs
TopNewTrendsCommentsPastAskShowJobs

rvrb

293 karmajoined vor 5 Jahren

comments

rvrb
·vorgestern·discuss
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
rvrb
·vorgestern·discuss
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.
rvrb
·vor 2 Monaten·discuss
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
rvrb
·vor 2 Monaten·discuss
thanks for sharing this. not sure if you are the author, but it's really useful reading this right now.

I am working, quite literally as I write this, on starting a community space like yours for 'digital makers' in Portland.

I wake up every morning feeling charged and ready; I go to sleep every night full of anxiety and doubts -- "who am I to start this thing? does anyone want this? I don't know what I'm doing!". ultimately, I feel, failure is better than not trying.

and it helps to know it's not about me. every person I talk to in my community feels the need for this thing. and that's why we want help from other people like us. we're just getting started!

if you live here and this sounds interesting to you, you can find us here: https://rcdc.space
rvrb
·vor 4 Monaten·discuss
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.
rvrb
·vor 4 Monaten·discuss
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.
rvrb
·vor 4 Monaten·discuss
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
rvrb
·vor 4 Monaten·discuss
Binary space partitioning
rvrb
·vor 6 Monaten·discuss
`extern` and `packed` container types have well defined layouts. a regular `struct` is an "auto" layout - and the compiler can and will rearrange whenever it wants.

if you need a well defined layout, use `extern`. if your struct makes sense to represent as an integer, use `packed`. I think it is often ill advisable to use `packed` otherwise.

you can explore this yourself on the Type info returned from @TypeInfo(T):

https://ziglang.org/documentation/master/std/#std.builtin.Ty...

https://ziglang.org/documentation/master/std/#std.builtin.Ty...

https://ziglang.org/documentation/master/std/#std.builtin.Ty...
rvrb
·vor 7 Monaten·discuss
[flagged]
rvrb
·vor 7 Monaten·discuss
I haven't verified this, but I would be willing to bet that most of Bun's issues here have more to do with interfacing with JavaScriptCore through the C FFI than Zig itself. this is as much a problem in Rust as it is in Zig. in fact, it has been argued that writing unsafe Zig is safer than writing unsafe Rust: https://zackoverflow.dev/writing/unsafe-rust-vs-zig/
rvrb
·vor 8 Monaten·discuss
you say this like it's some own or something, but I'd be more surprised if they didn't. believe it or not, they are already donating some of their funds to the upstream ecosystem[0].

[0]: https://ziglang.org/news/2025-financials/
rvrb
·vor 8 Monaten·discuss
C, C++, Rust, Zig. Rust and C++ have an infamous learning curve. If you know anything about using any systems language other than Zig, Zig is incredibly simple to pick up, like C. Unlike C, it pushes you toward making less mistakes.

If you don't know anything about using a systems language, Zig makes it easier for the people who do to review your code and make sure you didn't mess it up. It does this with very intentional design that makes it easier to understand the full impact of code quickly, reducing the cost of review, making review practical to catch the issues. It also has many other fail safes to catch these problems before they ever reach a production release.

So, yeah, it's totally depending on where you are coming from -- but Zig is not a tool built for a web developer who doesn't know anything about memory to go and ship an application within their first week. It does make it easier for that person to learn the ropes at a steady pace.

Meanwhile, everyone complaining that Zig is not memory safe doesn't seem to care that applications written in Zig do not have the vulnerabilities that memory safety solves on the scale that C does[0].

If you have not written a real application in Zig and evaluated it for vulnerabilities, but are claiming that creating Zig was irresponsible, and using it is too; you are cargo culting.

If you have, you probably understand there is a niche that Zig fits in and that it isn't surprising it exists to fill it. Like all things in our industry, there is a cost/benefit analysis required for choosing the tools you build with.

No one reasonable has claimed that memory safe languages should not exist, but there is a maddening number of people being disrespectful toward those who think there are other ways of addressing the same problems.

[0]: https://mitchellh.com/writing/ghostty-gtk-rewrite
rvrb
·vor 8 Monaten·discuss
Zig is famously simple to pick up and write with, so I don't know what you mean by "difficult". Software is dangerous. Memory safety is one of a million ways it can be dangerous. A compiler barfing when it thinks you are doing something unsafe with pointers is one approach to dealing with one of the ways that code can be dangerous to execute.

Zig does not ignore that particular danger, it just takes a different approach to dealing with it than some other modern languages. An approach that, I believe, leaves the developer with a little more humanity by allowing them the benefit of the doubt that they know what they are doing.

Everyone that has not built a systems language, or has not built a real application with both Zig and a memory safe language, that is reacting emotionally to what I've said should put a lot of consideration into whether they are cargo culting or using critical thought. Consider that we still do not yet know what is best, and shutting down attempts to explore different ideas with things like "creating [and using] this language is ignoring the humanity of the end user" is, well.. dumb.
rvrb
·vor 8 Monaten·discuss
Zig is a tool that helps professionals prevent those mistakes.

"Memory safe languages" are tools that prevent professionals from making those mistakes.

It's a subtle but important difference. Zig attempts to leave some humanity to the developer.

When someone says they are incapable of earning or deserving that, I feel sad.
rvrb
·vor 8 Monaten·discuss
the answer I've seen when it has been brought up before is that (for allocators) there is not a practical impact on performance -- allocating takes way more time than the virtual dispatch does, so it ends up being negligible. for code bloat, I'm not sure what you mean exactly; the allocator interface is implemented via a VTable, and the impact on binary size is pretty minimal. you're also not really creating more than a couple of allocators in an application (typically a general purpose allocator, and maybe an arena allocator that wraps it in specific scenarios).

for IO, which is new and I have not actually used yet, here are some relevant paragraphs:

  The new Io interface is non-generic and uses a vtable for dispatching function calls to a concrete implementation. This has the upside of reducing code bloat, but virtual calls do have a performance penalty at runtime. In release builds the optimizer can de-virtualize function calls but it’s not guaranteed.
  
  ...
  
  A side effect of proposal #23367, which is needed for determining upper bound stack size, is guaranteed de-virtualization when there is only one Io implementation being used (also in debug builds!).
https://kristoff.it/blog/zig-new-async-io/

https://github.com/ziglang/zig/issues/23367
rvrb
·vor 8 Monaten·discuss
out of curiosity, what feature do you want?
rvrb
·vor 8 Monaten·discuss
not being a direct competitor to either of these already existing languages is exactly why it is interesting!
rvrb
·vor 8 Monaten·discuss
I've tried writing a similar post, but I think it's a bit difficult to sound convincing when talking about why Zig is so pleasant. it's really not any one thing. it's a culmination of a lot of well made, pragmatic decisions that don't sound significant on their own. they just culminate in a development experience that feels pleasantly unique.

a few of those decisions seem radical, and I often disagreed with them.. but quite reliably, as I learned more about the decision making, and got deeper into the language, I found myself agreeing with them afterall. I had many moments of enlightenment as I dug deeper.

so anyways, if you're curious, give it an honest chance. I think it's a language and community that rewards curiosity. if you find it fits for you, awesome! luckily, if it doesn't, there's plenty of options these days (I still would like to spend some quality time with Odin)
rvrb
·vor 8 Monaten·discuss
matklad did it justice in his post here, in my opinion

https://matklad.github.io/2025/08/09/zigs-lovely-syntax.html