4 ms·

> For the rest C# is mostly perfect. No, it isn't. The power of C++ templates is still astronomically far from C# generics.

by pif 2y ago

jayd16 2y ago
What about the built in Roslyn source generator stuff? Is that sufficiently abusable? I'm not a templates/macro guy so I'm curious what's missing.
DeathArrow 2y ago
I don't miss that power. I remember having to modify some template heavy code and it brought me to the verge of madness. :)
roetlich 2y ago
Yes, another plus point of C#. Sorry for the snark, but I do think C# compile are just barely acceptable for me, so I'm happy they aren't adding more heavy compile time features.
lifthrasiir 2y ago
That power is usually considered too reckless to retain and simultaneously too cumbersome to actually use, partly because it was never planned in the first place.
- galangalalgol 2y ago
  C++ concepts restrain that recklessness, and people hate them for it. Rust will get most of that power when they finally stabilize const generic expressions. I like c# but like the article says, it isn't really borrow checking, so you don't get fearless concurrency. If I want to do coarse grained multi threading (not just a parallel for loop or iterator to speed up math) I only want to use rust now. Once I stopped having to think around thread safety issues and data consistency, I didn't want to go back. But for something single threaded c# or go are great and performant.
  - radicalbyte 2y ago
    Is Rust really bullet proof though? I've spent a lot of time fixing concurrency bugs (race conditions), it's one of those things that I'm very very good at but even then it feels like you're Indiana Jones dodging the hidden traps. Haskell promises to solve concurrency and the Rust boys are always claiming that it's impossible to write buggy code in Rust.. and the jump from C/C++/C#/Golang to Rust is much smaller than to Haskell..
    - galangalalgol 2y ago
      You can still leak memory via a container. You can still create deadlocks. You can still throw a panic (with a backtrace). It does not solve the halting problem. But if it compiles you will not have any form of undefined behavior. No reading or writing out of bounds. No use after free, no dangling pointers, and no data getting modified across threads in an inconsistent way. If it needs a lock, the compiler will tell you with an error.
      - radicalbyte 2y ago
        > If it needs a lock, the compiler will tell you with an error. Oh that's what I was getting at, that makes Rust pretty much a must-have tool to have in your tool-belt.
nick_ 2y ago
There are pros and cons. C++ templates can't be reified at run-time like C# generics can.
- int_19h 2y ago
  FWIW for C# this also requires having a JIT (to handle generic virtual methods).
  - neonsunset 2y ago
    GVM dispatch is notoriously slow(-ish), yeah. But it does not require JIT. Otherwise it wouldn't work with NativeAOT :) (the latter can also auto-seal methods and unconditionally devirtualize few-implementation members which does a good job, guarded devirtualization with JIT does this even better however)
    - int_19h 2y ago
      I remember when this feature was specifically not available with NativeAOT. It's good that it is now, but how can it be implemented in a way that has truly separate instantiations of generics at runtime, when calls cross assembly boundaries? There's no single good place to generate a specialization when virtual method body is in one assembly while the type parameter passed to it is a type in another assembly.
      - neonsunset 2y ago
        > how can it be implemented in a way that has truly separate instantiations of generics at runtime, when calls cross assembly boundaries There are no assembly boundaries under NativeAOT :) Even with JIT compilation - the main concern, and what requires special handling, are collectible assemblies. In either case it just JITs the implementation. The cost comes from the lookup - you have to look up a virtual member implementation and then specific generic instantiation of it, which is what makes it more expensive. NativeAOT has the definitive knowledge of all generic instantiations that exist, since it must compile all code and the final binary does not have JIT.
phito 2y ago
I'm so glad it doesn't. There is absolutely no need for it and when it's used it usually makes a big mess. It goes in the same pile as multiple inheritance.

> For the rest C# is mostly perfect. No, it isn't. The power of C++ templates is still astronomically far from C# generics.

by pif 2y ago

> For the rest C# is mostly perfect. No, it isn't. The power of C++ templates is still astronomically far from C# generics.

jayd16 2y ago

What about the built in Roslyn source generator stuff? Is that sufficiently abusable? I'm not a templates/macro guy so I'm curious what's missing.

DeathArrow 2y ago

I don't miss that power. I remember having to modify some template heavy code and it brought me to the verge of madness. :)

roetlich 2y ago

Yes, another plus point of C#. Sorry for the snark, but I do think C# compile are just barely acceptable for me, so I'm happy they aren't adding more heavy compile time features.

lifthrasiir 2y ago

That power is usually considered too reckless to retain and simultaneously too cumbersome to actually use, partly because it was never planned in the first place.

galangalalgol 2y ago
C++ concepts restrain that recklessness, and people hate them for it. Rust will get most of that power when they finally stabilize const generic expressions. I like c# but like the article says, it isn't really borrow checking, so you don't get fearless concurrency. If I want to do coarse grained multi threading (not just a parallel for loop or iterator to speed up math) I only want to use rust now. Once I stopped having to think around thread safety issues and data consistency, I didn't want to go back. But for something single threaded c# or go are great and performant.
- radicalbyte 2y ago
  Is Rust really bullet proof though? I've spent a lot of time fixing concurrency bugs (race conditions), it's one of those things that I'm very very good at but even then it feels like you're Indiana Jones dodging the hidden traps. Haskell promises to solve concurrency and the Rust boys are always claiming that it's impossible to write buggy code in Rust.. and the jump from C/C++/C#/Golang to Rust is much smaller than to Haskell..
  - galangalalgol 2y ago
    You can still leak memory via a container. You can still create deadlocks. You can still throw a panic (with a backtrace). It does not solve the halting problem. But if it compiles you will not have any form of undefined behavior. No reading or writing out of bounds. No use after free, no dangling pointers, and no data getting modified across threads in an inconsistent way. If it needs a lock, the compiler will tell you with an error.
    - radicalbyte 2y ago
      > If it needs a lock, the compiler will tell you with an error. Oh that's what I was getting at, that makes Rust pretty much a must-have tool to have in your tool-belt.

nick_ 2y ago

There are pros and cons. C++ templates can't be reified at run-time like C# generics can.

int_19h 2y ago
FWIW for C# this also requires having a JIT (to handle generic virtual methods).
- neonsunset 2y ago
  GVM dispatch is notoriously slow(-ish), yeah. But it does not require JIT. Otherwise it wouldn't work with NativeAOT :) (the latter can also auto-seal methods and unconditionally devirtualize few-implementation members which does a good job, guarded devirtualization with JIT does this even better however)
  - int_19h 2y ago
    I remember when this feature was specifically not available with NativeAOT. It's good that it is now, but how can it be implemented in a way that has truly separate instantiations of generics at runtime, when calls cross assembly boundaries? There's no single good place to generate a specialization when virtual method body is in one assembly while the type parameter passed to it is a type in another assembly.
    - neonsunset 2y ago
      > how can it be implemented in a way that has truly separate instantiations of generics at runtime, when calls cross assembly boundaries There are no assembly boundaries under NativeAOT :) Even with JIT compilation - the main concern, and what requires special handling, are collectible assemblies. In either case it just JITs the implementation. The cost comes from the lookup - you have to look up a virtual member implementation and then specific generic instantiation of it, which is what makes it more expensive. NativeAOT has the definitive knowledge of all generic instantiations that exist, since it must compile all code and the final binary does not have JIT.

phito 2y ago

I'm so glad it doesn't. There is absolutely no need for it and when it's used it usually makes a big mess. It goes in the same pile as multiple inheritance.