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

101–110 of 206 posts

Re: Why did we choose Rust to develop TiKV?

#101

Post by jcelerier »

pjc50 wrote: post #97
jcelerier wrote: post #88

Earlier quoted context omitted.

> This is a little difficult on Windows or POSIX systems. How so ? it's not like you are using the Win32 or POSIX APIs in 2017 anyways

Not everything has a convenient wrapper, just the high profile stuff like files and GUIs. Are there wrappers for things like dlopen()? posix_madvise? All the various set... functions? Filesystem ACLs? COM objects? (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. One implication of this is that I'm using the Microsoft MIPS compiler with t…

> 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, in a cross-platform way:

* http://www.boost.org/doc/libs/1_65_1/doc/html/boost_dll.html (does dlopen, dlclose, and so much more)

* http://www.boost.org/doc/libs/1_65_1/doc/html/boost/interpro... (advise() == posix_madvise if available)

> Filesystem ACLs ?

none that I know of :( though MS has a fairly decent "modern C++" API that covers WinRT: https://github.com/Microsoft/cppwinrt but I don't think ACLs are even available in WinRT

> COM

oh, yes: https://www.codeproject.com/Articles/5748/Introducing-Comet

Re: Why did we choose Rust to develop TiKV?

#102

Post by bpicolo »

sanxiyn wrote: post #100
bpicolo wrote: post #94

Anybody have experience with TiDB? How does it stack up against CockroachDB? Seems hard to find comparison. Probably hear less about it mostly because it's developed in China? Looks like it's an impressive piece of tech, though.

http://weekly.pingcap.com/2016/10/17/how-we-build-tidb/#atom... explains their main difference from CockroachDB.

Mostly curious how it works out in practice. Performance, etc.

Re: Why did we choose Rust to develop TiKV?

#103

Post by pjc50 »

jcelerier wrote: post #101
pjc50 wrote: post #97

Earlier quoted context omitted.

Not everything has a convenient wrapper, just the high profile stuff like files and GUIs. Are there wrappers for things like dlopen()? posix_madvise? All the various set... functions? Filesystem ACLs? COM objects? (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. One implication of this is that I'm using the Microsoft MIPS compiler with t…

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

Re: Why did we choose Rust to develop TiKV?

#104

Post by mrkgnao »

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.

Is this a hammer question, or one of e.g., concrete vs. wood?

Re: Why did we choose Rust to develop TiKV?

#105

Post by Koshkin »

pjc50 wrote: post #23
jcelerier wrote: post #2

> After years of usage of GC, it is very hard to go back time for manually managing the memory. ... are you guys sure of your "experienced C++ developers" ? There's as much memory management in modern C++ than in GC'ed language: none. Create your objects with `make_unique` or `make_shared` according to what makes sense (or just enforce `make_shared` if you're really dubious of the coding abilities of your team but at…

And do all the C++ libraries take only smart pointers as arguments and return only smart pointers as return values?

They don't, and it is (or should be) considered bad practice for functions, in general, to take/return smart pointers. Normally these should only be used as variables or class members; functions, on the other hand, should take/return raw pointers (except some special cases) or, better yet, references (except when there is a need to check for null value).

Re: Why did we choose Rust to develop TiKV?

#106

Post by peoplewindow »

dullgiulio wrote: post #13
eikenberry wrote: post #5

TLDR; the author likes rust and wanted to use it. The article reads like some dev's rationalizing what they want to do to the management. These types of things are fine, but as a dev to a dev it is obvious that they just want to use this cool tech. Good for them.

Even more, Go is excluded as (author's opinion) goleveldb is not as mature as RocksDB. Thus they should have used CGo, which is way suboptimal, slower etc. The title should have been: "C++11 or Rust? We chose Rust". In a greenfield project like this one seems to be, it's I choice I would approve. A personal note regarding future comments to this thread: I have had enough of negative advertising against Go in every la…

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.

Re: Why did we choose Rust to develop TiKV?

#107

Post by sanxiyn »

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.

Rust would use less memory than Go. (Dropbox also likes Go and used Rust over Go for the storage layer, and when asked, memory usage was their primary reason.)

Re: Why did we choose Rust to develop TiKV?

#108

Post by TremendousJudge »

greydius wrote: post #99
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?

Haskell is almost 30 years old and still considered 'new' and 'weird'.

I don't know about new but it is pretty weird

Re: Why did we choose Rust to develop TiKV?

#109

Post by jerf »

aaron-lebo wrote: post #72
MrBuddyCasino wrote: post #24

Earlier quoted context omitted.

Yes, they're trying very hard to be welcoming. This is markedly different from certain other programming communities and deserving of praise.

I mean, I've dropped in and out of the Ruby, Python, Javascript, Go, Clojure, Elixir etc communities and they all trying to be welcoming. It's kind of a given. It's rare to find the language community that isn't welcoming, and I think you'll find even that the most stubborn (lisp, Haskell) are very happy to have you and very happy to help new users. You probably have an argument that they are doing something differen…

I agree that most programming communities are friendly and open.

I can't help but notice that the same communities that have the reputation for being prickly are the ones that have the largest influx of people who come stomping in to the community, and one way or another try to turn the conversation to why everything the community is doing is wrong and stupid and how everything the community is doing needs to immediately be rewritten in accordance with their unambiguously correct opinions, even though they just joined the multi-year party ten minutes ago.

No, I do not have some particular community in mind that I'm coyly not specifying when I say that; it is a pattern I've observed across quite a few communities.

Re: Why did we choose Rust to develop TiKV?

#110

Post by jerf »

pjmlp wrote: post #49
fsloth wrote: post #37

Earlier quoted context omitted.

"No, reference counting is commonly seen as a specific implementation of garbage collection" Shared pointers provide the reference counting, but reference counting alone hardly constitutes a garbage collector because it doesn't collect all of the garbage. For example, shared_ptr:s alone do not automatically detect and collect cycles.

Chapter 5 of The Garbage Collection Handbook. http://gchandbook.org/

The dirty secret of the "garbage collection vs. manual memory management" war is that there isn't actually a bright shining line to be drawn anywhere; it's actually a relatively smooth continuum ranging on the one end from statically allocating all values up front (in the style of embedded system) to the dynamic languages on the other end, with dozens of stops in between.
Post reply on HN