Live data from Hacker News

Zig, the Small Language

zserge.com

31–40 of 429 posts

Re: Zig, the Small Language

#31
post #23

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?

I'd say at least 2x-5x with Go and 10x or more with CPython, depending on the type of work.

Re: Zig, the Small Language

#32
post #16

why 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.

I think it is more of a proxy to the controlability, which is not often the case with C/C++ where a seemingly small stdlib feature triggers a larger dependency and you can't easily get rid of them.

Re: Zig, the Small Language

#33
post #23

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?

>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

#34
post #25

Earlier 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.

I think that a Zig API for Unreal is very likely to appear at some point.

Re: Zig, the Small Language

#35

Earlier 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

> if we can do 1 + 1, we should be able to do vec2 + vec2, same with mat4 * mat4

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

#36

I 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…

This really irritated me when I started working with go, but it stopped bothering me and now I even mostly like it.

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.

[1]: https://staticcheck.io/

Re: Zig, the Small Language

#37

I 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…

There's a push-and-pull on this in D, too. For example, sometimes I want a backtrace at a certain point, so I'll add an `assert(0);` there. The compiler complains that the rest of the code is unreachable. I then have to block out the code with a `static if (0) { ... }`, or comment it out, which is annoying.

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

#38
post #6

why should I use Zig coming from Python/Go ?

Zig is much lower level than Python or Go. This means that you can write programs that use very little memory and run really fast. If minimizing memory use and maximizing speed are your primary objectives, Zig could be a better fit than Go or Python.

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

#39
post #7

Zig 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…

> 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 stupid decision years ago and they refuse to make it better

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.

Re: Zig, the Small Language

#40
I love zig but I have two pain points. Function naming convention as camelCase. I can overlook that and use snake_case in my code, which I do and people frown upon me. Second is inability to turn unused var check off.
Post reply on HN