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

161–170 of 206 posts

Re: Why did we choose Rust to develop TiKV?

#161

Post by Thaxll »

candiodari wrote: post #156
Thaxll wrote: post #154

Earlier quoted context omitted.

The reason is people have no clue about Go most of the time and advocate against it because it's popular. Pretty much like Node ect... I mean look at Erlang derivates / Haskell / Rust, you don't see negativity in related language.

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…

I don't code at work for programming language concept, you see you should use the tools that make sense for the task you're working on. I'm not being paid to have fun on using an academic language that no one use, have bad tooling, not enough libraries to work with. You never wonder why pretty much no one uses Haskell / Erlang if it's that great? Having the best language concepts doesn't mean a thing in the real world. I try those things at home not at work where $$$ is at play.

Re: Why did we choose Rust to develop TiKV?

#162

Post by sriram_malhar »

AYBABTME wrote: post #138
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.

Developing a storage layer as elaborate as RocksDB from scratch is quite an endeavor, and wanting to just use RocksDB instead of making your own is a smart decision. From there, Go is sort of easy to throw out of the picture: using cgo kills performance and safety. I say this as a person who uses Go as my workhorse, have used it for many years and has a favorable opinion of it.

Ah, my mistake. I misunderstood. I thought that they were replacing the C++-based RocksDB storage with one written in Rust. Yes, it makes perfect sense to use something if it is already proven itself.

Re: Why did we choose Rust to develop TiKV?

#163

Post by jaredklewis »

jjuel wrote: post #123
peoplewindow wrote: post #106

Earlier quoted context omitted.

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.

Welcome to HN lol. You’ve got it easy. Try being a front end dev, because as HN will tell you, none of us know anything about computer science, which is why we are wasting our lives making over engineered bloated shit. And we have a obsession with novelty, which is why all our technical decisions are based on what is currently fashionable.

HN is not a very understanding place...

Re: Why did we choose Rust to develop TiKV?

#164

Post by Koshkin »

Tyr42 wrote: post #141
Koshkin wrote: post #105

Earlier quoted context omitted.

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

I disagree? Functions which allocate things returning unique_ptr is much clearer than returning a raw pointer. Clear ownership being passed, as opposed to maybe just having a view into some internal buffer. I mean, if you only view functions as being called for side effects, then yeah maybe. But if you're constructing a data pipeline, unique_ptr in and out makes a lot of sense.

Sure, and that is a special case I was referring to. (Another one would be a class factory method returning a unique pointer to an interface.)

In general, though, passing a unique_ptr around is a bit cumbersome as this requires calling std::move way too often.

Re: Why did we choose Rust to develop TiKV?

#165

Post by model_m_warrior »

jaredklewis wrote: post #163
jjuel wrote: post #123

Earlier quoted context omitted.

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.

Welcome to HN lol. You’ve got it easy. Try being a front end dev, because as HN will tell you, none of us know anything about computer science, which is why we are wasting our lives making over engineered bloated shit. And we have a obsession with novelty, which is why all our technical decisions are based on what is currently fashionable. HN is not a very understanding place...

Indeed, Front enders will never be the geniuses the people writing ad hoc CRUD operation end points are.

Re: Why did we choose Rust to develop TiKV?

#166

Post by jdright »

abiox wrote: post #149
cyber1 wrote: post #51

Earlier quoted context omitted.

Swift can't replace Rust in system programming domain because he uses ARC for memory management but Rust gives you choices.

> system programming worth mentioning that this term has a broader meaning than how some rust evangelists use it.

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.

Re: Why did we choose Rust to develop TiKV?

#167

Post by Vendan »

candiodari wrote: post #156
Thaxll wrote: post #154

Earlier quoted context omitted.

The reason is people have no clue about Go most of the time and advocate against it because it's popular. Pretty much like Node ect... I mean look at Erlang derivates / Haskell / Rust, you don't see negativity in related language.

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 failed" should ever be a logical thing to do.

Re: Why did we choose Rust to develop TiKV?

#168

Post by [deleted] »

pjmlp wrote: post #128
blub wrote: post #117

Earlier quoted context omitted.

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/

[deleted]

Re: Why did we choose Rust to develop TiKV?

#170

Post by PopsiclePete »

candiodari wrote: post #156
Thaxll wrote: post #154

Earlier quoted context omitted.

The reason is people have no clue about Go most of the time and advocate against it because it's popular. Pretty much like Node ect... I mean look at Erlang derivates / Haskell / Rust, you don't see negativity in related language.

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…

I love Go and agree with everything you said.

I was never good at computer science-y "language theory" type stuff. I believe you when you say that Haskell or Forth are better languages - I just can't use them worth a damn.

Go is a practical language for me - it's not beautiful, or elegant, the type system is only 70% there, can be verbose, etc, etc, but it allows me to put my code in production and have a very high level of confidence that I won't get a phone call at 4 am. I don't have that confidence with Ruby, or Python, or Javascript.

I find that Go is very easy to pick up, and hard to really fuck up. Most people at my company can read my code and I can read theirs, which is mind-boggling to me. Go somehow achieved what I thought was impossible - to read and grok quickly other people's code.

Go sees was developed by "engineer" types - not "language nerds". And, yes, it shows.

FWIW, I also love Rust and C, but will choose Go over Rust any day when my productivity and dead-lines are more important than close-to-C performance.

Post reply on HN