This post was fantastic! Super well written and super interesting. I really liked the strategy of showing the same code over and over again with minute changes.
Thanks! I worry about that being too repetitive, but I do really prefer it when the steps are shown methodically and not elided… it’s just too easy to skip the wrong thing, thinking “oh everyone knows that bit” but maybe some people don’t and suddenly you’ve lost a chunk of people.
It’s great. It’s like watching a video of someone coding, but with advantages of a text medium.
I also never thought of a Brainfuck interpreter as a good Hello World type of a project. It’s actually quite a practical example - memory initialization, strings, basic io, parsing, error handling. Now that I think about it, I would like to explore the same for Rust, Pony and some Lisp variants.
It was a great writeup. Brainfuck is only drawback given it’s intentionally designed to give folks a headache. I used to recommend folks do these examples on p-code or Forth for easier to follow interpreter or just more useful. Be interesting to see p-code or Forth done like this Zig write-up in Zig itself or another language.
I really like what I’ve seen from zig and started trying to build it last night (currently fighting with a cmake issue building llvm and clang). I played with it months ago and just decided to again now that I have some time. This post looks really thorough and I look forward to going through it all in more depth once I’ve got the compiler built. It seems like exactly the kind of post a young language needs. Thanks.
Slightly off topic, but does Zig offer safety for concurrent access? I feel it’s a required feature nowadays, and a strong point of Pony or Rust. Zig looks very good, though.
Zig currently supports coroutines via async/await keywords and the
promise type. This can be used to build a single-threaded event-based
non-blocking I/O.
I’m working on a proof of concept TCP server to demonstrate this.
Next I will add kernel threads to the standard library. And then I will update my TCP server proof of concept by multiplexing the coroutines onto a thread pool.
That’s great, although why not futures instead of promises? I find promise an awkward term, as promises should not be broken, while futures are neutral in this respect. Mozart/Oz uses the terms futures, for instance.
I guess my question was if there was any safety mechanism within Zig to prevent concurrent access to shared memory.
Is this a question of syntax rather than semantics? I don’t really have a preference between promise or future. I think it’s important to figure out the semantics before 1.0.0 and then before releasing that version we can go through and do a syntax pass.
As for a direct answer to your question: no there are currently no data race prevention features in the language apart from atomic built-in functions.
It is a bit of both, I was pointing out that conceptually a promise should not be broken, and that then the term is less representative than futures to denote asynchronous events that might happen (or might be cancelled). Promises also come with some additional connotations, which futures don’t have. I was asking the question because I’m quite interested in terminology, especially in the context of programming languages and APIs. But in short if you can change from promise to future, I think you would be ideal for these reasons ;) thanks for your answers!
This post was fantastic! Super well written and super interesting. I really liked the strategy of showing the same code over and over again with minute changes.
Thanks! I worry about that being too repetitive, but I do really prefer it when the steps are shown methodically and not elided… it’s just too easy to skip the wrong thing, thinking “oh everyone knows that bit” but maybe some people don’t and suddenly you’ve lost a chunk of people.
It’s great. It’s like watching a video of someone coding, but with advantages of a text medium.
I also never thought of a Brainfuck interpreter as a good Hello World type of a project. It’s actually quite a practical example - memory initialization, strings, basic io, parsing, error handling. Now that I think about it, I would like to explore the same for Rust, Pony and some Lisp variants.
It was a great writeup. Brainfuck is only drawback given it’s intentionally designed to give folks a headache. I used to recommend folks do these examples on p-code or Forth for easier to follow interpreter or just more useful. Be interesting to see p-code or Forth done like this Zig write-up in Zig itself or another language.
I really like what I’ve seen from zig and started trying to build it last night (currently fighting with a cmake issue building llvm and clang). I played with it months ago and just decided to again now that I have some time. This post looks really thorough and I look forward to going through it all in more depth once I’ve got the compiler built. It seems like exactly the kind of post a young language needs. Thanks.
yeah, it is sad how big of a liability depending on llvm/clang can be.
Slightly off topic, but does Zig offer safety for concurrent access? I feel it’s a required feature nowadays, and a strong point of Pony or Rust. Zig looks very good, though.
Zig currently supports coroutines via async/await keywords and the promise type. This can be used to build a single-threaded event-based non-blocking I/O.
I’m working on a proof of concept TCP server to demonstrate this.
Next I will add kernel threads to the standard library. And then I will update my TCP server proof of concept by multiplexing the coroutines onto a thread pool.
Once that works, I will proceed with rewriting my music player server project in Zig.
At every point in the above steps I will look for ways to improve concurrency safety.
That’s great, although why not futures instead of promises? I find promise an awkward term, as promises should not be broken, while futures are neutral in this respect. Mozart/Oz uses the terms futures, for instance.
I guess my question was if there was any safety mechanism within Zig to prevent concurrent access to shared memory.
Is this a question of syntax rather than semantics? I don’t really have a preference between promise or future. I think it’s important to figure out the semantics before 1.0.0 and then before releasing that version we can go through and do a syntax pass.
As for a direct answer to your question: no there are currently no data race prevention features in the language apart from atomic built-in functions.
It is a bit of both, I was pointing out that conceptually a promise should not be broken, and that then the term is less representative than futures to denote asynchronous events that might happen (or might be cancelled). Promises also come with some additional connotations, which futures don’t have. I was asking the question because I’m quite interested in terminology, especially in the context of programming languages and APIs. But in short if you can change from promise to future, I think you would be ideal for these reasons ;) thanks for your answers!
https://github.com/zig-lang/zig/issues/858
One of these days I should play with zig, see how it compares with my pet project :)