5 ms·
I'd say the tooling is pretty great only with the exception of an IDE. Debugging, building, testing, packaging all seems pretty well handled.
by jonesetc 10y ago
I'd say the tooling is pretty great only with the exception of an IDE. Debugging, building, testing, packaging all seems pretty well handled.
- merb 10y agopackaging 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.
- krisdol 10y agoA big pain is still JIT compilation. Last time I used rust, even small changes to code required a full re-compilation.
- steveklabnik 10y agoTo 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.
- matthewmacleod 10y agoAre 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!
- krisdol 10y agoYou 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.
- msbarnett 10y ago> 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.
- pcwalton 10y agoBug 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.
- msbarnett 10y agoI'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.
- pcwalton 10y agoWell, 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!)
- msbarnett 10y agoI 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 https://github.com/rust-lang/rust/issues/33674
- blakeyrat 10y agoOk, maybe I've been too spoiled by Visual Studio, but debugging without an IDE? That sounds extremely painful to me.