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