Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interview with Zig language creator Andrew Kelley [video]

youtube.com

Post reply on HN
Print view View original

141–150 of 210 posts

Re: Interview with Zig language creator Andrew Kelley [video]

#141

Post by mwkaufma »

cycloptic wrote: post #39
voldacar wrote: post #27

Earlier quoted context omitted.

Yeah when I heard about this I instantly thought of game engines, but it makes total sense for HFT too. "Modern C++", with all its constant little mallocs and frees is so awful for anything that requires ultra low latency

Can you explain how this is a problem in modern C++? I was under the impression that all the STL containers (string, vector, list, map, etc.) worked the same and have an allocator parameter. Are there other areas where these are missing? Or is the issue that STL implementations almost always default to an allocator that uses malloc? I'm not trying to dog on Zig here (it's a nice little language) but this just doesn't…

Many core modern C++ types don't permit customizing the allocator. E.g. std::function

Re: Interview with Zig language creator Andrew Kelley [video]

#142

Post by mwkaufma »

mwkaufma wrote: post #141
cycloptic wrote: post #39

Earlier quoted context omitted.

Can you explain how this is a problem in modern C++? I was under the impression that all the STL containers (string, vector, list, map, etc.) worked the same and have an allocator parameter. Are there other areas where these are missing? Or is the issue that STL implementations almost always default to an allocator that uses malloc? I'm not trying to dog on Zig here (it's a nice little language) but this just doesn't…

Many core modern C++ types don't permit customizing the allocator. E.g. std::function

Furthermore, C++ dependencies commonly instantiate types like std::vector with the default allocator internally, rather than exposing it to the host application.

Re: Interview with Zig language creator Andrew Kelley [video]

#143

Post by AsyncAwait »

pron wrote: post #132
fsociety wrote: post #129

Earlier quoted context omitted.

I’d argue it does mean it is less effective at achieving correctness but the trade-off made is the whole point of Zig. Simple language that is really a better C.

It's hard to make a definitive argument one way or the other because the guarantees Rust makes come at a cost of compilation speed and language complexity that can have a negative effect on correctness. This question is impossible to answer without an empirical study. Unlike C, Zig is (or will be) memory safe, although its safety can be turned off, and often is -- after testing. Unlike C, it provides powerful abstrac…

> It's hard to make a definitive argument one way or the other because the guarantees Rust makes come at a cost of compilation speed

I don't think this is actually true. The compiler is slow but not due to memory safety; the 'cargo check' command is rather quick and the compiler itself doesn't seem to spend a lot of time in the frontend, most of the time in spent in the backend, past the borrow checking phrase.

Re: Interview with Zig language creator Andrew Kelley [video]

#144

Post by voldacar »

cycloptic wrote: post #71
voldacar wrote: post #69

Earlier quoted context omitted.

It isn't really a matter of can do/cannot do. It's more about the default patterns promoted by the idiomatic way of writing code. Yeah you could write C++ code that constantly passes around allocators while also using STL heavily, but it will be verbose, unnatural, and ugly. As well as having nicer syntax in general and real metaprogramming instead of the brain damage that is templates, zig promotes this kind of allo…

I'm not sure what you mean that it's verbose, unnatural and ugly. To me it looks the same. In C++, you have to pass around an allocator to your templates. You can typedef this away if you want. In Zig, you have to pass around an allocator as a function argument or a struct member. You can comptime this away if you want. Is there some fundamental way that I missed that Zig changes this? If your actual complaint is tha…

have fun trying to globally override new and delete in C++

(hint: there is no way to do this)

Re: Interview with Zig language creator Andrew Kelley [video]

#145

Post by aidenn0 »

pron wrote: post #22
tobz1000 wrote: post #17

Some of Zig's ideas fascinate me, both the great low-level concepts (e.g. arbitrary-sized ints), but much more than that, the high level concepts. Particularly great is Zig's handling of both macros and generic types, the answer to both of which seems to be: just evaluate them at compile-time with regular functions, no special DSL or extra syntax. Andrew mentions in the video a big drawback of this system - implicati…

Zig gives you memory safety (or, rather, will ultimately do that), but it does so in a way that's different from both languages with garbage collection (whether tracing or reference-counting) or with sound type-system guarantees a-la Rust. It does so with runtime checks that are turned on in development and testing and turned off -- either globally or per code unit -- in production. You lose soundness, but we don't h…

Valgrind on C is the closest thing I've worked with in terms of what Zig offers.

My experience is that Rust's approach is definitely better in terms of correctness than using valgrind during testing.

My intuition is that the advantages Zig brings to the table will not tip the balance.

That being said, the choice Zig makes is absolutely the right one. Rust fills the niche of a better and more correct C++ without fixing the issues of slow compilation and language complexity.

Zig fixes so much of what's wrong with C without abandoning the advantages of language simplicity and locality of reasoning. I love Zig, but need a medium sized non-work project for it.

Re: Interview with Zig language creator Andrew Kelley [video]

#146

Post by cycloptic »

voldacar wrote: post #144
cycloptic wrote: post #71

Earlier quoted context omitted.

I'm not sure what you mean that it's verbose, unnatural and ugly. To me it looks the same. In C++, you have to pass around an allocator to your templates. You can typedef this away if you want. In Zig, you have to pass around an allocator as a function argument or a struct member. You can comptime this away if you want. Is there some fundamental way that I missed that Zig changes this? If your actual complaint is tha…

have fun trying to globally override new and delete in C++ (hint: there is no way to do this)

Are you sure? https://en.cppreference.com/w/cpp/memory/new/operator_new#Gl...

You don't need to do this if you're using allocators.

Re: Interview with Zig language creator Andrew Kelley [video]

#147

Post by defen »

pron wrote: post #137
the_duke wrote: post #125

Earlier quoted context omitted.

There is some ongoing work towards custom allocators for containers in Rust std. [1] Right now you could also go no_std (you still get the core library, which does not contain any allocating data structures) and use custom containers with a passed in allocator. Zig is definitely a cool language, and it will be interesting if they can come up with good solutions to memory management! But sentences like these in the do…

> But sentences like these in the documentation [2] would make me prefer Rust for most low level domains While such use-after-free issues are not prevented at compile time, the plan is to ultimately have safe Zig catch them (and panic) at runtime, i.e. safe Zig shouldn't have undefined behaviour. Because this is done with runtime checks, the expectation is that those checks will be turned off (selectively, perhaps) i…

> In that case, the guarantees aren't as strong as Rusts, but those guarantees come at a significant cost -- to language complexity and compilation time -- that can also have a negative effect on correctness

How would those guarantees have a negative effect on correctness? Are you thinking something like, you need to design your data structure / program in a non-intuitive way that makes it more difficult to get the logic right, even though you are protected from memory safety issues?

Re: Interview with Zig language creator Andrew Kelley [video]

#148

Post by cycloptic »

mwkaufma wrote: post #142
mwkaufma wrote: post #141

Earlier quoted context omitted.

Many core modern C++ types don't permit customizing the allocator. E.g. std::function

Furthermore, C++ dependencies commonly instantiate types like std::vector with the default allocator internally, rather than exposing it to the host application.

Thank you for the examples. I'm not sure std::function is a good comparison. After some research it seems this used to be in the spec, but it was removed because nobody supported it correctly and it seems it was too difficult to do it in a type-safe manner anyway: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p030...

The other thing is that Zig doesn't seem to have any real plans to support C++-style closures right now. If they ever find a type-safe way to do it while supporting custom allocators, then that would be interesting, but at the moment I wouldn't say it's any better than C++ in this regard.

I actually have seen some C/C++ libraries that do allow changing the default allocator although it's usually only low-level libraries that bother to do this.

Re: Interview with Zig language creator Andrew Kelley [video]

#149

Post by cycloptic »

logicchains wrote: post #89
cycloptic wrote: post #39

Earlier quoted context omitted.

Can you explain how this is a problem in modern C++? I was under the impression that all the STL containers (string, vector, list, map, etc.) worked the same and have an allocator parameter. Are there other areas where these are missing? Or is the issue that STL implementations almost always default to an allocator that uses malloc? I'm not trying to dog on Zig here (it's a nice little language) but this just doesn't…

A concrete example is std::stable_sort. As far as I'm aware there's no way to pass it a custom allocator/buffer to avoid it allocating memory.

Thank you for the example.

Re: Interview with Zig language creator Andrew Kelley [video]

#150

Post by fluffy87 »

voldacar wrote: post #27
logicchains wrote: post #10

I work in HFT, and one of the key concerns when writing low-latency code is "is this code allocating memory, and if so, how can I stop it?" Zig is the perfect language for this use case as none of the standard library implicitly allocates, rather for anything that allocates, the caller must pass in an allocator. The stdlib also provides a handy arena allocator, which is often the best choice. This is a huge advantage…

Yeah when I heard about this I instantly thought of game engines, but it makes total sense for HFT too. "Modern C++", with all its constant little mallocs and frees is so awful for anything that requires ultra low latency

The actual Modern C++ design book from Alexander’s ci is about custom allocators and performance.

The irony.

Post reply on HN