27 ms·

Why did we choose Rust to develop TiKV?

159 points by cyber1 9y ago

jcelerier 9y ago
> 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 this point you'll have problems whatever you do).
- jhasse 9y ago
  You'll have to manually break cycles using weak_ptr though.
  - tentaTherapist 9y ago
    But you'd have to do that in Rust too, or at least use a library like petgraph, because Rust hates cycles even more than C++.
    - jhasse 9y ago
      True. But you wouldn't have to do that in most GC languages.
- blub 9y ago
  Yeah, that read like some Java advertising from the 90s. I wish more of these posts were honest and said "we picked X cause we think it's cool and we're gonna get paid to learn it". But they have to make up some convoluted explanation that sounds rational and acceptable instead.
  - c4pt0r 9y ago
    Hahahah, you're right. We picked Rust cuz our CEO and I think it's cool... XD
  - deadjoe 9y ago
    from the post , looks like they really do think picking rust is dope and already built a cool db system upon it. Maybe they already got bunch of bucks in the pocket. Huhhh..
- latch 9y ago
  First sentence is why I dread reading comment. Why you gotta be like that?
  - jcelerier 9y ago
    sorry, could you explain a bit more ? does '... are you guys sure of your "experienced C++ developers" ?' sound harsh to you ?
    - noselasd 9y ago
      It's just a very loaded opinion, while you pretend it's a universal fact. I have never heard, nor experienced, any seasoned C++ developer claiming that smart pointers is a substitute for garbage collection. Yes, smart pointers are nice, they alleviate you from a whole lot of manual memory management - but the programming model is still vastly different from what you would do in a traditional GC'ed language(such as Java or C#)
      - blub 9y ago
        A lot of C++ big names have said that smart pointers are better than garbage collection for handling resources. And they are, because GC only handles memory. Having memory leaks in modern C++ is a sign of not keeping up with the established idioms. Saying that experienced C++ programmers are worried about memory leaks is bizarre.
    - latch 9y ago
      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?"'
      - jcelerier 9y ago
        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 ?").
- fsloth 9y ago
  "...make_shared" Sorry, I'm going to be a bit harsh now. There is a host of distinctive differences between garbage collection and reference counting. Yes, both are memory handling strategies. That's where the similarities end. "Just slap it in a shared pointer" is never a good advice without knowledge what 'it' is or in what kind of system it exists in.
  - jcelerier 9y ago
    > There is a host of distinctive differences between garbage collection and reference counting. No, reference counting is commonly seen as a specific implementation of garbage collection. https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Reference_counting https://en.wikipedia.org/wiki/Garbage_collection_(computer_s... > "Just slap it in a shared pointer" is never a good advice without knowledge what 'it' is or in what kind of system it exists in. I agree, but it seems from their blogpost that they are not sure that their developers are able to handle the "mental overhead" of managing ownership, hence the simple solution of going for shared ownership everytime. (btw, I re-read your post three times and could not find any hint of harshness !)
    - fsloth 9y ago
      "No, reference counting is commonly seen as a specific implementation of garbage collection" Shared pointers provide the reference counting, but reference counting alone hardly constitutes a garbage collector because it doesn't collect all of the garbage. For example, shared_ptr:s alone do not automatically detect and collect cycles.
      - pjmlp 9y ago
        Chapter 5 of The Garbage Collection Handbook. http://gchandbook.org/ http://gchandbook.org/
        jerf 9y ago
        The dirty secret of the "garbage collection vs. manual memory management" war is that there isn't actually a bright shining line to be drawn anywhere; it's actually a relatively smooth continuum ranging on the one end from statically allocating all values up front (in the style of embedded system) to the dynamic languages on the other end, with dozens of stops in between.
- deleted 9y ago
  [deleted]
- pjc50 9y ago
  And do all the C++ libraries take only smart pointers as arguments and return only smart pointers as return values?
  - jcelerier 9y ago
    > 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 anyways.
    - pjc50 9y ago
      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.
      - pjmlp 9y ago
        Which is what keeps companies like LDRA in business. http://ldra.com/ http://ldra.com/
      - jcelerier 9y ago
        > 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
        pjc50 9y ago
        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!)
- tentaTherapist 9y ago
  But then your program uses slow, cache-unfriendly and much-reviled reference counting. I'd even prefer Ocaml and its fully-featured GC if C++ is only fast in artificial benchmarks and not in idiomatic code, which apparently must use RC. Note: I haven't used C++ at all on any project larger than a single file.
- stepik777 9y ago
  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?
  - duneroadrunner 9y ago
    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 https://github.com/duneroadrunner/SaferCPlusPlus
- p0nce 9y ago
  I think you are being needlessly inflammatory. The list of 3 items against C++ makes it pretty clear they do have experienced C++ developers.
eikenberry 9y ago
TLDR; the author likes rust and wanted to use it. The article reads like some dev's rationalizing what they want to do to the management. These types of things are fine, but as a dev to a dev it is obvious that they just want to use this cool tech. Good for them.
- throwaway884 9y ago
  Fits in pretty well with the ongoing Rust agenda here in HN
  - Tade0 9y ago
    To be fair the language is very pleasant to work with if you're a beginner, because the compiler seems to have been built around the concept of giving the most helpful (and polite!) messages possible. Never have I ever had a compiler tell me to "consider" changing some type declaration, because maybe, just maybe I was probably intending to do what it suggests all along. Also generally things you didn't write still compile and run. This is not a given in e.g. C/C++.
    - jhasse 9y ago
      > the compiler seems to have been built around the concept of giving the most helpful (and polite!) messages possible. I can't confirm that. I have already ran into compiler bugs and very very unhelpful error messages and I haven't really done that much in the language.
      - Tade0 9y ago
        Any specific messages you found to be unhelpful?
        jhasse 9y ago
        This one for example: https://github.com/rust-lang/rust/issues/17164 https://github.com/rust-lang/rust/issues/17164 There was another one, but I can't find the issue for it. I asked in IRC about it and it was fixed by adding &* before an expression. I didn't understand why ...
baq 9y ago
it'd be enough for me to say 'rust is kinda like c++ in terms of performance and complexity but without the 0 pointer'
- jhasse 9y ago
  Rust also has a "0 pointer": https://doc.rust-lang.org/std/option/ https://doc.rust-lang.org/std/option/ The equivalent of a null pointer exception in Rust is an unwrap panic. (IIRC if you use Option<Box<...>> None will even be represented by a null pointer internally)
  - Ygg2 9y ago
    Umm unwrap panic is definitely not the same. For one it's heavily discouraged. Any example using it is not best practice.
    - jhasse 9y ago
      I still got a few unwrap panics in libraries I've used (not in example code). Also: Using a null pointer in C++ is also heavily discouraged ;)
      - int_19h 9y ago
        Only if you are talking about raw pointers. Using unique_ptr or shared_ptr to hold nullptr is still pretty common in C++.
      - Ygg2 9y ago
        Yeah, but using Option is encouraged, while using Option.unwrap as error handling is discouraged. Ok, to be more precise, Option in Rust, isn't a null pointer. It's a nullable pointer. Practically speaking only Option::None is the null pointer. You can either deal with it (using if-let or match) or you can `unwrap` and assume it's never null. If you make that assumption and if and only if it was actually Option::None, will it throw null pointer exception. In contrast something like C/Java will allow you to use your nullable pointer (because all pointers/references are nullable by default) without any check and it's relatively easy to skip this step. In Rust, it's relatively hard to skip this step. EDIT: Changed per burntsushi post.
Shorel 9y ago
And lack of experience with D. Just kidding, great job!
pornel 9y ago
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?
- mac01021 9y ago
  “new and weird" is always relative to the industry/domain on application. In each domain , whether it be avionics or web development, managers are not going to want to use it until it has a proven record of success in that domain.
- zerr 9y ago
  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 :)
  - rf15 9y ago
    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)
    - blub 9y ago
      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.
      - pjmlp 9y ago
        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?
klakier 9y ago
When I see posts like "Why did we choose something over something other", I'm like "Nobody cares"
- sgift 9y ago
  And with that attitude we get the same problems over and over again.
- meche123 9y ago
  +1 This post is just an advertise for their product.
- oelmekki 9y ago
  Looks like you care enough for opening the comment page and dropping yours :)
amelius 9y ago
If you had lots of circularly referencing data structures, would it make more sense to choose a garbage-collected language like Go?
- int_19h 9y ago
  Most circular data structures still have some node that is semantically the owner of the whole thing. Having true circular ownership is much rarer.
  - amelius 9y ago
    Closures naturally generate cycles in the data dependency graph. A way out would be to copy the environment of a closure, but that would mean a performance penalty.
    - evincarofautumn 9y ago
      Whether and how closures generate cycles, and consequently the best implementation strategy, depends heavily on the language, though. You might have a strictly nested call stack or thunks and continuations; shared mutable environments or immutable copies and moves; copyable environments or linear/affine closure types; boxed closures that can be stored in data structures or unboxed closures that can’t always; first-class or second-class closures; a GC to rely on or none; &c.
cyber1 9y ago
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/CppCoreGuidelines http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines, "C++ programming language" book, also here https://herbsutter.com/gotw/ https://herbsutter.com/gotw/, etc and I can focus on algorithms and implementation. C++ combines a lot of different paradigms m.b. more correct I would like to say "C++ paradigms hell"! Which of C++ subsets is the right way, no one understands. Even Bjarne Stroustrup said, "Within C++, there is a much smaller and cleaner language struggling to get out." - and where is this "smaller and cleaner language"?. What is the idiomatic style in C++? Is it Google guidelines, CoreCpp guidelines or other enormous guides? I look inside a lot of C++ projects and each of them has different styles, use different paradigms, sometimes look like different languages! Rust, Go, C, Java code bases look the same, they have their own idiomatic style, their own way. I think Rust is the next step in the evolution of system programming language.
- blub 9y ago
  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 Rust, and a top reply said that they never encountered such issues because they program in a functional way. Go is an exception here, but as soon as they extend the language in a significant way (e.g. templates) differences will start to appear. C++ doesn't have an idiomatic style because it's used in very different ways by different people. It's impossible to have a fixed style and address the mass market.
  - usrusr 9y ago
    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.
noncoml 9y ago
The one reason I would give is Algebraic Data Types.
sriram_malhar 9y ago
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.
- sanxiyn 9y ago
  Rust would use less memory than Go. (Dropbox also likes Go and used Rust over Go for the storage layer, and when asked, memory usage was their primary reason.)
- jerf 9y ago
  "A storage layer should be IO-bound, and should hardly trouble the CPU; the choice of language really should not be a determining factor." This used to be true, but it's out-of-date now. You can now get a network pipe in to a system that a rather beefy multi-core CPU using a user-space TCP stack can barely keep up with, let alone do any real work, and if you can scrape up the PCI express lanes, putting a few of the latest SSDs into a system can start getting you theoretical maximum bandwidth numbers that just a few years ago looked more like what you'd expect for a RAM bandwidth number. I'm of the opinion that it was already not as true as commonly supposed 5 years ago (in my experience using slow languages on putatively IO-bound tasks was still noticeably slower than using fast languages), but the latest in network pipes and SSDs have really ended it. It's true that on most desktop systems you've still got more CPU than you know what to do with, but as you step into the serious database space that's not true anymore. For a serious database I wouldn't be perturbed if someone looked at Go's performance and just plain discarded it on the spot, even before considering GC issues. It's very fast for a scripting language; it's fairly slow for a compiled language. "The compiler spends hardly any time on optimization" is not what you want to read about your database implementation language. (I've got one of the nvme SSDs in my laptop, and it is interesting to see just how many CPU bottlenecks there still are in systems nowadays. In some sense, I really shouldn't ever see a "loading" screen because you "ought" to be able to read things off of my SSD fast enough to completely fill my RAM in 5-10 seconds; "merely" loading Firefox ought to be somewhere in the 50ms range. In practice I still see loading screens and load waits, because the CPUs are still doing things. Lots of things that used to be dominated by and hidden in the load time, but aren't anymore.)
baldfat 9y ago
> its innovation in the type system and syntax gives it a unique edge in developing Domain-Specific Libraries (DSL). I think Racket still has the edge for producing DSL?
pmarreck 9y ago
Because http://www.golang.sucks/ http://www.golang.sucks/? /opinion
StreamBright 9y ago
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.
- arjie 9y ago
  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.
  - new299 9y ago
    > 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. It's a real shame. I love reading about other disciplines and knowing about the practical trade offs.
- mrkgnao 9y ago
  Is this a hammer question, or one of e.g., concrete vs. wood?
- steveklabnik 9y ago
  > Imagine the same for architects Do you know the history of the term "design pattern" in software? It comes from this book: https://en.wikipedia.org/wiki/A_Pattern_Language https://en.wikipedia.org/wiki/A_Pattern_Language
- AYBABTME 9y ago
  I think "hammer" is pretty diminutive as a parallel for a choice of language. I feel a better parallel would be "architects talking about steel alloys versus composite materials" which is not crazy.
bpicolo 9y ago
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.
- sanxiyn 9y ago
  http://weekly.pingcap.com/2016/10/17/how-we-build-tidb/#atomic-clocks--gps-clocks-vs-timestamp-allocator http://weekly.pingcap.com/2016/10/17/how-we-build-tidb/#atom... explains their main difference from CockroachDB.
  - bpicolo 9y ago
    Mostly curious how it works out in practice. Performance, etc.
- lobster_johnson 9y ago
  A big difference is that TiDB is not ready for production yet. Having followed to the project for a while, another distinction is that TiDB is operationally more complex. You need to build and deploy TiDB (high-level query engine), TiKV (key/value store) and PD ("placement driver", which coordinates sharding and data migration) separately. TiDB is stateless and can be scaled freely, but TiKV and PD are both stateful and implement their own distributed consensus systems. PD actually embeds Etcd, whereas TiKV has its own Raft implementation in Rust. Compare this to Cockroach, which has a single monolithic daemon that you deploy everywhere, which contains both the distributed query engine, the key/value store, consensus/cluster coordinator, etc. (There may be benefits or drawbacks to the difference in design; I don't know the internals of either project well enough to debate that.) For an internal project I'm working on, running TiKV standalone actually looks very interesting, but it's not very well documented yet.

159 points by cyber1 9y ago

> 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 this point you'll have problems whatever you do).

jhasse 9y ago
You'll have to manually break cycles using weak_ptr though.
- tentaTherapist 9y ago
  But you'd have to do that in Rust too, or at least use a library like petgraph, because Rust hates cycles even more than C++.
  - jhasse 9y ago
    True. But you wouldn't have to do that in most GC languages.
blub 9y ago
Yeah, that read like some Java advertising from the 90s. I wish more of these posts were honest and said "we picked X cause we think it's cool and we're gonna get paid to learn it". But they have to make up some convoluted explanation that sounds rational and acceptable instead.
- c4pt0r 9y ago
  Hahahah, you're right. We picked Rust cuz our CEO and I think it's cool... XD
- deadjoe 9y ago
  from the post , looks like they really do think picking rust is dope and already built a cool db system upon it. Maybe they already got bunch of bucks in the pocket. Huhhh..
latch 9y ago
First sentence is why I dread reading comment. Why you gotta be like that?
- jcelerier 9y ago
  sorry, could you explain a bit more ? does '... are you guys sure of your "experienced C++ developers" ?' sound harsh to you ?
  - noselasd 9y ago
    It's just a very loaded opinion, while you pretend it's a universal fact. I have never heard, nor experienced, any seasoned C++ developer claiming that smart pointers is a substitute for garbage collection. Yes, smart pointers are nice, they alleviate you from a whole lot of manual memory management - but the programming model is still vastly different from what you would do in a traditional GC'ed language(such as Java or C#)
    - blub 9y ago
      A lot of C++ big names have said that smart pointers are better than garbage collection for handling resources. And they are, because GC only handles memory. Having memory leaks in modern C++ is a sign of not keeping up with the established idioms. Saying that experienced C++ programmers are worried about memory leaks is bizarre.
  - latch 9y ago
    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?"'
    - jcelerier 9y ago
      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 ?").
fsloth 9y ago
"...make_shared" Sorry, I'm going to be a bit harsh now. There is a host of distinctive differences between garbage collection and reference counting. Yes, both are memory handling strategies. That's where the similarities end. "Just slap it in a shared pointer" is never a good advice without knowledge what 'it' is or in what kind of system it exists in.
- jcelerier 9y ago
  > There is a host of distinctive differences between garbage collection and reference counting. No, reference counting is commonly seen as a specific implementation of garbage collection. https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Reference_counting https://en.wikipedia.org/wiki/Garbage_collection_(computer_s... > "Just slap it in a shared pointer" is never a good advice without knowledge what 'it' is or in what kind of system it exists in. I agree, but it seems from their blogpost that they are not sure that their developers are able to handle the "mental overhead" of managing ownership, hence the simple solution of going for shared ownership everytime. (btw, I re-read your post three times and could not find any hint of harshness !)
  - fsloth 9y ago
    "No, reference counting is commonly seen as a specific implementation of garbage collection" Shared pointers provide the reference counting, but reference counting alone hardly constitutes a garbage collector because it doesn't collect all of the garbage. For example, shared_ptr:s alone do not automatically detect and collect cycles.
    - pjmlp 9y ago
      Chapter 5 of The Garbage Collection Handbook. http://gchandbook.org/ http://gchandbook.org/
      - jerf 9y ago
        The dirty secret of the "garbage collection vs. manual memory management" war is that there isn't actually a bright shining line to be drawn anywhere; it's actually a relatively smooth continuum ranging on the one end from statically allocating all values up front (in the style of embedded system) to the dynamic languages on the other end, with dozens of stops in between.
deleted 9y ago
[deleted]
pjc50 9y ago
And do all the C++ libraries take only smart pointers as arguments and return only smart pointers as return values?
- jcelerier 9y ago
  > 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 anyways.
  - pjc50 9y ago
    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.
    - pjmlp 9y ago
      Which is what keeps companies like LDRA in business. http://ldra.com/ http://ldra.com/
    - jcelerier 9y ago
      > 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
      - pjc50 9y ago
        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!)
tentaTherapist 9y ago
But then your program uses slow, cache-unfriendly and much-reviled reference counting. I'd even prefer Ocaml and its fully-featured GC if C++ is only fast in artificial benchmarks and not in idiomatic code, which apparently must use RC. Note: I haven't used C++ at all on any project larger than a single file.
stepik777 9y ago
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?
- duneroadrunner 9y ago
  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 https://github.com/duneroadrunner/SaferCPlusPlus
p0nce 9y ago
I think you are being needlessly inflammatory. The list of 3 items against C++ makes it pretty clear they do have experienced C++ developers.

eikenberry 9y ago

TLDR; the author likes rust and wanted to use it. The article reads like some dev's rationalizing what they want to do to the management. These types of things are fine, but as a dev to a dev it is obvious that they just want to use this cool tech. Good for them.

throwaway884 9y ago
Fits in pretty well with the ongoing Rust agenda here in HN
- Tade0 9y ago
  To be fair the language is very pleasant to work with if you're a beginner, because the compiler seems to have been built around the concept of giving the most helpful (and polite!) messages possible. Never have I ever had a compiler tell me to "consider" changing some type declaration, because maybe, just maybe I was probably intending to do what it suggests all along. Also generally things you didn't write still compile and run. This is not a given in e.g. C/C++.
  - jhasse 9y ago
    > the compiler seems to have been built around the concept of giving the most helpful (and polite!) messages possible. I can't confirm that. I have already ran into compiler bugs and very very unhelpful error messages and I haven't really done that much in the language.
    - Tade0 9y ago
      Any specific messages you found to be unhelpful?
      - jhasse 9y ago
        This one for example: https://github.com/rust-lang/rust/issues/17164 https://github.com/rust-lang/rust/issues/17164 There was another one, but I can't find the issue for it. I asked in IRC about it and it was fixed by adding &* before an expression. I didn't understand why ...

baq 9y ago

it'd be enough for me to say 'rust is kinda like c++ in terms of performance and complexity but without the 0 pointer'

jhasse 9y ago
Rust also has a "0 pointer": https://doc.rust-lang.org/std/option/ https://doc.rust-lang.org/std/option/ The equivalent of a null pointer exception in Rust is an unwrap panic. (IIRC if you use Option<Box<...>> None will even be represented by a null pointer internally)
- Ygg2 9y ago
  Umm unwrap panic is definitely not the same. For one it's heavily discouraged. Any example using it is not best practice.
  - jhasse 9y ago
    I still got a few unwrap panics in libraries I've used (not in example code). Also: Using a null pointer in C++ is also heavily discouraged ;)
    - int_19h 9y ago
      Only if you are talking about raw pointers. Using unique_ptr or shared_ptr to hold nullptr is still pretty common in C++.
    - Ygg2 9y ago
      Yeah, but using Option is encouraged, while using Option.unwrap as error handling is discouraged. Ok, to be more precise, Option in Rust, isn't a null pointer. It's a nullable pointer. Practically speaking only Option::None is the null pointer. You can either deal with it (using if-let or match) or you can `unwrap` and assume it's never null. If you make that assumption and if and only if it was actually Option::None, will it throw null pointer exception. In contrast something like C/Java will allow you to use your nullable pointer (because all pointers/references are nullable by default) without any check and it's relatively easy to skip this step. In Rust, it's relatively hard to skip this step. EDIT: Changed per burntsushi post.

Shorel 9y ago

And lack of experience with D. Just kidding, great job!

pornel 9y ago

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?

mac01021 9y ago
“new and weird" is always relative to the industry/domain on application. In each domain , whether it be avionics or web development, managers are not going to want to use it until it has a proven record of success in that domain.
zerr 9y ago
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 :)
- rf15 9y ago
  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)
  - blub 9y ago
    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.
    - pjmlp 9y ago
      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?

klakier 9y ago

When I see posts like "Why did we choose something over something other", I'm like "Nobody cares"

sgift 9y ago
And with that attitude we get the same problems over and over again.
meche123 9y ago
+1 This post is just an advertise for their product.
oelmekki 9y ago
Looks like you care enough for opening the comment page and dropping yours :)

amelius 9y ago

If you had lots of circularly referencing data structures, would it make more sense to choose a garbage-collected language like Go?

int_19h 9y ago
Most circular data structures still have some node that is semantically the owner of the whole thing. Having true circular ownership is much rarer.
- amelius 9y ago
  Closures naturally generate cycles in the data dependency graph. A way out would be to copy the environment of a closure, but that would mean a performance penalty.
  - evincarofautumn 9y ago
    Whether and how closures generate cycles, and consequently the best implementation strategy, depends heavily on the language, though. You might have a strictly nested call stack or thunks and continuations; shared mutable environments or immutable copies and moves; copyable environments or linear/affine closure types; boxed closures that can be stored in data structures or unboxed closures that can’t always; first-class or second-class closures; a GC to rely on or none; &c.

cyber1 9y ago

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/CppCoreGuidelines http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines, "C++ programming language" book, also here https://herbsutter.com/gotw/ https://herbsutter.com/gotw/, etc and I can focus on algorithms and implementation. C++ combines a lot of different paradigms m.b. more correct I would like to say "C++ paradigms hell"! Which of C++ subsets is the right way, no one understands. Even Bjarne Stroustrup said, "Within C++, there is a much smaller and cleaner language struggling to get out." - and where is this "smaller and cleaner language"?. What is the idiomatic style in C++? Is it Google guidelines, CoreCpp guidelines or other enormous guides? I look inside a lot of C++ projects and each of them has different styles, use different paradigms, sometimes look like different languages! Rust, Go, C, Java code bases look the same, they have their own idiomatic style, their own way. I think Rust is the next step in the evolution of system programming language.

blub 9y ago
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 Rust, and a top reply said that they never encountered such issues because they program in a functional way. Go is an exception here, but as soon as they extend the language in a significant way (e.g. templates) differences will start to appear. C++ doesn't have an idiomatic style because it's used in very different ways by different people. It's impossible to have a fixed style and address the mass market.
- usrusr 9y ago
  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.

noncoml 9y ago

The one reason I would give is Algebraic Data Types.

sriram_malhar 9y ago

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.

sanxiyn 9y ago
Rust would use less memory than Go. (Dropbox also likes Go and used Rust over Go for the storage layer, and when asked, memory usage was their primary reason.)
jerf 9y ago
"A storage layer should be IO-bound, and should hardly trouble the CPU; the choice of language really should not be a determining factor." This used to be true, but it's out-of-date now. You can now get a network pipe in to a system that a rather beefy multi-core CPU using a user-space TCP stack can barely keep up with, let alone do any real work, and if you can scrape up the PCI express lanes, putting a few of the latest SSDs into a system can start getting you theoretical maximum bandwidth numbers that just a few years ago looked more like what you'd expect for a RAM bandwidth number. I'm of the opinion that it was already not as true as commonly supposed 5 years ago (in my experience using slow languages on putatively IO-bound tasks was still noticeably slower than using fast languages), but the latest in network pipes and SSDs have really ended it. It's true that on most desktop systems you've still got more CPU than you know what to do with, but as you step into the serious database space that's not true anymore. For a serious database I wouldn't be perturbed if someone looked at Go's performance and just plain discarded it on the spot, even before considering GC issues. It's very fast for a scripting language; it's fairly slow for a compiled language. "The compiler spends hardly any time on optimization" is not what you want to read about your database implementation language. (I've got one of the nvme SSDs in my laptop, and it is interesting to see just how many CPU bottlenecks there still are in systems nowadays. In some sense, I really shouldn't ever see a "loading" screen because you "ought" to be able to read things off of my SSD fast enough to completely fill my RAM in 5-10 seconds; "merely" loading Firefox ought to be somewhere in the 50ms range. In practice I still see loading screens and load waits, because the CPUs are still doing things. Lots of things that used to be dominated by and hidden in the load time, but aren't anymore.)

baldfat 9y ago

> its innovation in the type system and syntax gives it a unique edge in developing Domain-Specific Libraries (DSL). I think Racket still has the edge for producing DSL?

pmarreck 9y ago

Because http://www.golang.sucks/ http://www.golang.sucks/? /opinion

StreamBright 9y ago

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.

arjie 9y ago
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.
- new299 9y ago
  > 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. It's a real shame. I love reading about other disciplines and knowing about the practical trade offs.
mrkgnao 9y ago
Is this a hammer question, or one of e.g., concrete vs. wood?
steveklabnik 9y ago
> Imagine the same for architects Do you know the history of the term "design pattern" in software? It comes from this book: https://en.wikipedia.org/wiki/A_Pattern_Language https://en.wikipedia.org/wiki/A_Pattern_Language
AYBABTME 9y ago
I think "hammer" is pretty diminutive as a parallel for a choice of language. I feel a better parallel would be "architects talking about steel alloys versus composite materials" which is not crazy.

bpicolo 9y ago

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.

sanxiyn 9y ago
http://weekly.pingcap.com/2016/10/17/how-we-build-tidb/#atomic-clocks--gps-clocks-vs-timestamp-allocator http://weekly.pingcap.com/2016/10/17/how-we-build-tidb/#atom... explains their main difference from CockroachDB.
- bpicolo 9y ago
  Mostly curious how it works out in practice. Performance, etc.
lobster_johnson 9y ago
A big difference is that TiDB is not ready for production yet. Having followed to the project for a while, another distinction is that TiDB is operationally more complex. You need to build and deploy TiDB (high-level query engine), TiKV (key/value store) and PD ("placement driver", which coordinates sharding and data migration) separately. TiDB is stateless and can be scaled freely, but TiKV and PD are both stateful and implement their own distributed consensus systems. PD actually embeds Etcd, whereas TiKV has its own Raft implementation in Rust. Compare this to Cockroach, which has a single monolithic daemon that you deploy everywhere, which contains both the distributed query engine, the key/value store, consensus/cluster coordinator, etc. (There may be benefits or drawbacks to the difference in design; I don't know the internals of either project well enough to debate that.) For an internal project I'm working on, running TiKV standalone actually looks very interesting, but it's not very well documented yet.