Hacker News new | ask | show | jobs
by j-pb 33 days ago
> not from the language they use for the implementation.

Everybody has a plan until their compiler compiles an if-else wrong, and that's the level of instability that Zig had when I left it and Tigerbeetle committed to it.

No amount of testing is going to save you from that and it's a completely avoidable unnecessary self-inflicted problem, as a technical person that makes me seriously doubt every other decision you make on top of that. So I feel like they've already been fighting an uphill battle, where they have to proof that they have a stable system, despite an unconventional early stage foundation, and I feel like that it just got even harder.
1 comments
dzaramelcone 33 days ago
its giving fud
link
j-pb 33 days ago
Read through the stuff yourself if you don't believe me: https://github.com/ziglang/zig/issues?q=is%3Aissue%20label%3...
link
scrubs 30 days ago
Im learning zig for kernel bypass packet work. Aside from some noise, and one bug filed on cross compliation (prob simple to fix) bug, it works like I expect. Export of zig code to clib works fine. Comptime is great. Compile time superb. Like TB I will import no other modules ... and avoid all async.

But this link has got me concerned. When I get more ibverbs work done ill see how good/bad it is in rust.

In this kind of extremely low latency high throughput work there is hardly any (mostly none) MT data structures. Memory is pre-allocated for one pinned thread. Atomics are not much used either. So rust isn't going to help on design much. But I think rust/c interoperability is worse than zig.

In fairness to zig many of these issues were closed when zig 0.16.0 was released, which is what im using.

We'll see

link