Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A deep dive into Rust and C memory interoperability

notashes.me

Post reply on HN
Print view View original

81–84 of 84 posts

Re: A deep dive into Rust and C memory interoperability

#81

Post by cozzyd »

School-Cotton wrote: post #76
cozzyd wrote: post #69

Earlier quoted context omitted.

Imagine you had a bunch of rust binaries on your system instead of one. And you're running on a 2 GB emmc.

Okay, that's a niche scenario. I agree Rust during the statically linked jemalloc era might not be ideal in that scenario. But just because you can concoct some possible scenario in which it's not the best language to use doesn't mean you should write it off completely.

I would think Embedded Linux would be one of the most desired use cases for rust (certainly it's a place where higher level languages are often not an option due to resource usage).

Re: A deep dive into Rust and C memory interoperability

#83

Post by estebank »

cozzyd wrote: post #81
School-Cotton wrote: post #76

Earlier quoted context omitted.

Okay, that's a niche scenario. I agree Rust during the statically linked jemalloc era might not be ideal in that scenario. But just because you can concoct some possible scenario in which it's not the best language to use doesn't mean you should write it off completely.

I would think Embedded Linux would be one of the most desired use cases for rust (certainly it's a place where higher level languages are often not an option due to resource usage).

It's a matter of what use cases are catered to by default, and what use cases are possible. For example, having debug symbols on by default makes it easier to start using the language and debug your applications, at the cost of more disk space and having to configure your project if your needs are different. I think the discussion would have more merit if the defaults weren't configurable. But of course, the choice of defaults is one that will be contentious no matter what. It should still be done following the Hippocratic Oath of "first, do no harm". And some of us need to accept that our usecases are more niche than others, including mine.

Re: A deep dive into Rust and C memory interoperability

#84

Post by Arnavion »

RGBCube wrote: post #80
Arnavion wrote: post #71

Earlier quoted context omitted.

First of all, `dyn Vec` is impossible. Vec is a concrete type, not a trait. I assume you meant `Vec `. Second, no a `&mut Vec ` is not convertible to `&mut Vec `. This kind of unsized coercion cannot work because it'll require a whole different Vec to be constructed, one which has an `allocator: dyn Allocator` field (which is unsized, and thus makes the Vec unsized) instead of an `allocator: A` field. The unsized coe…

Sorry, I meant `&Vec `. And no, it is possible. Here is an example that does it with BufReader, which has T: ?Sized and uses it as a field: https://play.rust-lang.org/?version=stable&mode=debug&editio... Though it comes with a caveat that you can't take self by value, which is perfectly fine for this use case & is what a normal allocator-aware language does anyway.

I stand corrected. I didn't know rustc supported such a coercion automatically. Now I see it is documented in CoerceUnsized + Unsize.

That said, other than the problem of this being a breaking API change for Read::read_to_end, another problem is that Vec's layout is { RawVec, len } and the allocator is inside RawVec, so the allocator is not the last field of Vec, which is required for structs to contain unsized fields. It would require reordering Vec's fields to { len, RawVec } which may not be something libstd wants to do (since it'll make data ptr access have an offset from Vec ptr), or to inline RawVec into Vec as { ptr, cap, len, allocator }.

Post reply on HN