That's funny after reading the comments from the 1.0 release on HN last night I have been researching on this too. It really is the main feature users want so we should prioritize it. Personally, I have avoided this as I remember living without specialization (macros) but as Andy noted I think we could do better now.
A separate crate does seem overly disruptive to me also but if we struggle to make progress in the coming weeks maybe it's an option. Paddy Andy Grove <andygrov...@gmail.com> wrote: “Yes, that is my understanding too (specialization being the main blocker). I will start experimenting with removing one of the specializations over the next few days and see what I learn. It would be good if others want to try this too and we can swap notes. On Tue, Jul 28, 2020 at 11:37 AM Chao Sun <sunc...@apache.org> wrote: > Thanks Andy for starting the thread. Agree that supporting stable Rust > should be one of the top priorities. > > Instead of creating a new crate, I'd prefer to make the switch in-place in > the current crate if possible. A major part of the current code base, such > as compute kernels, ipc, etc., is built upon the existing APIs. Making a > new crate probably means a lot of re-implementation on these. Many apps > probably need a stable parquet crate together with arrow too which means > we'll need to do the same for that. > > To my understanding the main blocker is specialization which is used by > both arrow and parquet (packed_simd can be optional?). If this is true > perhaps we should first explore a way to remove this without API change. I > haven't found a way yet but I don't think it is impossible. > > On Tue, Jul 28, 2020 at 9:43 AM Andy Grove <andygrov...@gmail.com> wrote: > > > After seeing more feedback on this topic recently, I've been thinking > about > > this some more and wanted to make a proposal for how we can start to > > address this. > > > > It seems that we do have some code today that we could relatively easily > > support on stable Rust, such as the Buffer struct. What if we were to > > extract those parts out into a crate that can build on stable Rust as a > > starting point? > > > > We could then potentially start designing a new Array API in that crate > > that can work with stable, while also maintaining the nightly-only API in > > the other crate? > > > > I think I probably speak for many of the Rust committers when I say that > I > > understand Rust much better now than I did when initially designing the > > APIs and I think it would be good to take another look at how we might > want > > to implement this. > > > > Thanks, > > > > Andy. > > >”
