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

201–206 of 206 posts

Re: Why did we choose Rust to develop TiKV?

#201

Post by jdright »

abiox wrote: post #200
jdright wrote: post #198

Earlier quoted context omitted.

Simple put: Go ISN'T a true systems programming language because it simple does not work for every and ALL type of systems. Yes, it may work with some type of systems, but this does not make it a systems language. If you don't want to accept this fact , then you have bigger problems or you reality is narrow. Maybe this can help you see through your bubble: https://github.com/CppCon/CppCon2017/blob/master/Presentatio.…

oh, i see. so you were pointlessly making a some kind of fallacy argument. no "true" systems programming language, indeed.

Seriously? Fallacy? That is really not wanting to understand things how they are. You should really go back to textbooks and try to understand hardware.

Re: Why did we choose Rust to develop TiKV?

#202

Post by mtanski »

sriram_malhar wrote: post #187
jerf wrote: post #112

Earlier quoted context omitted.

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

> 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. I'd love to learn more about this. Can you please point me to some links that elaborate on this point with benchmarks? Thanks much.

LWN has had quite a few past articles that went into details of issues with processing network packets at line speeds on modern OSes and machines.

https://lwn.net/Articles/629155/ https://lwn.net/Articles/713918/ https://lwn.net/Articles/719850/

The block layer has gone through somewhat similar issues as some storage devices started approaching RAM speeds.

Re: Why did we choose Rust to develop TiKV?

#203

Post by topspin »

jhasse wrote: post #159
topspin wrote: post #157

Earlier quoted context omitted.

Right, but what you did not get was undefined behavior. That is the real difference, not that Rust "discourages" unwrap(). unwrap() panics, while unfortunate, are well defined.

In reality, this doesn't make a difference though ;)

Halting in a defined manner vs. continuing computation while undefined conditions prevail are fundamentally different outcomes. This is indeed a difference.

Re: Why did we choose Rust to develop TiKV?

#204

Post by jhasse »

topspin wrote: post #203
jhasse wrote: post #159

Earlier quoted context omitted.

In reality, this doesn't make a difference though ;)

Halting in a defined manner vs. continuing computation while undefined conditions prevail are fundamentally different outcomes. This is indeed a difference.

Computation doesn't continue, it segfaults.

Re: Why did we choose Rust to develop TiKV?

#205

Post by topspin »

jhasse wrote: post #204
topspin wrote: post #203

Earlier quoted context omitted.

Halting in a defined manner vs. continuing computation while undefined conditions prevail are fundamentally different outcomes. This is indeed a difference.

Computation doesn't continue, it segfaults.

You simply cannot know that and your assertion reveals a lack of understanding. Computation may continue indefinitely, unintentionally distributing your private keys or doing some other heinous thing forever, without any sort of MMU trap. Undefined means undefined, not 'segfault.'

Re: Why did we choose Rust to develop TiKV?

#206

Post by jhasse »

topspin wrote: post #205
jhasse wrote: post #204

Earlier quoted context omitted.

Computation doesn't continue, it segfaults.

You simply cannot know that and your assertion reveals a lack of understanding. Computation may continue indefinitely, unintentionally distributing your private keys or doing some other heinous thing forever, without any sort of MMU trap. Undefined means undefined, not 'segfault.'

I said "in reality". Can you give me an (realistic) example where using a nullptr doesn't result in a segfault?
Post reply on HN