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

181–190 of 206 posts

Re: Why did we choose Rust to develop TiKV?

#181

Post by dullgiulio »

steveklabnik wrote: post #153
Thaxll wrote: post #148

Earlier quoted context omitted.

There is nothing out of the box for profiling ( but it's bit different since no GC and use C/C++ tools ). What's the equivalent of doc godoc -http=:6060 ( it sounds silly by last time I was in a plane and was able to browse the Go doc Like if I had internet access )

Just cargo doc; I think it has a --open flag too. (Rust docs don't need a web server running)

Probably opens a "file://..." then. Go docs run their own embedded server, they don't need one, just to be precise.

Re: Why did we choose Rust to develop TiKV?

#182

Post by jdright »

abiox wrote: post #172
jdright wrote: post #166

Earlier quoted context omitted.

The Rust "evangelists" version of system is most of the time the broader meaning of it as Rust do not exclude an entire class of systems as some languages out there.

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

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

Re: Why did we choose Rust to develop TiKV?

#183

Post by steveklabnik »

dullgiulio wrote: post #181
steveklabnik wrote: post #153

Earlier quoted context omitted.

Just cargo doc; I think it has a --open flag too. (Rust docs don't need a web server running)

Probably opens a "file://..." then. Go docs run their own embedded server, they don't need one, just to be precise.

Yeah, that's exactly what it does.

Re: Why did we choose Rust to develop TiKV?

#184

Post by abiox »

jdright wrote: post #182
abiox wrote: post #172

Earlier quoted context omitted.

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

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.

Re: Why did we choose Rust to develop TiKV?

#185

Post by evincarofautumn »

amelius wrote: post #48
int_19h wrote: post #35

Earlier quoted context omitted.

Most circular data structures still have some node that is semantically the owner of the whole thing. Having true circular ownership is much rarer.

Closures naturally generate cycles in the data dependency graph. A way out would be to copy the environment of a closure, but that would mean a performance penalty.

Whether and how closures generate cycles, and consequently the best implementation strategy, depends heavily on the language, though. You might have a strictly nested call stack or thunks and continuations; shared mutable environments or immutable copies and moves; copyable environments or linear/affine closure types; boxed closures that can be stored in data structures or unboxed closures that can’t always; first-class or second-class closures; a GC to rely on or none; &c.

Re: Why did we choose Rust to develop TiKV?

#186

Post by candiodari »

Vendan wrote: post #167
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…

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.

Re: Why did we choose Rust to develop TiKV?

#187

Post by sriram_malhar »

jerf wrote: post #112
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 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.

Re: Why did we choose Rust to develop TiKV?

#188

Post by hashmal »

blaenk wrote: post #173
hashmal wrote: post #57

Earlier quoted context omitted.

All three have different goals and solve different problems. While you can compare things like "they both have MATCH statements" or "unions are safe", deeper they have nothing to do with each other. You would be crazy to use swift (or objc) in real-time stuff. You would be crazy to write a UI-heavy app in rust. (note: I'm talking about high level DOM-like manipulation, not about rendering engines)

> You would be crazy to write a UI-heavy app in rust. (note: I'm talking about high level DOM-like manipulation, not about rendering engines) I think the jury is still out on that one. I agree with the current state of things but the potential to ease and facilitate this is tremendous through the use of syntax extensions (procedural macros) which can dramatically simplify that use case. In general I think procedural…

I have to agree, things could change in the future. However, my guts tell me rust GUI libraries/frameworks won't be as great as say, Cocoa, although that's something I would love.

Re: Why did we choose Rust to develop TiKV?

#189

Post by p0nce »

ufo wrote: post #116
luckydude wrote: post #114

Earlier quoted context omitted.

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.

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

Re: Why did we choose Rust to develop TiKV?

#190

Post by p0nce »

ufo wrote: post #179
luckydude wrote: post #122

Earlier quoted context omitted.

Yes, precisely. C, for the most part (function pointers are an exception) has a pleasant syntax. Go didn't like semicolons and other stuff that it found unneeded, but mostly took a lot of syntax from C so it's easy to read Go code even without understanding the language. Rust kind of went in a different direction. Why? Understanding C syntax is pretty basic, there are a lot of C like languages. Why not be another one…

Other than its ubiquity, there are lots of bad thigns about C's syntax: * Assignment as an expression is bug-prone * The precedence for the binary operators is wonky * Optional braces in if statements make the grammar ambiguous and is also bug prone (the infamous Apple goto bug) * The type-declaration syntax is convoluted and people need tools like cdecl to understand the more tricky ones. * The cast syntax is ambigu…

> Assignment as an expression is bug-prone

Can be fixed without syntax change other than returning void.

> The precedence for the binary operators is wonky

But that's the precedence everyone is accustomed with. D enhance this by forbidding some non-parenthesized dangerous expressions.

> Optional braces in if statements make the grammar ambiguous and is also bug prone (the infamous Apple goto bug)

I've definately seen such bugs.

> The type-declaration syntax is convoluted and people need tools like cdecl to understand the more tricky ones.

This is fixed in languages that still feel C-like in syntax.

> The cast syntax is ambiguous and resolving this ambiguity relies on adding dirty hacks to the lexer to tell the parser about type names.

Yup.

Post reply on HN