The Zig Programming Language
Andrew Kelley (via Dan Luu):
Zig is an LLVM frontend, taking advantage of libclang to automatically import .h files (including macros and inline functions). Zig uses its own linker (LLD) combined with lazily building compiler-rt to provide out-of-the-box cross-compiling for all supported targets. Zig is intended to replace C. It provides high level features such as generics, compile time function execution, and partial evaluation, yet exposes low level LLVM IR features such as aliases. The Zig project believes that software can and should be perfect.
I liked the discussion about failed memory allocations and how Zig gives you a lot of information when an error occurs.
The entire concept of the heap is strictly in userspace. There are some standard library features that provide and work with heap allocators, but those are optional standard library features, not built into the language itself. If you never initialize a heap allocator, then you can be sure your program is never going to cause heap allocations.
Update (2019-07-05): Andrew Kelley:
The Zig community grew in size so much, that some weekends I found myself with only enough time to merge pull requests and respond to issues, and no time leftover to make progress on big roadmap changes.
I found this both exciting, and frustrating. Here I was working on legacy code 40 hours per week, while multiple Zig issues needed my attention.
And so I took the plunge. I gave up my senior backend software engineer salary, and will attempt to live on Patreon donations.
2 Comments RSS · Twitter
Why would you want to make functions throwable in the first place?
An Option to remove null is the right thing to handle all error cases without stacking them like classes and inheritance.
You only need a lint to check all paths to have the according return.
This is funny how they clam that this should be a readable and expressive language, but they are trying very hard to make thing as short as possible (and so unreadable and inexpressive).
Using 'pub' for public, 'fn' for function, '!' instead of throws, etc…
Wouldn't 'public func main() void throws' be far more readable than 'pub fn main() !void' ?