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

11–20 of 206 posts

Re: Why did we choose Rust to develop TiKV?

#11

Post by Tade0 »

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

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 compile and run. This is not a given in e.g. C/C++.

Re: Why did we choose Rust to develop TiKV?

#12

Post by lloydatkinson »

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

And /r/programming

Re: Why did we choose Rust to develop TiKV?

#13

Post by dullgiulio »

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.

Even more, Go is excluded as (author's opinion) goleveldb is not as mature as RocksDB. Thus they should have used CGo, which is way suboptimal, slower etc.

The title should have been: "C++11 or Rust? We chose Rust". In a greenfield project like this one seems to be, it's I choice I would approve.

A personal note regarding future comments to this thread: I have had enough of negative advertising against Go in every language related thread. People who use Go are not stupid: they know the language limits and tradeoffs and are okay with them. Deal with it.

Re: Why did we choose Rust to develop TiKV?

#14

Post by jhasse »

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…

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

Re: Why did we choose Rust to develop TiKV?

#15

Post by pornel »

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?

Re: Why did we choose Rust to develop TiKV?

#17

Post by jhasse »

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)

Re: Why did we choose Rust to develop TiKV?

#18

Post by [deleted] »

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…

[deleted]

Re: Why did we choose Rust to develop TiKV?

#19

Post by jcelerier »

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

"...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 blogpost that they are not sure that their developers are able to handle the "mental overhead" of managing ownership, hence the simple solution of going for shared ownership everytime.

(btw, I re-read your post three times and could not find any hint of harshness !)

Re: Why did we choose Rust to develop TiKV?

#20

Post by jcelerier »

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

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 ?
Post reply on HN