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

91–100 of 206 posts

Re: Why did we choose Rust to develop TiKV?

#91

Post by lilbobbytables »

jimsmart wrote: post #80
edem wrote: post #59

Earlier quoted context omitted.

I haven't used Go or Rust but when I compare them I have a gut feeling that I'd be better off with Rust primarily because Go's build tools are not adequate. What do you think about this?

Well, your question is simply too open-ended: nobody can really answer that for you, as you give no indication whatsoever as to your potential use-cases. FWIW: I've been coding in Go for a few years now, for me and (perhaps more importantly) the kind of projects I choose to use it for, the build tools have been more than adequate. As with many things: it ultimately depends on what you're wanting to do, and what your…

What kinds of projects do you use it for?

Re: Why did we choose Rust to develop TiKV?

#92

Post by arjie »

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.

With software the material you construct your creations influences the means. Architects most certainly do argue about whether they should use cross-laminated timber, reinforced concrete, glulam, or steel. They talk about these things and write long pieces on them. The materials influence the design of the building.

They don't talk about it on blogs on the Internet because that's not where the audience is. But they do talk about this.

Re: Why did we choose Rust to develop TiKV?

#93

Post by duneroadrunner »

stepik777 wrote: post #73
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 how would smart pointers help you if you need to return pointer to a member from a function? Does C++ protects you from moved from unique_ptr? Or from iterator invalidation? Or maybe you can safely use non-atomic shared pointer if you don't need to send it across threads?

While "just enforcing `make_shared`" wouldn't solve all the memory safety issues, it actually can be somewhat practical to "just avoid using any (or most) C++ elements that can access invalid (or uninitialized) memory", instead using the safe, compatible substitutes in the SaferCPlusPlus[1] library.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

Re: Why did we choose Rust to develop TiKV?

#95

Post by Thaxll »

edem wrote: post #59
dullgiulio wrote: post #13

Earlier quoted context omitted.

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…

I haven't used Go or Rust but when I compare them I have a gut feeling that I'd be better off with Rust primarily because Go's build tools are not adequate. What do you think about this?

What do you mean by not adequate? Go tooling is way better than Rust. The only thing that Rust does better in that field is package dependency and it's going to change soon for Go.

Re: Why did we choose Rust to develop TiKV?

#96

Post by bryanlarsen »

pjmlp wrote: post #70
blub wrote: post #47

Earlier quoted context omitted.

Yes, there's something not quite right with these company languages. Whoever is smart will take note of what happened to VisualBasic and is happening to Objective-C.

You mean like C and C++ being developed at AT&T, nowadays designed at ANSI, with people on ARM, Google, Apple, Blommberg, Sony, IBM, Microsoft's payroll?

Actually, C was a lot worse. For the first 9 years C was basically whatever AT&T wanted. In 78 K&R published The C Programming Language, creating a specification. In the next decade C was very much tied to Unix and non-Unix usages often had some oddities and interoperability issues. The last 3 decades have been good though.

Re: Why did we choose Rust to develop TiKV?

#97

Post by pjc50 »

jcelerier wrote: post #88
pjc50 wrote: post #61

Earlier quoted context omitted.

This is a little difficult on Windows or POSIX systems. Also, as others have pointed out, you can smart-pointerise everything, but still have problems with common tree and graph structures. Rust is rigorous. C++ isn't; I'm not aware of any mainstream compilers which even have the option to make use of bare pointers or unsafe casting or undefined behaviour into compiler warnings/errors.

> 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 this banner, that's probably older than some of the readers here and certainly predates C99:

    Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
    Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
... but my point is that it's not sensible to say nobody's using the system native APIs in 2017!)

Re: Why did we choose Rust to develop TiKV?

#98

Post by sanxiyn »

pdimitar wrote: post #84
rf15 wrote: post #45

Earlier quoted context omitted.

while I think that that would be a good thing (I like what happened with C#), I see the languages specified and controlled by Microsoft, Google and Apple as second-class languages, since they are often lacking in community input and are usually designed with certain platform-specific goals in mind instead of being cross-platform. (or company-strategic goals when it comes to Google)

Would you please give an example on how are Google's company-strategic goals making Go platform-specific, or hampered in any way? Please note that I am not demeaning your statement. It's a legitimate curiosity on my side.

One example that comes to mind is Go dependency management. For a long time (and still?) Go had no way to do versioned dependency. Obviously this is no problem for Google which reportedly build from HEAD, but this shows Google-bias in Go development.

Re: Why did we choose Rust to develop TiKV?

#99

Post by greydius »

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

Re: Why did we choose Rust to develop TiKV?

#100

Post by sanxiyn »

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