Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust 1.34.0

blog.rust-lang.org

Post reply on HN
Print view View original

91–100 of 149 posts

Re: Rust 1.34.0

#91

Post by nixpulvis »

steveklabnik wrote: post #89
nixpulvis wrote: post #87

Earlier quoted context omitted.

I personally feel like this falls clearly into the soundness hole catagory and should be allowed to be removed in a breaking way. I understand the desire to avoid breaking changes, but soundness issues like this chip away at what "safety" in Rust really means. I think I'd expect to see warnings about the existing safe method being deprecated for a while, then it's complete removal at the time of another edition of Ru…

Yes, as I said below, this is technically a thing we’re allowed to remove. Maybe someday we will. But we want to be careful. Editions cannot make this kind of change, as also discussed below.

I think it could be an edition thing though... just say Rust 2019 will not allow `Command::before_exec`. By turning on edition 2019 you've accepted the new brakages that it imposes on you, and this is one of them.

Never mind the fact that the function is still a symbol in the STD library.

I understand if this is too much complier magic, though it seems like the correct idea to me anyway.

Am I missing something?

P.S. symbol version pinning seems like a great idea, I've even dreamt of having exposed syntax for it, e.g. `Foo::::bar@v1.3.2(arg1, arg2)`.

Re: Rust 1.34.0

#92

Post by eridius »

pdpi wrote: post #29
korethr wrote: post #20

Hmm, fn before_exec strikes me as a thing that should be gotten rid of entirely in favor of unsafe fn before_exec if the former indeed turned out to actually have the potential to cause undefined behavior. But that'd probably be a breaking change which would require a major version number bump, so deprecation is absolutely the right thing IMO. And it also sets the stage to get rid of it outright come the next major v…

Not sure if there was nothing post-1.0, but this[0] particular mess was just before the 1.0 release and, at the time, caused a fair bit of chaos. 0. http://cglab.ca/~abeinges/blah/everyone-poops/

I remember that one. It came in just under the deadline and it would have been pretty bad if that got into 1.0.

The resolution of this not only had a notable effect on how Rust thought about memory safety (in particular, that leaking memory could not be considered unsafe as it's always possible to construct a leak using safe Rust if you have access to Rc, and as a result `std::mem::forget()` was changed from unsafe to safe), but also informed the way we used RAII going forward, as the fundamental unsafety was due to the use of an RAII value as a token representing external computation and was not itself used in order to perform that computation, which meant leaking the token didn't prevent computation from happening. In all other known cases of RAII, leaking the value is safe because without the value, you can't access the protected resources, but in this case the token represented a thread and the thread of course would continue to run after you leak the token. As a takeaway from this lesson, you can't use tokens to represent external processes, and probably shouldn't use them to represent e.g. hardware that needs to be put back into a known state when the token is dropped unless you have a mutex in there as well (which would cause deadlock if you drop the token and then reuse the resource, rather than sending bad commands that break the hardware). Instead, any time leaking the token would cause unsafety, you need to structure your code to use explicit scopes instead, such that the library can clean up at the end of the scope.

Re: Rust 1.34.0

#93

Post by steveklabnik »

nixpulvis wrote: post #91
steveklabnik wrote: post #89

Earlier quoted context omitted.

Yes, as I said below, this is technically a thing we’re allowed to remove. Maybe someday we will. But we want to be careful. Editions cannot make this kind of change, as also discussed below.

I think it could be an edition thing though... just say Rust 2019 will not allow `Command::before_exec`. By turning on edition 2019 you've accepted the new brakages that it imposes on you, and this is one of them. Never mind the fact that the function is still a symbol in the STD library. I understand if this is too much complier magic, though it seems like the correct idea to me anyway. Am I missing something? P.S.…

Please see the discussion below; I already discussed this at length :)

Re: Rust 1.34.0

#94

Post by epage »

pythonist wrote: post #83
jithesh wrote: post #11

Now that alternate registries to crates.io is available, hoping artifactory could add support for rust... - https://www.jfrog.com/jira/browse/RTFACT-13469

and https://newreleases.io to support at least https://crates.io.. .

Looks like thats a site for notifying you of new dependencies?

I think I'd prefer PRs like https://dependabot.com/

Re: Rust 1.34.0

#95

Post by centril »

steveklabnik wrote: post #39
sanxiyn wrote: post #37

Earlier quoted context omitted.

I think another big item is const fn and compile time function evaluation.

That’s under “const generics”, but yes. Technically const fn is already stable, it’s just expanding what it can do, generally, so we tend to talk about them as one thing.

I think it's not a good idea to talk about them as one thing and the use cases also differ. `const fn`s are deterministic ("pure") functions that can be evaluated at compile time if all arguments provided also can. `const A: B` generics are about compile-time value dependent typing. The former is important for the expressiveness of the latter but they are ultimately independent. Moreover, the implementation effort is also mostly independent (different people are doing the effort). Even having them in the same WG might not be a good idea.

Re: Rust 1.34.0

#96

Post by nicoburns »

eikenberry wrote: post #23
pjmlp wrote: post #9

Earlier quoted context omitted.

For me the best releases will be when it matches D/Delphi/Ada/Eiffel/.NET Native compile times and cargo supports binary dependencies. The language as such is already quite good, in spite of one or other possible improvements on borrow checker ergonomics (e.g. callbacks).

> 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.

This will probably be a big win if/when it lands [0] (adding the ability to replace LLVM with cranelift)

[0]: https://github.com/bjorn3/rustc_codegen_cranelift/issues/381

Re: Rust 1.34.0

#97

Post by ComputerGuru »

pdpi wrote: post #29
korethr wrote: post #20

Hmm, fn before_exec strikes me as a thing that should be gotten rid of entirely in favor of unsafe fn before_exec if the former indeed turned out to actually have the potential to cause undefined behavior. But that'd probably be a breaking change which would require a major version number bump, so deprecation is absolutely the right thing IMO. And it also sets the stage to get rid of it outright come the next major v…

Not sure if there was nothing post-1.0, but this[0] particular mess was just before the 1.0 release and, at the time, caused a fair bit of chaos. 0. http://cglab.ca/~abeinges/blah/everyone-poops/

Cached version: http://webcache.googleusercontent.com/search?q=cache:cglab.c...

Re: Rust 1.34.0

#98

Post by benesch »

steveklabnik wrote: post #77
benesch wrote: post #73

Earlier quoted context omitted.

Yes, absolutely! (Although note that I'm not the OP.)

Cool. To be clear, I think that it’s maybe not even possible with symbol versioning, because you need more information than that. The compiler has to know “is this function unsafe or not”, for example, not just “does this symbol exist.” I’m not an expert at symbol versioning, so maybe there’s a way to do this I’m not aware of. There’s also other stuff you’d need, too, I believe... but the real point is, you cannot do…

Yep, definitely. In this specific case of a missing unsafe marker you don’t need symbol versioning at all; you need the stdlib to somehow present two signatures for the same function that the compiler can select between according to the Rust version. It’s only for more complicated cases of API breakage (your function took an i32 but you need to extend it to an i64) that symbol versioning becomes necessary.

And great! All I wanted to point out was that, should the need arise, it is technically possible to tie stdlib function signatures to a particular edition.

Re: Rust 1.34.0

#99

Post by ben0x539 »

> 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 implementing versioning support for git dependencies.

There's many bad things I say about golang, but "I wish this module system additionally required me to host a language-specific package repository" is not one of them.

Re: Rust 1.34.0

#100

Post by Waterluvian »

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…

I dunno. The worst part of Go in my opinion is that disaster that is packaging. I like rust because there isn't eleventy ways to do things like that. I can certainly see your perspective. I'm just of the other opinion.
Post reply on HN