Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why did we choose Rust to develop TiKV?

pingcap.github.io

Post reply on HN
Print view View original

41–50 of 206 posts

Re: Why did we choose Rust to develop TiKV?

#41

Post by tentaTherapist »

jcelerier wrote: post #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…

But then your program uses slow, cache-unfriendly and much-reviled reference counting. I'd even prefer Ocaml and its fully-featured GC if C++ is only fast in artificial benchmarks and not in idiomatic code, which apparently must use RC.

Note: I haven't used C++ at all on any project larger than a single file.

Re: Why did we choose Rust to develop TiKV?

#42

Post by tentaTherapist »

jhasse wrote: post #3
jcelerier wrote: post #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…

You'll have to manually break cycles using weak_ptr though.

But you'd have to do that in Rust too, or at least use a library like petgraph, because Rust hates cycles even more than C++.

Re: Why did we choose Rust to develop TiKV?

#44

Post by jhasse »

tentaTherapist wrote: post #42
jhasse wrote: post #3

Earlier quoted context omitted.

You'll have to manually break cycles using weak_ptr though.

But you'd have to do that in Rust too, or at least use a library like petgraph, because Rust hates cycles even more than C++.

True. But you wouldn't have to do that in most GC languages.

Re: Why did we choose Rust to develop TiKV?

#45

Post by rf15 »

zerr wrote: post #40
pornel wrote: post #15

I 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 :)

while I think that that would be a good thing (I like what happened with C#), I see the languages specified and controlled by Microsoft, Google and Apple as second-class languages, since they are often lacking in community input and are usually designed with certain platform-specific goals in mind instead of being cross-platform. (or company-strategic goals when it comes to Google)

Re: Why did we choose Rust to develop TiKV?

#46

Post by blub »

cyber1 wrote: post #32

I 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/CppCoreGuide…

C and Java code bases certainly don't look the same. In fact, claiming that about C is simply insulting to the intellect of anyone reading your overenthusiastic message.

I also sincerely doubt that Rust code bases will look the same in ten years. It supports functional and OO paradigms and it's attracting very different classes of programmers. Recently someone wrote a post about difficulties with some OO concepts in Rust, and a top reply said that they never encountered such issues because they program in a functional way.

Go is an exception here, but as soon as they extend the language in a significant way (e.g. templates) differences will start to appear.

C++ doesn't have an idiomatic style because it's used in very different ways by different people. It's impossible to have a fixed style and address the mass market.

Re: Why did we choose Rust to develop TiKV?

#47

Post by blub »

rf15 wrote: post #45
zerr wrote: post #40

Earlier quoted context omitted.

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 :)

while I think that that would be a good thing (I like what happened with C#), I see the languages specified and controlled by Microsoft, Google and Apple as second-class languages, since they are often lacking in community input and are usually designed with certain platform-specific goals in mind instead of being cross-platform. (or company-strategic goals when it comes to Google)

Yes, there's something not quite right with these company languages.

Whoever is smart will take note of what happened to VisualBasic and is happening to Objective-C.

Re: Why did we choose Rust to develop TiKV?

#48

Post by amelius »

int_19h wrote: post #35
amelius wrote: post #31

If 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.

Closures naturally generate cycles in the data dependency graph. A way out would be to copy the environment of a closure, but that would mean a performance penalty.

Re: Why did we choose Rust to develop TiKV?

#49

Post by pjmlp »

fsloth wrote: post #37
jcelerier wrote: post #19

Earlier quoted context omitted.

> 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.

Chapter 5 of The Garbage Collection Handbook.

http://gchandbook.org/

Re: Why did we choose Rust to develop TiKV?

#50

Post by Ygg2 »

jhasse wrote: post #33
Ygg2 wrote: post #30

Earlier 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 ;)

Yeah, but using Option is encouraged, while using Option.unwrap as error handling is discouraged.

Ok, to be more precise, Option in Rust, isn't a null pointer. It's a nullable pointer. Practically speaking only Option::None is the null pointer. You can either deal with it (using if-let or match) or you can `unwrap` and assume it's never null. If you make that assumption and if and only if it was actually Option::None, will it throw null pointer exception.

In contrast something like C/Java will allow you to use your nullable pointer (because all pointers/references are nullable by default) without any check and it's relatively easy to skip this step. In Rust, it's relatively hard to skip this step.

EDIT: Changed per burntsushi post.

Post reply on HN