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

111–120 of 206 posts

Re: Why did we choose Rust to develop TiKV?

#111

Post by new299 »

arjie wrote: post #92
StreamBright wrote: post #89

It is kind of funny how software engineers can engage in lengthy discussion about tooling. Imagine the same for architects. Instead of looking at the building they would talk about the type of hammer they used while building it.

With software the material you construct your creations influences the means. Architects most certainly do argue about whether they should use cross-laminated timber, reinforced concrete, glulam, or steel. They talk about these things and write long pieces on them. The materials influence the design of the building. They don't talk about it on blogs on the Internet because that's not where the audience is. But they d…

> They don't talk about it on blogs on the Internet because that's not where the audience is. But they do talk about this.

It's a real shame. I love reading about other disciplines and knowing about the practical trade offs.

Re: Why did we choose Rust to develop TiKV?

#112

Post by jerf »

sriram_malhar wrote: post #68

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.

"A storage layer should be IO-bound, and should hardly trouble the CPU; the choice of language really should not be a determining factor."

This used to be true, but it's out-of-date now. You can now get a network pipe in to a system that a rather beefy multi-core CPU using a user-space TCP stack can barely keep up with, let alone do any real work, and if you can scrape up the PCI express lanes, putting a few of the latest SSDs into a system can start getting you theoretical maximum bandwidth numbers that just a few years ago looked more like what you'd expect for a RAM bandwidth number.

I'm of the opinion that it was already not as true as commonly supposed 5 years ago (in my experience using slow languages on putatively IO-bound tasks was still noticeably slower than using fast languages), but the latest in network pipes and SSDs have really ended it. It's true that on most desktop systems you've still got more CPU than you know what to do with, but as you step into the serious database space that's not true anymore. For a serious database I wouldn't be perturbed if someone looked at Go's performance and just plain discarded it on the spot, even before considering GC issues. It's very fast for a scripting language; it's fairly slow for a compiled language. "The compiler spends hardly any time on optimization" is not what you want to read about your database implementation language.

(I've got one of the nvme SSDs in my laptop, and it is interesting to see just how many CPU bottlenecks there still are in systems nowadays. In some sense, I really shouldn't ever see a "loading" screen because you "ought" to be able to read things off of my SSD fast enough to completely fill my RAM in 5-10 seconds; "merely" loading Firefox ought to be somewhere in the 50ms range. In practice I still see loading screens and load waits, because the CPUs are still doing things. Lots of things that used to be dominated by and hidden in the load time, but aren't anymore.)

Re: Why did we choose Rust to develop TiKV?

#113

Post by steveklabnik »

Thaxll wrote: post #95
edem wrote: post #59

Earlier quoted context omitted.

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?

What do you mean by not adequate? Go tooling is way better than Rust. The only thing that Rust does better in that field is package dependency and it's going to change soon for Go.

What parts of Go tooling do you miss in Rust?

Re: Why did we choose Rust to develop TiKV?

#114

Post by luckydude »

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?

I'm (very) old school, C is still my language of choice (though it could use some help). I like the syntax, it's pretty simple.

I tried playing with Rust and found the syntax to be off putting. I really wonder why each new language feels it is important to come up with a different syntax to say the same stuff. Go did a lot better than Rust in this respect, at least in my opinion.

It may be that appealing to C programmers isn't a thing any more, but if it is, then Rust could have done better. And, yes, I get that the syntax isn't the selling point of Rust, trust me, I get it. I just don't get why make people wade through some weird syntax when you don't need to.

Re: Why did we choose Rust to develop TiKV?

#115

Post by steveklabnik »

StreamBright wrote: post #89

It is kind of funny how software engineers can engage in lengthy discussion about tooling. Imagine the same for architects. Instead of looking at the building they would talk about the type of hammer they used while building it.

> Imagine the same for architects

Do you know the history of the term "design pattern" in software? It comes from this book: https://en.wikipedia.org/wiki/A_Pattern_Language

Re: Why did we choose Rust to develop TiKV?

#116

Post by ufo »

luckydude wrote: post #114
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?

I'm (very) old school, C is still my language of choice (though it could use some help). I like the syntax, it's pretty simple. I tried playing with Rust and found the syntax to be off putting. I really wonder why each new language feels it is important to come up with a different syntax to say the same stuff. Go did a lot better than Rust in this respect, at least in my opinion. It may be that appealing to C program…

Your comment about syntax sounds like you just want everything to look like C.

Re: Why did we choose Rust to develop TiKV?

#117

Post by blub »

pdimitar wrote: post #86
blub wrote: post #78

Earlier quoted context omitted.

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.

I think what is saying is that (1) these languages are too widely adopted to fail -- somebody is bound to take the ball and continue dribbling it even if the worst happens (company abandons language) and (2) to have a widely adopted language means you have to be a member of a number of committees -- because without standards you wouldn't become a widely adopted language in the first place. In short, we're quite safe…

The issue with C# and Swift is that the Apple and MS dev communities enjoy having a ready made solution that they can pick up and work with immediately. Official support is very important.

C# and to some extent Swift are also two huge platforms, there are very few organisations out there that would be able to steer their development.

Finally, they are not standardised in any way. MS tried something with 2.0 and then gave up.

My impression is that these two live and die by the will of their corporate masters. I'm not saying they will kill them or anything, that would be pretty stupid of them to do.

Re: Why did we choose Rust to develop TiKV?

#118

Post by blub »

pjmlp wrote: post #82
blub wrote: post #78

Earlier quoted context omitted.

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.

If Google, Apple or Microsoft take their employees out of ANSI or from GCC/LLVM contributions, I can assure you they won't move much beyond the current state.

What are the odds that all big players would remove support for something that their platforms are built on? At the same time?

C++ is one of the healthiest languages in existance. It hits all the important checkboxes of standardisation, wide industry and platform support and large community.

Re: Why did we choose Rust to develop TiKV?

#119

Post by jimsmart »

lilbobbytables wrote: post #91
jimsmart wrote: post #80

Earlier quoted context omitted.

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…

What kinds of projects do you use it for?

I've implemented some website backends, a ton of 'micro' services, various command-line tools, and a bunch of data-processing stuff. (The distinction between some of these is somewhat arbitrary)

These are the areas I think Go is most suited to, currently — and they've all been a breeze to implement/test/deploy/maintain.

Re: Why did we choose Rust to develop TiKV?

#120

Post by jcelerier »

pjc50 wrote: post #103
jcelerier wrote: post #101

Earlier quoted context omitted.

> I'm something of an outlier here, maintaining a big legacy MFC application that targets Windows CE, but I can't be the only one. The problem is not developing "legacy" apps, it's comparing the development and maintenance of "legacy" apps with apps that just get started being written today, for which the bare minimum is being cross-platform. > Are there wrappers for things like dlopen()? posix_madvise? Actually, yes…

Interesting stuff. Boost do seem to be aiming for complete wrapper coverage.

> Boost do seem to be aiming for complete wrapper coverage.

I don't think "boost" is aiming at anything. If you have a good idea of a library (and a good implementation!) you can submit it to boost. It's more a big repository of libraries with a somewhat consistent coding style.

Post reply on HN