Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



> I don't know of any core language features in C++ that allocate dynamic memory any longer.

The article mention coroutines. There may also be an allocation when one throws an exception.

> Everyone calls their project "simple" and everyone has a different meaning for it.

So true. For example, I'd say Brainfuck is simple. And much simpler than Zig. But that does not mean I'd want to use it.


Coroutines in C++ are a good example, definitely. Rust managed to use the borrow checker to avoid dynamic allocation with coroutines. I wonder how Zig handles this, and I hope it's not through undefined behavior.

From reading it over, it looks like Zig does use dynamic memory for coroutines but it requires the memory to be passed in at the point of construction. That has some pros and cons to it and is consistent with Zig's overall approach so I can respect that choice.


Not sure what you mean by dynamic memory. Much like a struct can be stored at any memory address - global, heap, stack - a coroutine ("async function") in zig can be stored at any memory address. Just like `pointer.* = Foo{ .a = 12, .b = 34}`, the pointer decides where the struct memory goes, `pointer.* = async foo();` the pointer decides where the async function's stack frame goes.


> As for hidden allocations, the only hidden allocation I know of was C's now deprecated runtime length array.

I believe there's plenty of functions in C's stdlib that just call malloc as they please, like localtime, for example.


localtime does not do any dynamic allocation and very few C functions do, there's malloc and some string handling functions that do it. Furthermore I am referring to core language, not standard library. Zig also uses dynamic memory in its standard library and any non-trivial standard library will do memory allocation.


Thanks for the correction on localtime, but they point is not avoiding allocation completely, is being explicit about it. All functions in Zig's stdlib that allocate memory take an allocator as parameter.

That's pretty much the whole point: allowing the programmer to know if a function might allocate or not, and allow them to customize which allocation scheme to use by passing in whatever allocator they prefer.


> well C++ has an atrocious build system, there is no justification for it nor is there any defending it

C++ has no build system. It has a compiler (and a preprocessor). That's it.

You can choose from a large number of possible build systems, some of which are atrocious (not always for the same reasons) and some of which are very nice.

C++ also has no package management system. For a lot of us , that's a feature not a defect.


With any compiled language you can use the compiler and vendor your dependencies instead of using the language's conventional package manager. For example, nothing prevents skipping Cargo and building Rust directly with rustc the way Bazel does.

https://github.com/bazelbuild/rules_rust


D dynamically allocates stuff that you never had in the first place so it's not like Java or anything like that.


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.


It is not entirely true, please check D as a Better C [1]. You can have your cake and eat it too with D.

[1]https://dlang.org/blog/2017/08/23/d-as-a-better-c/


Exceptions are the big sticking point at the moment, true, but you don't have to allocate them with the GC.

Rust and C++ don't have associative arrays in the language to begin with, so if you write C++ in D you won't allocate.


I never mentioned garbage collector or associative arrays, I mentioned dynamic memory, closures, and exceptions.


Well I hoped dynamic memory was obvious given the D GC is written entirely in D and it has to get memory from somewhere




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: