Live data from Hacker News

Why did we choose Rust to develop TiKV?

pingcap.github.io

121–130 of 206 posts

Re: Why did we choose Rust to develop TiKV?

#121
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?

Here at HN Rust seems to come up frequently and it's indeed why I decided to take a look.

For my many colleagues who do not read HN, Rust is something that they might have heard of but haven't given any real attention to. For that matter, most haven't looked at golang either and they probably couldn't tell you what the difference between the two are.

IMO it will take a while before it grabs the attention of the mainstream software community.

Re: Why did we choose Rust to develop TiKV?

#122
post #116

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.

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?

Personally, if every language was just a C variant I'd be happier. It would feel like "OK, I've got the basics down, let's go explore this dialect that added garbage collection and strings as real types" rather than "I want strings as real types, darn it, I need to go learn this Tcl language". That might be an extreme way to make my point, but I think it's clear, right?

Re: Why did we choose Rust to develop TiKV?

#123

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…

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.

Re: Why did we choose Rust to develop TiKV?

#124
post #46
post #32

I think TiKV is a good example where team chose Rust over Modern C++. Rust gives the same performance and is close to metal like C when it is necessary. All possible memory management mistakes it catches at compile time if it's not "unsafe" and this is a really great! With Rust I can hack without fear! I shouldn't remember tons of C++ rules which are described in http://isocpp.github.io/CppCoreGuidelines/CppCoreGuide…

C and Java code bases certainly don't look the same. In fact, claiming that about C is simply insulting to the intellect of anyone reading your overenthusiastic message. I also sincerely doubt that Rust code bases will look the same in ten years. It supports functional and OO paradigms and it's attracting very different classes of programmers. Recently someone wrote a post about difficulties with some OO concepts in…

I think you misread a terribly misreadable statement: what he meant wans't that C and Java look the same, he meant that any two C codebases will share a lot of similarity, any two Java codebases will share a lot of similarity and so on. C++ on the other hand can be anything from "C with objects" to deep template metaprogramming to "has there even been a C++ before 2011?" styles, which are as dissimilar from each other as you can get without crossing language borders.

Re: Why did we choose Rust to develop TiKV?

#125
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?

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…

When I look at Rust it seems to me to be very much C-inspired syntax. The code-blocks-return-a-value style makes it much easier to understand some conditional paths.

"Why would Rust change the syntax to say the same stuff?" Well, Rust is able to meet all of C's requirements while addressing one of C's big old warts: lexical analysis of C code is Very Hard. (e.g. if this particular build added "-DFOO" or "-Ibar/" to the command line then maybe there's a syntactical error or not).

This means that writing robust tools to analyze or modify C code is Very Hard. I don't know if this was an inspiration for Rust's syntax but regardless I'm thankful that they didn't try to reuse C syntax.

Most other successors to C (save perhaps C++) have taken on features that make them unable to write code that we have been able to write in C (bootloaders, OS kernels, interrupt routines, device drivers, etc). Teams had a really legitimate and mostly sane reason most of the time for saying "we couldn't possibly consider Java/Go/Python/etc because we won't be able to meet our product's latency requirements."

Re: Why did we choose Rust to develop TiKV?

#126
post #116

Earlier quoted context omitted.

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

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…

What about the people that don't like the C style syntax? I think there is room for many different types of syntax. Just stick to the style of languages you like and ignore the ones you don't. Pretty simple.

Re: Why did we choose Rust to develop TiKV?

#127
post #40
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?

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 :)

Yes next version of Swift will be so awesome it will kill all programing languages.

Re: Why did we choose Rust to develop TiKV?

#128
post #117

Earlier quoted context omitted.

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…

The issue with C# and Swift is that the Apple and MS dev communities enjoy having a ready made solution that they can pick up and work with immediately. Official support is very important. C# and to some extent Swift are also two huge platforms, there are very few organisations out there that would be able to steer their development. Finally, they are not standardised in any way. MS tried something with 2.0 and then…

> Finally, they are not standardised in any way. MS tried something with 2.0 and then gave up.

They are standardized, you just need to look at the right place.

https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

https://docs.microsoft.com/en-us/dotnet/visual-basic/referen...

http://fsharp.org/specs/language-spec/

https://swift.org/documentation/

Re: Why did we choose Rust to develop TiKV?

#129
post #118
post #82

Earlier quoted context omitted.

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.

What are the odds that all big players would remove support for something that their platforms are built on? At the same time? C++ is one of the healthiest languages in existance. It hits all the important checkboxes of standardisation, wide industry and platform support and large community.

I imagine you never lived through the days when each C++ compiler had a different understanding what it meant to compile C++ code.

It is just like trying to compile the Linux kernel with clang instead of gcc, with the source code full of gcc extensions.

Re: Why did we choose Rust to develop TiKV?

#130
post #95

Earlier quoted context omitted.

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.

What parts of Go tooling do you miss in Rust?

go fmt
Post reply on HN