Why did we choose Rust to develop TiKV?

apologies, but i don't quite follow. what do you refer to by 'class of systems'?

one common sentiment promulgated by rust evangelists is, for example, that go is 'not a systems language' because it has a GC. however, this definitional exclusion doesn't seem to align with (evidently broader) historical use of the term 'systems language'.

First, I want to say that I have great respect for you and everyone else in the Rust community. It's now my second-favorite language (after Go).

I've been learning Rust over the past months and I don't think the borrow checker stuff is as scary as people make it sound, match is amazing, so are traits, enums, cargo....

But, I can't, for the life of me, wrap my head around Rust's "concurrency" story. Yet.

Go concurrency is as close to trivial as one can get - channels, goroutines, select. That's it. And they compose nicely. I was doing concurrent networking stuff in a matter of days.

Rust has channels, select (kind-of?), but then I discovered it has futures, and something called "mio", and now something called "tokio", also read something about generators and coroutines, saw that C#-like "async/await" stuff is also being worked on, and I'm not sure how these things interact with each other.

I get the .NET async/await story, and always felt it was (good) syntactic sugar on top of "raw" JS-style futures, but how do all of them play with the CSP-style stuff like channels that's in the std. lib already? Is one being deprecated?

I feel in general Go's CSP model is more "powerful" and more "generic" than futures - you can even emulate futures/promises with Go's primitives, but I don't see how you can do what I do in Go with bare futures - "streaming" type stuff is especially hard with the futures' "all-or-nothing" approach.

I think Rust really nailed down the "one-thing-at-a-time" story - the docs, tutorials - all great. But for me it broke down quickly on the "easy concurrency" end - and maybe it's just a question of better tutorials/docs?

Also to note that Swift has bindings to the 2D, 3D and real time audio APIs on Apple platforms.

Thanks!

Yeah, so this is basically the result of two things:

1. Rust-the-language focused on making concurrency safe, and getting primtives right

2. The higher-level aspects of the story are still shaking out.

The core primitives are very simple: Sync and Send, two traits which let you declare invariants. But most people don't want to be programming with primitives. So there's been a lot of iteration on what a higher-level story looks like. There are a ton of options, and we've been iterating through them to figure it out. The stuff you're seeing is the result of that process, so you're seeing how the sausage is made, which can definitely be confusing. It's all under active work, and then, once the pieces are in place, getting the right docs/tutorials there.

So, yes. Thanks. It's a good reminder. We'll get there :)

One last thing, as a small amount of food for thought:

> I feel in general Go's CSP model is more "powerful" and more "generic" than futures

In some senses, yes, but they also come with tradeoffs, like any technical choice. Specifically, in order to do concurrency this way, you must go with green threads. And green threads lead to smaller stacks, which leads to non-zero cost of calling into C code, which is a drawback that Rust can't sustain. It works great for Go, but can't really work in Rust, generally. I mean, you can do it, yes, but that drawback doesn't work for the majority of our audience.

It's these kinds of tricky, in-the-weeds stuff that makes designs hard and take time.

No, there's OO C, low-level C, GLib C, etc. There's Android Java, Enterprise Java, Standard Java. Any language catering to different customers will have various styles.

There are two big C++ coding styles: C with classes, an old style which has little use nowadays and modern C++, the recommended way, used in new projects. Asking "what is the idiomatic style in C++?" must be a rhetorical question, because it's obviously modern C++, the leaders of the C++ community have made this clear repeatedly. Template metaprogramming is a technique, not a programming style.

OP should do more hacking without fear and less spreading FUD.