3 ms·

Did you actually watch the linked presentation? If so, I would be curious in an earnest rebuttal: I very much stand by my conclusions -- and even more so after

Did you actually watch the linked presentation? If so, I would be curious in an earnest rebuttal: I very much stand by my conclusions -- and even more so after having spent the years since on Rust-based systems and C/Rust hybrids. Specifically, I have not seen a BTree implementation in C that I would consider to be composable; can you point me to one?

menaerus 4y ago
I did not watch the presentation, sorry. Depends what the definition of composability you have in mind so if you share what you mean by "composable BTree" implementation, I would be happy to give my opinion. I ask because there's no much I can see about the composability of a b-tree implementation other than supporting multiple types, and this is certainly doable although not as elegant as in C++.
- bcantrill 4y ago
  While I appreciate your candor, you may want to know what argument, exactly, you are putatively refuting? (Specifically: the argument is not about types -- it's about ownership.) If it's not too much to ask, take two minutes to watch the linked clip. As for the composable BTree implementation, I actually am not asking for your opinion -- I'm asking for a link to the implementation itself. The details here matter (and indeed, that's the whole point).
  - menaerus 4y ago
    I watched the video now and it is literally what one of the parent comments paraphrased and what I was responding to. What you said is: > I can write C that frees memory properly...that basically doesn't suffer from memory corruption...I can do that, because I'm controlling heaven and earth in my software. It makes it very hard to compose software. Because even if you and I both know how to write memory safe C, it's very hard for us to have an interface boundary where we can agree about who does what. And I stand by my point. Single-responsibility principle will get you covered, yes, even in C. > I actually am not asking for your opinion -- You could show some respect. > I'm asking for a link to the implementation itself. The details here matter B-tree btw is a silly example which particularly is not among the hard design problems out there and there are dozens of implementations laying around. Obvious examples to look for would be in transactional database systems implemented in C. > (and indeed, that's the whole point). ... and the point not being quite clear, even after politely asking for a clarification, so perhaps next time you don't try to play the authority but try to provide an actual example to support your otherwise questionable claim. I'm sure Rust community will profit from individuals like yourself.
    - deleted 4y ago
      [deleted]

menaerus 4y ago

I did not watch the presentation, sorry. Depends what the definition of composability you have in mind so if you share what you mean by "composable BTree" implementation, I would be happy to give my opinion. I ask because there's no much I can see about the composability of a b-tree implementation other than supporting multiple types, and this is certainly doable although not as elegant as in C++.

bcantrill 4y ago
While I appreciate your candor, you may want to know what argument, exactly, you are putatively refuting? (Specifically: the argument is not about types -- it's about ownership.) If it's not too much to ask, take two minutes to watch the linked clip. As for the composable BTree implementation, I actually am not asking for your opinion -- I'm asking for a link to the implementation itself. The details here matter (and indeed, that's the whole point).
- menaerus 4y ago
  I watched the video now and it is literally what one of the parent comments paraphrased and what I was responding to. What you said is: > I can write C that frees memory properly...that basically doesn't suffer from memory corruption...I can do that, because I'm controlling heaven and earth in my software. It makes it very hard to compose software. Because even if you and I both know how to write memory safe C, it's very hard for us to have an interface boundary where we can agree about who does what. And I stand by my point. Single-responsibility principle will get you covered, yes, even in C. > I actually am not asking for your opinion -- You could show some respect. > I'm asking for a link to the implementation itself. The details here matter B-tree btw is a silly example which particularly is not among the hard design problems out there and there are dozens of implementations laying around. Obvious examples to look for would be in transactional database systems implemented in C. > (and indeed, that's the whole point). ... and the point not being quite clear, even after politely asking for a clarification, so perhaps next time you don't try to play the authority but try to provide an actual example to support your otherwise questionable claim. I'm sure Rust community will profit from individuals like yourself.
  - deleted 4y ago
    [deleted]