Zig is becoming more production-worthy(zigmonthly.org) |
Zig is becoming more production-worthy(zigmonthly.org) |
> 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.
- 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.
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.
Enjoy D now when it's more mature. The betterC switch is especially interesting.
I love KISS and Zig's simplicity especially but there is two sides to programming.
The engineers perspective and the user perspective.
I am both and prefer to have more paid hours and safer software ;)
I'm not sure it's nuts to build the compiler to 'fix' this, though. Customizing and building a tool really isn't such a big deal when you think about it.
I once said I would like arrays of 33 or more items to be Default and my resident Rustacean told me step 1 is to rebuild libcore after changing the appropriate macro :)
One of my favourite parts about UFCS is how it can turn C libraries that I've had to bind into nice clean looking interfaces!
esp_err_t sw_enableRx(SwSerial *self, bool State)
proc sw_enableRx*(self: ptr SwSerial, State: bool): esp_err_t {.importc: "$1", header: "<SwSerial.h>".}
var port = sw_open(params, etc)
port.enableRx(true)Nim almost feels like I'm writing a dynamic scripting language, except that I've worked with a typed python code base and it sucked because typing always felt taped on. With generics in Nim I feel like I'm duck typing, but my ducks are compile time checked!
I'm keen on experimenting with protocol oriented programming and as far as I understand, UFCS provides this really neatly to the language. I really like the idea of being able to define my own types and have them seamlessly work with functionality of other libs (and vice-versa) without needing to resort to a language feature like traits.
One piece of advice I can give, is functional programming (which I am a huge proponent of), as defined by a tonne of chained/composed operations on sequences
.map.filter.etc.etc()
You can still use a lot of FP ideas though, but one thing I always remind myself is at the end of the day Nim _is_ C, C is the output, so working within that idea helps a lot in terms of keeping things optimised with little effort on my behalf!
[1]: https://gavinhoward.com/2022/04/i-believe-zig-has-function-c...
The original color article is soo annoying, because it presents two things as one: a JS-specific limitation, and author's arbitrary opinion on how async syntax should (not) look like. Since then even languages that don't have JS's limitation still keep chasing the other point, because otherwise they're shamed for having "color".
It's not a question of inventing it, but rather of making it mainstream popular.
Oberon used hot code reload for OS modules.
Visual C++ has had edit-and-continue for years, and hot reload as improvement since the last two years.
Hot-code swapping seems to require a lot of tricky code. Are there compelling use cases that justify the implementation effort?
The examples seem to be mostly focused on swapping out functions but I dot see how it could handle structural changes to data structures.
I'm not sure you are using the same notion of "colorblind" as most people. All that is claimed is that much application code can be *compile time generic* over the async-ness of the I/O functions it calls. Stepping up the requirements to being runtime generic introduces some difficult concerns about the different error sets of different I/O functions, but async vs. non-async can be handled as in the above gist or by writing like one switch statement.
Months later I read Gavin's post (linked above). I found that post immensely helpful to understand Zig's design around sync/async function colors (thanks Gavin!). Gavin's post helped to illuminate for me that Zig functions do have colors, but that the compiler can infer the color in most usual cases. This is still very exciting!
As I see it, it's not to Zig's detriment whether it "has" function colors or not, I don't really care. I'm really excited about Zig either way. But I personally (coming from a decade+ of JS/Python/Go) found the verbiage I found used to describe Zig's behavior here confusing.
Not only do threads not really do the thing (in part because of the high cost of threads compared to alternatives), the alternative isn't only threads. Users of Lua, Greenlet, ucontext_t, libco, etc. have been able to write single-threaded code that's generic over the async-ness of its callees for decades. Recently there's a trend toward preferring needing to change 99 call sites and function signatures when adding a single piece of I/O to a single function though, needing to write two versions of each library, etc.
Plenty of coments of mine where I list what exists since their early days.
Yes, C++ compilers like Visual C++ support it. Or Unreal tooling like Live++.
Common Lisp is only hot-swappable when you're not running a binary, at least from what I know of SBCL.
So, it's hard to take your comment seriously. I am unfamiliar with Visual C++'s hot-swapping capabilities, but to claim the language itself can do it seems pretty ridiculous to me, as all you've got is machine code at runtime, C++ has no hot-swapping runtime and could never have one... which makes me think you're just confused about what we're talking about... I am not talking about debuggers here.
Maybe spend some time using proper Lisps like LispWorks and Allegro Common Lisp.
Language and implementation aren't the same thing.
There is so much to learn about compilers, young padawan.
Which is false.