> Debugging, building, testing, packaging all seems pretty well handled.

Eh, debugging is a mess, at least on OS X. Rust advertises LLDB support, but it seems semi-broken. Listing source is non-functional and just setting a break-point requires a lot of hand-holding.

Bug reports of specific problems would be very appreciated! We emit fairly complete DWARF, but debuggers tend to be finicky about the exact subset of DWARF they accept.

I'll try to submit a report later. It's exactly what it sounds like, though.

    $ cat hello.rs
    fn main() {
	println!("Hello world!");
    }
    $ lldb -v
    lldb-350.0.21.9
    $ uname -a
    Darwin mycomp 15.5.0 Darwin Kernel Version 15.5.0: Tue Apr 19 18:36:36 PDT 2016; root:xnu-3248.50.21~8/RELEASE_X86_64 x86_64
    $ rustc --version
    rustc 1.8.0
    $ rustc -g hello.rs
    $ ./hello
    Hello world!
    $ lldb hello
    (lldb) target create "hello"
    Current executable set to 'hello' (x86_64).
    (lldb) source list
    (lldb)
    (lldb) b 2
    error: No selected frame to use to find the default file.
    error: No file supplied and no default file available.

I don't see how the core team could be unaware of this unless literally no one has done even a cursory glance at OS X & LLDB in months.

I think this is a known issue relating to some lldb versions no longer treating unknown languages as C; which got fixed in lldb upstream but may not have been released yet.

Well, I do use it regularly for testing Servo. There's a debugger harness run as part of the test suite too. (Not to say we shouldn't fix whatever is causing your problem, though!)

I can make it work if I feed full file paths to the debugger using syntax I can't remember off the top of my head. Maybe that's one way some scripts might be functioning?

I'll copy and past this into a Github issue when I have a sec.

edit: https://github.com/rust-lang/rust/issues/33674

Thanks! Forwarding to the appropriate people.

packaging will work great if you don't rely on any unicorn library that will put their dylib/so files in some ugly path's that aren't standard. (FFI only) actually not the worst thing for most people, but linking against a paid library will mostly end up with setting LD_LIBRARY_PATH at some point.

Ok, maybe I've been too spoiled by Visual Studio, but debugging without an IDE? That sounds extremely painful to me.

A big pain is still JIT compilation. Last time I used rust, even small changes to code required a full re-compilation.

To be clear: Rust doesn't have a JIT. But we've been doing a lot of work on incremental recompilation, which will fix this problem. (Or rather, we've been working on the precursor requirement, MIR.)

To be extra clear, a crate is the unit of compilation in Rust, so changing your code means that the whole crate it's in needs recompiled; your dependencies won't be. Or, if your project is split up into multiple crates, the other ones won't. Incremental recompilation will reduce this level of granularity such that the whole crate won't need to be recompiled.

Are you sure you mean JIT rather than incremental compilation? The former is a pretty different concept that AFAIK Rust has no implementation of.

I think we are likely to see better incremental support with the recent development of MIR, but I'm not sure what the current plans are. Should help tooling around the language generally!

You are correct. I doubted JIT was the right word at the time but couldn't think of the right term. Incremental support is what I mean.