Hacker News Reader

As others have said; Rust is very stable now.

I started trying to learn Rust at 0.7 (maybe a bit earlier, I can only find references to 0.7 in a few projects of mine). Boy howdy did that feel like an exercise in futility. I would set it aside for 3 weeks, revisit it, and find entire language constructs had been removed. I complained about this and Steve Klabnik graciously reminded me that it was a work in progress and that the work was being done out in the open intentionally. I really can't thank him enough for that since it caused me to go from frustrated to sympathetic. As a result I decided to not write the language off. And I'm glad I didn't. After things slowed down around the betas for 1.0 it became clear that Rust was worth learning. I haven't had a chance to use it professionally, but for personal projects I find myself reaching for Rust for problems that would have caused me to have reached for C in the past.

Also, Google has gotten significantly better about returning current and up to date information on Rust as well. Around 2013-2014 my biggest gripe was that I'd search for how to do something only to find advice that was woefully out of date. I haven't had that experience in well over a year now.

I started to write a VM in Rust and every weekend, when I managed to get some time for work it would usually no longer work and the reason for it had to be found in some mailing list or commit message.

I had to stop doing that and rewrote it in C.

'Fortunately' we had some other problems as well but Im still hopeful that Rust is the language you want to use for this in the future.

I think it is. Especially if you keep your code in a public repo, any breaking changes (probably just tweaks as opposed to huge features that break stuff), will probably have a pr filed via cargo.

From what I understand, the rust team has scripts that crawls the repos and compiles everything looking for usages of some feature being used that's going to break in the next release, and they will issue a pull request to fix those.

It's more subtle than that. For most things, we guarantee no breakage at all, and we do runs like that (though not against github, but against crates.io) to verify we haven't accidentally broken something.

For stuff that we are allowed to change, but might cause breakage, we will try to find stuff and send PRs.

But the default and our intention is zero breakage as much as possible, not just "we'll fix it for you". We'd guarantee absolutely none but it's not actually possible in a statically typed language, so we have to go with "effectively none."

Automatically filed pull requests against my github repo would be amazing!

Actually, you all looking through crates and sending PR's is pretty impressive in itself.

I'm writing a VM as well, albeit a very simple one. I started sometime last fall and have never had a problematic upgrade.

I also got a new computer during that period and rustup has made setup really nice.

We were working mostly in the months before 1.0 so it was right in the time of rapid changes.

<3

> Has the pace of sweeping changes to the language slowed down in the past year?

Up until Rust 1.0 in the spring of 2015, my Rust code broke once or twice a week. Since then, I've had zero breakage.

> Has the pace of sweeping changes to the language slowed down in the past year?

Absolutely, Rust has been stable since 1.0 released in May 2015 with a promise of backwards compatibility and has largely upheld that promise.

Yeah although that doesn't mean the language isn't changing. Just that your old 1.0 code will still work.

It's been, god, 3 years now since I've started writing large Golang applications and I've yet to look back on a project ~6 months later without noticing flaws in design/architecture/intuitiveness. You are not alone in your hurdles.

On the bright side, that's am easy way to measure your growth. Look at it this way, if in six months or more if you look back on code you're writing now that's non-trivial and you can't think of a single thing you would do different what's more likely, that you were lucky/good enough to design it perfectly, or that you didn't actually learn anything from the experience (even if it's what assumptions about projects in that industry you shouldn't make going forward)?

I dread the day I no longer see progress. I suspect it's also about the time I'll really find programming no longer fun.

In my very limited experience, the libraries still aren't stable. I ran into a bunch of errors a couple of days ago because my distro was on 1.14 rust compiler but the latest was 1.15. I'm not sure exactly what the issue is but it looked like the standard libraries had changed between versions.

1.15 contained a new feature that was seriously awaited, so a lot of libraries pushed out a new version using that feature. Even with that, though, Cargo _should_ have saved you here, via the lockfile.

It shouldn't have been the standard library though. If it was, that'd be a serious bug! If you do figure it out, and it is the standard library, please file a bug. And if you need any help, feel free to reach out. I'm here to help.

This was using the latest toml and serde releases, which I think does use that new attribute stuff (which is fucking cool btw). But no warning from cargo until it was compiling the dependencies.

Yeah, that makes sense, they would totally be using it.

Still, upgrading to those releases _should_ have taken manual intervention; how were you depending on them in your Cargo.toml? And I guess you had no Cargo.lock for some reason?

Brand new project. I added them by putting the dependencies into the cargo.toml file (with the current version), is that how you're meant to add them or is there some kind of "cargo install" command?

Ah ha! Yeah, so it makes sense that the latest version would need the latest version of the compiler. You could use the previous version and it should still work. Usually, when a project requires a new Rust version, there's a bump to whichever version determines compatibility. (for x.y.z, x if x != and y if x == 0) Given that you said it was breaking, I thought you meant you had a project that suddenly stopped working, my bad.

For now, that's the standard way, at some point, we might pull a "cargo add" command into core, but there's some blocking on parsing.

It makes sense in this specific case, but I do hope it's not a sign of things to come and libraries aren't requiring bleeding edge features.

That's forwards compatibility, not backwards compatibility.