All it takes is one internet search with the words “zig style guide” to find countless examples to pull from online.
"Countless"? You should be able to find, say three style guides that talk about how to prevent memory errors then right? Because my one search didn't find any.
There are definitely some cases where memory safety isn't especially important:
Single player games
Apps that don't process external data (e.g. a simple calculator).
Lots of things running on microcontrollers, where the form of input could never possibly cause any security issues. E.g. a motor controller or a basic syringe pump or a (non-smart) washing machine or something.
Tests, e.g. I've considered writing RISC-V tests in Zig. They're traditionally written in C or assembly.
In cases like those, memory unsafety mainly leads to non-security bugs and annoying debugging sessions. But I wouldn't say it's as much of a deal breaker compared to e.g. writing a video codec or font renderer or web browser or DNS server or whatever.
I still think Rust is a better choice than Zig in most cases anyway, even ignoring memory safety. But in these cases it's at least a defensible choice.
Lol... I'm sure there's a meme or graph for where you are in learning C to believe this.
then translates to assembly code with a very predictable pattern.
Even this is a stretch. Modern C compilers can do some wild transformations. I assume you've seen the classic one where UB makes it jump to a function that you never actually call.
bash scripting is well-defined
Yeah I mean Bash's problem isn't that it's poorly defined - it's that the definition is awful!
C is firmly in the "not fun" camp with PHP, JavaScript and Bash. I'd say even assembly is more fun, in a puzzle challenge sort of way.
The most fun language I've used is QuakeC, because the only thing you can do with it is write Quake mods. It was a pretty neat language too from what I remember. It even automatically detected infinite loops!
Zig is way better than C in many other respects, so if you want a modern sane language and you're either a Rust luddite or working on a project where memory safety isn't that important, it might be attractive.
Like, if the choice is C or Zig, then Zig is pretty much a no-brainer (or it will be when it hits 1.0). It just fixes so many insane things about C that have been broken for literal decades.
No Zig definitely is special. You don't have to do any extra busy work to call C code - you can pretty much just #include the header and that's that. It's similar to calling C from C++.
In any other languages - including Rust - you have to do some work declaring functions, wrapping them and so on. It's not hard but it definitely is a non-zero amount of tedious work (especially before AI). There's absolutely no way you could describe it as "trivial", unless someone else has already done that work for you.
But I don't think it is a significant Zig advantage really. When I'm writing Rust, it's extremely rare that I want to call any C code that someone else hasn't already done the tedious wrapping for.
Well it seems a bit hollow for the Zig developers to say "there's no problem - just use a style guide!" when they themselves don't even use one and the only one they can point to just says "never dynamically allocate".
To be honest I don't see how a "style guide" is going to help. C++ has had all sorts of guidelines and style guides for decades and it helps a bit but... not really.
What does the Zig compiler's own style guide say about avoiding memory errors? As far as I can see nothing?
It's definitely better than C but I'm still unsold on the memory unsafety. Especially after the supposed answer to Bun's memory bugs was "just never dynamically allocate".
comptime is definitely neat and there are some other nice features but tbh it seems like the only true advantage it has over Rust is compile time, and only for incremental compilation. Is that enough? I would say probably not.
GitHub. You're hosting public stuff so there's no more risk of your data being sold on GitHub than anywhere else public. GitHub is what recruiters understand and expect.
I'll get downvoted by extremists but this is the best option if you want a job and aren't also an extremist.
I would consider Codeberg or maybe even Tangled for actual projects you're working on, but for just showing stuff of there's no advantage to not using GitHub.
Not exactly. It means that any of the code could lead to memory unsafety, but it's still better than Zig or C because you still only have to read 5% of the code to debug/fix those issues, instead of 100%.
5% is clearly better than 100%. Whatever else you think about this port you can't argue against that. In fact I can prove that it's better.
Does Rust's memory safety design improve memory safety? Yes, this is proven by experience (e.g. see Google's blog posts).
Does "normal" (not slop) Rust code rely on someunsafe? Yes. All Rust code must use some unsafe because it's used in the standard library, and even if you ignore that (there is an effort led by Amazon to formally verify it), it's usual for Rust projects to use at least some unsafe. Let's say 0.1% of lines.
So 0.1% unsafe is clearly better than 100%. Is it possible for 0.1% unsafe to be better than 100%, but somehow 5% isn't? That would require things to be non-monotonic which is completely implausible.
He doesn't appear to be using any features of Lisp that made it "the language of (70s) AI". You could do all of this just as easily in many other languages.
Portability: It means you can change your hardware target and you only have to worry about re-certifying this, instead of an entire compiler.
Testing: You can probably run your WASM code fully deterministically in a deterministic simulation much easier than native code. Also when developing you don't need the actual hardware.
Isolation / compartmentalisation. If I were them I would be strongly considering using the WASM component model (in future).
It would be good if they put their actual motivation in the readme though.
It doesn't mean you made the wrong decision. Changing the names has a potential cost - you break something (this is especially risky for environment variables which have insanely global scope, no static type checking, etc.).
Not changing the names has a potential cost too - causing confusion in future, wasted time, or even bugs due to the increased chance of mistakes.
I'm currently leaving a company where they almost never clean up their messes. Tons of old unused code is just left in the repo. Causes huge wastes of time.
Don't underestimate the potential cost of not keeping things orderly. There was a famous case (Knight Capital) caused by not cleaning up an old unused CLI flag and it cost them $440m and destroyed the company.
It definitely is capable of it now, if you put some effort into guiding it, and you're working in a popular domain/language. It couldn't really do it a year ago though so you might just be a bit out of date.
"Countless"? You should be able to find, say three style guides that talk about how to prevent memory errors then right? Because my one search didn't find any.