As a library maintainer I need to make the choice of which version to target.

It's easy to accidently use features of a recent rust version, as you can see in this example:

https://github.com/mkmik/slyce/issues/17

I could work around this issue and pin the rustc version in the CI system to avoid regressions, but is it worth the effort since it's likely that this particular user will eventually depend on another library that uses a feature of >1.43 and thus eventually give in and use rustup? I want to be helpful towards users of my library, but I wonder if the most rational choice is to encourage users to upgrade the toolchain more liberally.

This has the funny effect of posts getting harder to write as time goes on; we have less releases with big, important features, and more releases with "tons of bugfixes and some minor improvements."

I think the downvotes are because both the example and the generalized statement that C# is "noticeably faster" is bait / lazy.

If you're familiar with say, `Vec<u8>` and `[u8]`, `String` and `str` are basically the same except they are contractually valid UTF bytes. So just like you can `push` and `extend` to a `Vec`, you can do the same to a `String`.

With regard to generic type parameters, if you want to code in Java or Go style, you can use dynamic dispatch trait objects to remove type parameters.

The other ways are more "advanced", for when you're dealing with (for example) potentially unsafe coercions or you don't want to rely on inference for some reason.

Would have been easier to implement with a copy constructor I guess. Why not implicitly clone in some cases (since classes like String gets used so frequently).

I was imagining something spatial, a drawing, a map, something that makes it possible to overview and place the new features in context with each other. Probably nothing that can be realized.

Rust is much lower level and makes very different tradeoffs. Sometimes for the sake of performance, sometimes to enhance code readability.

But most of the design decisions are there for a reason, and are good choices.

Simple types (that are small and can be trivially memcopied) can implement the `Copy` trait, which makes cloning transparent. For other types, the `Clone` trait is there with `.clone()`. Having expensive copies be explicit is a intentional design decision.

For value conversions, the `Into/From` and `TryInto/TryFrom` traits make conversions a (usually type inferred) function call (.into(), .try_into()), which is really quite convenient, though at the expense of readability.

Regarding strings: they are are definitely complicated and sometimes awkward in Rust. But I'd argue that strings are inherently complicated. Most languages hide this complexity by just allocating and doing everything on the heap, which is not great in a language that values performance and wants to support environments without allocators.

This is already the case. Built-in types that are simple enough to be copied implicitly already are (roughly: those which don't manage any memory or other resources), and you can enable this for your own types with `#[derive(Copy)]`, as long as they are composed only of implicitly copyable types.

    #[derive(Copy)]
    struct S {
        x: i32,
        y: usize,
        z: Option<Result<(), ()>>,
    }

    fn f(x: S) {
        // ...
    }

    fn main() {
        let s = S { x: 0, y: 0, z: Some(Ok(())) };
        f(s);
        f(s);
    }

The Rust way of forcing non-trivial clones to be explicit is much better than C++ IMO, where someone forgetting a `&` or an `std::move` somewhere can cause an innocuous-looking function call to be arbitrarily slow.

In C# there are not implicit copies either (except of value types), because more complex types in C# are accessed via pointers to garbage-collected heap objects. Rust doesn't have a garbage collector, though.

Rust doesn't deal with "prone to misuse" but "provably safe, else explicitly unsafe, or made safe by the programmer through wrapping code." Global variables are inherently unsafe and need to be wrapped as such.

Of course you'll need global state at some point in your life. What Rust does is yell to remind you that it isn't thread safe.

If you stop thinking about a Rust program as a script where the runtime figures the hard stuff out for you, then these design decisions make a lot more sense. You have a lot more knobs to twiddle than in C#, no garbage collector, and no runtime. The compiler is pretty smart, but it tells you the things it knows and you're responsible for working around the limitations to create sound programs that the compiler can optimize.

> Why not hide it a bit by letting the implicit copy to happen to simpler structures ?

This is the Copy trait.

> Why no love for inheritance

There are a variety of reasons, but one interesting one is that inheritance and strong type inference have issues, and we have very strong type inference. Beyond that, there are various other reasons, but what it really comes down to is that there's just not a ton of pressure to actually implement it; it's not enough of an impediment for Rust users to justify adding it. Most requests come from people who do not write Rust, and once people get into Rust and how it works, they don't seem to need it much anymore.

This is of course very general and there are some people who love it and want it badly anyway, but "some people exist who want this feature" is not enough to make it happen. Rust already has a lot of features, and some people say too many. We have to be careful here.

> Why no love for global/static variables ?

What does "love" mean? Rust absolutely supports these.

So there's a lot to unpack here, but implicit copies do happen - if it's a copy-able data structure. Strings are huge, so no implicit copy. As far as `&` being too much to identify references vs not, i'm not sure how it could be made any shorter to identify a reference. You're already, commonly, hiding the lifetime associated with that, so it's really `&'a str`, but Rust lets you drop the `'a` most of the time.

Considerable effort has been put into easing the language and lowering syntax. What's left is essentials imo. I _want_ to see when something is a reference. I _want_ to know generic types. etcetc.

> -> Why no love for inheritance? :) - it makes certain patterns easier to implement

I can't speak much here. I've been using Go and Rust for so long i've forgotten what classical inheritance is actually useful for haha. The Go/Rust pattern of Structs, shared behavior, etc cover all use cases for me. i don't find myself missing something, fwiw, but i can't speak to which is "best".

> -> Why no love for global/static variables ? I know they are prone to be misused but some patterns like singleton really need a lot of shortcuts to implement. And there will always be some cases where you want to keep variables with static and global scope

You can have global variables fwiw. Granted, i use `lazy_static` which simplifies it a bit, but there's nothing i'm aware of which prevents this pattern. I've typically just used it in tests though. Globals are the devils candy ;)

  let foo1: String = "bar".into();
  let foo2 = core::convert::Into::into::<String>("bar");

    let my_str = "Hello".to_owned();
    match &my_str {
        "Hello" => (),
        _ => ()
    }