5 ms·

Such a boring release. That's why I love Rust.

• Twisol 8y ago
  For the most part, that's true. But I am so excited that custom Cargo registries have finally landed!
• pjmlp 8y ago
  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).
  • steveklabnik 8y ago
    Binary deps are on the Cargo team’s plans for the year, and compile times are always a focus. Working on it!
    • pjmlp 8y ago
      Looking forward to them. :)
  • whatshisface 8y ago
    We will soon have async/await syntax which will replace some of the use case of callbacks, and (I assume) reduce the borrow bookkeeping tedium.
    • pjmlp 8y ago
      I don't think it covers GUI callbacks like on Gtk-rs, accessing internal widget data.
      • bbatha 8y ago
        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.
        • steveklabnik 8y ago
          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.
          • bbatha 8y ago
            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.
  • servilio 8y ago
    Why binary dependencies, what for?
    • pjmlp 8y ago
      Compile speed, not compiling the same dependencies all over the time. Many commercial use cases require distribution of binary libraries, Rust community might care about winning those customers, or just let them go and leave them to keep using the languages that fulfil such use cases.
      • MaulingMonkey 8y ago
        And if you have to drop down to looking at the disassembly, distributing binaries helps ensure everyone's looking at the same disassembly. Reasons for this include investigating codegen bugs, figuring out optimization issues, ensuring functions involved in cryptography aren't leaking information through timing side channels, etc...
      • servilio 8y ago
        > Compile speed, not compiling the same dependencies all over the time. Sounds like caching these would be a simpler but solution. > Many commercial use cases require distribution of binary libraries [...] Good use case, and in this case another cache would solve the issue as well. Defining a protocol for binary caches and being able to add your own could solve this very well. The same solution could help solve the previous one too. BTW, if you are in either case, have you looked into Nipxkgs[1]? They might be able to do both, the basic capabilities are there, not sure if the Rust infrastructure[2] already provides it. [1] https://nixos.org/nixpkgs https://nixos.org/nixpkgs [2] https://nixos.org/nixpkgs/manual/#users-guide-to-the-rust-infrastructure https://nixos.org/nixpkgs/manual/#users-guide-to-the-rust-in...
  • eikenberry 8y ago
    > 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.
    • steveklabnik 8y ago
      We can only speculate about the lower bounds of compile times, but making things faster takes a lot of work. Rustc is a huge codebase, and making general leaps requires large architectural changes. We’ll just keep chipping away. It’ll take some time. There has been a lot of progress, it’s just been slow and steady. For example, since the first of 2018: https://perf.rust-lang.org/compare.html?start=2018-01-01&end=&stat=wall-time https://perf.rust-lang.org/compare.html?start=2018-01-01&end...
    • burntsushi 8y ago
      > 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 maxmem 702 MB faults 0 That's a >3x wall-clock speedup over the past 2.5 years on a cold start. That's pretty good.
      • Thaxll 8y ago
        The memory doubled?
        • BalinKing 8y ago
          Not sure if it’s the case here, but decreasing time complexity can often require a corresponding increase in space complexity.
        • pcwalton 8y ago
• Datenstrom 8y ago
  Personally I am very excited about TryFrom, I have been waiting for that forever it seems.
  • lewisinc 8y ago
    Agreed! I definitely have a handful of hand-rolled `try_from` definitions that I'm excited to erase from existence.