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

61–70 of 206 posts

Re: Why did we choose Rust to develop TiKV?

#61

Post by pjc50 »

jcelerier wrote: post #29
pjc50 wrote: post #23

Earlier quoted context omitted.

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

Re: Why did we choose Rust to develop TiKV?

#62

Post by hnlmorg »

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)

I can understand conservative choices when it comes to picking a language but what you describe is a potential risk for plenty other existing languages as well as any new language too. Rust wouldn't be where it is today if it wasn't sponsored by Mozilla. Java was Sun Microsystems baby and I remember all the concerns at the time with the Sun vs Microsoft fighting over control of the ecosystem. Plus even many of the non-corporate languages are still heavily dependant on a small subset of maintainers.

At the end of the day if a language proves popular enough in other domains outside of the area which is directly controlled by the language maintainers, then the community will usually find a way of taking over maintenance of it.

We've seen this with Pascal, various BASIC dialects (including Visual Basic), and to an extent Java too. The problem with Objective-C was that - as far as I'm aware at least - it wasn't widely used outside of Apple / NeXT's ecosystem so if Apple deprecate support for Objective-C on their own platforms then there's little incentive for the community to keep using language (much like the problems with Visual Basic - which is why few know about it's open source forks). But languages like C# and Go are used massively across a multitude of domains so even if MS/Google were to kill them tomorrow, the community would almost certainly find a way to keep language alive. Heck, Go might even become more popular if that happened since many of the complaints against it are down to the highly opinionated approach of the current leadership.

Let's also not forget that Go and C# tooling are open source so the community wouldn't have to reinvent the wheel like they did with Delphi / Object Pascal and Visual Basic.

Re: Why did we choose Rust to develop TiKV?

#64

Post by zerr »

cyber1 wrote: post #60
zerr wrote: post #58

Earlier quoted context omitted.

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.

Yes, there is a trade-off of course. I think Swift is in the middle on Usability - Safety axis (C++ being on the left and Rust on the right extremes).

Re: Why did we choose Rust to develop TiKV?

#65

Post by burntsushi »

Ygg2 wrote: post #50
jhasse wrote: post #33

Earlier quoted context omitted.

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…

Use of Option.unwrap (or Option.expect) in libraries is not discouraged, and it shouldn't be. It's an excellent way of checking a runtime invariant. Use of Option.unwrap is discouraged for error handling.

Stated differently, if a library you're using causes a panic, then it should be interpreted as a bug. The bug might be in the library, or it might be in the way that the library is being used (assuming the panic conditions have been documented as part of the library API's contract).

A separate argument says that you should reduce the number of places where your code can panic. That sounds like a fine goal to strive for, but must be balanced with other things.

Re: Why did we choose Rust to develop TiKV?

#66

Post by icen »

jhasse wrote: post #28
Tade0 wrote: post #21

Earlier quoted context omitted.

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

The &* thing is due to Deref coercions. The deference operator is a trait (Deref), which has an associated type that it dereferences to. This lets you do nice things, like dereference a Box to just a T, and let the Box implementation figure out how to get you there. (It's also used on method calls using .)

What you have is a reference to a type with a Deref-coercion to the type you want, but the compiler won't coerce under the reference for you, so you have to dereference and then reference it again, and then type inference can work out that you wanted to reference the coerced type.

Re: Why did we choose Rust to develop TiKV?

#67

Post by pjmlp »

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.

Apple thinks otherwise on the context of their OSes.

Re: Why did we choose Rust to develop TiKV?

#68

Post by sriram_malhar »

Considering that their team likes Go, it seems strange to me that they would consider Rust over Go for the storage layer. A storage layer should be IO-bound, and should hardly trouble the CPU; the choice of language really should not be a determining factor. The big wins in that space are architectural, not language specific.

Re: Why did we choose Rust to develop TiKV?

#69

Post by pjmlp »

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)

So I guess you also see C and C++ as second-class languages, given the employers of the people meeting at ANSI.

Re: Why did we choose Rust to develop TiKV?

#70

Post by pjmlp »

blub wrote: post #47
rf15 wrote: post #45

Earlier quoted context omitted.

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.

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