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

51–60 of 206 posts

Re: Why did we choose Rust to develop TiKV?

#51

Post by cyber1 »

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

Swift can't replace Rust in system programming domain because he uses ARC for memory management but Rust gives you choices.

Re: Why did we choose Rust to develop TiKV?

#54

Post by blub »

noselasd wrote: post #27
jcelerier wrote: post #20

Earlier quoted context omitted.

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 Ja…

A lot of C++ big names have said that smart pointers are better than garbage collection for handling resources. And they are, because GC only handles memory.

Having memory leaks in modern C++ is a sign of not keeping up with the established idioms. Saying that experienced C++ programmers are worried about memory leaks is bizarre.

Re: Why did we choose Rust to develop TiKV?

#55

Post by readittwice »

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

> that will be the end of Go and Rust

Will it? I don't think so, although I think Swift is great. IMHO Rust targets another market compared to Swift. Rust feels more low-level, e.g. Swift uses Reference Counting for everything. Swift also can't give you some of the nice guarantees you get in Rust.

Go also has some nice stuff compared to Swift: simplicity, goroutines or tracing GC. Go is also already widely used.

Swift is certainly great for Mac/iOS-Development, but I am somewhat skeptical for other platforms. I am afraid that non-apple-platforms will always feel a bit like second-class. It's just not Apple's main priority and most Swift-devs will always be paid by Apple. But who knows, I may be wrong.

Re: Why did we choose Rust to develop TiKV?

#56

Post by Ygg2 »

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

   > It supports functional and OO paradigms.
[Citation Needed]

I don't think anything in Rust supports OO paradigm. There are instances where people ask for OO paradigm, but so far, there wasn't any movements towards it.

There is no inheritance and no polymorphism based on it. There is generics polymorphism, but nothing like that.

Hell, even things like

    object.method()
is a sugar for:

    method(&object)
And I mean that in literal sense, you can use the second form always. https://play.rust-lang.org/?gist=6a8111b51c3862caa52c498c79e...

Re: Why did we choose Rust to develop TiKV?

#57

Post by hashmal »

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

All three have different goals and solve different problems. While you can compare things like "they both have MATCH statements" or "unions are safe", deeper they have nothing to do with each other.

You would be crazy to use swift (or objc) in real-time stuff. You would be crazy to write a UI-heavy app in rust. (note: I'm talking about high level DOM-like manipulation, not about rendering engines)

Re: Why did we choose Rust to develop TiKV?

#58

Post by zerr »

cyber1 wrote: post #51
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 :)

Swift can't replace Rust in system programming domain because he uses ARC for memory management but Rust gives you choices.

I don't think ARC is an issue here - it's just a deterministic reference counting - a la implicit using of smart pointers. Besides, Swift also has some unsafe pointer types as well.

Re: Why did we choose Rust to develop TiKV?

#59

Post by edem »

dullgiulio wrote: post #13
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 la…

I haven't used Go or Rust but when I compare them I have a gut feeling that I'd be better off with Rust primarily because Go's build tools are not adequate. What do you think about this?

Re: Why did we choose Rust to develop TiKV?

#60

Post by cyber1 »

zerr wrote: post #58
cyber1 wrote: post #51

Earlier quoted context omitted.

Swift can't replace Rust in system programming domain because he uses ARC for memory management but Rust gives you choices.

I don't think ARC is an issue here - it's just a deterministic reference counting - a la implicit using of smart pointers. Besides, Swift also has some unsafe pointer types as well.

Yes, you right according to "deterministic" but you forget about overhead. Rust gives you more safe control on memory management and in most cases, you can always write the fast and efficient safe program without the overhead. Rust give different smart pointers and even sometimes when you 100% understand what are you doing you can use unsafe raw ptr.
Post reply on HN