People be dead bland picking a name for the project. Once Rust had the same trend of tagging everything with a postfix "someproj-rs" and now every zig project I come across has some kind of Z-prefix "Zsomeproj, Z this, Zthat" like you can't even have a proper name? This is no hate people, but please don't produce eyesores
A learner here with a quick confusion. I was skimming through the internet for VM tooling and implementations, parsers specifically and came across this "prattle" crate which seems to be a general purpose pratt parser library. And I have not much to say about the library itself, it seems like an abandoned project in early development phase.
The thing that caught my eye was the demo piece of code they had on their docs, specifically
#[derive(Clone, Debug, Eq, Hash, Ord, PartialEq, PartialOrd)]enum CToken {Var(String),Add,Mul}
impl Display for CToken {fn fmt(&self, f: &mut Formatter) -> Result<(), Error> {
write!(f, "{:?}", self)}}
the enum CToken has already derived debug yet the example implements Display for CToken only to just debug print it as well. Is this some kind of a safety mechanism or fallback just in case the user writes
println!("{}",token) instead of debug printing it?
Or is something else going on I don't yet know about?
It's a funny contradiction how people be blatantly programming in dynamically typed languages like python yet scramble everywhere for type verification with type annotations and packages like pydantic. Why use a dynamic language if you need static type system guarantees at? Get a real language at this point dude.
Okay, aside the sarcasm this is a genuine critic, cry for help or curiosity post. I am a beginner to zig, familiar to C family of languages and a recent interest to a custom VM implementation brought me to zig. I've been exploring it for a couple of days only so pardon for my limited insights.
Zig surely is opinionated as well as quite stubborn and in a wrong way many times. Unused variables and even function parameters are hard errors rather than warnings. Like why?
I like the idea of pure control and absolute performance but why do we need to explicitly pass allocators everytime? Why not have defaulted allocator parameters just in-case? Maybe at least for less critical API.
Giving only single errors at a time in this age paired with lackluster lsp (maybe cause the compiler itself gives just one error at a time and lsp depends on compiler diagnostics) makes using the language pretty hectic. Leave alone all other use cases, how is any change that cascades to be caught ergonomically?
There could be multiple errors and all you see is a single one so you fix that and run the compiler thinking it is done and surprise, it's another error and the same cycle of "fix -> compile -> error" continues. It's so stupid that it's funny, and salute to those who are developing and maintaining large projects like ghostty and tigerbeetle with such lackluster tools.
So it's quite a bit of friction going forward and I am really questioning whether to keep going with zig ( does it get better, or there are work-arounds or other tools that help minimize such painpoints?). What's others noticeably (good or bad) in Zig from your experience? Please provide your 2 cents.