> The core team will then be able to begin thinking about: ... Exploring hot-code-swapping
Hot code swapping, plus Zig's ability to cross-compile, plus release-safe's memory assistance without mental overhead, all seem to come from one underlying drive: support and empower the programmer without getting in their way.
When designing a language, it's important to keep the user's ultimate goal in mind: making useful software. For some domains that might mean adding restrictions, but for other domains it means getting out of the programmer's way and making language mechanisms and tooling so they can iterate, experiment, and build faster.
I'm particularly excited about Zig's future in webassembly, where many safety concerns are already handled by sandboxing. It's amazing to read that someone ported an entire game to webassembly with Zig.
* Comptime, which can serve the purpose of generics without a new sub-language [1]
* Colorblind async-await, basically parameterizing async-ness to avoid the downsides of async's infectious nature [2]
* Hot-code swapping proof-of-concept [3] (Edit: specifically, new to low-level languages, AFAICT)
Pretty cool stuff!
[1] https://kristoff.it/blog/what-is-zig-comptime/
[2] https://kristoff.it/blog/zig-colorblind-async-await/
[3] https://www.reddit.com/r/Zig/comments/s9toy1/we_have_a_worki...
I kind of dont like Zig because of the syntax its just a little out of the norm from what I'm used to. I like D more if I want to go the C-like route, just hate that its not quite as popular as Go or Rust seem to be. Currently I'm diving into Nim more than anything though, it feels like the sweet spot for me.
But it shouldn't be easy to program in memory errors.
I'm still waiting for a flag to disable runtime bound checks
I don't want to leave a purely negative comment so I'll add that the only reason I'm posting in the first place is because, my own personal annoyances aside, the language does look very nice. Especially comptime, I wish every language had a similar construct built in as seamlessly as it is in zig.
I use this method to build a zig compiler to work with, and when I build a release build of my zig-project I switch to the official compiler and fix the handful 'unused variable' errors. Works fine for me.
That's nuts, both in a bad and a good way.
Giving it a bit of time is a good way to get used to it and ends generally (at least in my opinion) in better code.
Outside that :shrug:
But I think it is less annoying than trying to figure out why things aren’t working at runtime. It’s an interesting trade off, but I appreciate zig trying something different here.
Making it an optional flag has the issue of making it easier to just say "just compile this always with --allow-unused-vars" instead of cleaning up the code. We kinda see that happening with warnings in C/C++.
That said, I too think we should investigate if there's a reasonable middle ground that could be found.
- If you ever want to allocate memory, you have to pass in an allocator to the function doing the allocating. You also have to explicitly allocate and deallocate.
- Zig has no concept of a string - it’s just a slice of bytes. This also means Zig has no support for string concatenation, UTF-8, regex, or any of the other many niceties we’ve come to expect as standard.
Zig is not the next Rust or the next C++ - it’s very much the next C.
Zig may be fine for people programming an OS or very highly performance sensitive application. But it’s too low level, and too obtuse about being low-level, for me to ever want to actually use it.
- Regex can be provided as a library and specialized at comptime. There's never been a need for regex to be part of a primitive type and many other languages do fine without it. Concatenation is a question of "where do you allocate memory" as you have explicit allocation it's not clear what zig should do with it thus the default is to let you call std.mem.concat and dealing with the possible failure or having a look at the problem and asking if you really need concat in the first place. Often you don't as formatting string is better done with std.fmt and ArrayList(u8)'s writer().
I used to think the same thing but it makes sense that for a finite state machine, the matcher doesn't need to work with validated strings at all.
You should read the first 2 paragraphs of burntsushi's (wrote rust regex implementation and a lot more) doc comment here: https://docs.rs/bstr/latest/bstr/#when-should-i-use-byte-str...
And that is great, once Zig is fully settled down we need something like Objective-Zig, or may be call it Zag.
So far Rust has the smallest of inroads to embedded.
I hope Zig makes it, but I’ve been down this road before.
I currently use Nim for our firmware at work, because at the end of the day —compileOnly means it’s just C. It’s been excellent for ESP-IDF/FreeRTOS, but I’d love to see Zig tackle it as well.
One lovely side effect of using Nim is our “business logic” code is remarkably simple in the firmware, as I got PPPoS working nicely with our Cat-M1/LTE NB-IoT modem, so making network requests is literally a single line of standard-library Nim. Quite lovely!
The less we have to write C/C++ the better, and I’d love to see Zig and Rust do a great job in embedded-land!
Getting to use Nim for your day job sounds like a dream! I'm particularly keen on Nim's UFCS
> The standard library can be used unmodified on freestanding targets thanks to explicit allocation, comptime is extremely useful for things like precalculated lookup tables, and the unfinished C backend (part of the stage 2 compiler) means we’ll be able to target exotic architectures that LLVM can’t.
Even when I was single I don't remember having that much time. Chores, making dinner, keeping in touch with friends and family would have left me with less than 40 hours if I'd worked 60 hours.
I'm impressed with their diligence.
