undefined | Better HN

0 pointsExpurple8mo ago0 comments

> Not really, because the crates they depend on cannot expose APIs with semantic changes across versions.

Not sure what you're talking about. Any specific examples?

> Also it requires everything to be compiled with the same compiler, from source code.

It's not related to editions at all. It's related to not having an implicit stable ABI.

It's possible have a dynamic Rust library that exposes a repr(C) interface, compile it into an .so using one version of the compiler, and then compile the dependent "pure Rust" crates using another compiler that's just going to read the metadata ("headers") of that library and link the final binary together. Same as in C and C++. You just can't compile any Rust code into a stable dynamic library, by defalut. (You can still always compile into a dylib that needs a specific compiler version)

0 comments

pjmlp8mo ago

To avoid repeating myself, here is an example from 4 years ago.

https://news.ycombinator.com/item?id=26966151

ExpurpleOP8mo ago

As the other commenter responded there, your example isn't about editions at all. It's about mixing ABIs and mixing multiple versions of the language runtime. Those are entirely separate issues.

You're correct that the possible changes in editions are very limited. But editions don't hinder interoperability in any way. They are designed not to. Today, there are no interoperability problems caused by editions specifically.

> compromises will be required, specially regarding possible incompatible semantic differences across editions.

That's just an assumption in your head. 4 editions later, it still hasn't manifested in any way.

pjmlp8mo ago

4 editions later, Rust is yet to be used at the scale of C and C++ across the industry, my point on the comment is how editions will look like after 50 years of Rust history.

ABIs and multiple versions of the language runtime, are part of what defines a language ecosystem, hence why editions don't really cover as much as people think they do.

1 more reply

adastra228mo ago

As the response to that comment points out, you are confusing editions for ABI changes. Different editions are purely a source-level change in the language. All editions are ABI-compatible.

pjmlp8mo ago

Not really, because one thing that apparently I haven't gotten across is that they don't cover semantic changes, only grammar ones for the most part.

What is the compiler supposed to generate if code from edition X calls code in edition X + 10, with a lambda written in X + 5, expecting using a specific language construct that has changed semantics across editions, maybe even more than once?

Everything compiling from source, same compiler.

2 more replies

j / k navigate · click thread line to collapse

0 pointsExpurple8mo ago0 comments

> Not really, because the crates they depend on cannot expose APIs with semantic changes across versions.

Not sure what you're talking about. Any specific examples?

> Also it requires everything to be compiled with the same compiler, from source code.

It's not related to editions at all. It's related to not having an implicit stable ABI.

0 comments

pjmlp8mo ago

To avoid repeating myself, here is an example from 4 years ago.

https://news.ycombinator.com/item?id=26966151

ExpurpleOP8mo ago

As the other commenter responded there, your example isn't about editions at all. It's about mixing ABIs and mixing multiple versions of the language runtime. Those are entirely separate issues.

> compromises will be required, specially regarding possible incompatible semantic differences across editions.

That's just an assumption in your head. 4 editions later, it still hasn't manifested in any way.

pjmlp8mo ago

4 editions later, Rust is yet to be used at the scale of C and C++ across the industry, my point on the comment is how editions will look like after 50 years of Rust history.

ABIs and multiple versions of the language runtime, are part of what defines a language ecosystem, hence why editions don't really cover as much as people think they do.

1 more reply

adastra228mo ago

As the response to that comment points out, you are confusing editions for ABI changes. Different editions are purely a source-level change in the language. All editions are ABI-compatible.

pjmlp8mo ago

Not really, because one thing that apparently I haven't gotten across is that they don't cover semantic changes, only grammar ones for the most part.

Everything compiling from source, same compiler.

2 more replies

j / k navigate · click thread line to collapse