Probably the most significant addition in this release is the cargo check subcommand, which does all the type/safety checking part of rustc, but skips the LLVM part of generating the actual binary.
If you just want to make sure you code compiles, this is the command for you.
I might be a minority here, but can someone please update me on there state of Rust on iOS? I develop C++ cross platform iOS/Android apps and would love to use Rust if possible.
The last time I checked Rust didn't support .frameworks creation, didn't support Bitcode and calling the main thread from Rust wasn't easy.
I would love to hear if these issues have been resolved.
> The last time I checked Rust didn't support .frameworks creation
From a purely "how do I get something I can link to" perspective, you can still build a cdylib and a header for it, Xcode will let you include the header in your Objective-C code or in the Swift bridging header, and then you can link to the cdylib and copy it into the "Frameworks" subdirectory in the bundle at build time. I've been doing that in an OS X app for several months and it works out very well.
> calling the main thread from Rust wasn't easy.
If you want to schedule code to run in the main queue/thread/runloop, that's an Apple-specific thing Rust wouldn't be aware of by default, but I did find a wrapper for libdispatch/GCD, and it seems to support calling things on the main queue which should do what you want.
You can also have your app provide a C callback to the Rust code (even a Swift closure with captured variables, with some clever workarounds since you can't do that by default), and then in the callback you can schedule code to run on the main queue/thread if you want.
I haven't seen much on it. Doesn't mean solutions don't exist, but I regularly read updates on reddit and what people are working on, and I haven't seen much there. I feel like Swift is more likely to fill that role by coming to android.
for me it works great, a few quirks to configure xcode at first (like with most things in xcode when you need more than a 100% cocoa app), then now the workflow is unobtrusive. debugging also works from xcode, minus coloring of rust code.
my only concern is bitcode support, not feasible now due to a version mismatch between apple's llvm and rust's llvm (you can emit bitcode with rustc). which means currently you can ship apps for iOS, but not watchOS or tvOS.
I am glad that FreeBSD is on the "Tier 2" list of supported platforms [1] but am wondering, is there any way to convince you guys to make it "Tier 1"? If so, how?
I am willing to dedicate some amount of my own time to make it happen but am not convinced that my skills [2] and the amount of time I have available to spend is sufficient to make a difference.
I think it is unlikely we will make FreeBSD tier 1 any time soon. The project is stretched beyond its limits with its platform support commitments, and FreeBSD is historically difficult for us to support.
The next tier 1 is going to be ARM, probably for both Android and Linux, and then I personally don't see any others on the horizon. I actually see our tiers being redefined soon to be more graduated, and not have so many tier 2 commitments (we're happy to build artifacts for obscure platforms, less happy to be on the hook for guaranteeing obscure platforms continue to build - not saying FreeBSD specifically is 'obscure').
That said, the differences between tier 1 and tier 2 are not so great. If a platform has testing on CI then it is pretty close to tier 1, even if it's technically tier 2. The problem here is that testing the FreeBSD targets requires running FreeBSD in some way and that has been hard for our CI to do. Anything that can be crossed from Linux is easy, everything else is a painful special case. So with FreeBSD we do the the cross-building, but not the cross-testing. So the most effective thing to do to take Rust FreeBSD support to the next level is to figure out a way to get the CI to run tests.
There may be opportunities in the future for paid Rust platform support, where if a motivated party donates the right amount of money, we'll make it happen. I think that will have to happen to get some of the remaining platforms up to production quality.
Semi-official answer since this isn't an area I work on directly:
In general, the differences between Tier 2 and Tier 1 are:
1. Get tests running on every commit.
2. Gate building on those tests passing.
The first is a technical/money issue, the latter is a social issue. That is, getting all tests working is technical, being able to afford running them on every commit is monetary, but gating builds on failures on a platform is an issue of "who is responsible for making sure things stay passing."
Given that we run these tests on every commit, in some sense, it would be the PR author's job, but if they get stuck, we need someone who's able to help them fix that. That is the hardest part of moving from tier 2 to tier 1 in my personal opinion. Who is that person? What happens if they drop off the project?
I like rust a lot, but even hello world web apps compile (and recompile) so slowly. I barely get a single step down my to do list before recompiles take more than a second, and it makes it functionally unusable compared to other tools. I know this sounds silly, but it's true. I don't want the check, I want to see the webpage changed after my code changes. I keep hearing about incremental compiles but when I used nightly and tried turning it on, I guess it didn't work because compile times barely changed.
Although you broke your promise about avoiding breaking changes. I know I know, it wasn't promise and wasn't about breaking changes, it was something else about something else.
"The attribute `export_macro` is currently unknown to the compiler" - what a surprise in beta 1.17.
I'm wondering if the following will be one day possible with Rust. I want to build a fast data-store with the basic data-structures offered by Rust (e.g., std::collections), which are stored in a memory-mapped file. The problem with mmapped files is that they don't always appear at the same address (this is not always possible, especially if you open multiple stores at once). So in order to use the standard data-structures, Rust must provide some mechanism to make this possible (I realize that this can be tricky). Alternatively, I could write my own data-structures, but of course, I'd prefer to use the standard ones.
There's a bug open about this, and I am literally deploying the fix right now. It'll probably be fixed by the time you read this comment :) (EDIT: deployed successfully, refresh the page)
We used a time-based release schedule; each minor version comes out every six weeks. We believe this approach is better for a number of reasons, including quality.
It's hard for a software project to make progress if the only way to reach users is non-rolling distros. To a large extent, the progress of software in non-rolling distros relies on enough other people using the intermediate versions from outside the distro repo, in rolling distros or on Mac/Windows.
Personally I love this feature in a build tool. The Stack tool for Haskell does the same, which means I can use the newest version very easily, without depending on some volunteer's Ubuntu PPA (which may not exist).
[+] [-] AsyncAwait|9 years ago|reply
If you just want to make sure you code compiles, this is the command for you.
There's also a bunch of API stablilizations around Strings, Vectors etc, complete changelog: https://github.com/rust-lang/rust/blob/master/RELEASES.md#ve...
Congratulations to everyone involved on the release!
[+] [-] tupshin|9 years ago|reply
[+] [-] zellyn|9 years ago|reply
Well played, Rust devs, well played. https://imgur.com/a/lK1BQ
[+] [-] steveklabnik|9 years ago|reply
[+] [-] FlyingSnake|9 years ago|reply
The last time I checked Rust didn't support .frameworks creation, didn't support Bitcode and calling the main thread from Rust wasn't easy.
I would love to hear if these issues have been resolved.
[+] [-] mrsteveman1|9 years ago|reply
From a purely "how do I get something I can link to" perspective, you can still build a cdylib and a header for it, Xcode will let you include the header in your Objective-C code or in the Swift bridging header, and then you can link to the cdylib and copy it into the "Frameworks" subdirectory in the bundle at build time. I've been doing that in an OS X app for several months and it works out very well.
> calling the main thread from Rust wasn't easy.
If you want to schedule code to run in the main queue/thread/runloop, that's an Apple-specific thing Rust wouldn't be aware of by default, but I did find a wrapper for libdispatch/GCD, and it seems to support calling things on the main queue which should do what you want.
https://crates.io/crates/dispatch
You can also have your app provide a C callback to the Rust code (even a Swift closure with captured variables, with some clever workarounds since you can't do that by default), and then in the callback you can schedule code to run on the main queue/thread if you want.
[+] [-] conradev|9 years ago|reply
[+] [-] steveklabnik|9 years ago|reply
Bitcode is tough, see https://github.com/rust-lang/rust/issues/35968
In general, we'd love to get this into better shape, but need some help from people with the time and expertise to hack on it.
[+] [-] pjmlp|9 years ago|reply
Do you have any better approach to JNI calls other than Djinni, SafeJNI, SWIG, RPC-like with bulk of work on Java side?
[+] [-] agmcleod|9 years ago|reply
[+] [-] hashmal|9 years ago|reply
my only concern is bitcode support, not feasible now due to a version mismatch between apple's llvm and rust's llvm (you can emit bitcode with rustc). which means currently you can ship apps for iOS, but not watchOS or tvOS.
(my use case of rust is DSP / audio synthesis)
[+] [-] eriknstr|9 years ago|reply
I am willing to dedicate some amount of my own time to make it happen but am not convinced that my skills [2] and the amount of time I have available to spend is sufficient to make a difference.
[1]: https://forge.rust-lang.org/platform-support.html
[2]: https://www.github.com/eriknstr
[+] [-] brson|9 years ago|reply
The next tier 1 is going to be ARM, probably for both Android and Linux, and then I personally don't see any others on the horizon. I actually see our tiers being redefined soon to be more graduated, and not have so many tier 2 commitments (we're happy to build artifacts for obscure platforms, less happy to be on the hook for guaranteeing obscure platforms continue to build - not saying FreeBSD specifically is 'obscure').
That said, the differences between tier 1 and tier 2 are not so great. If a platform has testing on CI then it is pretty close to tier 1, even if it's technically tier 2. The problem here is that testing the FreeBSD targets requires running FreeBSD in some way and that has been hard for our CI to do. Anything that can be crossed from Linux is easy, everything else is a painful special case. So with FreeBSD we do the the cross-building, but not the cross-testing. So the most effective thing to do to take Rust FreeBSD support to the next level is to figure out a way to get the CI to run tests.
There may be opportunities in the future for paid Rust platform support, where if a motivated party donates the right amount of money, we'll make it happen. I think that will have to happen to get some of the remaining platforms up to production quality.
[+] [-] steveklabnik|9 years ago|reply
In general, the differences between Tier 2 and Tier 1 are:
1. Get tests running on every commit.
2. Gate building on those tests passing.
The first is a technical/money issue, the latter is a social issue. That is, getting all tests working is technical, being able to afford running them on every commit is monetary, but gating builds on failures on a platform is an issue of "who is responsible for making sure things stay passing."
Given that we run these tests on every commit, in some sense, it would be the PR author's job, but if they get stuck, we need someone who's able to help them fix that. That is the hardest part of moving from tier 2 to tier 1 in my personal opinion. Who is that person? What happens if they drop off the project?
[+] [-] hawkice|9 years ago|reply
[+] [-] pcwalton|9 years ago|reply
The feature is designed so that incremental typechecking can happen—it just doesn't yet.
[+] [-] steveklabnik|9 years ago|reply
[+] [-] EugeneOZ|9 years ago|reply
[+] [-] EugeneOZ|9 years ago|reply
"The attribute `export_macro` is currently unknown to the compiler" - what a surprise in beta 1.17.
[+] [-] shock|9 years ago|reply
[+] [-] nrc|9 years ago|reply
[+] [-] eptcyka|9 years ago|reply
What I can't wait for is Tokio for Diesel and Rocket.
[+] [-] 0xFFC|9 years ago|reply
[+] [-] amelius|9 years ago|reply
[+] [-] fnord123|9 years ago|reply
Usually this means you want to build things build on arrays.
>The problem with mmapped files is that they don't always appear at the same address
i.e. you use arrays and then index into the array instead of using pointers.
> So in order to use the standard data-structures, Rust must provide some mechanism to make this possible
Well, arrays exist in Rust. Or you're going to have to be more specific about what you're trying to do.
[+] [-] ComputerGuru|9 years ago|reply
Edit: so it was 1.15! I've been running 1.14 on my laptop and didn't realize it!
[+] [-] steveklabnik|9 years ago|reply
[+] [-] kosinus|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] riquito|9 years ago|reply
[+] [-] steveklabnik|9 years ago|reply
Thank you!
[+] [-] sametmax|9 years ago|reply
[+] [-] steveklabnik|9 years ago|reply
[+] [-] tedunangst|9 years ago|reply
[+] [-] steveklabnik|9 years ago|reply
[+] [-] Animats|9 years ago|reply
Rust isn't in the Ubuntu distribution, either.
Stop rolling your own installer and use the distro programs. You are not a special snowflake.
[+] [-] hsivonen|9 years ago|reply
That said, Ubuntu does carry (an obsolete version of) Rust: http://packages.ubuntu.com/search?keywords=rustc&searchon=na...
[+] [-] steveklabnik|9 years ago|reply
rustup.sh has been deprecated for months now.
> Rust isn't in the Ubuntu distribution, either.
It's in Debian now, so (as far as I know) that means it should end up in Ubuntu soonish.
> Stop rolling your own installer and use the distro programs.
Not everyone is on Linux.
[+] [-] runeks|9 years ago|reply
[+] [-] Ar-Curunir|9 years ago|reply