Earlier quoted context omitted.
> bun seems to be committed to slop rust already. so, with their ethic, maybe we should just disassociate them from zig and let them go realize their slop dreams? Closing your eyes and pretending a problem does not exist is the a good solution. The fact of the matter is one of the biggest projects that used Zig thought that the devX was so bad that they opted to rewrite their entire 1M LOC project into a different la…
> The fact of the matter is one of the biggest projects that used Zig thought that the devX was so bad It's unlikely to be just a devex issue. The fact of the matter is that a memory unsafe language is an extremely tough sell today, and companies that have a security team at all have likely already made or are planning on making policies like https://chromium.googlesource.com/chromium/src/+/master/docs... There's a r…
Zig: Build System Reworked
131–140 of 263 posts
Re: Zig: Build System Reworked
#132Earlier quoted context omitted.
I would be very surprised to see a large Rust codebase being harder to maintain than a large Zig codebase. The former makes it much easier to maintain invariants at scale.
Neither has been battle-tested at the relevant scale.
Re: Zig: Build System Reworked
#133This sounds like great news, Zig's compilation times are already terrific and this is going to only make them better.
Just creating a file with dummy test like if (2 * 2 != 5) { @panic("fail"); } And running `zig test file.zig -OReleaseSafe` takes a couple seconds on my computer. It also keeps taking the same amount of time every time I do it when I modify that file. Using 0.16 (or master) version so my toolchain isn't old and I'm on linux. Zig is super nice to use as a language but the compiler/stdlib isn't developed conservatively…
This kind of thing just feels unacceptable considering I don't really see ANY improvement on the issues I had from back then.
Also had a similar baffling experience when I last tried to come back to writing Zig. The std.time.Instant or similar API that also exists in rust and most other languages was move to the new Io interface and they also completely removed that std.time.Instant code.
Overall it feels like people developing the tool don't respect the people using the tool. C++ or even Rust are much less enjoyable languages to write compared to Zig so it is really sad that it is not possible to actually use Zig for me.
Re: Zig: Build System Reworked
#134Why would I want to use this over, say, Node.js and TypeScript?
You can't run Node on embedded systems, because there isn't enough memory.
A compiled zig program can be only several kilobytes with no depedenencies.
Array access programmed in low-level languages can be optimized with SIMD and parallelization, which will be orders of magnitude faster than the same thing on Javascript. Text processing, image manipulation, video processing, hashing, etc.
There is like infinite reasons to not use Javascript.
Re: Zig: Build System Reworked
#135Earlier quoted context omitted.
Neither has been battle-tested at the relevant scale.
What kind of scale are you thinking of?
Re: Zig: Build System Reworked
#136Re: Zig: Build System Reworked
#137Would someone tell a rust user why they should and should not try zig?
I don't think Rust users are relevant here. It primarily comes down to personal preferences, and since Zig and Rust are so different, some will be drawn to Rust and others to Zig. If you really like a language and it suits your needs, be it Rust or any other, there's no need to look to switch. I think that the audience Zig is aimed at is low-level programmers who haven't taken a liking to Rust, which is the majority…
Re: Zig: Build System Reworked
#138Earlier quoted context omitted.
I thank Go for this. Go's compilation times seemed to inspire other language devs
Go changed something, not sure if 20 or 21, where it will download the Go compiler of all your third-party which don’t match yours. It slows things down.
Re: Zig: Build System Reworked
#139Earlier quoted context omitted.
> For the rare exceptions, I make a C lib The problem is that most people using Python don't have enough expertise in C to do the same. It also kinda destroys the argument that Python is good if your solution for performance is to use a different language alongside it.
The argument is that the ergonomics of using Python are worth the squeeze of learning two languages. Are the ergonomics of using Zig really enough to justify replacing Python on the happy path, or would it end up replacing just C?
But... the LSPs I've tried (and I've tried a bunch!) are all atrocious: false positives and false negatives galore. Perhaps I'm spoiled by LSPs from languages with better type systems. Our code is strewn with (to me) mysterious comments such as `# NOQA 1234` which my colleague uses to make his Python tooling work with the codebase. I'm used to languages like Elm or Gleam in which a LSP error means there is an actual problem with your code, and a lack of a LSP error means the code will compile and run.
Re: Zig: Build System Reworked
#140Earlier quoted context omitted.
I don't think Rust users are relevant here. It primarily comes down to personal preferences, and since Zig and Rust are so different, some will be drawn to Rust and others to Zig. If you really like a language and it suits your needs, be it Rust or any other, there's no need to look to switch. I think that the audience Zig is aimed at is low-level programmers who haven't taken a liking to Rust, which is the majority…
.....Did you just complain about Rust's "lower adoption" compared to C++, immediately following it by "Zig, on the other hand :eyes_emoji:"