3 ms·

May someone chime in between that and make a quick 3-way comparison with Golang? I already know Rust and shipped nontrivial stuff, but I need something simpler

May someone chime in between that and make a quick 3-way comparison with Golang? I already know Rust and shipped nontrivial stuff, but I need something simpler that average developers can pickup quickly to produce performant+parallel code and be able to crosscompile+ship a single binary. (The last point already ruled out Crystal which has a poor crosscompilation story as well as insanely long compile times for nontrivial stuff = bad DX)

pizza234 4y ago
The main topic of the article is about resource management (ie. allocation), which is automatic in Golang, so a comparison wouldn't make much sense in this context. Additionally, a requirement of the project is: > On the engineering side of things, we are building a reliable, predictable system. And predictable means really predictable. Rather than reigning in sources of non-determinism, we build the whole system from the ground up from a set of fully deterministic, hand crafted components. which rules out garbage collected languages (also see the design document here: https://github.com/tigerbeetledb/tigerbeetle/blob/fe09404d465df46b2bdfc017633eff37b4ab2343/docs/DESIGN.md https://github.com/tigerbeetledb/tigerbeetle/blob/fe09404d46...).
eatonphil 4y ago
It takes a while to understand allocations in Go. There are obvious ones like `make()` and `new()` and `append()` (though this one doesn't always allocate depending on the capacity of the thing you pass to append, I think). There are less obvious ones (if you don't have experience thinking about it) like string appending and "casting" between `string` and `[]byte`. I think it's also tricky to figure out when escape analysis goes wrong and you're accidentally heap allocating things you didn't need to. You develop an awareness of these aspects if you do performance-sensitive code in Go. But in Zig all allocations are explicit so you can't really accidentally have allocations. On the other hand, you have to manually manage memory in Zig. Unlike Rust, Zig has no builtin atomic reference counting. So memory management in Rust and Go are "easier" if you don't want to be aware of memory allocations. Memory management in Zig is "easier" if you need to be aware of memory allocations. And neither Zig nor Go are as strict as Rust about ownership so it's "easier" to express internally-mutable datastructures in Zig or Go (see "Entirely Way Too Many Linked Lists" [0]). Whereas it's easier to be sure you haven't screwed up ownership in Rust compared to Zig. In Go you don't have to worry since the GC will not let ownership be a problem. [0] https://rust-unofficial.github.io/too-many-lists/ https://rust-unofficial.github.io/too-many-lists/
kaba0 4y ago
Go is absolutely nothing like Rust, Zig, C; it is arguably closer to JS than those. I really dislike how it is camouflaged as a low-level language.

pizza234 4y ago

The main topic of the article is about resource management (ie. allocation), which is automatic in Golang, so a comparison wouldn't make much sense in this context. Additionally, a requirement of the project is: > On the engineering side of things, we are building a reliable, predictable system. And predictable means really predictable. Rather than reigning in sources of non-determinism, we build the whole system from the ground up from a set of fully deterministic, hand crafted components. which rules out garbage collected languages (also see the design document here: https://github.com/tigerbeetledb/tigerbeetle/blob/fe09404d465df46b2bdfc017633eff37b4ab2343/docs/DESIGN.md https://github.com/tigerbeetledb/tigerbeetle/blob/fe09404d46...).

eatonphil 4y ago

It takes a while to understand allocations in Go. There are obvious ones like `make()` and `new()` and `append()` (though this one doesn't always allocate depending on the capacity of the thing you pass to append, I think). There are less obvious ones (if you don't have experience thinking about it) like string appending and "casting" between `string` and `[]byte`. I think it's also tricky to figure out when escape analysis goes wrong and you're accidentally heap allocating things you didn't need to. You develop an awareness of these aspects if you do performance-sensitive code in Go. But in Zig all allocations are explicit so you can't really accidentally have allocations. On the other hand, you have to manually manage memory in Zig. Unlike Rust, Zig has no builtin atomic reference counting. So memory management in Rust and Go are "easier" if you don't want to be aware of memory allocations. Memory management in Zig is "easier" if you need to be aware of memory allocations. And neither Zig nor Go are as strict as Rust about ownership so it's "easier" to express internally-mutable datastructures in Zig or Go (see "Entirely Way Too Many Linked Lists" [0]). Whereas it's easier to be sure you haven't screwed up ownership in Rust compared to Zig. In Go you don't have to worry since the GC will not let ownership be a problem. [0] https://rust-unofficial.github.io/too-many-lists/ https://rust-unofficial.github.io/too-many-lists/

kaba0 4y ago

Go is absolutely nothing like Rust, Zig, C; it is arguably closer to JS than those. I really dislike how it is camouflaged as a low-level language.