4 ms·

I'm a C# dev main and love spans. I understand it's not in the same realm as Rust, but how comparable is this to some of the power that Rust gives you?

afdbcreid 1y ago
It's a taste. C# allows the more common patterns, but Rust allows much more. For example, Rust allows the equivalent of storing `Span<T>` (called slice in Rust) everywhere (including on the heap, although this is rare).
- Rohansi 1y ago
  The restriction in C# comes from its ability to reference stack allocated memory. I'm not familiar with Rust but it probably figures it out based on the lifetime of T.
  - Measter 1y ago
    It's not the lifetime of T, but the lifetime of whatever is storing T.
- sedatk 1y ago
  C# has a separate heap storable span equivalent called Memory<T>.
  - afdbcreid 1y ago
    AFAIK it's less efficient though.
    - sedatk 1y ago
      Yes, but it can still beat copying.
whizzter 1y ago
I think the main differentiator is this: C# is GC'd, the system will protect memory in use and while it can allow things like Span<>, Memory<>,etc there are some constraints due to sloppy lifetime reasoning but in general "easy" usage since you do not need to care about lifetime. Rust has lifetime semantics built down to the core of the language, the compiler will know much better about what's safe but also forbid you early from things that are safe but not provable (they're improving the checkers based on experience though), due to it's knowledge it will be better at handling allocations more exactly. Personally as someone with an assembly, C,C++,etc background, while I see the allure of Rust and do see it as a plus if less experienced devs that really need perf go for Rust for critical components, and thinking I'm going to try to do some project in Rust... I've so far not seen a project where the slight performance improvement of Rust will outweight the "productivity" gain from being able to do a bit "sloppy" connections that C# allows for.
- int_19h 1y ago
  C# ref types also have a form of borrow checker that ensures that they never outlive whatever they point to. It's a more simplified version than Rust because lifetimes are always inferred.
  - whizzter 1y ago
    Yeah, ran into one of those rules the other week. Was kinda annoying since it was a very theoretical issue compared to the real case I had that was completely safe.
    - neonsunset 1y ago
      [dead]
    - int_19h 1y ago
      `unsafe` exists for stuff like that, although I'm not so sure that such tricks are GC-safe.
      - 1y ago
louthy 1y ago
This should help: “A comparison of Rust’s borrow checker to the one in C#” https://em-tg.github.io/csborrow/ https://em-tg.github.io/csborrow/
osigurdson 1y ago
For many projects, the GC is a complete non-issue and you never think about it. For some it is a huge issue and you are always thinking about this ghost in the background and how to craft things so that the ghost doesn't haunt you. If you always have to think about it like this you are probably better off using a non-GCed language.

afdbcreid 1y ago

It's a taste. C# allows the more common patterns, but Rust allows much more. For example, Rust allows the equivalent of storing `Span<T>` (called slice in Rust) everywhere (including on the heap, although this is rare).

Rohansi 1y ago
The restriction in C# comes from its ability to reference stack allocated memory. I'm not familiar with Rust but it probably figures it out based on the lifetime of T.
- Measter 1y ago
  It's not the lifetime of T, but the lifetime of whatever is storing T.
sedatk 1y ago
C# has a separate heap storable span equivalent called Memory<T>.
- afdbcreid 1y ago
  AFAIK it's less efficient though.
  - sedatk 1y ago
    Yes, but it can still beat copying.

whizzter 1y ago

I think the main differentiator is this: C# is GC'd, the system will protect memory in use and while it can allow things like Span<>, Memory<>,etc there are some constraints due to sloppy lifetime reasoning but in general "easy" usage since you do not need to care about lifetime. Rust has lifetime semantics built down to the core of the language, the compiler will know much better about what's safe but also forbid you early from things that are safe but not provable (they're improving the checkers based on experience though), due to it's knowledge it will be better at handling allocations more exactly. Personally as someone with an assembly, C,C++,etc background, while I see the allure of Rust and do see it as a plus if less experienced devs that really need perf go for Rust for critical components, and thinking I'm going to try to do some project in Rust... I've so far not seen a project where the slight performance improvement of Rust will outweight the "productivity" gain from being able to do a bit "sloppy" connections that C# allows for.

int_19h 1y ago
C# ref types also have a form of borrow checker that ensures that they never outlive whatever they point to. It's a more simplified version than Rust because lifetimes are always inferred.
- whizzter 1y ago
  Yeah, ran into one of those rules the other week. Was kinda annoying since it was a very theoretical issue compared to the real case I had that was completely safe.
  - neonsunset 1y ago
    [dead]
  - int_19h 1y ago
    `unsafe` exists for stuff like that, although I'm not so sure that such tricks are GC-safe.
    - 1y ago

louthy 1y ago

This should help: “A comparison of Rust’s borrow checker to the one in C#” https://em-tg.github.io/csborrow/ https://em-tg.github.io/csborrow/

osigurdson 1y ago

For many projects, the GC is a complete non-issue and you never think about it. For some it is a huge issue and you are always thinking about this ghost in the background and how to craft things so that the ghost doesn't haunt you. If you always have to think about it like this you are probably better off using a non-GCed language.