3 ms·

I see. Having to say .into() makes me feel a little better about it. But it does make it clear there is a runtime performance cost to insisting on a strict owne

by jblow 11y ago

I see. Having to say .into() makes me feel a little better about it. But it does make it clear there is a runtime performance cost to insisting on a strict ownership model.

pcwalton 11y ago
If the API has to hang onto the string, sure. But not all APIs have to do that. The only reason why the Elasticsearch API requires owned strings in this case is that the JSON API does, and this is a trait that many JSON APIs share, regardless of language. (For example, the first Google result for "c json api" pulls up this API [1], which also copies strings.) You could write a JSON API that doesn't insist on a strict ownership model, if you wanted. There is even a type, MaybeOwned [2], in the standard library to support this kind of API. In such a library, the JSON type would have a lifetime parameter, which could be 'static for owned strings, but which could be non-static for JSON types that contain references to strings. [1]: https://jansson.readthedocs.org/en/2.7/apiref.html#string https://jansson.readthedocs.org/en/2.7/apiref.html#string [2]: http://doc.rust-lang.org/0.11.0/collections/str/type.MaybeOwned.html http://doc.rust-lang.org/0.11.0/collections/str/type.MaybeOw...
- dbaupp 11y ago
  Incidentally, MaybeOwned is now written `Cow<str>`. http://doc.rust-lang.org/std/borrow/enum.Cow.html http://doc.rust-lang.org/std/borrow/enum.Cow.html
deleted 11y ago
[deleted]
Rusky 11y ago
The only runtime performance cost here is one you would need regardless for correctness- you only need to copy if you're going to hold onto the data longer than a borrow would allow. In fact, Rust's semantics allows a fewer number of copies than naive use of std::string, since an already-owned value won't be copied, as mentioned above.
steveklabnik 11y ago
I would be really interested in hearing you elaborate on specifics here, possibly even with code. (Also, I can't wait until I can download Jai and give it a go, keep putting out videos.)
- jblow 11y ago
  Well, keeping in mind that I don't know much of the specifics of Rust, and am just making a guess at what it's like to use, this is what I mean: Actually predicting where data is really going to go involves solving the halting problem. So by necessity any static analysis of ownership is going to be conservative, in the sense that it has to err on the side of safety. So there's a process of structuring things so that it's not just the programmer who understands, but the compiler who understands. Structuring the code in alternative ways so that ownership is made clear and/or ambiguous cases are resolved. Sometimes this could be a small amount of work, but sometimes it could be a very large amount of work (analogous to the simpler situation in C++ where you are using const everywhere but need to change something deep down in the call tree and now either everyone has to lose their consts or you have to do unsavory things). At points, it might be possible to structure things so that the compiler would understand them and let you do it, but it would take a large amount of refactoring that one doesn't want to do right now (especially if one has had a few experiences of starting that refactor and having it fail), so instead one might punt and just say "this parameter is owned, problem solved". And that's great, you can stop refactoring, but you just took a performance hit. Now, in some cases it is probably the case that this is in reality an ambiguous and dangerous ownership situation and the language just did you a favor. But there are also going to be cases where it's not a favor, it's just the understanding of ownership being conservative (because it has to be), and therefore diverging from reality. But I want to get work done today so I make the parameter owned, now the compiler is happy, but there is a performance cost there. If I were not so eager on getting work done today, I might be able to avoid this performance hit by wrestling with the factoring. But I might deem the cost of that prohibitive. That's all I mean. But like I said, I have never written a large program in Rust so I am not speaking from experience.
  - jblow 11y ago
Manishearth 11y ago
I don't see what you mean. Borrowed poitners (and
Manishearth 11y ago
I don't see what you mean. Borrowed pointers (and `AsRef`) work fine in Rust. In fact, Rust's borrowing model provides some perf gains easily where it would be hard to do so in C++ (http://manishearth.github.io/blog/2015/05/03/where-rust-really-shines/ http://manishearth.github.io/blog/2015/05/03/where-rust-real...)

by jblow 11y ago

I see. Having to say .into() makes me feel a little better about it. But it does make it clear there is a runtime performance cost to insisting on a strict ownership model.

pcwalton 11y ago

If the API has to hang onto the string, sure. But not all APIs have to do that. The only reason why the Elasticsearch API requires owned strings in this case is that the JSON API does, and this is a trait that many JSON APIs share, regardless of language. (For example, the first Google result for "c json api" pulls up this API [1], which also copies strings.) You could write a JSON API that doesn't insist on a strict ownership model, if you wanted. There is even a type, MaybeOwned [2], in the standard library to support this kind of API. In such a library, the JSON type would have a lifetime parameter, which could be 'static for owned strings, but which could be non-static for JSON types that contain references to strings. [1]: https://jansson.readthedocs.org/en/2.7/apiref.html#string https://jansson.readthedocs.org/en/2.7/apiref.html#string [2]: http://doc.rust-lang.org/0.11.0/collections/str/type.MaybeOwned.html http://doc.rust-lang.org/0.11.0/collections/str/type.MaybeOw...

dbaupp 11y ago
Incidentally, MaybeOwned is now written `Cow<str>`. http://doc.rust-lang.org/std/borrow/enum.Cow.html http://doc.rust-lang.org/std/borrow/enum.Cow.html

deleted 11y ago

[deleted]

Rusky 11y ago

The only runtime performance cost here is one you would need regardless for correctness- you only need to copy if you're going to hold onto the data longer than a borrow would allow. In fact, Rust's semantics allows a fewer number of copies than naive use of std::string, since an already-owned value won't be copied, as mentioned above.

steveklabnik 11y ago

I would be really interested in hearing you elaborate on specifics here, possibly even with code. (Also, I can't wait until I can download Jai and give it a go, keep putting out videos.)

jblow 11y ago
Well, keeping in mind that I don't know much of the specifics of Rust, and am just making a guess at what it's like to use, this is what I mean: Actually predicting where data is really going to go involves solving the halting problem. So by necessity any static analysis of ownership is going to be conservative, in the sense that it has to err on the side of safety. So there's a process of structuring things so that it's not just the programmer who understands, but the compiler who understands. Structuring the code in alternative ways so that ownership is made clear and/or ambiguous cases are resolved. Sometimes this could be a small amount of work, but sometimes it could be a very large amount of work (analogous to the simpler situation in C++ where you are using const everywhere but need to change something deep down in the call tree and now either everyone has to lose their consts or you have to do unsavory things). At points, it might be possible to structure things so that the compiler would understand them and let you do it, but it would take a large amount of refactoring that one doesn't want to do right now (especially if one has had a few experiences of starting that refactor and having it fail), so instead one might punt and just say "this parameter is owned, problem solved". And that's great, you can stop refactoring, but you just took a performance hit. Now, in some cases it is probably the case that this is in reality an ambiguous and dangerous ownership situation and the language just did you a favor. But there are also going to be cases where it's not a favor, it's just the understanding of ownership being conservative (because it has to be), and therefore diverging from reality. But I want to get work done today so I make the parameter owned, now the compiler is happy, but there is a performance cost there. If I were not so eager on getting work done today, I might be able to avoid this performance hit by wrestling with the factoring. But I might deem the cost of that prohibitive. That's all I mean. But like I said, I have never written a large program in Rust so I am not speaking from experience.
- jblow 11y ago

Manishearth 11y ago

I don't see what you mean. Borrowed poitners (and

Manishearth 11y ago

I don't see what you mean. Borrowed pointers (and `AsRef`) work fine in Rust. In fact, Rust's borrowing model provides some perf gains easily where it would be hard to do so in C++ (http://manishearth.github.io/blog/2015/05/03/where-rust-really-shines/ http://manishearth.github.io/blog/2015/05/03/where-rust-real...)