why should I use Zig coming from Python/Go ?
Zig, the Small Language
21–30 of 429 posts
Re: Zig, the Small Language
#22I tried Zig recently but I found the unsilenceable lints to be a huge productivity killer. I actually posted a link to the GitHub issue this morning. https://news.ycombinator.com/item?id=32751317 This makes a normal workflow with `watchexec zig test` basically impossible, since before I can even run the tests I have to spend time hunting down which variables are used/unused at the moment and (un)commenting them. And…
Not that this lint actually achieves that, or even prevents real errors. Go has the same, and it's so simplistic as to only be annoying. For instance not sure whether this fails in Zig but Go will allow this:
v1, err := Foo()
if err != nil {
return nil, err
}
v2, err := Bar(v1)
return v2, nil
Error of second call is never checked, but go has no issue with that, because it only tracks definitions per use. v1, err := Foo()
v2, err := Bar(v1)
if err != nil {
return nil, err
}
return v2, nil
also works fine, despite probably sending complete nonsense to Bar, for the same reason.But then it's an absolute pain in the ass every time you're fucking around and stop using a debug import or whatever.
Re: Zig, the Small Language
#23why should I use Zig coming from Python/Go ?
Fast code and fast compile time.
The syntax of Zig appears to be quite user friendly but not sure if there are hidden pitfalls.
I am excited for Zig but careful in adopting new languages but if this takes off, what sort of changes might we see? Cheaper C/C++ programmers?
Re: Zig, the Small Language
#24why should I use Zig coming from Python/Go ?
Re: Zig, the Small Language
#25why should I use Zig coming from Python/Go ?
Realistically, you probably shouldn't. Zig seems to be positioning itself as a systems-level language—more of an alternative to C/C++/Rust than to Python/Go. If you're building low-level, high-performance software, it might be interesting to you; otherwise, I don't see a practical benefit.
Re: Zig, the Small Language
#26why should I use Zig coming from Python/Go ?
Re: Zig, the Small Language
#27Current $work language is Go, which is so painful to use. I often look wistfully at all of Zig's features that improve on what Go does (particularly with regard to error handling). I hope in the future I can use Zig as a Go replacement and not just a C/C++ replacement.
Re: Zig, the Small Language
#28why do people care about binary size? I have never understood this. Disk space isn't free but the size of the binaries on my machine doesn't seem like a big problem to me in that regard.
Re: Zig, the Small Language
#29Earlier quoted context omitted.
"In the beginning the [operator overloading] was created. This has made a lot of people very angry and been widely regarded as a bad move." But in all seriousness that's pretty much antithetical to zig's goals regarding explicitness.
if we can do 1 + 1, we should be able to do vec2 + vec2, same with mat4 * mat4 Odin proved it that it can be made efficiently while keeping sanity
And vec2 + vec2 can probably be unambiguously translated to assembly code while mat4 * mat4 is an other story. In most cases it should be a function call, and not a trivial one, with SIMD it can be relatively fast but still several orders of magnitude slower than 1 + 1. (we're talking about more than 500 scalar-equivalent operations)
And unfortunately, from my experience, if you let people (especially new coders) use this kind of powerful syntactic sugar they tend to ignore the performance characteristics because it look so simple and basic, like if the CPU had a special instruction to multiply two 4x4 matrices.
I prefer when the function call is explicit, it is a bit more cumbersome to write, but there is less hidden complexity.
Re: Zig, the Small Language
#30why do people care about binary size? I have never understood this. Disk space isn't free but the size of the binaries on my machine doesn't seem like a big problem to me in that regard.