←back to thread

200 points jorangreef | 4 comments | | HN request time: 0.66s | source
Show context
logicchains ◴[] No.24293046[source]
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 over C++ and Rust, because it makes it much harder for e.g. the intern to write code that repeatedly creates a vector or dynamically allocated string in a loop. Or to use something like std::unordered_map or std::deque that allocates wantonly.

replies(8): >>24293328 #>>24293382 #>>24293469 #>>24293919 #>>24293952 #>>24294403 #>>24294507 #>>24298257 #
voldacar ◴[] No.24293469[source]
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
replies(3): >>24293652 #>>24299417 #>>24300117 #
cycloptic ◴[] No.24293652[source]
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 seem to be something that only Zig can do.
replies(3): >>24294240 #>>24294749 #>>24299554 #
voldacar ◴[] No.24294240[source]
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 allocator-aware programming style in a way that's clean and idiomatic

replies(1): >>24294275 #
1. cycloptic ◴[] No.24294275[source]
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 that C++ templates are bad and you're saying Zig comptime is better, that's different than having woes about allocators.

replies(2): >>24298526 #>>24299764 #
2. fsociety ◴[] No.24298526[source]
The difference is you have to pass an allocator to the standard library functions in Zig. That’s why it is idiomatic compared to C++.
3. voldacar ◴[] No.24299764[source]
have fun trying to globally override new and delete in C++

(hint: there is no way to do this)

replies(1): >>24299945 #
4. cycloptic ◴[] No.24299945[source]
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.