5 ms·

Sorry to pull the rug out from under ya'll like this but that article was a couple years old, so I gave it a once-over pass to update it. Mainly the "No hidden

Sorry to pull the rug out from under ya'll like this but that article was a couple years old, so I gave it a once-over pass to update it. Mainly the "No hidden allocations" section is rewritten. You can see the full commit diff here: https://github.com/ziglang/www.ziglang.org/commit/bede1e57b6831a740211b03344889a78e9ee2885 https://github.com/ziglang/www.ziglang.org/commit/bede1e57b6...

dralley 6y ago
It'd be great to include some information about the awesome cross-compilation support! Thanks for all of your work, it's great.
Ericson2314 6y ago
There's many things you do that I like, but Rust's bad choices about allocation are also almost all library not language mistakes.
- aidenn0 6y ago
  You only get one chance to omit something from the standard library. After that, you're stuck with it forever.
  - lilyball 6y ago
    Rust has “Editions”, which are points where they can make breaking changes as programs and crates (libraries) have to opt-in to the new edition, and you can mix crates from different editions. So if they need to make backwards-incompatible changes in order to add allocator support, they can do this in an edition.
    - dralley 6y ago
      To the language, but not to the standard library. The standard library is eternal.
      - deleted 6y ago
        [deleted]
      - varajelle 6y ago
        One can still deprecate things
    - pjmlp 6y ago
      While I am on the Rust side on this, I am not sold out on mixing crates with different editions, because I believe it won't work at scale in typical enterprise contexts. Meaning, having binary crates compiled with different epochs, and then passing data and closures across crate public functions, specially using as input data from modern ones into the older ones. With the language evolution it won't be possible to keep semantic changes to work as expected, or if the runtime requirements have changed, that linking everything together will still work as expected. To me epochs seem to only work when using a single compiler, compiling all crates from scratch, with is nice, but not what enterprise C, C++, Java, .NET code looks like, and any new language being adopted is expected to play the same game. Hence why Apple took such a big effort to make Swift ABI being able to deal with language updates.
      - fluffything 6y ago
        Editions only support syntactic changes, so what you are afraid of cannot happen. We mix editions in >1000 crate projects every day just fine, and we are sure it will work with all future editions.
        pjmlp 6y ago
        Which just reinforces my opinion about them. How are the editions going to help when semantic changes do eventually come up in future Rust versions?
        lilyball 6y ago
        If future Rust versions do make semantic changes to existing language constructs, that will presumably only apply to crates built with the new edition, and crates built with the old will get the old semantics. If we’re talking ABI-level stuff, that doesn’t require an edition because you build all your crates with the same compiler, so it can use a consistent ABI. Swift’s ABI stability has nothing to do with semantic changes and everything to do with they wanted binary compatibility, so they could start using Swift in the system frameworks that your app links against.

dralley 6y ago

It'd be great to include some information about the awesome cross-compilation support! Thanks for all of your work, it's great.

Ericson2314 6y ago

There's many things you do that I like, but Rust's bad choices about allocation are also almost all library not language mistakes.

aidenn0 6y ago
You only get one chance to omit something from the standard library. After that, you're stuck with it forever.
- lilyball 6y ago
  Rust has “Editions”, which are points where they can make breaking changes as programs and crates (libraries) have to opt-in to the new edition, and you can mix crates from different editions. So if they need to make backwards-incompatible changes in order to add allocator support, they can do this in an edition.
  - dralley 6y ago
    To the language, but not to the standard library. The standard library is eternal.
    - deleted 6y ago
      [deleted]
    - varajelle 6y ago
      One can still deprecate things
  - pjmlp 6y ago
    While I am on the Rust side on this, I am not sold out on mixing crates with different editions, because I believe it won't work at scale in typical enterprise contexts. Meaning, having binary crates compiled with different epochs, and then passing data and closures across crate public functions, specially using as input data from modern ones into the older ones. With the language evolution it won't be possible to keep semantic changes to work as expected, or if the runtime requirements have changed, that linking everything together will still work as expected. To me epochs seem to only work when using a single compiler, compiling all crates from scratch, with is nice, but not what enterprise C, C++, Java, .NET code looks like, and any new language being adopted is expected to play the same game. Hence why Apple took such a big effort to make Swift ABI being able to deal with language updates.
    - fluffything 6y ago
      Editions only support syntactic changes, so what you are afraid of cannot happen. We mix editions in >1000 crate projects every day just fine, and we are sure it will work with all future editions.
      - pjmlp 6y ago
        Which just reinforces my opinion about them. How are the editions going to help when semantic changes do eventually come up in future Rust versions?
        lilyball 6y ago
        If future Rust versions do make semantic changes to existing language constructs, that will presumably only apply to crates built with the new edition, and crates built with the old will get the old semantics. If we’re talking ABI-level stuff, that doesn’t require an edition because you build all your crates with the same compiler, so it can use a consistent ABI. Swift’s ABI stability has nothing to do with semantic changes and everything to do with they wanted binary compatibility, so they could start using Swift in the system frameworks that your app links against.