If you had lots of circularly referencing data structures, would it make more sense to choose a garbage-collected language like Go?
Why did we choose Rust to develop TiKV?
31–40 of 206 posts
Re: Why did we choose Rust to develop TiKV?
#32I think TiKV is a good example where team chose Rust over Modern C++. Rust gives the same performance and is close to metal like C when it is necessary. All possible memory management mistakes it catches at compile time if it's not "unsafe" and this is a really great!
With Rust I can hack without fear! I shouldn't remember tons of C++ rules which are described in http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines, "C++ programming language" book, also here https://herbsutter.com/gotw/, etc and I can focus on algorithms and implementation.
C++ combines a lot of different paradigms m.b. more correct I would like to say "C++ paradigms hell"! Which of C++ subsets is the right way, no one understands. Even Bjarne Stroustrup said, "Within C++, there is a much smaller and cleaner language struggling to get out." - and where is this "smaller and cleaner language"?. What is the idiomatic style in C++? Is it Google guidelines, CoreCpp guidelines or other enormous guides?
I look inside a lot of C++ projects and each of them has different styles, use different paradigms, sometimes look like different languages!
Rust, Go, C, Java code bases look the same, they have their own idiomatic style, their own way.
I think Rust is the next step in the evolution of system programming language.
Re: Why did we choose Rust to develop TiKV?
#33Earlier quoted context omitted.
Rust also has a "0 pointer": https://doc.rust-lang.org/std/option/ The equivalent of a null pointer exception in Rust is an unwrap panic. (IIRC if you use Option > None will even be represented by a null pointer internally)
Umm unwrap panic is definitely not the same. For one it's heavily discouraged. Any example using it is not best practice.
I still got a few unwrap panics in libraries I've used (not in example code).
Also: Using a null pointer in C++ is also heavily discouraged ;)
Re: Why did we choose Rust to develop TiKV?
#34The one reason I would give is Algebraic Data Types.
Re: Why did we choose Rust to develop TiKV?
#35If you had lots of circularly referencing data structures, would it make more sense to choose a garbage-collected language like Go?
Most circular data structures still have some node that is semantically the owner of the whole thing. Having true circular ownership is much rarer.
Re: Why did we choose Rust to develop TiKV?
#36Earlier quoted context omitted.
Umm unwrap panic is definitely not the same. For one it's heavily discouraged. Any example using it is not best practice.
I still got a few unwrap panics in libraries I've used (not in example code). Also: Using a null pointer in C++ is also heavily discouraged ;)
Only if you are talking about raw pointers. Using unique_ptr or shared_ptr to hold nullptr is still pretty common in C++.
Re: Why did we choose Rust to develop TiKV?
#37Earlier quoted context omitted.
"...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.
> There is a host of distinctive differences between garbage collection and reference counting. No, reference counting is commonly seen as a specific implementation of garbage collection. https://en.wikipedia.org/wiki/Garbage_collection_(computer_s... > "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. I agree, but it seems from their blog…
"No, reference counting is commonly seen as a specific implementation of garbage collection"
Shared pointers provide the reference counting, but reference counting alone hardly constitutes a garbage collector because it doesn't collect all of the garbage.
For example, shared_ptr:s alone do not automatically detect and collect cycles.
Re: Why did we choose Rust to develop TiKV?
#38I can't wait until Rust is no longer be perceived as hipster trendy choice. It's a very solid language in the no-GC niche and shouldn't need a blog post from every project that uses it. Does it have to be 30 years old before it's not "new" and weird?
“new and weird" is always relative to the industry/domain on application. In each domain , whether it be avionics or web development, managers are not going to want to use it until it has a proven record of success in that domain.
Re: Why did we choose Rust to develop TiKV?
#39it'd be enough for me to say 'rust is kinda like c++ in terms of performance and complexity but without the 0 pointer'
Rust also has a "0 pointer": https://doc.rust-lang.org/std/option/ The equivalent of a null pointer exception in Rust is an unwrap panic. (IIRC if you use Option > None will even be represented by a null pointer internally)
Yeah, but unwrap is very, very explicitly marked, and its use is discouraged, and unlike null it's nothing close to an undesirable edge case on every single pointer.
Edit: In my perfect language there wouldn't be an unwrap, only matching on an Option, but I guess Rust is too pragmatic for that.
Re: Why did we choose Rust to develop TiKV?
#40I can't wait until Rust is no longer be perceived as hipster trendy choice. It's a very solid language in the no-GC niche and shouldn't need a blog post from every project that uses it. Does it have to be 30 years old before it's not "new" and weird?
On the other hand I can't wait when Swift becomes general, non-Apple language, available on most platforms (including the most popular one) "with batteries" - that will be the end of Go and Rust I think :)