Hacker Newsnew | past | comments | ask | show | jobs | submit | more mark4's commentslogin

Newbie question. Why is this useful? Wouldn't slices be enough to fulfill the use-cases this would see?


Some things want an array of a specific size. If you have a function like https://doc.rust-lang.org/stable/std/primitive.u16.html#meth...

  pub const fn from_be_bytes(bytes: [u8; 2]) -> u16
you can't pass it a slice. This would let you pass a vector to this function.

Now, because this wasn't possible previously, it means many things take a slice, and then check that the length is the length they expect, because that ends up being easier for folks. Stuff like this helps it be able to be done properly.

(This specific function is one example that is done in this style, and it's a pain. I have real world code that looks like

  let foo = u16::from_be_bytes([some_slice[0], some_slice[1]]);
This gets even worse with say, u128::from_be_bytes.)


TryInto is already implemented for slices in 1.47, so `let foo = u16::from_be_bytes(some_slice.try_into().unwrap());` would work before 1.48.

This trait wasn't implemented for vectors though, so you would have to write `let foo = u16::from_be_bytes(some_vec.to_slice().try_into().unwrap());`.

With new release you can drop `to_slice()` part. Nothing earth-shattering, but makes sense.


> TryInto is already implemented for slices in 1.47, so `let foo = u16::from_be_bytes(some_slice.try_into().unwrap());` would work before 1.48.

Rustdocs say it was 1.36 even? https://doc.rust-lang.org/nightly/std/primitive.array.html#i...


Yeah, by "In 1.47" I mean that as of 1.47 it was already implemented, didn't check since which version.


Ah fun! I missed that. Time to clean up some code...


That doesn't work with non-copyable types.


steveklabnik is (of course) correct, but you also have to consider the performance cost of a dynamicaly sized slice versus a statically sized array.

A situation I've encountered several times already is implementing statically sized FIFOs. At the moment in Rust I can't implement a type "FIFO of depth N" where is a generic, static parameter. My only choices are implementing "FIFO of depth n" where n is provided dynamically at runtime (and implemented internally using something like a VecDeque) or a completely fixed depth FIFO type that I need to duplicate for every depth (FIFO32, FIFO16, FIFO10 etc...).

If you require very high performance a dynamically checked FIFO can incur a fairly large overhead when a well optimized static FIFO can implement most operations in a couple of opcodes at most.


You maybe could write something like this:

  pub struct Fifo<T: AsMut<[u8]>> {
and then back it with an array. I learned this trick from whitequark.

(Though maybe if you want something other than a slice of bytes, this gets harder... I've used this trick for ringbuffers/mmio only, personally, so YMMV.)

That being said real const generics will make this way nicer, eventually.



I wasn't aware of this trick, thank you for that. I guess if I have to implement another FIFO before const generics land I'll have an opportunity to try it out...


Yet another front-page article about Rust.


Your answer resonated with me a lot. Can you elaborate on this? What is that structural reason?

> The underlying reason is structural -- neither our funding agency nor our institution is willing to yield on a fundamental sticking point that is causing all of our young researchers to leave.


The National Science Foundation (for good reasons) will not fund more than a month or two of a Principal Investigator's annual salary. They'll fund many other types of position, but not that one.

Our University (for good reasons) is reticent to hire into faculty positions, where the state/university would fund a PI's salary. Furthermore, any research professors must fund themselves through grants.

NSF is the only serious game in town for our grant funding.

Even though we have the country's best infrastructure for these experiments, are leaders in our field, can attract grants, and have done so since 1987, we haven't been institutionally capable of retaining promising early/mid-career researchers since ~1999.

The big losers in this situation are the country's experimental capability and science in general. We easily have at least another decade's advances ahead of us. The issue isn't really one of total amounts of funding, but rather whether we are allowed to invest in retaining skilled and knowledgeable leadership.


What changed in ~1999 in your Dept? I've heard similar stories too many times and I'd be curious what the solution was before.

Also do you have any insight into the NSF's resistance to funding PI's?


1999 was roughly the last time we made a faculty hire into our group.

My understanding is that NSF doesn't want PI salaries to be dependent upon grants -- that way, your job isn't (directly) on the line for a specific line of research. It removes at least a little bit of bias toward proposing research just to stay funded.

Moreover, the policy is an incentive for universities to hire faculty, which is generally good for research/teaching.

The hard thing, from the university's perspective, is that a faculty hire is, assuming tenure, very expensive. There is generally a ~$0.5-1M laboratory-startup package, plus a commitment of a professor's salary until ~2055. For this reason, our Department is generally allotted ~1 faculty hire/year. Only exceptional events, like the appearance of a huge and sustained source of money or winning the Nobel Prize (UW Physics: 1989 and 2016) will permit extra hires in targeted fields.

Furthermore, because faculty hires are so rare and each professor gets a vote, each hire has an impact on internal politics. Our department is comparatively friendly, but faculty-hire slots are the most precious commodity in any department.

All of this is to say that it is difficult to find a path that, in this case, would help to retain knowledge and talent in our group. The meeting of the minds that needs to happen is between national funding policy and the status quo among most universities. It is so far above my pay-grade that I've not yet found a reasonable angle from which to attempt to solve the problem.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: