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

21–30 of 206 posts

Re: Why did we choose Rust to develop TiKV?

#21

Post by Tade0 »

jhasse wrote: post #14
Tade0 wrote: post #11

Earlier quoted context omitted.

To be fair the language is very pleasant to work with if you're a beginner, because the compiler seems to have been built around the concept of giving the most helpful (and polite!) messages possible. Never have I ever had a compiler tell me to "consider" changing some type declaration, because maybe, just maybe I was probably intending to do what it suggests all along. Also generally things you didn't write still co…

> the compiler seems to have been built around the concept of giving the most helpful (and polite!) messages possible. I can't confirm that. I have already ran into compiler bugs and very very unhelpful error messages and I haven't really done that much in the language.

Any specific messages you found to be unhelpful?

Re: Why did we choose Rust to develop TiKV?

#22

Post by c4pt0r »

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

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.

Hahahah, you're right. We picked Rust cuz our CEO and I think it's cool... XD

Re: Why did we choose Rust to develop TiKV?

#23

Post by pjc50 »

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…

And do all the C++ libraries take only smart pointers as arguments and return only smart pointers as return values?

Re: Why did we choose Rust to develop TiKV?

#24

Post by MrBuddyCasino »

Tade0 wrote: post #11
throwaway884 wrote: post #9

Earlier quoted context omitted.

Fits in pretty well with the ongoing Rust agenda here in HN

To be fair the language is very pleasant to work with if you're a beginner, because the compiler seems to have been built around the concept of giving the most helpful (and polite!) messages possible. Never have I ever had a compiler tell me to "consider" changing some type declaration, because maybe, just maybe I was probably intending to do what it suggests all along. Also generally things you didn't write still co…

Yes, they're trying very hard to be welcoming. This is markedly different from certain other programming communities and deserving of praise.

Re: Why did we choose Rust to develop TiKV?

#25

Post by deadjoe »

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

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.

from the post , looks like they really do think picking rust is dope and already built a cool db system upon it. Maybe they already got bunch of bucks in the pocket. Huhhh..

Re: Why did we choose Rust to develop TiKV?

#26

Post by lmm »

throwaway884 wrote: post #9
eikenberry wrote: post #5

TLDR; 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

What kind of agenda could there be? Mozilla can't afford anything like as many people to push a language as Google can. Rust is pretty popular but the simplest explanation that fits the facts is that the language really is that good.

Re: Why did we choose Rust to develop TiKV?

#27

Post by noselasd »

jcelerier wrote: post #20
latch wrote: post #6

Earlier quoted context omitted.

First sentence is why I dread reading comment. Why you gotta be like that?

sorry, could you explain a bit more ? does '... are you guys sure of your "experienced C++ developers" ?' sound harsh to you ?

It's just a very loaded opinion, while you pretend it's a universal fact. I have never heard, nor experienced, any seasoned C++ developer claiming that smart pointers is a substitute for garbage collection.

Yes, smart pointers are nice, they alleviate you from a whole lot of manual memory management - but the programming model is still vastly different from what you would do in a traditional GC'ed language(such as Java or C#)

Re: Why did we choose Rust to develop TiKV?

#28

Post by jhasse »

Tade0 wrote: post #21
jhasse wrote: post #14

Earlier quoted context omitted.

> the compiler seems to have been built around the concept of giving the most helpful (and polite!) messages possible. I can't confirm that. I have already ran into compiler bugs and very very unhelpful error messages and I haven't really done that much in the language.

Any specific messages you found to be unhelpful?

This one for example: https://github.com/rust-lang/rust/issues/17164

There was another one, but I can't find the issue for it. I asked in IRC about it and it was fixed by adding &* before an expression. I didn't understand why ...

Re: Why did we choose Rust to develop TiKV?

#29

Post by jcelerier »

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

And do all the C++ libraries take only smart pointers as arguments and return only smart pointers as return values?

> And do all the C++ libraries take only smart pointers as arguments and return only smart pointers as return values?

C++ libraries that would be as recent as Rust libraries would certainly take things by value or reference so there would be no problems. I honestly don't know libraries with raw pointers in their APIs that aren't from the 90's or before; and I don't think you want to use those in a current product anyways.

Re: Why did we choose Rust to develop TiKV?

#30

Post by Ygg2 »

jhasse wrote: post #17
baq wrote: post #7

it'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)

Umm unwrap panic is definitely not the same.

For one it's heavily discouraged. Any example using it is not best practice.

Post reply on HN