Live data from Hacker News

Why did we choose Rust to develop TiKV?

pingcap.github.io

81–90 of 206 posts

Re: Why did we choose Rust to develop TiKV?

#82
post #78
post #70

Earlier quoted context omitted.

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?

Looking into the past can have some predictive value, but looking that far back and at a different company is of very limited value. If one evaluates C# they should obviously look at what MS are doing. Same thing for Swift and Apple.

If Google, Apple or Microsoft take their employees out of ANSI or from GCC/LLVM contributions, I can assure you they won't move much beyond the current state.

Re: Why did we choose Rust to develop TiKV?

#83
post #76

Earlier quoted context omitted.

sorry, could you explain a bit more ? does '... are you guys sure of your "experienced C++ developers" ?' sound harsh to you ?

You're talking to someone who says they're an experienced painter. They show you some of their work. You reply "are you sure you're an 'experienced painter'?" After answering a question during a job interview, the interviewer says 'are you sure you're a "senior programmer?"'

I don't see a problem with either (and heard far worse in my professional life; the best to date would more or less translate to "what are you ? a bunch of fucking monkeys ?").

Re: Why did we choose Rust to develop TiKV?

#84
post #45
post #40

Earlier quoted context omitted.

On the other hand I can't wait when Swift becomes general, non-Apple language, available on most platforms (including the most popular one) "with batteries" - that will be the end of Go and Rust I think :)

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.

Re: Why did we choose Rust to develop TiKV?

#85

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

I think you are being needlessly inflammatory. The list of 3 items against C++ makes it pretty clear they do have experienced C++ developers.

Re: Why did we choose Rust to develop TiKV?

#86
post #78
post #70

Earlier quoted context omitted.

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?

Looking into the past can have some predictive value, but looking that far back and at a different company is of very limited value. If one evaluates C# they should obviously look at what MS are doing. Same thing for Swift and Apple.

I think what is saying is that (1) these languages are too widely adopted to fail -- somebody is bound to take the ball and continue dribbling it even if the worst happens (company abandons language) and (2) to have a widely adopted language means you have to be a member of a number of committees -- because without standards you wouldn't become a widely adopted language in the first place.

In short, we're quite safe in terms of if C#, Swift and Go will live on. They will.

Re: Why did we choose Rust to develop TiKV?

#87
post #57
post #40

Earlier quoted context omitted.

On the other hand I can't wait when Swift becomes general, non-Apple language, available on most platforms (including the most popular one) "with batteries" - that will be the end of Go and Rust I think :)

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)

Very true.

In the same lane of thought, I am in love with Go when it comes to microservices, network libraries/bridges and CLI tools but it's very ill-suited for web development. So I shrugged it off and only do web dev with Elixir.

Conversely, Elixir is awesome for a multitude of things but it absolutely can't compete with Go in its strong areas.

Language wars are pointless.

Re: Why did we choose Rust to develop TiKV?

#88
post #61

Earlier quoted context omitted.

> And do all the C++ libraries take only smart pointers as arguments and return only smart pointers as return values? C++ libraries that would be as recent as Rust libraries would certainly take things by value or reference so there would be no problems. I honestly don't know libraries with raw pointers in their APIs that aren't from the 90's or before; and I don't think you want to use those in a current product any…

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

Re: Why did we choose Rust to develop TiKV?

#90
post #70
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?

You know... there's a difference between "(...) with people on ARM, Google, Apple, Blommberg, Sony, IBM, Microsoft's payroll?" and "people on Google payroll". In one case you have many companies cooperating, in the other - just one company.
Post reply on HN