May I ask what the hype is with Zig? What makes it so attractive?
Is it the performance? The easy interop with C? The ease of controlling the memory allocation?
Zig is hard but worth it
201–210 of 307 posts
Re: Zig is hard but worth it
#202Earlier quoted context omitted.
I disagree. I actively avoid languages that rely on package managers simply because they only give the illusion of being beneficial. It ends up being more boilerplate I have to learn to use an ecosystem, because they don't actually solve dependency hell and now there's a whole additional complicated tool with its own DSL I have to contend with in order to fix what's broken (or even diagnose issues.) The more peripher…
Just curious, not snide: what language fits this criteria? C/C++? Using Python 3.7+ in a way that completely ignores Pip, because the stdlib is now quite expansive?
Odin
Re: Zig is hard but worth it
#203Earlier quoted context omitted.
I disagree. I actively avoid languages that rely on package managers simply because they only give the illusion of being beneficial. It ends up being more boilerplate I have to learn to use an ecosystem, because they don't actually solve dependency hell and now there's a whole additional complicated tool with its own DSL I have to contend with in order to fix what's broken (or even diagnose issues.) The more peripher…
I agree entirely. Relying on a package manager in order for a language to be useful indicates to me that there's a deficiency in the language.
Is every language supposed to come with HTTP and TLS stack, clients for every database, de/serializers for every format, every image and video codec, every de/compressor, GUI toolkits, 3D rendering, Bluetooth… where do you stop?
And then how do you maintain all of this bloat to a competitive level, so that users don't need to reach for faster/newer alternative packages anyway?
And how do you maintain portability and backward compatibility of a language with such a vast API surface?
In modern development there's just too much stuff to keep everyone happy with batteries included. Sooner or later users will need something that isn't built in, and that will cause pain and crappy workarounds if the language doesn't have first-class support for dependencies.
Re: Zig is hard but worth it
#204My main issue with Zig is that I’m scared to invest time in writing something nontrivial to see the community/adoption flounder then regret not using Rust or C++ later The language itself is fun. The explicit-ness of choosing how allocation is done feels novel, and comptime is a clean solution for problems that are ugly in most languages. Aside from lack of community I’d say the biggest nuisance is error handling in…
My impression of the Zig language as a total outsider is that it seems like it has the underpinnings of success: it has a niche, it has a governance model, and it has real commercial users. It just has to not blunder very hard on the way to some level of promised stability.
Re: Zig is hard but worth it
#205Earlier quoted context omitted.
It's significantly nicer to write than C (my opinion obviously). I see it as a general purpose language. But mostly the team decided to do this because we wanted to unify on one language and double down on the investment in Zig. I'm not a fanboy (nothing wrong if anyone is, just clarifying about myself); I think this choice was right.
I guess I don't see C as programming language for writing scripts in either. In my view any language that requires a separate complication step is not a scripting language, and therefore not a language in which one writes scripts. In C or Zig you write programs. Maybe I am just being too pedantic.
I didn't call it a scripting language. Nor do I think C would be great to write scripts in either. :) I only said we write scripts in Zig. But if you'd like to call these files programs instead of scripts then that's ok too!
Re: Zig is hard but worth it
#206Earlier quoted context omitted.
FWIW Zig can do that without operator overloading: https://www.godbolt.org/z/7zbxnncv6
First of all that only works with vectors, but I want operator overloading to also work on things like matrices or custom types (for example quaterions, or a symmat3 struct that represents a symmetric 3x3 matrix using only 6 floats). Additionally, for efficient math code you often want vector / matrix types in AOSOA fasion: for example Vec3 to store an AVX lane for each X/Y/Z component. I want vector/matrix operation…
I have a marvelous proof that you can solve that with comptime but unfortunately the margins of this website are too small to contain it.
Re: Zig is hard but worth it
#207Earlier quoted context omitted.
Will Rust keep growing? Yes, I think so. Will it turn into a C++-like monster? I don't know. Maybe, but when it comes to C++ it always feels like its "monster" status is largely a result of previous mistakes or early design decisions piling up, and causing trouble (eg. C-style arrays, exceptions, implicit conversions, fiddly sum types rather than first class support, no pattern matching etc.). Rust will grow large, a…
> Time will tell if we'll eventually look back some of Rust's design decisions as bad or unwieldy (probably). I think time has already told for things like async and lifetimes.
Can't say much about async, since I really lack the experience to say whether async in Rust could feasibly and realistically be much better than it currently is. Some people say that it'd be great if it worked as effortlessly as in Go, but I assume that you don't get to have that without performance tradeoffs.
As for lifetimes, what's the issue? Do you have any reason to believe lifetimes are frustrating because they were badly designed, rather than the fact that they're making complexity explicit which was previously hidden?
Re: Zig is hard but worth it
#208Earlier quoted context omitted.
Rust hasn't grown in scope very much since its release, but in places where it has grown, particularly async and unpin, I find that there features interact very badly with lifetimes and borrowing. I am often forced to ditch borrowing across async method calls and to put everything in Arcs, even when the lifetime is well-defined and it could be easily used if it had been scoped threads instead of futures. I fear that…
Technically though, isn’t memory safety not necessary in some cases? For example, single player video games. You can exploit your own machine if you want, but that’s not an issue. I like rust, but if I ran into async issues and annoying stuff, I could see a world where I grab a non-memory safe language to make games easily.
It is an issue if it also allows players to work around DLC and other goodies.
Or if having the game on the system can be used by another malicious application as jumping point into root access, starting it as subprocess and injecting the exploit.
Example, Windows attacks via Notepad.
Re: Zig is hard but worth it
#209Earlier quoted context omitted.
Have you tried bevy? I’m starting with bevy for a non-game project, but I’m blown away by how simple it is to use once you get used to the magic.
Bevy isn't on the same level as tools like UE and Godot.
Depends on what you're doing. I'm writing a non-game app that requires a scenegraph, raycast mouse selection tool, and other tools of the sort typically required by games and provided by a game engine. But there's a lot of game stuff I don't need, and I need to make major customizations to the rendering engine. It ended up being easier to implement in bevy, due to its modularity, than it would have been in UE4 or Godot.
Re: Zig is hard but worth it
#210Earlier quoted context omitted.
For 'game-ey' math code, a matrix is at most 4x4 floats (64 bytes), that's fine for a value type that might live on the stack. vec2..4 and matching matrix types up to 4x4 is basically also what's provided in GPU shading languages as primitive types, and personally I would prefer such a set of "SIMD-y" primitive types for Zig (maybe a bit more luxurious than @Vector, e.g. with things like component swizzling syntax -…
You might like Odin, it has a similar philosophy to Zig and supports swizzling: https://odin-lang.org/docs/overview/#swizzle-operations Matrix types are also built in: https://odin-lang.org/docs/overview/#matrix-type I’ve thought for a little while that Odin could be a secret weapon for game dev and similar pieces of software.
I'm actually dabbling with Odin a bit in the scope of language bindings for the sokol headers:
https://github.com/floooh/sokol-odin
It's a very enjoyable language!