It's also using some manual clone instead of Cargo overrides, and manually running rather than `cargo run`... time for some PRs, I guess!

EDIT: further, looks like it's on a really old Rust: https://github.com/kanaka/rust-pcre wasn't updated since October...

EDIT 2: I tried to update the code, but it's really, really out of date, and will be a ton of work. So I've just submitted https://github.com/kanaka/mal/pull/23 instead. :(

Well, I'm not going to remove it. But I will see if I can find some time to improve it in the next few days. I've been meaning to cycle back around. Of course, fixes from somebody who's actually a Rust expert would have been preferred :-)

The reason it still uses the alternate pcre is because this still hasn't been fixed: https://github.com/rust-lang/regex/issues/28 I would love to get rid of that nastiness.

That's a bummer, because until then, you'll be strongly mis-representing Rust :/

I hope that you are mis-representing Rust. I'd be pretty discouraged if I was learning a new language and one of the first interactions I had with a notable community member was a notice of take-down containing neither encouragement nor constructive criticism.

To be clear: I spent about half an hour working on updating things for head Rust. But when a language changes as much as Rust does, at some point, if you haven't kept up with it, it's basically impossible to update, it's simply easier to nuke it and start all over. This is why we have always recommended that people use the nightlies rather than the releases, because even upgrading per-point release is quite difficult. Not only that, since it's unclear which version of Rust this even compiles with, it's not as if I could install an old Rust and submit particular, concrete improvements for a Rust of that vintage. Starting over from scratch _is_ a concrete improvement, because it's the actual best path to moving forward in this particular case.

Have I mentioned how much I can't wait until 1.0.0 actually ships?

I agree with you that this comment is quite harsh, but i'd like to point out that it's not a fair representation of steveklabnik's usual interaction with the community on reddit and IRC, as far as i can tell.

Klabnik is a big voice in the Rust community. But regardless of how he might come across here; he is almost always positive and constructive when talking about the language.

For that matter: the constructive part was in the other post where he suggested some improvements. I can understand if the pull request is seen as aggressive, though.

I'm quite happy to take PRs from an expert to address the issues and represent Rust better. :-)

UPDATE: I will point out that the README is pretty clear that this is rust 0.13. Doesn't mean it's a good representation of rust 0.13 either of course, but it clearly isn't based on a recent version of Rust.

Wait, you are being sarcastic, right? You know that you're replying to Steve Klabnik, who is on the Rust core team?

Yes, it was intended to be somewhat in jest. "The expert" was a subtle (perhaps too subtle) acknowledgement of his role. Although, I am serious that if somebody with better Rust chops than I wants to fixup the code so that it represents Rust better, then I AM quite happy to pull those in and improve the implementation.

Thanks for the feedback.

That did seem rather inefficient at the time but I wasn't able to discern the more efficient method at the time. I've kind of been waiting for Rust 1 to cycle back around. But I'll see if I might be able to address some of those and bump to Rust 1.0 alpha in the next few days.

Note the conversation about performance is kind of unfortunate. Those numbers should be considered VERY rough (they were just a personal notes file of mine). Also, with --release, the numbers place rust in the same range as other compiled languages.

pcwalton: thanks to Alex Crichton, the implementation has been cleaned up and updated to Rust 1.0.0 nightly. Yay! The feedback you noted has been applied to the code base. The performance has definitely improved some. Alex did some performance profiling and it looks like that hashmap performance may be the main bottleneck. The micro-benchmarks (and yes I admit they aren't good tests) don't really test strings, so it's probably the newer Rust version and the other cleanup that Alex did.

But if you want to take another pass through the code now that it's not based on an ancient Rust version, I'm always happy to take any advice from the master. :-)