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

71–80 of 206 posts

Re: Why did we choose Rust to develop TiKV?

#71

Post by pjmlp »

pjc50 wrote: post #61
jcelerier wrote: post #29

Earlier quoted context omitted.

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

This is a little difficult on Windows or POSIX systems. Also, as others have pointed out, you can smart-pointerise everything, but still have problems with common tree and graph structures. Rust is rigorous. C++ isn't; I'm not aware of any mainstream compilers which even have the option to make use of bare pointers or unsafe casting or undefined behaviour into compiler warnings/errors.

Which is what keeps companies like LDRA in business.

http://ldra.com/

Re: Why did we choose Rust to develop TiKV?

#72

Post by aaron-lebo »

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

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

I mean, I've dropped in and out of the Ruby, Python, Javascript, Go, Clojure, Elixir etc communities and they all trying to be welcoming. It's kind of a given. It's rare to find the language community that isn't welcoming, and I think you'll find even that the most stubborn (lisp, Haskell) are very happy to have you and very happy to help new users.

You probably have an argument that they are doing something different and right, but how markedly different is it really?

Re: Why did we choose Rust to develop TiKV?

#73

Post by stepik777 »

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 how would smart pointers help you if you need to return pointer to a member from a function? Does C++ protects you from moved from unique_ptr? Or from iterator invalidation? Or maybe you can safely use non-atomic shared pointer if you don't need to send it across threads?

Re: Why did we choose Rust to develop TiKV?

#74

Post by gnuvince »

Ygg2 wrote: post #56
blub wrote: post #46

Earlier quoted context omitted.

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…

Traits can be used for polymorphism: https://play.rust-lang.org/?gist=5d4bae81014d879b43bad1326dd...

Re: Why did we choose Rust to develop TiKV?

#76

Post by latch »

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 ?

You're talking to someone who says they're an experienced painter. They show you some of their work. You reply "are you sure you're an 'experienced painter'?"

After answering a question during a job interview, the interviewer says 'are you sure you're a "senior programmer?"'

Re: Why did we choose Rust to develop TiKV?

#77

Post by Ygg2 »

gnuvince wrote: post #74
Ygg2 wrote: post #56

Earlier quoted context omitted.

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

Traits can be used for polymorphism: https://play.rust-lang.org/?gist=5d4bae81014d879b43bad1326dd...

True, but what people ask for when they ask for OO is for structs to be extendable.

Re: Why did we choose Rust to develop TiKV?

#78

Post by blub »

pjmlp wrote: post #70
blub wrote: post #47

Earlier quoted context omitted.

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.

You mean like C and C++ being developed at AT&T, nowadays designed at ANSI, with people on ARM, Google, Apple, Blommberg, Sony, IBM, Microsoft's payroll?

Looking into the past can have some predictive value, but looking that far back and at a different company is of very limited value.

If one evaluates C# they should obviously look at what MS are doing. Same thing for Swift and Apple.

Re: Why did we choose Rust to develop TiKV?

#79

Post by msl09 »

edem wrote: post #59
dullgiulio wrote: post #13

Earlier quoted context omitted.

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?

I haven't used Rust yet but I can tell you that the go tools are very robust. It's a very good language if you stay within it's optimal scope and do everything by the book, go tends to punish quite hard developers that try to be "create" with project layouts and best code practices and so on.

Re: Why did we choose Rust to develop TiKV?

#80

Post by jimsmart »

edem wrote: post #59
dullgiulio wrote: post #13

Earlier quoted context omitted.

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?

Well, your question is simply too open-ended: nobody can really answer that for you, as you give no indication whatsoever as to your potential use-cases.

FWIW: I've been coding in Go for a few years now, for me and (perhaps more importantly) the kind of projects I choose to use it for, the build tools have been more than adequate.

As with many things: it ultimately depends on what you're wanting to do, and what your expectations are.

Post reply on HN