18 ms·

Why Zig when there is already C++, D, and Rust?

276 points by mardiyah 6y ago

chromatin 6y ago
Actual article title is “...C++, D, and Rust.” D sometimes feels like Rodney Dangerfield =)
- mhh__ 6y ago
  As a community I really think we're not flashy enough about what we have.
  - chadcmulligan 6y ago
    we get no respect, I tell ya, no respect
  - chromatin 6y ago
    Yes, one of D’s major failings is in fact not technical, but marketing.
    - benibela 6y ago
      At least it is mentioned I used to believe Object Pascal would replace C++, but now it is not even mentioned
  - ku-man 6y ago
    You had your oportunity in the early 2000's, but unfortunately you squandered it.
Technically 6y ago
> Rust seems to encourage a single global allocator strategy, which is not suitable for many use-cases such as OS development and high-performance game development. I'd really love to hear them expound on this as I'm pretty sure rust has both OSes written in it and access to custom allocators. I just used `TypedArena` for managing memory in a real-time (DSP) event loop yesterday. Hell, you can just spew `unsafe` everywhere and manually manage memory like zig/c's strategy seems to be, although I'm not sure what the benefit would be. But hey, this isn't a knock—I've just been traumatized by years of completely avoidable segfaults and do everything in my power to avoid the experience.
faitswulff 6y ago
I've been working my way through the blog os resources in Rust (https://os.phil-opp.com/ https://os.phil-opp.com/) - is there a similar tutorial for Zig? I think it would be a great comparison. Closest thing I can find is this hobby x86 kernel in Zig: https://news.ycombinator.com/item?id=21967668 https://news.ycombinator.com/item?id=21967668
- ajxs 6y ago
  If you can't find one you should consider making your own and contributing a 'bare bones' style tutorial to https://wiki.osdev.org/ https://wiki.osdev.org/. If you're familiar with the subject matter, getting to the point of working serial output in a new language shouldn't take too long.
jkelleyrtp 6y ago
I love both Zig and Rust - I believe they both serve different types of systems programming - but for many developers, I'm not sure how important these points are. Zig's reasons for being better include: - No operator overloading - Rust panics when allocator fails - Rust uses a std allocator (which is configureable) - No metaprogramming (IE, macros) - Simpler to grok Essentially, Zig being the "Go" of C/C++/Rust/D. But, I think that dances around the problem where Systems Programming is just complex. Just because some functions and control flow is simpler doesn't mean the program itself is. If trying to pull Rust programmers away, I'm not sure the merits in this article are strong enough. However, for newcomers to systems programming, Zig might be easier to learn and solve problems with.
- deleted 6y ago
  [deleted]
- slezyr 6y ago
  > - No operator overloading Ehh??? It's the first point there. And I don't like all this hate for operator overloading. I prefer to write "vec1 * (vec2 + vec3)" instead of "vec1.mul(vec2.plus(vec3))".
  - whatshisface 6y ago
    Operator overloading is hated among programmers who never use math; in that community all uses of "+" are to do something other than addition, usually something that's not even remotely related to addition. Operators end up as one-character infix method names.
    - colejohnson66 6y ago
      I don’t think I’ve ever seen a library overload math operators when they didn’t do what you’d expect. And just because a language feature is abused doesn’t mean it’s bad. Typescript’s generics are Turing Complete, but they’re still great.
      - 6y ago
mooman219 6y ago
<rust evangelism strike force> It sounds like the complaints here are operator overloading, global allocator by default, and metaprogramming. I think the value of these features are certainly not objective, but it's not a very compelling argument to avoid a language because of them. As for optional standard library support, this is actually really common in Rust and is a breeze to support. Just annotating [no_std] basically gets you there libc wise. There's even additional restrictions like [no_core] to remove even more. I believe this should be noted. I think the author missed an opportunity to really drill into actual pain points like the steep learning curves to c++ and rust, and where/if Zig excels in specific examples. </rust evangelism strike force>
- mhh__ 6y ago
  I guess I would be in the D evangelism strike force, but I concur. D also has a really rather nice composable allocator system in the standard library.
- nynx 6y ago
  Rust is also getting configurable allocators soon. Most standard collections will take an additional, optional allocator. There are also a few people who want to rethink the design of allocators to allow for inline storage. It definitely sounds interesting, but may end up being too complicated.
  - mmastrac 6y ago
    Do you have a link to the RFC for this? This sounds awesome. EDIT: thanks to the links below I found this [1] and this [2] [1] https://github.com/rust-lang/rust/issues/32838 https://github.com/rust-lang/rust/issues/32838 [2] https://github.com/rust-lang/rfcs/pull/1398 https://github.com/rust-lang/rfcs/pull/1398
    - swsieber 6y ago
      While I don't have an RFC your you (I'm not the same person), here's an interesting thread on maybe tweaking the interface: https://internals.rust-lang.org/t/is-custom-allocators-the-right-abstraction/13460 https://internals.rust-lang.org/t/is-custom-allocators-the-r...
bsder 6y ago
Flagging Out of Memory panics is pretty disingenuous. Unless Zig only does static allocation of memory (fixed stack and heap), it is equally at the mercy the Linux optimistic memory allocator. With Linux, you can request your memory, get no error code, and then when you go to use it--BOOM.
- Kranar 6y ago
  That can be disabled and is disabled in many situations where one would use C or C++ such as embedded devices. It can be disabled system wide or an application can disable it for itself.
- AndyKelley 6y ago
  Linux is only one of many, many different environments in which the same Zig code can be compiled to target. That's the point, you write your code in a portable, reusable manner, and it behaves correctly everywhere.
zabzonk 6y ago
OK, I'll bite. What does this statement: var a = b + c.d; actually do?
- kccqzy 6y ago
  I think the article is trying to say the plus and the dot access are guaranteed to be language built-ins and therefore be very cheap to call. Furthermore they can't fail by throwing exceptions or such. (Note that in C the plus operator may result in UB, such as signed overflow, or forming a pointer beyond one past the allocated size.)
- agytvfr 6y ago
  In Zig? It would allocate stack space for a new variable a, and add b and the d field of c together and insert that value into the memory location that a reserved. In D or Python or anything that allows for properties, it would be allocating a where-ever the language allocates stuff, then calling an infix function '+' which could be anything depending on the language including starting up a JVM in the background for god knows what reason, and calls it with the arguments b and the result of calling the property function d of the object c.
  - zabzonk 6y ago
    But what are the types of those fields it is "adding"? What are the semantics of "adding" for those types? These things are not obvious from reading that statement.
    - qayxc 6y ago
      They are obvious to the programmer who knows the types of b and d and thus the semantics of adding them. The operation itself implies that both b and c.d must be primitive types and so the semantics of the operation are defined by Zig's language rules. edit: To clarify - this in contrast to, say C++, where nothing can be inferred about the types of the variables involved and the semantics of the operation, since '+' can be overloaded.
- 6y ago
dleslie 6y ago
IMHO, the list seems to confirm why I would choose C++ or Rust over Zig. I might still consider choosing Zig over C, but since Zig has nowhere near the embedded coverage as C, with all the obscure compilers, it seems to me that Zig will remain a niche contender.
- AnIdiotOnTheNet 6y ago
  This is a recognized problem, which is why a C compile target is on the todo list.
potatochup 6y ago
I was interested by this statement made in the article: "The entire concept of the heap is strictly in userspace" Is that just an analogy between Kernel and userspace from operating systems? Or is it an actual term used for programming languages, when abstract from an operating system? If I was running zig on a bare-metal embedded device, and wrote my own heap allocator, is it appropriate to call that a "userspace" heap allocator?
- sobeston 6y ago
  The concept of the heap is in the userspace of the language. This terminology is confusing to someone thinking of usermode/kernelmode - this is instead talking of userspace versus language-space. As in, users implement code to reason about heap memory; the language does not know or care what heap is. At a language level, zig does not have a "new" or a "malloc" or anything of the sort.
- kristoff_it 6y ago
  It means that it's a feature that can be implemented without special language-level support. As an example, Go 1 has maps and slices which are "magic" generic types that a 3rd party library author would not be able to recreate.
ryanisnan 6y ago
First example doesn't use typing. Curious why? I have negative knee-jerk reactions to code without type annotations.
- AndyKelley 6y ago
  the caption above the example says: > ...without needing to know the types of anything:
EdwardDiego 6y ago
> C++, D, and Go have throw/catch exceptions Pretty sure Go doesn't have throw/catch.
- throw_m239339 6y ago
  > Pretty sure Go doesn't have throw/catch. Go has panic/recover, which are basically exceptions with some different scoping rules.
- deleted 6y ago
  [deleted]
- tym0 6y ago
  'panic' is pretty much that.
- AndyKelley 6y ago
  not only is panic/recover identical to throw/catch but with non-standard names, it is used in the go standard library.
  - erik_seaberg 6y ago
    throw/catch is more readable, because panic/recover doesn’t switch on type and isn’t block scoped (the defer stack is set up at runtime, which also can’t be good for the optimizer).
    - dilap 6y ago
      that's sort of a feature though, since it makes it less likely to be used ;-) rust, i believe, can also recover from panics, but it's even less ergonomic, which makes it even more of a feature zig goes to the extreme and makes panics completely unrecoverable, tho it's unclear how practical that is for e.g. long running servers w/ many clients interesting discussion here: https://github.com/ziglang/zig/issues/3516 https://github.com/ziglang/zig/issues/3516
Kranar 6y ago
I look forward to seeing Zig, but this is a pretty bad explanation and is wrong in fundamental ways: >This means you can be sure that the following code calls only foo() and then bar(). No you can't be sure of this. Zig has different rules about error handling depending on what mode you build your software in, and it's not clear or rigorously specified how different modules built using different modes interact with one another when it comes to error handling. So that initial line: var a = b + c.d; That may end up causing a panic depending on the type of b and c.d, or it might result in undefined behavior, in which nothing is guaranteed. You also need to know something about the type of c, since if c is a pointer type then it could be a dangling reference. As for hidden allocations, the only hidden allocation I know of was C's now deprecated runtime length array. C++ doesn't have this feature and I don't know of any core language features in C++ that allocate dynamic memory any longer. Some older compilers used dynamic memory for exception handling but modern C++ compilers preallocate memory for all of the standard exception types. I want to say that Rust also doesn't dynamically allocate memory but I'm not 100% sure about that. D does a boat load of dynamic memory allocation in the core language which is rather unfortunate. For bare metal support, Rust has first class support for no standard library. C++ does not but in practice clang/GCC and MSVC all support compiling without it. As for being a portable language, that's a nice goal that Zig can establish for itself, but that's all it is right now. For build system... well C++ has an atrocious build system, there is no justification for it nor is there any defending it. Good on Zig for wanting to make the entire developer experience pleasant and making package management a core priority. And finally for simplicity, that word really doesn't mean anything anymore. Everyone calls their project "simple" and everyone has a different meaning for it. Zig can claim its simple, maybe it's true, maybe it isn't, I think that's something that can only be decided if and after it gets some degree of adoption.
- mhh__ 6y ago
  D dynamically allocates stuff that you never had in the first place so it's not like Java or anything like that.
  - Kranar 6y ago
    Can you explain what you mean by never had in the first place? The core D language allocates closures and exceptions which is like Java. Rust and C++ don't do any kind of dynamic allocation for these features.
whateveracct 6y ago
Can't wait to build a world of memory management tools in Haskell with the help of -XLinearTypes. What this article mentions about non-global allocators will fit perfectly.
- Ericson2314 6y ago
  Sorry, but you cannot write malloc in linear Haskell. I wish you could too.
  - whateveracct 6y ago
    I could mmap some virtual memory and write malloc's API to allocate chunks, kept safe by linear haskell I can write a variety of memory allocators, kept safe by linear haskell more generally, anything you can do in C, you can do in Haskell. So malloc is fair game (although i'd just call the C one from Haskell)
    - Ericson2314 6y ago
      No I mean linear arrows vs linear kinds means you can't write malloc without CPSing.
      - whateveracct 6y ago
        yeah i don't especially expect that to matter in practice. monads used to require CPSing all over the place too.
sideeffffect 6y ago
Has anyone tried to combine Zig with Cosmopolitan libc yet? https://justine.lol/cosmopolitan/index.html https://justine.lol/cosmopolitan/index.html
jbritton 6y ago
I’m wondering if there is a way to specify an allocator in some context without always having to pass the allocator to every function. A dynamic variable binding maybe, but I’m not sure how the function would handle an optional allocator parameter. Perhaps this would go against the Zig philosophy of avoiding unexpected behavior, but such a feature done right would seem better to me.
- kristoff_it 6y ago
  You could surely come up with a scheme of that kind in your application. To make it as simple as possible, you could simply have a global variable with the allocator you want to use, and pass a reference to it to every stdlib function you use; nothing stops you from doing that. The explicitness is supposed to be respected by libraries, so that then the writer of the final program can enjoy maximum flexibility.
- 59nadir 6y ago
  It's almost always a mistake to take the convenience of not having to pass an allocator over the flexibility of passing one. Testing, optimization via different allocators, etc. all become much easier to work with if you just make it a hard rule that anything that allocates takes an allocator. It's impossible to misuse a function if it takes all its dependencies as arguments, etc.. With that said, I create structures that embed their allocator(s) and use them for their whole lifetime, with the rule that all their allocations have to come from the embedded ones or ones passed into methods (usually I don't mix argument allocators & stored ones, but this isn't a hard rule).
flohofwoe 6y ago
IMHO those "language designer trivia" are interesting to read and think about but in the end irrelevant for popularity (and I think Zig will be popular). My personal favourites so far are: - The language is really simple and "enjoyable". Writing C++ often feels like puzzle solving to me even after 25 years. From the little Rust I've written so far, I got the same impression. Writing Zig is like writing C or Go but even more straight-forward. The language completely "disappears" while coding. - The simple integration with C, Objective-C and C++ doesn't get enough credit (disclaimer: I haven't tried C++ yet). Even if Zig aims to replace C, I think the reality will be that most cross-platform / "cross-language" libraries will continue to be written in C, and most "serious" Zig projects will actually be mixed-language projects. Most other languages are too much trapped in their own ecosystem and aim to "rewrite the world" (which won't happen of course). - Integrating the build system into the compiler and standard library is the right way to do it (not a feature unique to Zig, but if the C/C++ world is looking for the right way to solve the "build system problem", this is it). ...lots of other cool stuff in Zig to write about such as the incredibly simple module system, the comptime-, reflection- and generics-features, but IMHO the only feature that really counts in the end is: ergonomics. This is the one thing that matters and where Zig beats the more "powerful" alternatives.
- samatman 6y ago
  To add to what you're saying, Zig (and only Zig) is a plausible contender for replacing C, exactly because consuming a Zig .o file from C is roughly as simple as consuming a C .o from Zig. So if you have a C program, and you want to dip your toes in Zig-land by writing the next library in Zig, you just can. If you chose Rust instead, you're going to have a bad time.
  - drewm1980 6y ago
    Learning how to write memory safe code in Rust is a challenge at first, but it buys you access to an ecosystem of transitive dependencies that are (mostly) efficiently implemented and interconnected through memory safe API's. That advantage remains even if you have you have to manually define an unsafe C API for the rust code you added to your codebase.
PolCPP 6y ago
So for someone who's not actively into the systems programming ecosystem, how used is Zig (niche i guess?), and how different is it to nim? Since i don't see any mentions to it.
codeflo 6y ago
It's a bit unfortunate that an article titled "Why Zig when there is C++, D and Rust" mentions a lot of features that are shared by Zig, C++, D or Rust, not always giving credit or explaining how Zig solves these problems better. Point by point: - No hidden control flow: Linus Torvalds used to argue for C over C++ for similar reasons. I think it's a valid point for some kinds of systems programming. IMO, the argument is a lot stronger for features like destructors (C++) or Drop (in Rust) because those are truly hidden. At least the + sign is visible, and experienced C++ devs read it as a function call anyway. - No hidden allocations: This is just a library design choice in C++ and Rust, not baked into the language. The standard libraries of those languages usually favor convenience over the last bit of flexibility and performance. At least in the case of C++, there's an ecosystem of libraries like the EASTL that make different choices. - No standard library: That's fully supported in common C++ compilers and Rust. If Zig goes beyond what those languages offer, which it might, then the article should probably explain how. - Error handling: "Zig is designed such that the laziest thing a programmer can do is [...] properly bubble errors up." That's also true for exceptions. Presumably, Zig doesn't have exceptions. This could be explained, and contrasted with Rust's monadic approach to error handling. - Compatibilty with C: That doesn't tell me much, because C++, D and Rust all have excellent C compatibility. - Package manager: Great! Both Rust and D also have one, so this might mainly be a point in contrast to C++? - No metaprogramming: I looked up how Zig treats format strings. It looks like it's possible for functions to have "compile time arguments", and there are some rules around compile-time evaluation of if statements and inlineable loops [1]. At first glance, there might be some parallels to D's metaprogramming capabilities, which also has static ifs and loops, but I don't know if that mechanism is as powerful. It certainly looks elegant, but to me, it clearly is a kind of metaprogramming, not "no metaprogramming". Having said all this, I'm very happy that there are more languages in this space now. Maybe at this point, the best strategy for a project like Zig is to address Rust head-on in comparisons like this. It's very unlikely that someone reads this article in 2021, is looking for a new systems language and isn't also considering Rust. [1] https://ziglang.org/documentation/master/#Compile-Time-Expressions https://ziglang.org/documentation/master/#Compile-Time-Expre...
- defen 6y ago
  > - Compatibilty with C: That doesn't tell me much, because C++, D and Rust all have excellent C compatibility. Zig's @cImport/translate-c is significantly easier to use than Rust's bindgen (though it's been a few years since I used bindgen) plus it can translate actual functions to Zig and not just declarations (e.g. inline functions)
AndyKelley 6y ago
Sorry to pull the rug out from under ya'll like this but that article was a couple years old, so I gave it a once-over pass to update it. Mainly the "No hidden allocations" section is rewritten. You can see the full commit diff here: https://github.com/ziglang/www.ziglang.org/commit/bede1e57b6831a740211b03344889a78e9ee2885 https://github.com/ziglang/www.ziglang.org/commit/bede1e57b6...
- dralley 6y ago
  It'd be great to include some information about the awesome cross-compilation support! Thanks for all of your work, it's great.
- Ericson2314 6y ago
  There's many things you do that I like, but Rust's bad choices about allocation are also almost all library not language mistakes.
  - aidenn0 6y ago
    You only get one chance to omit something from the standard library. After that, you're stuck with it forever.
    - lilyball 6y ago
      Rust has “Editions”, which are points where they can make breaking changes as programs and crates (libraries) have to opt-in to the new edition, and you can mix crates from different editions. So if they need to make backwards-incompatible changes in order to add allocator support, they can do this in an edition.
      - dralley 6y ago
        To the language, but not to the standard library. The standard library is eternal.
        deleted 6y ago
p0nce 6y ago
> D has an optional garbage collector, and it is common for code to use it, so without a full and recursive audit of all your dependency tree, it’s likely that you are accidentally using the garbage collector. No audit needed since 2014 when the @nogc attribute was introduced. Under @nogc there is zero hidden allocations.
- AndyKelley 6y ago
  Thank you - I removed the incorrect claim from the article
  - p0nce 6y ago
    Thanks!
p0nce 6y ago
"hidden" destructors are precisely what makes C++ safer than C at being correct.
junon 6y ago
I'm still miffed about Andrew's response to DOS vulnerabilities in the standard library. I know that Zig isn't at a v1 yet (or wasn't at the time, at least) but that's no excuse to shut down conversation about security. I also don't like that the discord is run like a cult. If you say anything bad about Zig, you're berated until you ultimately have to leave. It's the Rust community all over again.
crowf 6y ago
> If Zig code doesn’t look like it’s jumping away to call a function, then it isn’t. I'll admit, I don't know zig. But how would it implement 1.0*2.0 for an architecture that doesn't support float multiplication? I assume that it would do something like compiler-rt and replace that operation with a function call. See https://github.com/llvm/llvm-project/tree/main/compiler-rt/lib/builtins https://github.com/llvm/llvm-project/tree/main/compiler-rt/l... for examples of "code that doesn't look like a function call" that actually is.
- kaba0 6y ago
  The compiler can inline the necessary instruct in-place for such an architecture. I think no jumping away is meant more in terms of no hidden side effect
Blikkentrekker 6y ago
> If Zig code doesn’t look like it’s jumping away to call a function, then it isn’t. This means you can be sure that the following code calls only foo() and then bar(), and this is guaranteed without needing to know the types of anything: Okay, but what's the advantage, when due to optimizations such as inlining and tail call elimination, this isn't reliable in the other direction to begin with? The reason compilers can remove function calls as such as an optimization is because it doesn't alter the semantics. Rust will certainly inline most implementations of `std::ops::Add` to begin with as they tend to be small enough, and does it really matter they not be inlined?
antpls 6y ago
Caches are everywhere, and systems have now 5 layers of different memories, from L1 to a network attached storage, plus accelerators memories such as GPU. I would like a language designed to target a hierarchical-memory system. I would like a language that forces me write single-threaded batched (or "blocked") algorithms with low cache misses. How many pieces of code are out there where an easy x4 speedup could be achieved today if there were written with batched operations from the start? (It also shows how limited are the compiler in autovectorizing) Rust gives me guarantes regarding memory safety, I would like a language that gives me guarantees that SIMD instructions and 2 cache levels are correctly used, without having to read the source code and compiler output.
- frozenport 6y ago
  Algorithms that rely on branching are generally incompatible with SIMD. Simply put, many things won't benefit from it. Caching on requires temporary structures whose sizes etc need to be empirically determined. See https://halide-lang.org/tutorials/tutorial_introduction.html https://halide-lang.org/tutorials/tutorial_introduction.html for some limited attempts to make a language to solve these two problems.
- jorangreef 6y ago
  Having worked on hash table implementations in C, and having done everything to minimize cache misses, e.g. using tiny 8-bit bloom filters within a cache line to avoid further cache line probes, I now prefer Zig to C, because I believe it makes memory alignment far more explicit in the type system. You can even align the stack memory for a function and this is all upfront in the documentation. You don't need arcane compiler specific pragmas. Zig just makes it easy. Zig's alignment options are so powerful and neat and available compared to C, right down to allocations with custom alignments, and all first class at the language level. Compare that with C's malloc() and posix_memalign(). Implementing a Direct IO system in Zig recently was also a breeze. I also appreciate Zig's approach to memory management, where even the choice of allocator is considered important, and for things like async/await, Zig's explicitness around memory requirements is brilliant. Zig's @frameSize builtin (https://ziglang.org/documentation/0.7.1/#frameSize https://ziglang.org/documentation/0.7.1/#frameSize) will tell you exactly how much memory a whole chain of functions will need to run async, including their stack variables. You can even choose where you want their async frames to be stored: global, heap or stack. Again and again, Zig's design decisions have just been spot on. Huge kudos to Andy Kelley and the Zig communities.
mangecoeur 6y ago
Tbh this sounds more like “we dont need all these newfangled tools, in my day we just ...” writing software is complex, you do actually need sophisticated tools. Saying the language is simple just moves the complexity somewhere else. I say having many of the hard problems be solved by the language itself and its much larger development community is much better than just heaping it on the individual programmers (who might then get it wrong).
- flohofwoe 6y ago
  That's the wrong impression, C already fills that "in my days" niche nicely (and it does it well) ;) Zig enforces correctness in a lot of places, it doesn't have C's sloppy implicit type conversions, it's impossible to accidentally use uninitialized data, it has "proper" arrays and slices with range checking, it enforces to handle return values, it has a proper error-handling system, etc etc... But it's quite hard to balance "correctness" with "convenience", Zig has placed itself somewhere between "hippie C" and "extremist Rust". When it comes to enforcing correctness, it's much closer to Rust than C though.
- AnIdiotOnTheNet 6y ago
  > writing software is complex, you do actually need sophisticated tools. Eh, in my experience people mostly use 'sophisticated tools' because either their language doesn't do enough to help them out or the just really like making things more complicated than they need to be. Like, watch Casey Muratori develop a game in front of a live audience with C++ using a text editor, compiler, and a debugger. Or Jonathan Blow developing a compiler in C++ and a game in his own language using a text editor, a compiler, and a debugger.
  - mangecoeur 6y ago
    Actually I think this kind of example is exactly the problem: people think that if Jonathan Blow can do it with a plain text editor, anyone can. But Mr Blow is one of the very best in his field, the vast majority of programmers are not at that level. So they need languages and tools to help them out.
ngrilly 6y ago
Does Zig plan to support closures?
- kristoff_it 6y ago
  There's a proposal for that https://github.com/ziglang/zig/issues/6965 https://github.com/ziglang/zig/issues/6965
- buffalobuffalo 6y ago
  I was just reading through the language specs, and I think that's the only real dealbreaker for me. Not having closures would really make programming difficult.
anta40 6y ago
I'm still constantly evaluating Nim, D, and Rust. And tooling-wise, I think they are production-ready. Not sure what kind of thing I write in Zig. Will also try it, anyway :)
- ku-man 6y ago
  Do you have a blog where you record your experiences? Also, are you using c++ as the main programming language to compare to?
happyweasel 6y ago
Only manual memory management? Come on.. and on top of that .. no destructors ?? Pre C++98 already beats this language..
orisho 6y ago
Is it possible to mix Evented and Blocking modes in a single Zig app? At work we write libraries that mix them. For example you might want to do CPU bound work in threads, while you'd want a single thread to manage IO (this thread would run in Evented mode). At a glance, this seems not possible in Zig because it's a compiletime flag?
- kristoff_it 6y ago
  It's possible. The global flag is just a convention used currently by the standard library. There still are some rough spots, but I've written a TUI chat client that uses blocking I/O when interacting with the terminal, while all other operations are evented and use async/await. We still need to nail down the interface, but there is no technical blocker.
anothernewdude 6y ago
Serious question: Is there D? It has been years since I last heard anything about it - is it still fractured between multiple stdlibs? Has it seen any take up or sizable projects adopt it?
yrimaxi 6y ago
I have to hand it to Kelley. I didn’t believe in this project when I first read one of his initial “I want to make a proglang” articles. Just one guy? And he doesn’t have a programming language background? And he wants to make a language which can be used instead of C, the most hard to replace programming language (apparently)? I still haven’t tried it myself. But I see now that there are plenty of people who have made an informed choice and chosen Zig over the other systems programming languages. So obviously they must be doing something right. Obviously Zig has something that system programmers like. So, props!

276 points by mardiyah 6y ago

chromatin 6y ago

Actual article title is “...C++, D, and Rust.” D sometimes feels like Rodney Dangerfield =)

mhh__ 6y ago
As a community I really think we're not flashy enough about what we have.
- chadcmulligan 6y ago
  we get no respect, I tell ya, no respect
- chromatin 6y ago
  Yes, one of D’s major failings is in fact not technical, but marketing.
  - benibela 6y ago
    At least it is mentioned I used to believe Object Pascal would replace C++, but now it is not even mentioned
- ku-man 6y ago
  You had your oportunity in the early 2000's, but unfortunately you squandered it.

Technically 6y ago

> Rust seems to encourage a single global allocator strategy, which is not suitable for many use-cases such as OS development and high-performance game development. I'd really love to hear them expound on this as I'm pretty sure rust has both OSes written in it and access to custom allocators. I just used `TypedArena` for managing memory in a real-time (DSP) event loop yesterday. Hell, you can just spew `unsafe` everywhere and manually manage memory like zig/c's strategy seems to be, although I'm not sure what the benefit would be. But hey, this isn't a knock—I've just been traumatized by years of completely avoidable segfaults and do everything in my power to avoid the experience.

faitswulff 6y ago

I've been working my way through the blog os resources in Rust (https://os.phil-opp.com/ https://os.phil-opp.com/) - is there a similar tutorial for Zig? I think it would be a great comparison. Closest thing I can find is this hobby x86 kernel in Zig: https://news.ycombinator.com/item?id=21967668 https://news.ycombinator.com/item?id=21967668

ajxs 6y ago
If you can't find one you should consider making your own and contributing a 'bare bones' style tutorial to https://wiki.osdev.org/ https://wiki.osdev.org/. If you're familiar with the subject matter, getting to the point of working serial output in a new language shouldn't take too long.

jkelleyrtp 6y ago

I love both Zig and Rust - I believe they both serve different types of systems programming - but for many developers, I'm not sure how important these points are. Zig's reasons for being better include: - No operator overloading - Rust panics when allocator fails - Rust uses a std allocator (which is configureable) - No metaprogramming (IE, macros) - Simpler to grok Essentially, Zig being the "Go" of C/C++/Rust/D. But, I think that dances around the problem where Systems Programming is just complex. Just because some functions and control flow is simpler doesn't mean the program itself is. If trying to pull Rust programmers away, I'm not sure the merits in this article are strong enough. However, for newcomers to systems programming, Zig might be easier to learn and solve problems with.

deleted 6y ago
[deleted]
slezyr 6y ago
> - No operator overloading Ehh??? It's the first point there. And I don't like all this hate for operator overloading. I prefer to write "vec1 * (vec2 + vec3)" instead of "vec1.mul(vec2.plus(vec3))".
- whatshisface 6y ago
  Operator overloading is hated among programmers who never use math; in that community all uses of "+" are to do something other than addition, usually something that's not even remotely related to addition. Operators end up as one-character infix method names.
  - colejohnson66 6y ago
    I don’t think I’ve ever seen a library overload math operators when they didn’t do what you’d expect. And just because a language feature is abused doesn’t mean it’s bad. Typescript’s generics are Turing Complete, but they’re still great.
    - 6y ago

mooman219 6y ago

<rust evangelism strike force> It sounds like the complaints here are operator overloading, global allocator by default, and metaprogramming. I think the value of these features are certainly not objective, but it's not a very compelling argument to avoid a language because of them. As for optional standard library support, this is actually really common in Rust and is a breeze to support. Just annotating [no_std] basically gets you there libc wise. There's even additional restrictions like [no_core] to remove even more. I believe this should be noted. I think the author missed an opportunity to really drill into actual pain points like the steep learning curves to c++ and rust, and where/if Zig excels in specific examples. </rust evangelism strike force>

mhh__ 6y ago
I guess I would be in the D evangelism strike force, but I concur. D also has a really rather nice composable allocator system in the standard library.
nynx 6y ago
Rust is also getting configurable allocators soon. Most standard collections will take an additional, optional allocator. There are also a few people who want to rethink the design of allocators to allow for inline storage. It definitely sounds interesting, but may end up being too complicated.
- mmastrac 6y ago
  Do you have a link to the RFC for this? This sounds awesome. EDIT: thanks to the links below I found this [1] and this [2] [1] https://github.com/rust-lang/rust/issues/32838 https://github.com/rust-lang/rust/issues/32838 [2] https://github.com/rust-lang/rfcs/pull/1398 https://github.com/rust-lang/rfcs/pull/1398
  - swsieber 6y ago
    While I don't have an RFC your you (I'm not the same person), here's an interesting thread on maybe tweaking the interface: https://internals.rust-lang.org/t/is-custom-allocators-the-right-abstraction/13460 https://internals.rust-lang.org/t/is-custom-allocators-the-r...

bsder 6y ago

Flagging Out of Memory panics is pretty disingenuous. Unless Zig only does static allocation of memory (fixed stack and heap), it is equally at the mercy the Linux optimistic memory allocator. With Linux, you can request your memory, get no error code, and then when you go to use it--BOOM.

Kranar 6y ago
That can be disabled and is disabled in many situations where one would use C or C++ such as embedded devices. It can be disabled system wide or an application can disable it for itself.
AndyKelley 6y ago
Linux is only one of many, many different environments in which the same Zig code can be compiled to target. That's the point, you write your code in a portable, reusable manner, and it behaves correctly everywhere.

zabzonk 6y ago

OK, I'll bite. What does this statement: var a = b + c.d; actually do?

kccqzy 6y ago
I think the article is trying to say the plus and the dot access are guaranteed to be language built-ins and therefore be very cheap to call. Furthermore they can't fail by throwing exceptions or such. (Note that in C the plus operator may result in UB, such as signed overflow, or forming a pointer beyond one past the allocated size.)
agytvfr 6y ago
In Zig? It would allocate stack space for a new variable a, and add b and the d field of c together and insert that value into the memory location that a reserved. In D or Python or anything that allows for properties, it would be allocating a where-ever the language allocates stuff, then calling an infix function '+' which could be anything depending on the language including starting up a JVM in the background for god knows what reason, and calls it with the arguments b and the result of calling the property function d of the object c.
- zabzonk 6y ago
  But what are the types of those fields it is "adding"? What are the semantics of "adding" for those types? These things are not obvious from reading that statement.
  - qayxc 6y ago
    They are obvious to the programmer who knows the types of b and d and thus the semantics of adding them. The operation itself implies that both b and c.d must be primitive types and so the semantics of the operation are defined by Zig's language rules. edit: To clarify - this in contrast to, say C++, where nothing can be inferred about the types of the variables involved and the semantics of the operation, since '+' can be overloaded.
6y ago

dleslie 6y ago

IMHO, the list seems to confirm why I would choose C++ or Rust over Zig. I might still consider choosing Zig over C, but since Zig has nowhere near the embedded coverage as C, with all the obscure compilers, it seems to me that Zig will remain a niche contender.

AnIdiotOnTheNet 6y ago
This is a recognized problem, which is why a C compile target is on the todo list.

potatochup 6y ago

I was interested by this statement made in the article: "The entire concept of the heap is strictly in userspace" Is that just an analogy between Kernel and userspace from operating systems? Or is it an actual term used for programming languages, when abstract from an operating system? If I was running zig on a bare-metal embedded device, and wrote my own heap allocator, is it appropriate to call that a "userspace" heap allocator?

sobeston 6y ago
The concept of the heap is in the userspace of the language. This terminology is confusing to someone thinking of usermode/kernelmode - this is instead talking of userspace versus language-space. As in, users implement code to reason about heap memory; the language does not know or care what heap is. At a language level, zig does not have a "new" or a "malloc" or anything of the sort.
kristoff_it 6y ago
It means that it's a feature that can be implemented without special language-level support. As an example, Go 1 has maps and slices which are "magic" generic types that a 3rd party library author would not be able to recreate.

ryanisnan 6y ago

First example doesn't use typing. Curious why? I have negative knee-jerk reactions to code without type annotations.

AndyKelley 6y ago
the caption above the example says: > ...without needing to know the types of anything:

EdwardDiego 6y ago

> C++, D, and Go have throw/catch exceptions Pretty sure Go doesn't have throw/catch.

throw_m239339 6y ago
> Pretty sure Go doesn't have throw/catch. Go has panic/recover, which are basically exceptions with some different scoping rules.
deleted 6y ago
[deleted]
tym0 6y ago
'panic' is pretty much that.
AndyKelley 6y ago
not only is panic/recover identical to throw/catch but with non-standard names, it is used in the go standard library.
- erik_seaberg 6y ago
  throw/catch is more readable, because panic/recover doesn’t switch on type and isn’t block scoped (the defer stack is set up at runtime, which also can’t be good for the optimizer).
  - dilap 6y ago
    that's sort of a feature though, since it makes it less likely to be used ;-) rust, i believe, can also recover from panics, but it's even less ergonomic, which makes it even more of a feature zig goes to the extreme and makes panics completely unrecoverable, tho it's unclear how practical that is for e.g. long running servers w/ many clients interesting discussion here: https://github.com/ziglang/zig/issues/3516 https://github.com/ziglang/zig/issues/3516

Kranar 6y ago

I look forward to seeing Zig, but this is a pretty bad explanation and is wrong in fundamental ways: >This means you can be sure that the following code calls only foo() and then bar(). No you can't be sure of this. Zig has different rules about error handling depending on what mode you build your software in, and it's not clear or rigorously specified how different modules built using different modes interact with one another when it comes to error handling. So that initial line: var a = b + c.d; That may end up causing a panic depending on the type of b and c.d, or it might result in undefined behavior, in which nothing is guaranteed. You also need to know something about the type of c, since if c is a pointer type then it could be a dangling reference. As for hidden allocations, the only hidden allocation I know of was C's now deprecated runtime length array. C++ doesn't have this feature and I don't know of any core language features in C++ that allocate dynamic memory any longer. Some older compilers used dynamic memory for exception handling but modern C++ compilers preallocate memory for all of the standard exception types. I want to say that Rust also doesn't dynamically allocate memory but I'm not 100% sure about that. D does a boat load of dynamic memory allocation in the core language which is rather unfortunate. For bare metal support, Rust has first class support for no standard library. C++ does not but in practice clang/GCC and MSVC all support compiling without it. As for being a portable language, that's a nice goal that Zig can establish for itself, but that's all it is right now. For build system... well C++ has an atrocious build system, there is no justification for it nor is there any defending it. Good on Zig for wanting to make the entire developer experience pleasant and making package management a core priority. And finally for simplicity, that word really doesn't mean anything anymore. Everyone calls their project "simple" and everyone has a different meaning for it. Zig can claim its simple, maybe it's true, maybe it isn't, I think that's something that can only be decided if and after it gets some degree of adoption.

mhh__ 6y ago
D dynamically allocates stuff that you never had in the first place so it's not like Java or anything like that.
- Kranar 6y ago
  Can you explain what you mean by never had in the first place? The core D language allocates closures and exceptions which is like Java. Rust and C++ don't do any kind of dynamic allocation for these features.

whateveracct 6y ago

Can't wait to build a world of memory management tools in Haskell with the help of -XLinearTypes. What this article mentions about non-global allocators will fit perfectly.

Ericson2314 6y ago
Sorry, but you cannot write malloc in linear Haskell. I wish you could too.
- whateveracct 6y ago
  I could mmap some virtual memory and write malloc's API to allocate chunks, kept safe by linear haskell I can write a variety of memory allocators, kept safe by linear haskell more generally, anything you can do in C, you can do in Haskell. So malloc is fair game (although i'd just call the C one from Haskell)
  - Ericson2314 6y ago
    No I mean linear arrows vs linear kinds means you can't write malloc without CPSing.
    - whateveracct 6y ago
      yeah i don't especially expect that to matter in practice. monads used to require CPSing all over the place too.

sideeffffect 6y ago

Has anyone tried to combine Zig with Cosmopolitan libc yet? https://justine.lol/cosmopolitan/index.html https://justine.lol/cosmopolitan/index.html

jbritton 6y ago

I’m wondering if there is a way to specify an allocator in some context without always having to pass the allocator to every function. A dynamic variable binding maybe, but I’m not sure how the function would handle an optional allocator parameter. Perhaps this would go against the Zig philosophy of avoiding unexpected behavior, but such a feature done right would seem better to me.

kristoff_it 6y ago
You could surely come up with a scheme of that kind in your application. To make it as simple as possible, you could simply have a global variable with the allocator you want to use, and pass a reference to it to every stdlib function you use; nothing stops you from doing that. The explicitness is supposed to be respected by libraries, so that then the writer of the final program can enjoy maximum flexibility.
59nadir 6y ago
It's almost always a mistake to take the convenience of not having to pass an allocator over the flexibility of passing one. Testing, optimization via different allocators, etc. all become much easier to work with if you just make it a hard rule that anything that allocates takes an allocator. It's impossible to misuse a function if it takes all its dependencies as arguments, etc.. With that said, I create structures that embed their allocator(s) and use them for their whole lifetime, with the rule that all their allocations have to come from the embedded ones or ones passed into methods (usually I don't mix argument allocators & stored ones, but this isn't a hard rule).

flohofwoe 6y ago

IMHO those "language designer trivia" are interesting to read and think about but in the end irrelevant for popularity (and I think Zig will be popular). My personal favourites so far are: - The language is really simple and "enjoyable". Writing C++ often feels like puzzle solving to me even after 25 years. From the little Rust I've written so far, I got the same impression. Writing Zig is like writing C or Go but even more straight-forward. The language completely "disappears" while coding. - The simple integration with C, Objective-C and C++ doesn't get enough credit (disclaimer: I haven't tried C++ yet). Even if Zig aims to replace C, I think the reality will be that most cross-platform / "cross-language" libraries will continue to be written in C, and most "serious" Zig projects will actually be mixed-language projects. Most other languages are too much trapped in their own ecosystem and aim to "rewrite the world" (which won't happen of course). - Integrating the build system into the compiler and standard library is the right way to do it (not a feature unique to Zig, but if the C/C++ world is looking for the right way to solve the "build system problem", this is it). ...lots of other cool stuff in Zig to write about such as the incredibly simple module system, the comptime-, reflection- and generics-features, but IMHO the only feature that really counts in the end is: ergonomics. This is the one thing that matters and where Zig beats the more "powerful" alternatives.

samatman 6y ago
To add to what you're saying, Zig (and only Zig) is a plausible contender for replacing C, exactly because consuming a Zig .o file from C is roughly as simple as consuming a C .o from Zig. So if you have a C program, and you want to dip your toes in Zig-land by writing the next library in Zig, you just can. If you chose Rust instead, you're going to have a bad time.
- drewm1980 6y ago
  Learning how to write memory safe code in Rust is a challenge at first, but it buys you access to an ecosystem of transitive dependencies that are (mostly) efficiently implemented and interconnected through memory safe API's. That advantage remains even if you have you have to manually define an unsafe C API for the rust code you added to your codebase.

PolCPP 6y ago

So for someone who's not actively into the systems programming ecosystem, how used is Zig (niche i guess?), and how different is it to nim? Since i don't see any mentions to it.

codeflo 6y ago

It's a bit unfortunate that an article titled "Why Zig when there is C++, D and Rust" mentions a lot of features that are shared by Zig, C++, D or Rust, not always giving credit or explaining how Zig solves these problems better. Point by point: - No hidden control flow: Linus Torvalds used to argue for C over C++ for similar reasons. I think it's a valid point for some kinds of systems programming. IMO, the argument is a lot stronger for features like destructors (C++) or Drop (in Rust) because those are truly hidden. At least the + sign is visible, and experienced C++ devs read it as a function call anyway. - No hidden allocations: This is just a library design choice in C++ and Rust, not baked into the language. The standard libraries of those languages usually favor convenience over the last bit of flexibility and performance. At least in the case of C++, there's an ecosystem of libraries like the EASTL that make different choices. - No standard library: That's fully supported in common C++ compilers and Rust. If Zig goes beyond what those languages offer, which it might, then the article should probably explain how. - Error handling: "Zig is designed such that the laziest thing a programmer can do is [...] properly bubble errors up." That's also true for exceptions. Presumably, Zig doesn't have exceptions. This could be explained, and contrasted with Rust's monadic approach to error handling. - Compatibilty with C: That doesn't tell me much, because C++, D and Rust all have excellent C compatibility. - Package manager: Great! Both Rust and D also have one, so this might mainly be a point in contrast to C++? - No metaprogramming: I looked up how Zig treats format strings. It looks like it's possible for functions to have "compile time arguments", and there are some rules around compile-time evaluation of if statements and inlineable loops [1]. At first glance, there might be some parallels to D's metaprogramming capabilities, which also has static ifs and loops, but I don't know if that mechanism is as powerful. It certainly looks elegant, but to me, it clearly is a kind of metaprogramming, not "no metaprogramming". Having said all this, I'm very happy that there are more languages in this space now. Maybe at this point, the best strategy for a project like Zig is to address Rust head-on in comparisons like this. It's very unlikely that someone reads this article in 2021, is looking for a new systems language and isn't also considering Rust. [1] https://ziglang.org/documentation/master/#Compile-Time-Expressions https://ziglang.org/documentation/master/#Compile-Time-Expre...

defen 6y ago
> - Compatibilty with C: That doesn't tell me much, because C++, D and Rust all have excellent C compatibility. Zig's @cImport/translate-c is significantly easier to use than Rust's bindgen (though it's been a few years since I used bindgen) plus it can translate actual functions to Zig and not just declarations (e.g. inline functions)

AndyKelley 6y ago

Sorry to pull the rug out from under ya'll like this but that article was a couple years old, so I gave it a once-over pass to update it. Mainly the "No hidden allocations" section is rewritten. You can see the full commit diff here: https://github.com/ziglang/www.ziglang.org/commit/bede1e57b6831a740211b03344889a78e9ee2885 https://github.com/ziglang/www.ziglang.org/commit/bede1e57b6...

dralley 6y ago
It'd be great to include some information about the awesome cross-compilation support! Thanks for all of your work, it's great.
Ericson2314 6y ago
There's many things you do that I like, but Rust's bad choices about allocation are also almost all library not language mistakes.
- aidenn0 6y ago
  You only get one chance to omit something from the standard library. After that, you're stuck with it forever.
  - lilyball 6y ago
    Rust has “Editions”, which are points where they can make breaking changes as programs and crates (libraries) have to opt-in to the new edition, and you can mix crates from different editions. So if they need to make backwards-incompatible changes in order to add allocator support, they can do this in an edition.
    - dralley 6y ago
      To the language, but not to the standard library. The standard library is eternal.
      - deleted 6y ago

p0nce 6y ago

> D has an optional garbage collector, and it is common for code to use it, so without a full and recursive audit of all your dependency tree, it’s likely that you are accidentally using the garbage collector. No audit needed since 2014 when the @nogc attribute was introduced. Under @nogc there is zero hidden allocations.

AndyKelley 6y ago
Thank you - I removed the incorrect claim from the article
- p0nce 6y ago
  Thanks!

p0nce 6y ago

"hidden" destructors are precisely what makes C++ safer than C at being correct.

junon 6y ago

I'm still miffed about Andrew's response to DOS vulnerabilities in the standard library. I know that Zig isn't at a v1 yet (or wasn't at the time, at least) but that's no excuse to shut down conversation about security. I also don't like that the discord is run like a cult. If you say anything bad about Zig, you're berated until you ultimately have to leave. It's the Rust community all over again.

crowf 6y ago

> If Zig code doesn’t look like it’s jumping away to call a function, then it isn’t. I'll admit, I don't know zig. But how would it implement 1.0*2.0 for an architecture that doesn't support float multiplication? I assume that it would do something like compiler-rt and replace that operation with a function call. See https://github.com/llvm/llvm-project/tree/main/compiler-rt/lib/builtins https://github.com/llvm/llvm-project/tree/main/compiler-rt/l... for examples of "code that doesn't look like a function call" that actually is.

kaba0 6y ago
The compiler can inline the necessary instruct in-place for such an architecture. I think no jumping away is meant more in terms of no hidden side effect

Blikkentrekker 6y ago

> If Zig code doesn’t look like it’s jumping away to call a function, then it isn’t. This means you can be sure that the following code calls only foo() and then bar(), and this is guaranteed without needing to know the types of anything: Okay, but what's the advantage, when due to optimizations such as inlining and tail call elimination, this isn't reliable in the other direction to begin with? The reason compilers can remove function calls as such as an optimization is because it doesn't alter the semantics. Rust will certainly inline most implementations of `std::ops::Add` to begin with as they tend to be small enough, and does it really matter they not be inlined?

antpls 6y ago

Caches are everywhere, and systems have now 5 layers of different memories, from L1 to a network attached storage, plus accelerators memories such as GPU. I would like a language designed to target a hierarchical-memory system. I would like a language that forces me write single-threaded batched (or "blocked") algorithms with low cache misses. How many pieces of code are out there where an easy x4 speedup could be achieved today if there were written with batched operations from the start? (It also shows how limited are the compiler in autovectorizing) Rust gives me guarantes regarding memory safety, I would like a language that gives me guarantees that SIMD instructions and 2 cache levels are correctly used, without having to read the source code and compiler output.

frozenport 6y ago
Algorithms that rely on branching are generally incompatible with SIMD. Simply put, many things won't benefit from it. Caching on requires temporary structures whose sizes etc need to be empirically determined. See https://halide-lang.org/tutorials/tutorial_introduction.html https://halide-lang.org/tutorials/tutorial_introduction.html for some limited attempts to make a language to solve these two problems.
jorangreef 6y ago
Having worked on hash table implementations in C, and having done everything to minimize cache misses, e.g. using tiny 8-bit bloom filters within a cache line to avoid further cache line probes, I now prefer Zig to C, because I believe it makes memory alignment far more explicit in the type system. You can even align the stack memory for a function and this is all upfront in the documentation. You don't need arcane compiler specific pragmas. Zig just makes it easy. Zig's alignment options are so powerful and neat and available compared to C, right down to allocations with custom alignments, and all first class at the language level. Compare that with C's malloc() and posix_memalign(). Implementing a Direct IO system in Zig recently was also a breeze. I also appreciate Zig's approach to memory management, where even the choice of allocator is considered important, and for things like async/await, Zig's explicitness around memory requirements is brilliant. Zig's @frameSize builtin (https://ziglang.org/documentation/0.7.1/#frameSize https://ziglang.org/documentation/0.7.1/#frameSize) will tell you exactly how much memory a whole chain of functions will need to run async, including their stack variables. You can even choose where you want their async frames to be stored: global, heap or stack. Again and again, Zig's design decisions have just been spot on. Huge kudos to Andy Kelley and the Zig communities.

mangecoeur 6y ago

Tbh this sounds more like “we dont need all these newfangled tools, in my day we just ...” writing software is complex, you do actually need sophisticated tools. Saying the language is simple just moves the complexity somewhere else. I say having many of the hard problems be solved by the language itself and its much larger development community is much better than just heaping it on the individual programmers (who might then get it wrong).

flohofwoe 6y ago
That's the wrong impression, C already fills that "in my days" niche nicely (and it does it well) ;) Zig enforces correctness in a lot of places, it doesn't have C's sloppy implicit type conversions, it's impossible to accidentally use uninitialized data, it has "proper" arrays and slices with range checking, it enforces to handle return values, it has a proper error-handling system, etc etc... But it's quite hard to balance "correctness" with "convenience", Zig has placed itself somewhere between "hippie C" and "extremist Rust". When it comes to enforcing correctness, it's much closer to Rust than C though.
AnIdiotOnTheNet 6y ago
> writing software is complex, you do actually need sophisticated tools. Eh, in my experience people mostly use 'sophisticated tools' because either their language doesn't do enough to help them out or the just really like making things more complicated than they need to be. Like, watch Casey Muratori develop a game in front of a live audience with C++ using a text editor, compiler, and a debugger. Or Jonathan Blow developing a compiler in C++ and a game in his own language using a text editor, a compiler, and a debugger.
- mangecoeur 6y ago
  Actually I think this kind of example is exactly the problem: people think that if Jonathan Blow can do it with a plain text editor, anyone can. But Mr Blow is one of the very best in his field, the vast majority of programmers are not at that level. So they need languages and tools to help them out.

ngrilly 6y ago

Does Zig plan to support closures?

kristoff_it 6y ago
There's a proposal for that https://github.com/ziglang/zig/issues/6965 https://github.com/ziglang/zig/issues/6965
buffalobuffalo 6y ago
I was just reading through the language specs, and I think that's the only real dealbreaker for me. Not having closures would really make programming difficult.

anta40 6y ago

I'm still constantly evaluating Nim, D, and Rust. And tooling-wise, I think they are production-ready. Not sure what kind of thing I write in Zig. Will also try it, anyway :)

ku-man 6y ago
Do you have a blog where you record your experiences? Also, are you using c++ as the main programming language to compare to?

happyweasel 6y ago

Only manual memory management? Come on.. and on top of that .. no destructors ?? Pre C++98 already beats this language..

orisho 6y ago

Is it possible to mix Evented and Blocking modes in a single Zig app? At work we write libraries that mix them. For example you might want to do CPU bound work in threads, while you'd want a single thread to manage IO (this thread would run in Evented mode). At a glance, this seems not possible in Zig because it's a compiletime flag?

kristoff_it 6y ago
It's possible. The global flag is just a convention used currently by the standard library. There still are some rough spots, but I've written a TUI chat client that uses blocking I/O when interacting with the terminal, while all other operations are evented and use async/await. We still need to nail down the interface, but there is no technical blocker.

anothernewdude 6y ago

Serious question: Is there D? It has been years since I last heard anything about it - is it still fractured between multiple stdlibs? Has it seen any take up or sizable projects adopt it?

yrimaxi 6y ago

I have to hand it to Kelley. I didn’t believe in this project when I first read one of his initial “I want to make a proglang” articles. Just one guy? And he doesn’t have a programming language background? And he wants to make a language which can be used instead of C, the most hard to replace programming language (apparently)? I still haven’t tried it myself. But I see now that there are plenty of people who have made an informed choice and chosen Zig over the other systems programming languages. So obviously they must be doing something right. Obviously Zig has something that system programmers like. So, props!