Comment by artemonster
2 months ago
Tried trying zig, but was baffled by all the allocator dance you need to do and asking nicely to access a list (catching potential exceptions?) Tried odin, but the tooling is very raw. Tried rust, didnt want to try to please borrow checker that distracts me from my thoughts.
Idk, if someone just reinvents clean C without the nonsense garbage with some modules and package manager this will be a huge win. Let me access my null pointers, let me leak memory, just get the hell out of my way and let me program and hold my hand only where I want it to be held - sane types that give me refactoring, code completion and code understanding, modules with imports. Let compiler give sane error messages instead of this cryptic c++ garbage. Is this too much to ask?
D's "Better C"[1] mode looks like what you describe. Has syntax similar to C with a real module system, metaprogramming, slice types etc.,
1 - https://dlang.org/spec/betterc.html
I also had a brief look at Zig for writing a WASM module, but settled for Rust. I had no real gripes with the language, but the spartan documentation made making progress into a slog.
I wouldn't mind a "better C" that could use an LLM for static code analysis while I was coding. I.e. be more strict about typing, perhaps. Get out of my way, but please inform me if I need more coffee.
Allocation in Zig takes some getting used to but it's actually really nice. It took me a few weeks but I honestly believe you should give it another chance and more time
I personally find it much more ergonomic to have the allocator attached to the type (as in Ada). Aside from the obvious benefit of not needing to explicitly pass around your allocator everywhere, it also comes with a few other benefits:
- It becomes impossible to call the wrong deallocation procedure.
- Deallocation can happen when the type (or allocator) goes out of scope, preventing dangling pointers as you can't have a pointer type in scope when the original type is out of scope.
This probably goes against Zig's design goal of making everything explicit, but I think that they take that too far in many ways.
There is no reason you can't attach an Allocator to the type (or struct, in Zig).
A fairly common pattern in the Zig stdlib and my own code is to pass the allocator to the `init` function of a struct.
If what you mean is that allocation should be internal to the type, I don't agree with that. I much prefer having explicit control over allocation and deallocation.
The stdlib GPA for example is pretty slow, so I often prefer to use an alternative allocator such as an arena backed by a page allocator. For a CLI program that runs and then exits, this is perfect.
Same can be said about Borrow Checker.
looks like zig is exactly what you want. Difference only in std. C prefer global allocator, while zig ask it explicitly.
So, if only there is std with implicit allocators?
C's compilation unit model, lack of a formal module system and lack of language-level package management are the best things about it.
Separating interface and implementation is a good thing, but often you just want to split things into separate files without separate compilation. C supports #include and so it is maximally flexible.
[dead]