Our great sponsors
-
zig
General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
open-reckless-drivin
A work-in-progress open source reimplementation of the classic Macintosh shareware game Reckless Drivin'
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
> If zig supports compiler hooks, then it could conceivably halt compilation unless these invariants are satisfied.
Can you sketch out why hooks are necessary on the proposals, like 14656 ? So far I have not read a justification, what the advantage of coupling it to the compiler provides as performance gains on concrete examples. Afaik, Rust has lifetime checks decoupled to parallelize compilation and I have not seen research or a list of the possible optimizations with synthetic benchmark results.
> I'm not convinced that this needs to be in the type system.
If you want to prevent static analysis semantics becoming an incompatibilty mess like C due to 1. unknown and 2. untrackable tag semantics, then you have to provide a at least an AST to ensure annotations have known + unique semantics as I explain in https://github.com/ziglang/zig/issues/14656#issuecomment-143.... I would say that this is a primitive quasi-type check decoupled from main compilation and could be kept very flexible for research experiments by having an uri + multihash (so basically what Zig uses as package).
More concretely: Stuff to look out for is RefinedC and related projects to have more strict C semantics + how to compose those things outside the regular Zig type system.
I would suggest you to checkout Odin[0]. It's very similar to Zig but has much better ergonomics and probably the closest to a 'Better C' replacement in my experience.
[0] - https://odin-lang.org
There is no single "zip". Java's .zip() will work on two sources, as will C#'s Zip(). Haskell's zip is no different, only accepting two parameters. I don't know any language other than Python that shares Python's iterator zip() implementation.
In implementation, Python's zip will return a generator that is iterated over using the iterator functionality, while Zig's .zip is compiled as a loop. Python's iteration may be turned into a loop, it may be interpreted, or it may be turned into some other kind of bytecode, who knows. The standard cpython implementation is much more complex, though: https://github.com/python/cpython/blob/main/Python/bltinmodu...
Concatenating zip()s is an unnecessarily complex solution, both in terms of syntax and in code generated. In Python this may not matter because it's a relatively slow programming language in general (the language often being "glue between fast C methods"), but in Zig this can easily become untennable.
I also disagree that you don't need more than 3. As the article states, if you leverage array-of-structs rather than struct-of-arrays you can use this to "deconstruct" objects without paying the memory usage penalty of struct padding. The 15% wasted RAM in this example is relatively small compared to some real use scenarios; something as common as a 3D vector will often have a whopping 25% space waste.
Other languages allow this as well (and often using such iterations are much faster than zip()ing lists together) but the lack of guarantees and repetitive syntax becomes a pain.
For Zip it's TrustedRandomAccess[0] instead of TrustedLen. Imo the most radioactively unsafe trait in the standard library and will likely never be stabilized in its current form.
[0] https://github.com/rust-lang/rust/blob/f540a25745e03cfe9eac7...
I’ve absolutely had satisfaction with my several personal projects written in Zig. And based on an imperfect measurement (GitHub stars) I have also had moderate success in making something useful. It’s a terminal fuzzy finder [0]. I also maintain a Zig Lua bindings package [1], and I’m working on a port of an old Macintosh game [2].
Zig is exactly what I want out of a language though, so take my opinion with a grain of salt :)
[0]: https://github.com/natecraddock/zf
[1]: https://github.com/natecraddock/ziglua
[2]: https://github.com/natecraddock/open-reckless-drivin
I’ve absolutely had satisfaction with my several personal projects written in Zig. And based on an imperfect measurement (GitHub stars) I have also had moderate success in making something useful. It’s a terminal fuzzy finder [0]. I also maintain a Zig Lua bindings package [1], and I’m working on a port of an old Macintosh game [2].
Zig is exactly what I want out of a language though, so take my opinion with a grain of salt :)
[0]: https://github.com/natecraddock/zf
[1]: https://github.com/natecraddock/ziglua
[2]: https://github.com/natecraddock/open-reckless-drivin
I’ve absolutely had satisfaction with my several personal projects written in Zig. And based on an imperfect measurement (GitHub stars) I have also had moderate success in making something useful. It’s a terminal fuzzy finder [0]. I also maintain a Zig Lua bindings package [1], and I’m working on a port of an old Macintosh game [2].
Zig is exactly what I want out of a language though, so take my opinion with a grain of salt :)
[0]: https://github.com/natecraddock/zf
[1]: https://github.com/natecraddock/ziglua
[2]: https://github.com/natecraddock/open-reckless-drivin