There's also crates to avoid heap allocations for usually small vectors: tinyvec, smallvec, arrayvec
Note: gameswithgo you seem to be shadow banned. Your comment history looks alright tho. You may want to email hn@ycombinator.com asking to have that fixed (edit: found the culprit https://news.ycombinator.com/item?id=30732886)
I really enjoy some of the optimization details like when the memory overhead of Option<> can be elided completely. Other languages with Options will actually toss data up on the heap that doesn't need to be because it is in a Option and, or at the very least always take up a byte with the tag.
Details like this let you use the safer and more ergonomic solutions by default rather than having to worry if they are worth the overhead.
Indeed. Also more broadly Rust's types do not exist at runtime, and so you get the New Type idiom. If we care about the difference between a Row and a Column in the program, we can create distinct Row and Column types, and Rust won't allow you to use a Row when you need a Column, even if they're both "just integers", yet at runtime there's no cost for this, if the obvious representation of Row and Column is a 32-bit integer that fits nicely in the general purpose registers and takes up 4 bytes of RAM, that's how they're both represented at runtime.
You can do a lot of this in languages like C++ but there are some pernicious limits that Rust didn't have e.g. C++ can't conceive of Zero Size Types.
This depends on what one thinks of as build quality. If it is a certain way things look and feels that evoke emotions of quality and power, then yes, Apple's build quality is better.
But if you appreciate that things are engineered in a way to make repair-ability and upgrade-ability easy to make your life better and have less hassle, perhaps the Framework has better build quality.
I don't think Go's documentation is better than Rust, Go is just a lot simpler than Rust. Especially if you are a programmer with a background in any of the C-ish syntax languages (C,C++, javascript, Java, C#, etc), its just really easy to pick up.
Rust is a mind bending ordeal by comparison with both the borrow checker and other foreign ideas that take a while to come to terms with.
> I don't think Go's documentation is better than Rust, Go is just a lot simpler than Rust.
Having used both I disagree; Go's stdlib is extremely well documented, even unexported types are along with examples etc. Rust docs are useful but more often feel like there's many things you're expected to figure out from the source and only minimal examples are given.
I am a fan of Rust, but I think Go's docs are an example to follow. The more complex the language, the richer docs it should have imo.
Quite aside from docs, Go's tooling situation is also better.
They both have good patches of documentation and bad ones. They're both better documented than, say, Ruby. Go has multiple edges, not just simplicity, but also a larger user base. You couldn't reasonably disqualify either language basd on their documentation. Certainly, Go is easier to pick up than Rust, but nobody's arguing that.
There are also alternative vector like types for different use cases, and you can roll your own.