Thoughts on Backward Compatibility

Guillaume Piolat first.name at gmail.com
Mon Feb 19 23:40:41 UTC 2024


On Friday, 16 February 2024 at 01:44:51 UTC, Paul Backus wrote:
>
> Why might that be? Glancing over some of the Rust release notes 
> myself, I notice a couple of trends.
>
> 1. Many of the changes are low-impact and provide a clear 
> migration path for existing code.
> 2. Many of the changes involve fixing holes in Rust's 
> memory-safety checks.
>

So here is my first impression of Rust, I had to build a 
measuring tool today and the only workable one happened to be in 
Rust.

Remarks:
   - "rustup" can be get with a curl | sh commandline... it's 
nice, it means it's a few less click to get, and you can't really 
have a bad rustup version anyway.
   - I had to install various nightlies using "rustup toolchain", 
which is an "edition" + a target. A bit like Flutter does.
   - cargo is essentially like dub, I saw no big difference here. 
The binaries are annoyingly deep in sub-directories to find. One 
letter shortcuts useful.
   - code didn't build (1000+ packages!), I had to fix the 
dependencies in ~/.cargo to proceed. I must say it all build 
pretty fast.
     Now, for build errors, there were an enormous wall of text 
(almost too much) explaining how to fix the issues, so despite my 
ignorance of the language it was possible to continue.
   - libraries don't looks as friendly without the GC, for example 
CLAP vs a D argument parser.

Pros:
I think rustup is a big win here, a principled approach to 
install this or that version of D for this or that platform would 
perhaps be a good idea, it is similar to DVM, but DVM isn't much 
used.

Cons:
A bit of a wordey experience, and necessity to use nightlies for 
features that are in nightly since 3 years (will they get 
merged?). Unnatural package count.


More information about the Digitalmars-d mailing list