Why did we choose Rust to develop TiKV?
81–90 of 206 posts
Re: Why did we choose Rust to develop TiKV?
#82Earlier 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.
Re: Why did we choose Rust to develop TiKV?
#83Earlier 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?"'
Re: Why did we choose Rust to develop TiKV?
#84Earlier 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)
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…
Re: Why did we choose Rust to develop TiKV?
#86Earlier 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.
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?
#87Earlier 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)
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?
#88Earlier 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.
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?
#89Re: Why did we choose Rust to develop TiKV?
#90Earlier 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?