Why did we choose Rust to develop TiKV?
pingcap.github.io
Why did we choose Rust to develop TiKV?
1–10 of 206 posts
Re: Why did we choose Rust to develop TiKV?
#2> After years of usage of GC, it is very hard to go back time for manually managing the memory.
... are you guys sure of your "experienced C++ developers" ? There's as much memory management in modern C++ than in GC'ed language: none. Create your objects with `make_unique` or `make_shared` according to what makes sense (or just enforce `make_shared` if you're really dubious of the coding abilities of your team but at this point you'll have problems whatever you do).
Re: Why did we choose Rust to develop TiKV?
#3> After years of usage of GC, it is very hard to go back time for manually managing the memory. ... are you guys sure of your "experienced C++ developers" ? There's as much memory management in modern C++ than in GC'ed language: none. Create your objects with `make_unique` or `make_shared` according to what makes sense (or just enforce `make_shared` if you're really dubious of the coding abilities of your team but at…
You'll have to manually break cycles using weak_ptr though.
Re: Why did we choose Rust to develop TiKV?
#4> After years of usage of GC, it is very hard to go back time for manually managing the memory. ... are you guys sure of your "experienced C++ developers" ? There's as much memory management in modern C++ than in GC'ed language: none. Create your objects with `make_unique` or `make_shared` according to what makes sense (or just enforce `make_shared` if you're really dubious of the coding abilities of your team but at…
Yeah, that read like some Java advertising from the 90s.
I wish more of these posts were honest and said "we picked X cause we think it's cool and we're gonna get paid to learn it". But they have to make up some convoluted explanation that sounds rational and acceptable instead.
Re: Why did we choose Rust to develop TiKV?
#5TLDR; the author likes rust and wanted to use it. The article reads like some dev's rationalizing what they want to do to the management. These types of things are fine, but as a dev to a dev it is obvious that they just want to use this cool tech. Good for them.
Re: Why did we choose Rust to develop TiKV?
#6> After years of usage of GC, it is very hard to go back time for manually managing the memory. ... are you guys sure of your "experienced C++ developers" ? There's as much memory management in modern C++ than in GC'ed language: none. Create your objects with `make_unique` or `make_shared` according to what makes sense (or just enforce `make_shared` if you're really dubious of the coding abilities of your team but at…
First sentence is why I dread reading comment. Why you gotta be like that?
Re: Why did we choose Rust to develop TiKV?
#7it'd be enough for me to say 'rust is kinda like c++ in terms of performance and complexity but without the 0 pointer'
Re: Why did we choose Rust to develop TiKV?
#8And lack of experience with D.
Just kidding, great job!
Re: Why did we choose Rust to develop TiKV?
#9TLDR; the author likes rust and wanted to use it. The article reads like some dev's rationalizing what they want to do to the management. These types of things are fine, but as a dev to a dev it is obvious that they just want to use this cool tech. Good for them.
Fits in pretty well with the ongoing Rust agenda here in HN
Re: Why did we choose Rust to develop TiKV?
#10> After years of usage of GC, it is very hard to go back time for manually managing the memory. ... are you guys sure of your "experienced C++ developers" ? There's as much memory management in modern C++ than in GC'ed language: none. Create your objects with `make_unique` or `make_shared` according to what makes sense (or just enforce `make_shared` if you're really dubious of the coding abilities of your team but at…
"...make_shared"
Sorry, I'm going to be a bit harsh now.
There is a host of distinctive differences between garbage collection and reference counting. Yes, both are memory handling strategies. That's where the similarities end.
"Just slap it in a shared pointer" is never a good advice without knowledge what 'it' is or in what kind of system it exists in.