after seeing so many segfaults in the bun.sh project, I don't feel confident enough to use it.
Sure it allows you to move fast but at what cost
Zig: The Modern Alternative to C
111–120 of 181 posts
Re: Zig: The Modern Alternative to C
#112Earlier quoted context omitted.
The point that paragraph is trying to make but articulates imperfectly is that you explicitly pass an Allocator to the stdlib routines that allocate -- rather than having them allocate on the heap implicitly.
So you have coloured functions? The red that can allocate, and the blue that cannot?
If you want to think of it that way, the stdlib `voluntarily` colors its functions by allocator. You can do whatever you want in your own functions, including always using a global allocator and never passing it anywhere.
Re: Zig: The Modern Alternative to C
#113It looks like Zig doesn't have a GC. Does it have any improvements over C in that area? Like Rust's lifetimes?
Short answer: not exactly, no. Long answer: Zig does a lot of stuff to make the easy way of dealing with memory the correct way. The typical pattern is to use defer/errdefer statements to clean up on end of scope or in case of error. One of the included allocators checks for leaks and use after free, and it is trivial to change which allocator is used based on build mode. It is also very strict about pointers and has…
Longer answer: I think it's inevitable that someone will write a static checker for lifetime analysis.
Re: Zig: The Modern Alternative to C
#114after seeing so many segfaults in the bun.sh project, I don't feel confident enough to use it. Sure it allows you to move fast but at what cost
Are you still running into segfaults in recent versions of Bun? If so can you file an issue or provide some same code? We try to fix these quickly
Re: Zig: The Modern Alternative to C
#115Earlier quoted context omitted.
It is not an alternative to Go same as C++ or Rust is not really an alternative to Go. They are on a different level, but can do the same job. Though I could argue that Tcl could be an alternative to Go, I think many would not agree. Zig has manual memory management, doesn't have much of a runtime (no CSP out of the box) and above all is not mature yet (breaking changes do happen). As of now it has one of the best st…
I'm hearing this so often that I think I have to write a blog post some day. I think both Zig and Rust can be an alternative to Go. Zig is still young, so it probably lacks tools for many domains, but if it grows I expect it to get more tooling similarly to what's happening for Rust. So just talking for Rust today, it's used in: - gaming - web apps - networking - CLIs - distributed systems - crypto - systems programm…
In a way I feel that everything is an alternative to everything and at the same time nothing is.
As you said it all depends on the circumstances. But I don't really see Zig competing with Go. They both can do mostly the same things, but they both approach them from quite a different sides.
For example bash is being used in:
- gaming (https://github.com/JosefZIla/bash2048)
- web apps (https://github.com/avleen/bashttpd)
- networking
- CLIs
- distributed systems (https://github.com/frameable/aviary.sh)
- crypto (https://armedia.com/blog/blockchain-program-written-bash/ https://github.com/grondilu/bitcoin-bash-tools)
- systems programming (https://github.com/damphat/kv-bash)
- language tooling
Some of those make more sense than others. However we all talk about a mythical general case. For every language there are niches that are covered by it more significantly. For Go it would probably be web backend. It doesn't mean it is only suited to this one niche, it is used in everything. In general it is used there more. I don't believe that Rust sees the most use in the same niche to the same order that Go sees it.
Is Rust or Zig an alternative to php, awk or Lisp or vice versa? In practice I don't really think so.
I guess it all depends on one's definition of "alternative". I don't think that a statistical Go programmer would see Zig as a real alternative. Statistical C programmer might see it as a Go alternative, but that probably would not be a question he would ask.
Re: Zig: The Modern Alternative to C
#116Earlier quoted context omitted.
Which is absolutely not solved by assigning it to _ neither, if anything it will just make the variable appear used in syntax highlighting and that will make me forget to properly use it! IDEs just gray out the unused variables and that is an 1000x better way of handling this issue.
I think you misunderstand the purpose of assigning to _. Extremely common bug 1: a function returns an error/future, but you don’t check/poll it “foo();”. May happen because you copy some tutorial code that’s not rigid about error checking, or you don’t realize that this language doesn’t have futures that run without being polled. Quite common bug 2: you store the error/future, but don’t check/poll it “let a = foo();…
You misunderstand me - I’m talking about my original problem of an unused variable that happened due to me commenting out something for example. Temporarily unused variable if you will.
Without recursively commenting out any further variable that have also become unused by my action (which I hope we can all agree is extreme tedious and error prone), I am left with no choice but assigning it to _, which as you mentioned already have a normal usage, making it later very hard to discern which is just a temporarily unused variable, or a deliberately ignored one. The very “feature” can cause bugs, besides being annoying as hell.
Re: Zig: The Modern Alternative to C
#117genuine question: why might you pick Zig over Rust?
Re: Zig: The Modern Alternative to C
#118Does Zig still have that insane compiler enforced no unused variables policy? Honestly, that is such a stupid thing that it literally kept me away from the language, which I otherwise find interesting for its niche.
I'm waiting for the first fork that will do away with that "feature".
It already exists. You’ll just have to compile it yourself which is relatively easy.
Re: Zig: The Modern Alternative to C
#119"that could one day replace C" I don't understand why would anybody say that, it's seems such a simple concept to me that nothing ever will replace C. Think about just the Linux kernel, nothing else. Nobody will and can rewrite every part of it that a C compiler will not be needed.
I doubt every single line of C will be removed considering a lot of it is drivers for hardware no one has anymore, but I’d say in 10 years the majority of actually used code in the Linux kernel will be Rust. The Asahi project has shown that Rust is the better choice for kernel code right now.
That will make backporting security fixes fun.
(I think there's less than a ten percent chance of this happening)
Re: Zig: The Modern Alternative to C
#120I tried using Zig for a little bit, and it just doesn't feel ergonomic to use _for me_. It's not 1.0 so I'm hoping that a lot of that will be ironed out, but some of it is baked into the language. Being forced to assign variables to _ if you aren't using them somewhere else in the program annoyed me a lot more than I expected. Especially in the learning phase when you are asking a lot of questions and have to write u…
var arr: [30_000]u8 = undefined;
for (&arr) |*x| x.* = 0;