Setting our vision for the 2017 cycle

[cuviper]

[Other possibilities, or potential non-goals]
Adding compiler/platform targets

I would love to see firmer support for the existing non-x86 architectures. I feel a bit guilty that I’m only building i686 and x86_64 for Fedora so far, but these are the only Tier 1 targets. Perhaps I should bite the Tier 2 bullet for aarch64 and armv7, but the rest don’t have bootstrap binaries for rustc and cargo, especially ppc64 and ppc64le I’d hope for next.

[mgattozzi]

I can see that. I guess it would just be nice to have it just work depending on the target platform without having to do the extra bit of linking. I.E. if compiling for arduino using no std rustc knows what to do without having to do that extra work. Making it more accessible to people who just want to code on a system without having to figure out how to configure it properly could go a long way towards adoption of Rust in that ecosystem.

[kornel]

In terms of compiler errors, currently linker errors are the weakest. It’s just “we ran this unreadable long command and something didn’t work”.

I know it’s probably hard to fix, and it’s not rustc, but the rest of the toolchain, but still — these errors happen, and it’s often hard to figure out why.

[jethrogb]

In terms of compiler errors, currently linker errors are the weakest. It’s just “we ran this unreadable long command and something didn’t work”.

I know it’s probably hard to fix, and it’s not rustc, but the rest of the toolchain, but still — these errors happen, and it’s often hard to figure out why.

I don’t know if the linker output is unambiguously parseable or if there is some way to output something machine-readable, but it would be very helpful if rustc would tell you which specific crates have unresolved symbols.

[arthurprs]

But that’s implementing a new hasher, not using a different hasher. I can argue that people with enough know-how to implement a hash function themselves are completely capable of implementing rust hasher interface.

[eternaleye]

I don’t know if the linker output is unambiguously parseable

Regrettably, no

[quote=“jethrogb, post:31, topic:3958”]or if there is some way to output something machine-readable, but it would be very helpful if rustc would tell you which specific crates have unresolved symbols. [/quote]

Probably the most promising approach would be using LLD from the LLVM project as a library, but that’s going to be blocked on:

1. LLD maturing significantly
2. LLD growing a C API, rather than just C++
3. Rust bindings for that C API
4. LLD supporting all of Rust’s platforms

[comex]

I brought this up in a different thread, but I think ‘insecure but fast hashing’ is a red herring in most cases. Instead, the default HashMap should use an adaptive scheme that starts with an insecure hash and switches to a secure one if an attack is detected (based on load factor and maximum distance of entries from their ideal location). That should provide the best of both worlds except if code size needs to be minimized, which is not the reason most people seem to want to use insecure hashers.

[comex]

Regrettably, no

Why not?

[anp]

I see many specific, granular issues/complaints/problems here. But I see very few attempts to translate those into high-level goals that could actually be set, planned, and executed over the course of an entire year.

Might it be more productive for this conversation if each specific problem or issue is “translated” into the high-level goal it’s related to?

An attempt to summarize high-level items I see in the thread so far that aren’t in @aturon’s original post:

• Rust needs better answers (either guides, outreach, or new features) for teams & programmers coming from OOP – this seems very related to “Rust should have a lower learning curve” to me, but could be distinct if it covers type system features for inheritance?
• Rust’s ownership system needs to aid in modelling more complex systems (i.e. parent/child communication)
• Rust’s tooling needs to be first-class to aid adoption (beyond IDE support, i.e. rustdoc)
• Rust’s community and processes need better visibility to “casual” participants and newcomers (e.g. RFC visibility and dashboards, also casual is a bad word for this, but I can’t think of a better one here)
• Rust needs a better story for embedded development (re: no_std)
• Rust’s support for compile-time code generation should be improved and stabilized, especially for those uses that are already encouraging many users to stay on nightly (custom_derive in particular)
• Rust needs better testing and doc generation across conditional compilation directives
• Rust needs better publicly available information and guides about improving performance for common programs (i.e. hashing), or it needs to refocus its efforts on providing fast-by-default tools in std and common crates
• Rust needs to define and execute better processes for improving documentation and guides across the ecosystem, but especially for core projects
• Rust needs cleaner integration with the system toolchains it depends on

I have some of my own thoughts, too, so I’ll be back :).

[eternaleye]

Instead, the default HashMap should use an adaptive scheme that starts with an insecure hash and switches to a secure one if an attack is detected (based on load factor and maximum distance of entries from their ideal location).

Hm, maybe something that (during resize) measures both the maximum load encountered while resizing in both the new and old backing vector, and upgrades if it does not decrease sufficiently? That way, you avoid having any added code in the hot paths of insert and lookup.

Regrettably, no

Why not?

Well, for one, “which linker?”

Invoking the linker isn’t especially bad, as there are basically only two options in terms of “how to invoke it” (ld vs. link.exe), and which one to use is clear from the target. However, if you’re going to parse the output, you’re now going to get tripped up by different output from ld.bfd vs. ld.gold vs. different versions of same vs…

[brettcannon]

Rust’s should provide a more seamless FFI story

An essential adoption vector for Rust is to use it for building components in a larger system. For this use-case to really sing, we need a seamless “FFI” experience. The meaning of “FFI” here is potentially quite broad—from making it trivial to bind unsafe C APIs (#include somelib.h for Rust), to C++ integration, to embedding in languages like Ruby, Python or JS, to compiling to wasm. We’ve been making progress on all of these fronts, but to make an even bigger impact, we could consider choosing a small number of such scenarios to really focus on as a community this year.

I can confidently say that if you improved the FFI story so that it was easy to use with Python then you would garner a lot of support and users from the Python community. For the past two years I have constantly heard rumblings from people at PyCon about how they would give Rust a look if they could write Python extensions in it (and I’m guilty of wanting this myself). And if you managed to make it work with something like Cython or CFFI so you could also work with PyPy then Rust would get even more mileage out of its Python story.

[eternaleye]

And if you managed to make it work with something like Cython

Cython example: https://github.com/synapticarbors/rust-cython-test

The header (which the example hand-writes) can be autogenerated using rusty-cheddar

or CFFI

CFFI example: https://gist.github.com/seanjensengrey/f5d73bbdf22cfa1ad463

[comex]

I suspect that in practice there aren’t that many different variants of error message that commonly used versions of commonly used linkers output in common cases, and if the format isn’t recognized you can always fall back on showing the user the original spew. It’s definitely a hacky approach, but that’s different from unworkable

[burntsushi]

Another example: https://github.com/jbaiter/python-rust-fst

(It even has CI setup and everything to build wheels.)

[brettcannon]

Very nice! It would be neat to try and work in struct/enum support somehow so that there was corresponding niceties on the Rust side as well (e.g. exposing the Python code object in such a way that methods that exist in Python are also exposed in Rust).

[nikomatsakis]

This is great. It’d be nice if you linked to the original comments for context too

EDIT: I know, I know, “give 'em an inch, they want a mile”

[Eh2406]

This is a grate https://github.com/dgrunwald/rust-cpython project! But it has no windows support https://github.com/dgrunwald/rust-cpython/issues/10 becust rustc dose not “dllimport on Windows/MSVC”

Rust <–> Python can use some love!

[zepto]

Wondering if a runtime for embedded systems cropped up as a suggestion? Seems to be a great use case for rust given the memory safety, etc. For sure I’d like to sketch for arduino/genuino in rust.

[anp]

No problem. I’ll update it in a few hours and try to keep up with new comments.

[aturon]

If the current order of vision statement implies prioritization

I should’ve been explicit about this. The order does roughly reflect the sense one gets from the survey results, but it’s rough at best. I’m not sure whether a ranking of the final vision statements is a good idea, vs trying to scope them so that it’s feasible to get all of their goals done in a year.