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

191–200 of 206 posts

Re: Why did we choose Rust to develop TiKV?

#191

Post by Vendan »

candiodari wrote: post #186
Vendan wrote: post #167

Earlier quoted context omitted.

Range is hardly return-type polymorphic. It always returns the same things, you are just free to ignore them, i.e. for k := range map { } is the same thing as for k, _ := range map { } Would requiring the second version instead of the first actually be that much of an improvement? The only true return-type polymorphism is type assertions, which is reasonable in my mind cause I don't think ignoring the "assertion fail…

Ok. Now consider what happens with slices/arrays instead of maps. 1) for k := range list {} 2) for k, i := range list {} In python, the equivalents are: 1) for x in lst: 2) for x, y in enumerate(lst): So are these "the same" ? No.

more accurately it's

  for index := range list {}
and

  for index, value := range list {}
Yes, these 2 version do perform very similarly, you are just ignoring the second return value in the first version, i.e.:

  for index, _ := range list {}

Re: Why did we choose Rust to develop TiKV?

#192

Post by peoplewindow »

jjuel wrote: post #123
peoplewindow wrote: post #106

Earlier quoted context omitted.

Re your last part - is that fair? It's very common that programmers have to end up maintaining code written in languages they don't like, due to the original authors moving on, lack of better jobs in their area, whatever. People advocate against Go partly because they'd rather not have to work on Go codebases in future.

Well I don't want to work on C++ or Rust in the future should I go into every thread about it and slam them for their shortcomings? Should I call every dev that uses them stupid? That is what he was talking about. You can not like the language, but don't call people who do like it and use it idiots. There are better ways to get your points across.

People do! But not as much with C++ because it's very rare to find a C++ developer who is genuinely in love with the language and is unaware of its faults. Not many people starting new C++ codebases today unless they feel they have no credible alternative choice.

To a lesser extent the same is true of Rustaceans - they tend to be well aware of the constraints of their language, and won't try to defend it or pump it outside of some specific use cases. Nor do the Rust designers who are fairly humble.

Nobody should be calling Go users stupid. But they typically don't. At least not here. The language itself, on the other hand ...

Re: Why did we choose Rust to develop TiKV?

#193

Post by jdright »

abiox wrote: post #184
jdright wrote: post #182

Earlier quoted context omitted.

Real real-time embedded systems, low-level operating system components, etc. are some kind of things that GC languages exclude completely, so by definition, the subset of "system programming" set is eliminated from use with ie. Go but not from Rust. Consequently, Rust has wider class of systems which makes it a true system programming language as C and C++.

"system programming" is not composed entirely of things where GC presents a non-trivial problem.

But 100% > 50%.

Re: Why did we choose Rust to develop TiKV?

#194

Post by peoplewindow »

Thaxll wrote: post #161
candiodari wrote: post #156

Earlier quoted context omitted.

Or perhaps they're language geeks. Go is truly a horror show when it comes to programming language concepts. Everything about go is a complete special case. Select ... has it's own type system exceptions (and so many exceptions you might as well say Go simply has different type systems for all built in types, for all built in functions, and for several special forms). Make ... ditto. New ... ditto. "Go" same. Channel…

I don't code at work for programming language concept, you see you should use the tools that make sense for the task you're working on. I'm not being paid to have fun on using an academic language that no one use, have bad tooling, not enough libraries to work with. You never wonder why pretty much no one uses Haskell / Erlang if it's that great? Having the best language concepts doesn't mean a thing in the real worl…

He wasn't saying use Haskell instead. It was a comparison of the complexity of the type system vs power provided.

Most Go programs could have been written in Java, Scala, C# or Kotlin and been shorter, more predictable and probably faster. Certainly more maintainable (ok maybe not for Scala).

Re: Why did we choose Rust to develop TiKV?

#195

Post by jerf »

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.

Google around for the Intel DPDK, and you can find things like this: http://www.cs.cornell.edu/courses/cs5413/2014fa/projects/gro...

You can also do a simple math analysis to see it. If you have an incoming 10Gbps connection, a single core machine has approx. 1/3rd of a cycle per bit to do everything it's going to do with that packet. Even going to a 128 core machine and assuming perfect parallelism with some sort of magical packet muxer gives you a whopping 43-ish cycles per bit. I've never worked on this myself, but I saw a team in my company working with it and were pretty pleased to be able to push ~2Gbps through their 10Gbps network connection with a pretty beefy machine, and just about all they were doing was relatively simple load balancing.

Re: Why did we choose Rust to develop TiKV?

#196

Post by luckydude »

p0nce wrote: post #189
ufo wrote: post #116

Earlier quoted context omitted.

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

What is the added value of things not looking like C?

Yeah, exactly the right question. To me, C is like English, everyone has learned how to speak it. Creating some new syntax is a little like switching to a different language. I find that difficult and annoying.

Here's an example. When I was doing the GUI tools for BitKeeper 20 years ago I used Tcl because Tk was (and still is so far as I can tell) the best gui toolkit around. But Tcl? Holy moly, what a miserable language (with apologies, and respect to John O, it's miserable). So I got some compiler people to make a second, parallel, compiler that took what looked like C as input and compiled it down to Tcl byte codes.

Pingo! All the power of Tk but with a C-like language on top. And you can call the tcl library code and it can call you.

All open source at http://little-lang.org

I wish someone would take the ideas there and make a gcc/clang dialect that had all C stuff but added in a ref counter and real strings, etc.

Re: Why did we choose Rust to develop TiKV?

#198

Post by jdright »

abiox wrote: post #197
jdright wrote: post #193

Earlier quoted context omitted.

But 100% > 50%.

i don't quite follow what you're trying to say.

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

Re: Why did we choose Rust to develop TiKV?

#199

Post by SAI_Peregrinus »

jdright wrote: post #198
abiox wrote: post #197

Earlier quoted context omitted.

i don't quite follow what you're trying to say.

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

Another way to say it: The set of systems programming tasks for which Rust can be used is a superset of that for which Go can be used. Go cannot be used for real time code, as it does not provide latency guarantees. Go cannot be used for many embedded (microcontroller) systems as the runtime is required.

I've gotten Rust code to run on an ATSAMD21G18 Arm Cortex M0 (Adafruit Feather board). That board has 256K flash and 32K RAM. Go executables can't even fit in the program flash! Considering the sheer number of systems that have microcontrollers in them somewhere it would be very hard to call a language that doesn't support them a "systems" language. Maybe "applications language" would be more appropriate.

Re: Why did we choose Rust to develop TiKV?

#200

Post by abiox »

jdright wrote: post #198
abiox wrote: post #197

Earlier quoted context omitted.

i don't quite follow what you're trying to say.

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