4 ms·

> So there is pattern matches, immutability, traits, and so on, in Rust style, but no lifetimes and related syntax. I think C# fits the bill. Pattern matching:

> So there is pattern matches, immutability, traits, and so on, in Rust style, but no lifetimes and related syntax. I think C# fits the bill. Pattern matching: https://docs.microsoft.com/en-us/dotnet/csharp/fundamentals/functional/pattern-matching https://docs.microsoft.com/en-us/dotnet/csharp/fundamentals/... Immutability arrived recently: https://nietras.com/2021/06/14/csharp-10-record-struct/ https://nietras.com/2021/06/14/csharp-10-record-struct/ Traits are different however. The language has interfaces for decades, when used as generic constraints they’re free performance wise i.e. don’t compile into virtual calls (also allows to use interfaces on value types without boxing things into the heap), however it’s impossible to implement traits externally like `impl Interface for Type` in Rust.

grumpyprole 5y ago
F# would fit the bill better I think compared to C#. F# has proper algebraic types like Rust, full pattern matching, immutability by default, less OOP baggage.
- Const-me 5y ago
  I don’t disagree, but some other stuff often used in system and low-level programming is easier to use from C#: stackalloc and unmanaged heap, spans, SIMD intrinsics from System.Runtime.Intrinsics namespace, scalar intrinsics from BinaryPrimitives and BitOperations classes, C interop, threads synchronization, etc.
coldtea 5y ago
>I think C# fits the bill. It should also have the other Rust aspects: LLVM binaries, no MS involved, and so on.
- Const-me 5y ago
  > LLVM binaries I wouldn’t want LLVM, I like JIT. The binaries are CPU and OS agnostic; sometimes I debug C# code on AMD64 Win10 which then runs on Alpine Linux with ARMv7 and ARM64 CPU. It’s relatively easy to generate code in runtime, allows to beat C performance in some cases, and enables good serialization libraries. Binaries are tiny because CIL is more efficient than machine code. In modern .NET startup time is pretty good despite the JIT. Also, on modern hardware you wouldn’t want short-lived processes being launching at kilohertz frequency regardless on the language. Because cache hierarchy, you’d want to reuse RAM pages over time as much as possible. > no MS involved I think after the complete thing is cross platform and open source, MS involvement is not a huge deal anymore.
alkonaut 5y ago
Sadly even in its latest incarnation it doesn’t. It still doesn’t have basic exhaustive pattern matching/sum types. More importantly, even once it gets that, its standard library wasn’t written with them in mind. It gained (value) tuples quite late, so standard library functions still use awkward “out” parameters and so on.

grumpyprole 5y ago

F# would fit the bill better I think compared to C#. F# has proper algebraic types like Rust, full pattern matching, immutability by default, less OOP baggage.

Const-me 5y ago
I don’t disagree, but some other stuff often used in system and low-level programming is easier to use from C#: stackalloc and unmanaged heap, spans, SIMD intrinsics from System.Runtime.Intrinsics namespace, scalar intrinsics from BinaryPrimitives and BitOperations classes, C interop, threads synchronization, etc.

coldtea 5y ago

>I think C# fits the bill. It should also have the other Rust aspects: LLVM binaries, no MS involved, and so on.

Const-me 5y ago
> LLVM binaries I wouldn’t want LLVM, I like JIT. The binaries are CPU and OS agnostic; sometimes I debug C# code on AMD64 Win10 which then runs on Alpine Linux with ARMv7 and ARM64 CPU. It’s relatively easy to generate code in runtime, allows to beat C performance in some cases, and enables good serialization libraries. Binaries are tiny because CIL is more efficient than machine code. In modern .NET startup time is pretty good despite the JIT. Also, on modern hardware you wouldn’t want short-lived processes being launching at kilohertz frequency regardless on the language. Because cache hierarchy, you’d want to reuse RAM pages over time as much as possible. > no MS involved I think after the complete thing is cross platform and open source, MS involvement is not a huge deal anymore.

alkonaut 5y ago

Sadly even in its latest incarnation it doesn’t. It still doesn’t have basic exhaustive pattern matching/sum types. More importantly, even once it gets that, its standard library wasn’t written with them in mind. It gained (value) tuples quite late, so standard library functions still use awkward “out” parameters and so on.