Priorities after 1.0

[mingwandroid]

msvcrt.dll is the only backwards compatible C runtime, and as pointed out on the linked page, Microsoft work to ensure that it remains that way. The others have redistribution limitations that make them incompatible with programs not compiled with MSVC.

The problem here is that by supporting a second crt-incompatible toolchain, you fork the world of Rust libraries into distinct and incompatible sets. This is why Python has a large problem with Fortran on Windows. I would urge the Rust project to think about whether this is worth doing for the “reduce our dependence on mingw-w64” goal and what achieving this goal actually gains you.

[arielb1]

rustc should not depend on a particular C runtime. I think libstd can be ported to the Win32 API.

[aepsil0n]

I didn’t follow what you mean by “value types” and I don’t see what is impossible without CTFE. I also don’t understand the part about the compiler executing effectual code - i don’t see how that’s interesting from the perspective of the end user.

I was talking about something like RFC #884 and in particular more advanced developments there upon, like allowing a type to be parametrized over a value of a more general type (i.e. bound by some trait). In any case, the compiler would have to be able to evaluate certain expressions at compile-time for successful type checking.

[viperscape]

I think the HKT in Rust would really shine when building libraries and collection types, which is where it is probably a benefit.

[nwin]

I very much agree with the prioritization, it sounds very exiting.

Beside that I hope that famous #6393 gets a high priority. I am convinced it will have a big influence on the user experience and am afraid than many people will get the wrong impression that Rust is “too complicated”.

Beside that it is sometimes very annoying to work around this limitation. It can require extensive rewrites of code which make the code much harder to comprehend. More importantly something it is impossible to work around it without having to change the API. API changes just to work around limitation in the borrow checker are not a good thing and I’m getting a little stomachache from having to use transmute or raw pointers just to temporarily mediate the problem.

[mingwandroid]

To use the Win32 API you must link to a particular C runtime.

[diwic]

I was wondering if the Rc<Trait> stuff (i e, for Rc to directly hold a trait instead of requiring an extra Rc<Box<Trait>>) is still on the roadmap? The topic “smart pointer enhancements” seems to be something else.

[glaebhoerl]

@diwic I believe that’s “DST coercions” or “unsize coercions” or something similarly named, with a PR by @nrc slated to be merged in not long after 1.0 (IIRC).

[P1start]

@glaebhoerl @diwic To be more precise, the exact PR is #24619, which enables Rc<Trait>, but will not get into 1.0 (so we’ll have to wait for 1.1). However, it will of course be available on the nightly channel as soon as it gets merged (which hopefully will be soon).

[diwic]

Oh nice! Looks like this could go in soon even if it’s not listed by Niko above.

[loes]

As a mobile application developer, the idea of using Rust to speed up slow Java code or share code between Android and iOS looks really interesting to me. Native code is important here because even with the new ART runtime, arithmetic code sometimes runs up to 5-10 times slower in Java than in native. In a mobile environment, this can also mean more battery usage or a poor user experience if too much CPU time is being used.

Rust has a lot of advantages that could make it an ideal language for dropping down into native code. Unfortunately, the current level of support appears to consider these platforms as second-class citizens.

What would make Rust useful from my viewpoint:

1. Compilers available to target all of the same targets possible with the NDK for Android, including armeabi, armeabi-v7a, and so on.
2. Clear documentation and instructions on how to integrate this into an existing NDK or XCode build.
3. Solid FFI support. As an example, currently, Rust has task unwinding but it doesn’t look like there’s any way to catch this unwinding at the FFI boundary without the overhead of creating a new task. This seems pretty dangerous and unreliable to me.

With Android and iOS as first-class targets, I would feel much more comfortable about choosing Rust over C or C++ for native components, whether used for performance reasons or for code reuse between platforms.

[arielb1]

Rust is not going to have any way to catch unwinding.

[oli-obk]

Solid FFI support. As an example, currently, Rust has task unwinding but it doesn’t look like there’s any way to catch this unwinding at the FFI boundary without the overhead of creating a new task. This seems pretty dangerous and unreliable to me.

You should write your code in a way that it doesn’t panic but uses Result and Option everywhere. Then you do not need to worry about unwinding, as it won’t happen except when running out of memory.

[pepp]

Rust is not going to have any way to catch unwinding.

AFAIK it is possible to catch unwinding in unsafe code which you need for FFI anyway. http://doc.rust-lang.org/std/thread/fn.catch_panic.html

You should write your code in a way that it doesn’t panic

Once you use any third-party library you cannot be sure that it wont panic unless it is promised by the author. I would be interested in statistics how many libraries are guaranteed not to panic.

[loes]

What about the standard library or 3rd-party crates? It sounds unrealistic to audit all possible places where a panic can be thrown. It would be better to have a facility to catch these at the FFI boundary, which would be required to avoid undefined behavior in any case.

[loes]

Ah, this looks interesting! This would help to solve one part of the FFI puzzle.

[arielb1]

Rust libraries should not panic except on a bug (what would be an assertion failure or segfault on C/C++).

[arielb1]

We already turn panics into aborts on FFI boundaries.

[quantheory]

As someone who probably wants to write pretty different code from the average Rust user (mostly expensive multiphysics code, i.e. complicated parallel floating-point number crunching), I have somewhat of a different priorities:

1. Pretty much any features that would be useful for abstracting over “array-like” (contiguous and piecewise contiguous) containers while still retaining information “under the surface” that the compiler can use to do optimization. E.g. generic integer parameters, HKTs. Allocation on the stack is important.

2. SIMD improvements. So stabilizing the SIMD library itself, but also features like the ability to specify a minimum alignment on a type. (Frankly, I’m kind of amazed that no one has mentioned alignment in this thread so far, since it also relates to interoperability issues like C/C++ integration.)

3. Specialization!

4. Distributed-memory parallelism. In particular interaction with GPUs and other accelerators (not my specialty, and probably mostly something for external libraries to figure out, but I’d like any obstacles to be removed for people who do want to work on this).

So to the extent that I work on the compiler and language, these are what I’m going to be interested in working on independent of the broader community or core team pushes. I’m not necessarily going to push the core team to prioritize these things, but I would like to see the development process be relatively accommodating to efforts that are focused on a different set of priorities, as long as those aren’t in conflict with the needs of the wider community. I’m hoping that the subteam governance changes would help somewhat with that, especially by scaling the decision-making process out so that the core team doesn’t become a bottleneck for RFCs.

[gnzlbg]

Distributed-memory parallelism. In particular interaction with GPUs and other accelerators (not my specialty, and probably mostly something for external libraries to figure out, but I’d like any obstacles to be removed for people who do want to work on this).

I’ve cited one obstacle before, it has to do with generating wrappers to C libraries.

The MPI standard defines some constants, these are C macros in MPI libraries, but in each library they have potentially completely different values (and types).

It would be helpful if the C Preprocessor could be run via rustc to substitute these values automatically on FFI.

Of course one can have a script that does this before calling rust C, but that complicates the way you can use crates io to include such wrappers in your project, since it is not enough to get the rust code and compile it, but you have to preprocess the code in an intermediate step before using it, and maybe do so multiple times if you change the underlying MPI implementation in a cluster via a module system.