Rust 1.34.0 • Hacker News Board

Re: Rust 1.34.0

#131

Post by steveklabnik » Fri, Apr 12, 2019, 1:13 PM UTC

phaylon wrote: post #130

steveklabnik wrote: post #128

Earlier quoted context omitted.

Yes, there are some lang team members that want to change this policy, but it is not the current policy. Those changes were for soundness fixes. You can see how controversial that RFC was, and for that exact reason.

No, that wasn't for soundness fixes. This is from the discussion surrounding syntax changes like turbofish or chained if-let bindings. Can you point me towards an authoritative post in the turbofish discussion that says that it can't happen because of backwards-compatibility changes? Because before it was locked it seemed that the language team wanted to go ahead. I've been repeatedly told by language team members th…

Those things didn’t happen yet. I’m talking about the ones that did happen.

My understanding is that, again, some lang team members want a different policy. That doesn’t mean that it’s actually different.

Re: Rust 1.34.0

#132

Post by phaylon » Fri, Apr 12, 2019, 1:15 PM UTC

steveklabnik wrote: post #129

phaylon wrote: post #124

Earlier quoted context omitted.

Can I copy a module from an old project into a new crate and it will always work without adjustments? What about code examples from StackOverflow, or Github issues? Will these work without adjustments in my local project? Will a future syntax highlighter always be able to highlight the code in my old Rust articles? Will future tooling always be able to read my current code? Can I make editor macros and snippets that…

1. Depends on the new project, of course. Just like any language. 2. Same thing. You can construct an example that breaks any language in existence. 3. Yes. 4. Yes. 5. Yes. 6. You’re using an idiosyncratic definition, so yes, it’s not the same. Backwards compatibility is about the same thing continuing to compile, not about changing things and expecting it to still compile; that’s forwards compatibility.

Once again something is at odds here. You give resounding "Yes" comments, but in the backwards compatibility discussions I had with language team members, those "Yes" comments were actually "not really our problem" answers.

I also don't know how current code running in a future compiler is forward-compatibility. And the Rust guarantee only kind-of holds if you define "code" as "crate". Everything outside of or crossing that boundary is not compatible.

To clarify and bring it to an example: Are you guaranteeing that `(a(d))` will always be parsed as a tuple with two comparisons? Because if so I believe you're the only one.

Re: Rust 1.34.0

#133

Post by phaylon » Fri, Apr 12, 2019, 1:20 PM UTC

steveklabnik wrote: post #131

phaylon wrote: post #130

Earlier quoted context omitted.

No, that wasn't for soundness fixes. This is from the discussion surrounding syntax changes like turbofish or chained if-let bindings. Can you point me towards an authoritative post in the turbofish discussion that says that it can't happen because of backwards-compatibility changes? Because before it was locked it seemed that the language team wanted to go ahead. I've been repeatedly told by language team members th…

Those things didn’t happen yet. I’m talking about the ones that did happen. My understanding is that, again, some lang team members want a different policy. That doesn’t mean that it’s actually different.

Where do you get that understanding? All the comments and the summaries I've seen by language team members on this give me a different impression. See this comment from Niko for example: https://github.com/rust-lang/rust/issues/53668#issuecomment-...

So, can you point me to a comment that tells me that the policy still holds and is as you are presenting it?

Re: Rust 1.34.0

#134

Post by steveklabnik » Fri, Apr 12, 2019, 3:01 PM UTC

phaylon wrote: post #133

steveklabnik wrote: post #131

Earlier quoted context omitted.

Those things didn’t happen yet. I’m talking about the ones that did happen. My understanding is that, again, some lang team members want a different policy. That doesn’t mean that it’s actually different.

Where do you get that understanding? All the comments and the summaries I've seen by language team members on this give me a different impression. See this comment from Niko for example: https://github.com/rust-lang/rust/issues/53668#issuecomment-... So, can you point me to a comment that tells me that the policy still holds and is as you are presenting it?

The language evolution RFC.

Re: Rust 1.34.0

#135

Post by littlestymaar » Fri, Apr 12, 2019, 4:51 PM UTC

burntsushi wrote: post #115

littlestymaar wrote: post #112

Earlier quoted context omitted.

This is only for debug builds though, cranelift. Isn't going to offer good enough performance for a release mode binary anytime soon (and probably never will).

If Cranelift makes debug builds much faster, then that's still a huge win. In my line of work, I do tend to compile things in release mode a lot purely because I often need to debug performance related problems, and for that, debug mode doesn't work. However, most of the test suites in my crates are built and run in debug mode. For example, the test suite for regex-syntax is fairly large, and it can take several seco…

I 100% agree with you that Cranelift is a big deal (Last year I had to change my desktop CPU just to be able to build, in a reasonable amount of time in debug mode, the Rust project I'm working on − ok my CPU was still a Core 2 Duo at this point).

Even for things where debug mode is too slow, Cranelift could be a game changer since it promises to produce more performant binaries than LLVM in debug mode (Idk if it will be fast enough for you use-cases though).

I just wanted to point out that Cranelift won't solve the compile-time issue all by itself.

Re: Rust 1.34.0

#136

Post by eikenberry » Fri, Apr 12, 2019, 5:05 PM UTC

burntsushi wrote: post #68

eikenberry wrote: post #23

Earlier quoted context omitted.

> For me the best releases will be when it matches D/Delphi/Ada/Eiffel/.NET Native compile times [..] Any ideas on when this will be? There has been talk about faster compile times for years now without that much apparent progress.

> There has been talk about faster compile times for years now without that much apparent progress. Really? What makes you say that? Have you tried it? $ git clone git://github.com/BurntSushi/ripgrep $ cd ripgrep $ git checkout 0.4.0 $ time cargo +1.12.0 build --release real 1:09.13 user 2:06.08 sys 2.839 maxmem 359 MB faults 1292 $ cargo clean $ time cargo +1.34.0 build --release real 22.484 user 2:32.66 sys 3.380 m…

3X speedup is a definite improvement. I don't use rust regularly, so have been relying on community news for updates and while they have mentioned planned work to increase compilation speed a few times they haven't really talked about any landing (that I saw anyways).

Also cold start speed is not really what I care about. I am more concerned with compiler speed while working and running tests. I find that if a language compiler is to slow it breaks flow while testing changes. I haven't seen much mention of the improvements the incremental compiler gives in a while. Last I read was the 2017 blog post [1] during beta and it only showed modest improvements and more recently I only see talk of how it still needs a lot of work [2].

[1] https://internals.rust-lang.org/t/incremental-compilation-be...

[2] https://nicoburns.com/blog/rust-2019/#compile-times-especial...

Re: Rust 1.34.0

#137

Post by phaylon » Fri, Apr 12, 2019, 5:21 PM UTC

steveklabnik wrote: post #134

phaylon wrote: post #133

Earlier quoted context omitted.

Where do you get that understanding? All the comments and the summaries I've seen by language team members on this give me a different impression. See this comment from Niko for example: https://github.com/rust-lang/rust/issues/53668#issuecomment-... So, can you point me to a comment that tells me that the policy still holds and is as you are presenting it?

The language evolution RFC.

How do you square your interpretation with the comment I linked to above?

Re: Rust 1.34.0

#138

Post by bbatha » Fri, Apr 12, 2019, 7:45 PM UTC

steveklabnik wrote: post #43

bbatha wrote: post #41

Earlier quoted context omitted.

I think that's likely. async/await doesn't appear to map directly onto traditional OO GUI framework callbacks well, just like rust doesn't tend to map well to traditional OO. I believe that async/await will open up new architectural patterns that should be as ergonomic as traditional OO callbacks for GUIs. But these won't map well to existing code or existing frameworks.

There have been attempts, like relm, to map futures onto GTK. That means it would work with async/await too, as they’re fundamentally sugar for futures.

Even those are basically Relm components that happen to render via GTK. You can't really import a plain `GObject` and implement a traditional `fn on_click()` without having to worry about internal mutability and the associated borrow checking complexities.

Re: Rust 1.34.0

#139

Post by ben0x539 » Fri, Apr 12, 2019, 7:57 PM UTC

Manishearth wrote: post #127

ben0x539 wrote: post #99

> People maintaining proprietary/closed-source code cannot use crates.io, and instead are forced to use git or path dependencies. This is usually fine for small projects, but if you have a lot of closed-source crates within a large organization, you lose the benefit of the versioning support that crates.io has. I'm surprised that making people run their own registries is the preferred way to address this, instead of…

What do you mean by "versioning support for git dependencies"? We do support pulling in git dependencies based on a branch (I think tags work?) We also support checking the version of the git dep. It's fetching the dep that's the problem. Git has no uniform protocol for talking about versions, especially when it comes to resolving SemVer ("you asked for 0.2.1 but I also have 0.2.5, here you go") If you want go-style…

"Versioning support" is the wording from the release notes. I don't know why cargo's version resolution logic can't be applied to git dependencies, treating a tag like "v4.2" or "4.2" as a version 4.2 doesn't seem very contentious. I also don't know what you mean by local git dep.

Re: Rust 1.34.0

#140

Post by burntsushi » Fri, Apr 12, 2019, 9:03 PM UTC

eikenberry wrote: post #136

burntsushi wrote: post #68

Earlier quoted context omitted.

> There has been talk about faster compile times for years now without that much apparent progress. Really? What makes you say that? Have you tried it? $ git clone git://github.com/BurntSushi/ripgrep $ cd ripgrep $ git checkout 0.4.0 $ time cargo +1.12.0 build --release real 1:09.13 user 2:06.08 sys 2.839 maxmem 359 MB faults 1292 $ cargo clean $ time cargo +1.34.0 build --release real 22.484 user 2:32.66 sys 3.380 m…

3X speedup is a definite improvement. I don't use rust regularly, so have been relying on community news for updates and while they have mentioned planned work to increase compilation speed a few times they haven't really talked about any landing (that I saw anyways). Also cold start speed is not really what I care about. I am more concerned with compiler speed while working and running tests. I find that if a langua…

Incremental compilation was a big improvement over the status quo.

I don't follow compiler performance developments. I'm just responding to clarify that there has been performance improvements. They have likely just built up over time. I don't think there was any one specific change that dramatically improved things.