Very little of the language is available at comptime. Allocation is unavailable and the zig developers have declared this a non-feature. That either locks out or requires redundant implementations of a great many things.
If you look at puffoflogic's comment history you can see they are maliciously claiming incorrect things about zig over and over. Here I am refuting them again.
FBA was usable last time I tried zig, but I don't count it because if you knew ahead of time how much you needed to allocate, well then you didn't need an allocator at all. I.e. I define "allocator" to mean "dynamic allocator". Note that the buffer provided to FBA would have to be provided at the very top.
Fixed-size allocators are not composable. You cannot write any kind of comptime routine which calls further routines which need to do allocation, and how much allocation they do is based on arguments to your routine - except by forcing your caller to calculate how much allocation needs to be done. But that leaks your implementation details to your caller, largely invalidating the point of making some kind of comptime routine in the first place. Therefore comptime can be used as a toy, or in C-style language-enforced NIH mode (where you [re]write every single routine you need yourself, or at least know the intimate implementation details of all of them), but not in a serious programming stance.
If I remember right, FixedBufferAllocator requires you to set an upper bound for the amount of memory you allocate -- you don't have to get the number exactly right or anything.
Runtime allocators also have a limit to how much memory you can allocate. It's usually higher, but there's still a limit. Your computer doesn't have an infinite amount of memory.
> if you knew ahead of time how much you needed to allocate, well then you didn't need an allocator at all.
Sure, if it's all code you're writing yourself then it's doable to avoid using an allocator. If you want to reuse existing code that does expect an allocator, however, then being able to use a FBA is handy.
You can just return arbitrarily large arrays or whatever, but this is probably not what you want because it's a separate implementation from the one that takes an allocator. I think if FBA works then you have the building blocks to make one that does not fail by running out of memory e.g. by doing the FBA thing but getting a bigger backing array whenever you need it.
Overall I am not the right guy for this conversation because I am too used to never calling mmap at runtime either.
> it's a separate implementation from the one that takes an allocator
I want to give zig a fair assessment so yes, this is absolutely right. This is why I have elsewhere said that zig is basically two separate but superficially similar languages. You can probably accomplish just about anything in comptime zig, if you're willing to completely reimplement it from the core language up. The limitations I mention come in if you try to write code to be used in either comptime or runtime zig. So comptime zig has no growable arrays, no dictionaries, no string searching, no regexes, etc. etc. until these are reimplemented specifically for comptime zig. Mostly this is just sad, that a decent idea was implemented with such a terrible downside that would be so easy to fix: just add allocators. Just. Add. Allocators. But no, the zig team has explicitly rejected this.
> Just. Add. Allocators. But no, the zig team has explicitly rejected this.
I'm torn on this. To me, comptime is the C preprocessor but sane. Anything you can do above that is bonus. I don't need comptime to be totally Turing complete.
And, I do NOT want macros in the language. Macros are a bottomless well of suck. Lisps/Schemes still tie themselves into knots with macro hygeine. Rust's procmacros are terrible and debugging them is worse--just try figuring out what some intermediate expansion did.
The point of Zig is to NOT be Rust/C++/etc. The point is to be C with a bunch of the sharp edges and corners filed off. It's not for everybody. If you want web services, use Go. ML/AI--Python for ecosystem. Rust for strong safety guarantees.
Zig has some nice things while still remaining relatively small. It, like most modern languages, understands that ecosystem is important. It does a better job than almost everybody at cross compiling. comptime gets you a lot of the benefits of templates while dodging lots of the suckage.
However, at some point, you have to declare "Stop, that isn't going to be part of the language" or you wind up with the ungodly mess that is C++.
You can string format using `std.fmt.comptimePrint`[1]. For example, combined with features like `@compileError`[2], it allows you to make your own error messages (useful for generic functions)
