3 ms·
That kind of integration is another reason, yes, but this is a passable moat, so I'm not talking about it much (mind you, I live in HPC world). If programming
by bayindirh 3y ago
That kind of integration is another reason, yes, but this is a passable moat, so I'm not talking about it much (mind you, I live in HPC world).
If programming is a team sport, every team player should be up to the level your project needs. If they are not, they should raise their bars. Seriously.
Yes, seriously, be mindful. Implement allocation and destruction first, fill your code between these two steps.
A couple of Valgrind tests is actually a whole procedure. It's an unfortunate downplay by me [0], probably because I'm very used to use Valgrind as a second nature.
[0]: https://news.ycombinator.com/item?id=31218757 https://news.ycombinator.com/item?id=31218757
- kaba0 3y agoSo what about multithreaded code with potential race conditions that result in memory errors sometimes. Valgrind already only able to test the actually ran code paths, let alone find race condition-y bugs. Also, this elitist notion of raising the bar is an instant “turnoff” for me, with all due respect, I can only assume from that that the given person may not be as much an expert as they think of themselves. Not saying that it applies to you as well, but you don’t leave me much other choice.
- lenkite 3y agoMemory safe - I will give you that. All the guarantees you listed are fine for synchronous Rust. But race conditions and deadlocks are not unknown in async Rust. Lots of race condition issues in tokio - including issues where futures leak.
- kaba0 3y agoThat’s true, and usually I am the one pointing this out, that Rust is only data race free :D thanks for the pointer!