12 ms·

Rust 1.71.0

280 points by mbStavola 3y ago

dagmx 3y ago
Debugger visualization is a really great idea. I hadn’t thought of using attribute annotation to do it but now I’m wishing more languages had that.
- jauntywundrkind 3y ago
  Do any other languages have anything like this debugger_visualizer attribute?
  - dagmx 3y ago
    Not that I know of. But I’d certainly like to know that I missed it
  - colejohnson66 3y ago
    C# has the `DebuggerDisplay` attribute: https://learn.microsoft.com/en-us/visualstudio/debugger/using-the-debuggerdisplay-attribute?view=vs-2022 https://learn.microsoft.com/en-us/visualstudio/debugger/usin...
    - mihular 3y ago
      Yes and much more like DebuggerVisualizerAttribute which allows you to present data in any possible way. https://learn.microsoft.com/en-us/visualstudio/debugger/create-custom-visualizers-of-data?view=vs-2022 https://learn.microsoft.com/en-us/visualstudio/debugger/crea...
  - klysm 3y ago
    I guess repr is kind of similar in python but not really
    - yencabulator 3y ago
      Python's repr is Rust's impl Debug for Foo
  - fsloth 3y ago
    A slightly different thing - Visual Studio allows you to create custom visualizations for any live debug data. This is absolutely wonderful.
  - scottlamb 3y ago
    One of the nice things about Rust's RFC process for new features is they answer questions like this: https://rust-lang.github.io/rfcs/3191-debugger-visualizer.html#prior-art https://rust-lang.github.io/rfcs/3191-debugger-visualizer.ht... edit: actually, I guess that focuses more on the debugger side, and less on the language side, so not a great answer to your question.
  - mark_undoio 3y ago
    Not exactly but for shared libraries in general it's possible to ship some accompanying Python that will get installed and automatically loaded by GDB. You can even embed that Python script within the shared object using some scary ELF tricks - I was surprised, to say the least, to discover this is supported.
  - ojosilva 3y ago
    Perl has Smart::Comments, original work by the brilliant Damian Conway. https://metacpan.org/pod/Smart::Comments https://metacpan.org/pod/Smart::Comments
armchairhacker 3y ago
#[debug_visualizer] seems like it will be very useful. One of the current issues with Rust (and a place where C++ is still better) is debugging. Granted, I end up needing to debug Rust code much less often than C++ code, but it would still be nice to actually call rust functions in IntelliJ (and it seems there's limited support in gdb and lldb), and view data-structures like maps opaquely instead of just their complex internals.
- mark_undoio 3y ago
  I'm a debugger specialist, not a Rust specialist - but I'm surprised the experience of viewing data structures is not better for you. What platform / debugger are you on? I'd expect the GDB pretty-printers (which from the article it looks like Rust has been shipping by default for the standard library) to be taking care of this relatively well - e.g. looking at https://github.com/rust-lang/rust/pull/72357 https://github.com/rust-lang/rust/pull/72357 it appears that `HashMap` and `HashSet` have printers. (Raw C++ data structures without some form of pretty printing are also incomprehensible for normal development - and I'd be surprised if third party libraries were particularly good at shipping pretty printers, though I may be wrong!)
  - JakobH 3y ago
    I love debugging, how do I go deeper in the art of debugging?
    - jackbracken 3y ago
      Release more bugs
    - wiz21c 3y ago
      per-bugging or re-bugging is the way
    - mark_undoio 3y ago
      If you use GDB, I recommend checking out the official documentation: https://sourceware.org/gdb/current/onlinedocs/gdb.html/ https://sourceware.org/gdb/current/onlinedocs/gdb.html/ It's quite hard work sometimes - there's a lot in there - but the capabilities available are amazing and it's well worth nosing around. I also recommend just hitting TAB a lot and seeing what commands are suggested. Then use the "help"command to find out more. My employer also hosts some articles that digest some knowledge we've gained into a more palatable form: https://undo.io/resources/gdb-watchpoint/ https://undo.io/resources/gdb-watchpoint/
swader999 3y ago
I write billing apps because I'm a masochist and feel there is deeper meaning to be gained through suffering. Lot of data and rules to process. Torn between learning Go or Rust next.
- brink 3y ago
  Mostly depends on how ambitious you're feeling, imo. fwiw - I learned Rust, was painful at first, but now I love it.
  - swader999 3y ago
    From what I've read, it seems like if you can learn Rust, go would be a quick afterthought to pick up. Just not sure if it was my own money for dev expenses if I would choose it.
    - eYrKEC2 3y ago
      That is very fair. I was useless the first month of Rust. I would say that new rust devs are basically in training and unavailable for ~4 weeks. Rust mastery takes much longer than that, of course. However, the type checking in Rust is fantastic. The confidence in correctness that you have when it is complete is much higher than many other languages.
    - masklinn 3y ago
      > Just not sure if it was my own money for dev expenses if I would choose it. Use case would probably be a major factor in the decision e.g. picking up rust from scratch to write a basic network service would probably be stupid unless it had very strict requirements known in advance (and even then you might want to write it in go anyway in case that works out or to quickly uncover issues you’d hadn’t predicted). If you know in advance you have very strict resource constraints however, or you really need the reliability (of extensively encoding things in the typesystem), or you’re writing native extensions (python + rust via pyo3 is great, python + go is something I’d avoid unless the entire solution already existed in Go and I could expose it to python over a pipe), etc… then the investment would likely be more worth it. Basically, how much return would you expect, Go requires very little investment, Rust a lot more.
epage 3y ago
From cargo's changelog [0] > Automatically inherit workspace fields when running `cargo new`/`cargo init`. #12069 [1] imo I think this is a big quality of life improvement [0] https://github.com/rust-lang/cargo/blob/master/CHANGELOG.md#cargo-171-2023-07-13 https://github.com/rust-lang/cargo/blob/master/CHANGELOG.md#... [1] https://github.com/rust-lang/cargo/pull/12069 https://github.com/rust-lang/cargo/pull/12069
orra 3y ago
Nice to have the option to unwind across an FFI boundary. It's also good that (in a future release) erroneously unwinding across a C ABI boundary will abort, instead of being undefined behaviour.
revskill 3y ago
I think versioning like 13.07.23 is better. You automatically get: - Minor version upgrade every day. - Major version upgrade every month.
- dagmx 3y ago
  But that forces a very specific schedule on projects and ruins the semver meaning of what a version entails. I really dislike date based versioning unless the major version is year aligned and is truly a big jump forward (like Jetbrains do it). Otherwise how do you know when a breaking change happens? Or if a version is significant or not? With 1.69.1 I know how .1 relates to .69 and to the 1.
  - revskill 3y ago
    No news is good news, so it's fine to upgrade without any changes.
  - aseipp 3y ago
    Calver I think is more useful for applications that get continuously developed and released, honestly. Like, whenever you are using a webapp that is just self-contained thing, semver doesn't necessarily mean much, it basically just boils down to "Big version number bump = more recent." I think this is one of the reasons programmers gets mad at like, Google Chrome or Firefox or whatever about having version number 100, but literally nobody else cares. Version numbers just fundamentally mean something different to engineers who think of "consuming programs" like they do consuming an API, versus a user, who just thinks of it as "Bigger number = more recent = good." > Otherwise how do you know when a breaking change happens? Linux is a good illustrative example of how this works. How do you know when a breaking change in Linux happens? The answer is the developers define a stable boundary (userspace) and stick to it, whether or not they use semver, and the other components are out of scope (kernel APIs). They simply have a different criterion for where the line gets drawn. This makes some people mad and some people happy, but it's not exactly new. Similarly, in most of the calver applications I've seen and used, you typically just don't do huge breaking changes, you just do gradual migrations of existing things, with warnings, rollouts, cutovers, brownouts, etc to control what happens. So the answer is "when do they happen" is "they mostly don't." The release process and guarantees are just different. Same with "is a version significant or not." How do you know if a version of Linux is significant? You go read the release notes. They come out once every 3 months, so you always know when to look. When you do calver based releases, that question just matters a whole lot less in some sense. Did a feature not get in this time by a hair? It will just get in next time, so there's no need to squeeze yourself or sweat bullets about extending your runway. Sometimes a lot of big features land in one release and sometimes they get held back. It's just how it works. I don't think calver is very good for actual programmer-facing APIs, necessarily, but it can work e.g. webapps tend to have different versioning schemes and techniques for REST APIs, so clearly semver isn't the only possible technique. It does help introduce some mechanical semantics that can be tool checked, etc. For Rust that's really useful, but for a lot of cases that isn't so relevant.
n8henrie 3y ago
I'm excited about the array <-> tuple conversion! (At least for small ones.)
qhwudbebd 3y ago
vendor/regex-syntax, vendor/regex-syntax-0.6.26, vendor/regex-syntax-0.6.28, vendor/regex-syntax-0.6.29 vendor/cargo_metadata, vendor/cargo_metadata-0.14.0, vendor/cargo_metadata-0.14.2, vendor/cargo_metadata-0.15.2 vendor/filetime, vendor/filetime-0.2.16, vendor/filetime-0.2.19, vendor/filetime-0.2.20 vendor/parking_lot_core, vendor/parking_lot_core-0.8.5, vendor/parking_lot_core-0.8.6, vendor/parking_lot_core-0.9.4, vendor/parking_lot_core-0.9.6 etc. Lovely.

280 points by mbStavola 3y ago

Debugger visualization is a really great idea. I hadn’t thought of using attribute annotation to do it but now I’m wishing more languages had that.

jauntywundrkind 3y ago
Do any other languages have anything like this debugger_visualizer attribute?
- dagmx 3y ago
  Not that I know of. But I’d certainly like to know that I missed it
- colejohnson66 3y ago
  C# has the `DebuggerDisplay` attribute: https://learn.microsoft.com/en-us/visualstudio/debugger/using-the-debuggerdisplay-attribute?view=vs-2022 https://learn.microsoft.com/en-us/visualstudio/debugger/usin...
  - mihular 3y ago
    Yes and much more like DebuggerVisualizerAttribute which allows you to present data in any possible way. https://learn.microsoft.com/en-us/visualstudio/debugger/create-custom-visualizers-of-data?view=vs-2022 https://learn.microsoft.com/en-us/visualstudio/debugger/crea...
- klysm 3y ago
  I guess repr is kind of similar in python but not really
  - yencabulator 3y ago
    Python's repr is Rust's impl Debug for Foo
- fsloth 3y ago
  A slightly different thing - Visual Studio allows you to create custom visualizations for any live debug data. This is absolutely wonderful.
- scottlamb 3y ago
  One of the nice things about Rust's RFC process for new features is they answer questions like this: https://rust-lang.github.io/rfcs/3191-debugger-visualizer.html#prior-art https://rust-lang.github.io/rfcs/3191-debugger-visualizer.ht... edit: actually, I guess that focuses more on the debugger side, and less on the language side, so not a great answer to your question.
- mark_undoio 3y ago
  Not exactly but for shared libraries in general it's possible to ship some accompanying Python that will get installed and automatically loaded by GDB. You can even embed that Python script within the shared object using some scary ELF tricks - I was surprised, to say the least, to discover this is supported.
- ojosilva 3y ago
  Perl has Smart::Comments, original work by the brilliant Damian Conway. https://metacpan.org/pod/Smart::Comments https://metacpan.org/pod/Smart::Comments

armchairhacker 3y ago

#[debug_visualizer] seems like it will be very useful. One of the current issues with Rust (and a place where C++ is still better) is debugging. Granted, I end up needing to debug Rust code much less often than C++ code, but it would still be nice to actually call rust functions in IntelliJ (and it seems there's limited support in gdb and lldb), and view data-structures like maps opaquely instead of just their complex internals.

mark_undoio 3y ago
I'm a debugger specialist, not a Rust specialist - but I'm surprised the experience of viewing data structures is not better for you. What platform / debugger are you on? I'd expect the GDB pretty-printers (which from the article it looks like Rust has been shipping by default for the standard library) to be taking care of this relatively well - e.g. looking at https://github.com/rust-lang/rust/pull/72357 https://github.com/rust-lang/rust/pull/72357 it appears that `HashMap` and `HashSet` have printers. (Raw C++ data structures without some form of pretty printing are also incomprehensible for normal development - and I'd be surprised if third party libraries were particularly good at shipping pretty printers, though I may be wrong!)
- JakobH 3y ago
  I love debugging, how do I go deeper in the art of debugging?
  - jackbracken 3y ago
    Release more bugs
  - wiz21c 3y ago
    per-bugging or re-bugging is the way
  - mark_undoio 3y ago
    If you use GDB, I recommend checking out the official documentation: https://sourceware.org/gdb/current/onlinedocs/gdb.html/ https://sourceware.org/gdb/current/onlinedocs/gdb.html/ It's quite hard work sometimes - there's a lot in there - but the capabilities available are amazing and it's well worth nosing around. I also recommend just hitting TAB a lot and seeing what commands are suggested. Then use the "help"command to find out more. My employer also hosts some articles that digest some knowledge we've gained into a more palatable form: https://undo.io/resources/gdb-watchpoint/ https://undo.io/resources/gdb-watchpoint/

swader999 3y ago

I write billing apps because I'm a masochist and feel there is deeper meaning to be gained through suffering. Lot of data and rules to process. Torn between learning Go or Rust next.

brink 3y ago
Mostly depends on how ambitious you're feeling, imo. fwiw - I learned Rust, was painful at first, but now I love it.
- swader999 3y ago
  From what I've read, it seems like if you can learn Rust, go would be a quick afterthought to pick up. Just not sure if it was my own money for dev expenses if I would choose it.
  - eYrKEC2 3y ago
    That is very fair. I was useless the first month of Rust. I would say that new rust devs are basically in training and unavailable for ~4 weeks. Rust mastery takes much longer than that, of course. However, the type checking in Rust is fantastic. The confidence in correctness that you have when it is complete is much higher than many other languages.
  - masklinn 3y ago
    > Just not sure if it was my own money for dev expenses if I would choose it. Use case would probably be a major factor in the decision e.g. picking up rust from scratch to write a basic network service would probably be stupid unless it had very strict requirements known in advance (and even then you might want to write it in go anyway in case that works out or to quickly uncover issues you’d hadn’t predicted). If you know in advance you have very strict resource constraints however, or you really need the reliability (of extensively encoding things in the typesystem), or you’re writing native extensions (python + rust via pyo3 is great, python + go is something I’d avoid unless the entire solution already existed in Go and I could expose it to python over a pipe), etc… then the investment would likely be more worth it. Basically, how much return would you expect, Go requires very little investment, Rust a lot more.

epage 3y ago

From cargo's changelog [0] > Automatically inherit workspace fields when running `cargo new`/`cargo init`. #12069 [1] imo I think this is a big quality of life improvement [0] https://github.com/rust-lang/cargo/blob/master/CHANGELOG.md#cargo-171-2023-07-13 https://github.com/rust-lang/cargo/blob/master/CHANGELOG.md#... [1] https://github.com/rust-lang/cargo/pull/12069 https://github.com/rust-lang/cargo/pull/12069

orra 3y ago

Nice to have the option to unwind across an FFI boundary. It's also good that (in a future release) erroneously unwinding across a C ABI boundary will abort, instead of being undefined behaviour.

revskill 3y ago

I think versioning like 13.07.23 is better. You automatically get: - Minor version upgrade every day. - Major version upgrade every month.

dagmx 3y ago
But that forces a very specific schedule on projects and ruins the semver meaning of what a version entails. I really dislike date based versioning unless the major version is year aligned and is truly a big jump forward (like Jetbrains do it). Otherwise how do you know when a breaking change happens? Or if a version is significant or not? With 1.69.1 I know how .1 relates to .69 and to the 1.
- revskill 3y ago
  No news is good news, so it's fine to upgrade without any changes.
- aseipp 3y ago
  Calver I think is more useful for applications that get continuously developed and released, honestly. Like, whenever you are using a webapp that is just self-contained thing, semver doesn't necessarily mean much, it basically just boils down to "Big version number bump = more recent." I think this is one of the reasons programmers gets mad at like, Google Chrome or Firefox or whatever about having version number 100, but literally nobody else cares. Version numbers just fundamentally mean something different to engineers who think of "consuming programs" like they do consuming an API, versus a user, who just thinks of it as "Bigger number = more recent = good." > Otherwise how do you know when a breaking change happens? Linux is a good illustrative example of how this works. How do you know when a breaking change in Linux happens? The answer is the developers define a stable boundary (userspace) and stick to it, whether or not they use semver, and the other components are out of scope (kernel APIs). They simply have a different criterion for where the line gets drawn. This makes some people mad and some people happy, but it's not exactly new. Similarly, in most of the calver applications I've seen and used, you typically just don't do huge breaking changes, you just do gradual migrations of existing things, with warnings, rollouts, cutovers, brownouts, etc to control what happens. So the answer is "when do they happen" is "they mostly don't." The release process and guarantees are just different. Same with "is a version significant or not." How do you know if a version of Linux is significant? You go read the release notes. They come out once every 3 months, so you always know when to look. When you do calver based releases, that question just matters a whole lot less in some sense. Did a feature not get in this time by a hair? It will just get in next time, so there's no need to squeeze yourself or sweat bullets about extending your runway. Sometimes a lot of big features land in one release and sometimes they get held back. It's just how it works. I don't think calver is very good for actual programmer-facing APIs, necessarily, but it can work e.g. webapps tend to have different versioning schemes and techniques for REST APIs, so clearly semver isn't the only possible technique. It does help introduce some mechanical semantics that can be tool checked, etc. For Rust that's really useful, but for a lot of cases that isn't so relevant.

n8henrie 3y ago

I'm excited about the array <-> tuple conversion! (At least for small ones.)

qhwudbebd 3y ago

vendor/regex-syntax, vendor/regex-syntax-0.6.26, vendor/regex-syntax-0.6.28, vendor/regex-syntax-0.6.29 vendor/cargo_metadata, vendor/cargo_metadata-0.14.0, vendor/cargo_metadata-0.14.2, vendor/cargo_metadata-0.15.2 vendor/filetime, vendor/filetime-0.2.16, vendor/filetime-0.2.19, vendor/filetime-0.2.20 vendor/parking_lot_core, vendor/parking_lot_core-0.8.5, vendor/parking_lot_core-0.8.6, vendor/parking_lot_core-0.9.4, vendor/parking_lot_core-0.9.6 etc. Lovely.