Earlier quoted context omitted.
Fast code and fast compile time.
hmmm but how much of a performance gain is there from say CPython or even Go? 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?
Zig, the Small Language
31–40 of 429 posts
Re: Zig, the Small Language
#32why 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
#33Earlier quoted context omitted.
Fast code and fast compile time.
hmmm but how much of a performance gain is there from say CPython or even Go? 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?
Zig is very likely to appeal to people who loves C, or newcomers who are looking for performance.
The quality-of-life gains might lead to marginal changes in productivity/cost, but I would not bet on it.
Re: Zig, the Small Language
#34Earlier quoted context omitted.
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.
Thanks, this is the take I was looking for. It would be great if Unreal Engine could be ported to Zig and then I would be happy to get into it again.
Re: Zig, the Small Language
#35Earlier 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
why? operator overloading doesn't help you solve any problems. you can have the readability with methods which are named appropriately.
operator overloading seems so powerful and useful until you realize one day that it only changes the appearance of things, and makes no difference whatsoever to anything you are actually doing.
Re: Zig, the Small Language
#36I 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…
> I do understand the reasoning (they don't want people committing poor quality code) 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, b…
The missing error checks are annoying, but if you have appropriate editor config it is hard to miss them: https://cdn.billmill.org/static/newsyctmp/warning.png
Basically writing go without `staticcheck`[1] is not recommended. If you do have it set up, it's pretty easy to avoid simple errors like that. I do wish the compiler checked it for you.
Re: Zig, the Small Language
#37I 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…
But most everyone else likes this, so it stays in.
There are no real right answers here. Adding a switch for it just brings its own annoyance (every compiler switch is a bug). You just wind up settling for a local optimum.
Re: Zig, the Small Language
#38why should I use Zig coming from Python/Go ?
If you're coming from Python and Go, then producing the fastest possible program that uses the least amount of memory probably isn't your top objective. Zig is fast, but you're going to have to think about memory management and other things you take for granted in garbage collected language. Zig also has nowhere near the number of libraries that exist in Python or Go, so you'll be building a lot more stuff yourself.
Also, the simplicity of a language like Zig may be a hindrance if you're working with really big code bases. If you need something that will scale to really large projects, like say a web browser, you're probably better off in Rust.
If performance is not an issue and you want something that will let you focus on the program's logic rather than the implementation, Python is probably what you want.
If you're writing a microservice to run in a datacenter, you'll be up and running in Go much more quickly and the performance is probably good enough.
But if you're writing a program for an embedded or limited environment, or you need something that's simple and fast, then Zig is worth a look. And of course, Zig is worth a look because it's very simple and easy to learn so you can be up and running very quickly.
Re: Zig, the Small Language
#39Zig indeed is pretty nice, i just wish it had some more sweet to it - my math type with + - * / overloads - simpler way to fill an array, i can never remember the syntax, it doesn't feel natural `[_]u8{0} * 10;` - smarter type system, i am tired of casting everything twice A good language is not a language set in stone, a good language is a language that doesn't make me feel like i have to suffer because they made a…
It depends. Low level coding the like of which zig is tailored to tends to involve a lot "write and forget about it" infrastructure stuff. At least that's my use case.
It sucks to painfully go over that cryptographic hash, that codec or that compressing algorithm you wrote 15 years ago and still works flawlessly because it wouldn't compile with the modern version of the language.
I think zig is very nice but I wouldn't use it even for my personal projects because it's still unstable (and from my POV it will remain that way for at least 5-10 years).
C is terrible but it's not sufficiently terrible that I would use a language that is orders of magnitudes less popular and still in its infancy. Too risky.