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

My “grand vision” for Rust

blog.yoshuawuyts.com

Post reply on HN
Print view View original

51–60 of 323 posts

Re: My “grand vision” for Rust

#51

Post by aw1621107 »

pjmlp wrote: post #48
SkiFire13 wrote: post #45

Earlier quoted context omitted.

> requires full access to source code What do you mean? Editions don't require full access to source code. Rust in general relies heavily on having access to source code, but that has nothing to do with how editions work

Yes they do, when mixing crates from various editions and how changes interact together.

> when mixing crates from various editions and how changes interact together.

Could you elaborate more on this? It's not obvious to me right now why (for example) Crate A using the 2024 edition and Crate B using the 2015 edition would require both full access to both crates' source beyond the standard lack of a stable ABI.

Re: My “grand vision” for Rust

#52

Post by pjmlp »

aw1621107 wrote: post #51
pjmlp wrote: post #48

Earlier quoted context omitted.

Yes they do, when mixing crates from various editions and how changes interact together.

> when mixing crates from various editions and how changes interact together. Could you elaborate more on this? It's not obvious to me right now why (for example) Crate A using the 2024 edition and Crate B using the 2015 edition would require both full access to both crates' source beyond the standard lack of a stable ABI.

Because in order to have standard library breaking changes across editions, if those types are exposed in the crate public types, or change their semantics across editions, the compiler has to be able to translate between them when generating code.

See the Rust documentation on what editions are allowed to change, and the advanced migration guide on examples regarding manual code migration.

Not so much what has happened thus far, rather the limitations imposed in what is possible to actually break across editions.

Re: My “grand vision” for Rust

#53

Post by [deleted] »

pkal wrote: post #44

From the historical sources I could find online, it appears that Rust's borrow system was independently invented, or at least they don't mention linear logic or anything substructural. This is kind of interesting to me, especially given the reactions in this thread, and ties into the general difficulty of PL research to find acceptance among practitioners, especially when presented by researchers (which I think is re…

[deleted]

Re: My “grand vision” for Rust

#54

Post by patrick451 »

zozbot234 wrote: post #9
ozgrakkurt wrote: post #4

This sounds insane at this point. The language already has too many features. Would be cool if all these people with amazing visions could move it elsewhere. Rust is fast tracking being as bad as c++ in terms of just garbage in it. IMO the worst thing about c++ isn't that it is unsafe but it is extemely difficult to learn to a satisfying degree. This is already kind of feels true for Rust and it will be surely true i…

> The language already has too many features. That's actually the point. Many of these additions can be phrased as unifying existing features and allowing them to be used in previously unusable ways and contexts. There's basically no real increase in user-perceived complexity. The Rust editions system is a key enabler of this, and C++ has nothing comparable.

This comparison is useless until rust commits to a stable ABI.

Re: My “grand vision” for Rust

#55

Post by Rusky »

pjmlp wrote: post #52
aw1621107 wrote: post #51

Earlier quoted context omitted.

> when mixing crates from various editions and how changes interact together. Could you elaborate more on this? It's not obvious to me right now why (for example) Crate A using the 2024 edition and Crate B using the 2015 edition would require both full access to both crates' source beyond the standard lack of a stable ABI.

Because in order to have standard library breaking changes across editions, if those types are exposed in the crate public types, or change their semantics across editions, the compiler has to be able to translate between them when generating code. See the Rust documentation on what editions are allowed to change, and the advanced migration guide on examples regarding manual code migration. Not so much what has happe…

Or put another way, a hypothetical feature that you made up in your head is the thing that requires source access. Editions do not let you change the semantics of types.

To be fair, Rust tooling does tend toward build-from-source. But this is for completely different reasons than the edition system: if you had a way to build a crate and then feed the binary into builds by future compilers, it would require zero additional work to link it into a crate using a different edition.

Re: My “grand vision” for Rust

#56

Post by Ygg2 »

Animats wrote: post #24

This may be too much advanced type theory for a useful language. You can go all the way to formal verification. This is not enough for that. Or you can stop at the point all memory error holes have been plugged. That's more useful. You can go way overboard with templates/macros/traits/generics. Remember C++ and Boost. I understand that Boost is now deprecated. I should work some more on my solution to the back-refere…

> This may be too much advanced type theory for a useful language.

Maybe but:

- Move fixes Pin

- Linear types, prevent memory leaks

- potentially effects simplify so many things

Each of these functionalities unlock capabilities people have complained about Rust. Namely async, gen blocks, memory leaks.

Re: My “grand vision” for Rust

#57

Post by Ygg2 »

pjmlp wrote: post #3

Reposting my comment from Reddit, I had some Scala 3 feelings when reading the vision, I hope Rust doesn't gets too pushy with type systems ideas. That is how we end with other ecosystems doubling down in automatic memory management with a good enough ownership model for low level coding, e.g. Swift 6, OxCaml, Chapel, D, Linear Haskel, OCaml effects,... Where the goal is that those features are to be used by experts,…

Doubt Rust will ever get to implicit hell of Scala 2.

If for anything, Rust isn't married to C as Scala is to Java.

Re: My “grand vision” for Rust

#58

Post by Rusky »

satvikpendem wrote: post #21
jcranmer wrote: post #19

Earlier quoted context omitted.

You're not wrong here. Not that I'm entirely up-to-speed on all of the deep Rust discussions, but the sense I have of the language evolution is that while there is definitely a loud contingent of people pushing for a lot of the complexity of full effect systems or linear types, these sorts of proposals aren't actually all that likely to actually move forward in the language. (I should note that of all of the features…

Yoshua works directly on developing the language, and mentions he is working on these features specifically (he is part of the effects initiative), I'm not sure you won't see these features in Rust.

Yoshua is part of the "loud contingent" being described. He's not on the lang team, and he's been "working on" things like keyword generics for years without any indication that they are going to make it into the language.

Re: My “grand vision” for Rust

#59

Post by dnautics »

Animats wrote: post #24

This may be too much advanced type theory for a useful language. You can go all the way to formal verification. This is not enough for that. Or you can stop at the point all memory error holes have been plugged. That's more useful. You can go way overboard with templates/macros/traits/generics. Remember C++ and Boost. I understand that Boost is now deprecated. I should work some more on my solution to the back-refere…

I'm not 100% convinced that "plugging memory error holes" was right at the compiler level.

Currently building out clr, which uses a heuristic (not formal verification) method for checking soundness of zig code, using ~"refinement types". In principle one could build a more formal version of what I'm doing.

https://github.com/ityonemo/clr

Re: My “grand vision” for Rust

#60

Post by Pedro_Ribeiro »

zamalek wrote: post #42

I'm terrified by the notion of try fns. Are we getting exceptions (and therefore losing one of rust's greatest features)?

Isn't his point exactly that we don't want to have too many function colors and instead want a generic way of declaring side effects so people can do what they want (be it try fns, IO, async, etc..., no panicking)?
Post reply on HN