Disclaimer: I may be slightly biased because I originally committed the rusti code.
I think the general conclusion you've come to here is that a tool that is explicitly marked as experimental is in fact, experimental. Good language tools, especially REPLs, don't pop up into existence out of nowhere. They need to be polished over time with the language itself. rusti is certainly unstable, but this is not the fault of the tool but the way the compiler works. I knew that pretty printing history into a big list of strings was a bad way for it to work, but there was no other way to make it work at the time. Each compiler instance (i.e. every time a line was inputted) had to be run on a separate task every time, so the history had to be sendable. A better alternative would have been to store the history as AST (so it didn't need to be parsed each time, only compiled), but that wasn't sendable. As far as I know, each compiler instance no longer needs to be on a separate task so this could probably be used instead now. In my opinion, rusti gets the job done. Yes, having in-memory compiled state would work a lot better. But I don't know how viable that is. I know for a fact that a big feature plan is to have the compiler only partially compile when applicable, i.e. only compile things are actually important. That would help drastically here. And no-no-no, I think removing the JIT backend is a really bad idea. That sort of thing is really useful and removing it now is not going to be productive. There has been much work from the community recently to improve rusti and the JIT compiler. I think once Mozilla setup automated testing of the JIT compiler it could easily be polished and have all tests green under it, which would be great. On Wed, May 29, 2013 at 2:03 PM, Alex Crichton <[email protected]> wrote: > I've been tinkering with rusti recently, and I'm reaching the > conclusion that it should be removed entirely from the compiler. As > many people are probably aware, rusti hasn't been working > fantastically for awhile now, but that's only partially why I think > that it should be removed. > > - What I think a REPL should be > > In my opinion, the point of rusti is to be a REPL for rust. I type in > valid rust code and it spits out the results. This all works today, > except for the fact that it's not a REPL in the sense of what other > languages have. I'm most familiar with ruby's irb, so these opinions > will be derived from that. > > When using a REPL, I imagine that there's a flow of execution that's > just pausing for a very long time between lines (waiting for input). > What this means is that if I've defined any variables or functions > previously, they're still available to me at the current line. Not > only that, but nothing is "re-run" in the sense that if the previous > line calculated fib(50), I don't want each line I enter into the repl > to calculate again fib(50) for some reason. > > - What rusti is > > The way that rusti works today in my opinion is a bit hacky once you > look inside. It will take your line of input, fmt! it into a template, > and then compile the whole template (via rustc using LLVM). After > compilation is successful, it walks down the ast to figure out what > you just input, and it then records that line of input in its history > *as a string*. What this means is that for the second line of input to > rusti, it will put both the history and the input into the template, > and re-run all the code again. > > Now this doesn't sound that bad in theory. Normally rusti is for quick > computations. There's not much of a history and nothing really takes a > long time. This quickly becomes a problem though for anything which > uses resources. Let's say that you call io::println. Do you really > want that statement executed every time you enter a line into rusti? > What if you opened a file or a network connection? In my opinion, > re-running code is unacceptable. > > This actually glosses over the fact that rusti currently doesn't even > save all input. It only saves declarations and definitions right now. > I made a patch to save assignments as well, but that still doesn't > work in all situations. I don't believe that there's a good way to > "filter the code" such that you "only get what you want" (which is > what rusti currently attempts). > > - Can rusti be my version of a REPL? > > Basically what all that means is that rusti has to save the world's > state between your lines of input to be my version of a REPL. To the > best of my knowledge (which could very well be wrong), this is not > possible to do in Rust. > > This leads me to the conclusion that rusti cannot be a true REPL (at > least the way I see a REPL). In my opinion, this also means that rusti > should be discarded. If someone new comes to rust and tries out the > fancy 'rusti' command, they'll start to play around but very quickly > run into some odd scenario that doesn't match what they think. After > playing around for awhile, they may realize that the "REPL" is > behaving oddly, or they'll just leave entirely. Regardless, no one is > going to get what they're expecting when they run rusti. > > If no one gets what they want when they run it, and I don't believe > that anyone can ever actually get what they want, I don't think that > there's a reason to keep it around as a tool that is built into rust. > I believe that the 'rust run' command is an excellent alternative. No, > it's not as fast as rusti, but it's correct and you know exactly > what's happening. I don't necessarily think that this warrants the > removal of the "-Z jit" flag either, but it makes me seriously > question whether it's worth maintaining that code. > > > > So that's all just my own personal opinion. I was wondering what other > people thought about this course of action? If anyone has questions > about how rusti currently works, I can also do my best to answer those > as well. > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
