8 ms·
One year since stable? It feels like five years for the level of maturity they have achieved.
by grenoire 10y ago
One year since stable? It feels like five years for the level of maturity they have achieved.
- deutronium 10y agoI was confused by that, apparently it's one year since the first stable release.
- merb 10y agoExcept the tooling, could be better. A language like Rust will benefit from a rich IDE a lot. But still the language is great.
- nemaar 10y agoWith this speed of development, I'm pretty sure it is coming.
- merb 10y agoactually idea-rust made great progress, yes.
- jonesetc 10y agoI'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.
- sargun 10y agoI really wish that Jetbrains had a Rust IDE. I love their Go, and Erlang plugins for IntelliJ, Java with IntelliJ, and Clion with C. Without them, I don't think I could be anywhere as effective as I am. I tried to pickup Rust, but I was super frustrated by the code/compile/run cycle with the current plugin. But, hopefully more users will make that better.
- grenoire 10y agoJetbrains Rust IDE would genuinely make Rust my go-to language for pretty much every task I can think of.
- PascalW 10y agoCouldn't agree more! There's some work ongoing on a third party Rust plugin for InteliJ but it still has a long way to come.
- deleted 10y ago[deleted]
- EugeneOZ 10y agoThere is unofficial plugin: https://github.com/intellij-rust/intellij-rust https://github.com/intellij-rust/intellij-rust and works very well: https://www.youtube.com/watch?v=mHa7QlFz7io https://www.youtube.com/watch?v=mHa7QlFz7io (small video recorded by me)
- jdright 10y agoIs that Racer happening? It look like there is still a lag in the completion suggestion... and that is a huge problem (mainly when using it as to find things).
- EugeneOZ 10y agoNo, this plugin works without Racer. I use it every day and I don't see any problems with code completion. Except of cases where code completion isn't supported yet :) But it's all personal and better to try - it's free. To clarify: I'm not author of this plugin. And I tried Racer with Microsoft Visual Code plugin - it works without any lags, very fast. Just fails sometimes :)
- AsyncAwait 10y agoNot as great as a full IDE, but Atom.io + tokamak(https://vertexclique.github.io/tokamak https://vertexclique.github.io/tokamak) + atom-ctags(https://atom.io/packages/atom-ctags https://atom.io/packages/atom-ctags) get you a decent editor/light IDE setup. I agree however that it would be nice to have ie lifetimes visualized and stuff like that, hopefully sometime soon...
- josteink 10y ago> Except the tooling, could be better. A language like Rust will benefit from a rich IDE a lot. I just found this link[1] for a pretty complete Emacs IDE-like setup the other day. I'm not a Rust programmer, but it seemed promising enough that it made me want to give it a spin. [1] http://julienblanchard.com/2016/fancy-rust-development-with-emacs/ http://julienblanchard.com/2016/fancy-rust-development-with-...
- shmerl 10y agoI'm not into IDEs, so that doesn't bother me. But by tooling I'd understand cargo. It is improving.
- tracker1 10y agoReplied in the wrong child.... May want to give VS Code + RustyCode[1] extensions a look. [1] https://github.com/saviorisdead/RustyCode https://github.com/saviorisdead/RustyCode
- vvanders 10y agoI actually find the tooling to be quite decent. VSCode + Racer has worked pretty well for me so far.
- Lewisham 10y agoI'd say rustdoc is pretty rough. It's very hard to navigate the rust stdlib vs, say, Go, and when you do find what you want, it's often specified in some very cryptic manner that seems to require a PL PhD. It is a really big barrier to adoption because it's very hard to find out what functionality is or is not offered. Here's an example: I want to iterate over a set. Easy, right? No. http://static.rust-lang.org/doc/master/std/collections/hash_set/struct.IntoIter.html http://static.rust-lang.org/doc/master/std/collections/hash_... Look at the signature for Cycle. It's really hard to know what this does even though it's trivial: fn cycle(self) -> Cycle<Self> where Self: Clone When you click through to the real documentation, it describes a useful use case for this. But that's not how programmers think. They think "I need to do X right now so I'll find something that looks right" not "I'm going to click through the documentation... oh X looks interesting I'll remember that later". There's no way to infer what Cycle really does without having actually clicked through or used it.
- pcwalton 10y ago> fn cycle(self) -> Cycle<Self> where Self: Clone I agree that a summary would be good, but this doesn't require a PL Ph.D. It means "cycle is a method that moves its receiver and returns a Cycle object of the same type of the receiver, and only works if the receiver is cloneable". The trickiest thing here, IMHO, is move semantics, which is something fundamental to Rust in general.
- vvanders 10y agoYup, I've got the same feeling here. If you've spent more than a cursory time with Rust this is pretty straightforward. You'd represent this in Java(minus move semantics, because Java has nothing like that) via: class IntoIter { public Cycle<T extends Clone> { ... } ... } Where Clone is just an interface that knows how to clone its value.
- Lewisham 10y agoFair enough; some more noodling over the signature made it a bit more obvious than it seemed banged out at the back of an OSCON presentation. I think the point still holds. Maybe just not for that one.
- quarterto 10y agoWell, it has been around for about that long. The "one year" is since the stable release 1.0.
- grenoire 10y agoI meant since the stable release in fact.
- steveklabnik 10y agoRust has been in development for almost a decade at this point; but the language changed significantly many times before 1.0. It's been one year since the 1.0 release, which is the language we know today as "Rust". All those older languages are dead and gone now. I'm actually doing a talk about the ACM's Applicative conference in NYC this year talking about the history of Rust.
- jandrese 10y agoThis is one thing that's a little annoying to me. I know if I develop a Rust app today I can't leave it alone or it will decay horribly.
- steveklabnik 10y agoThat should not be true. 1.0 meant that we stopped breaking things on a daily basis, if your code runs on stable today, it should run on stable tomorrow, modulo any soundness fixes (of which we have had two or three this year, which were all trivial to update). If it is true, please file bugs. We do our best not to break people's stuff, going to pretty extreme lengths compared to many other ecosystems.
- kzrdude 10y agoand occasional other breaking compiler bug fixes that are not really soundness fixes.
- pcwalton 10y ago> This is one thing that's a little annoying to me. I know if I develop a Rust app today I can't leave it alone or it will decay horribly. No, it won't. Rust has been stable since 1.0, as the article itself mentions.
- tatterdemalion 10y agoGood news for you: this is a complete misconception. Rust has been stable for a year. With a minor caveat for actual bugs in the language, your code will compile on all Rust 1.X compilers from now until the end of time. Upgrading Rust versions has been a breeze.