5 ms·

Honest q, which part is out of date and why? Thanks

by thund 2y ago

valcron1000 2y ago
Pretty much everything: > While C# does have AOT capabilities nowadays this is not as mature as Go's and not all platforms support it https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=windows%2Cnet9plus https://learn.microsoft.com/en-us/dotnet/core/deploying/nati... Only Android is missing from that list (marked as "Experimental"). We could argue about maturity but this is a bit subjective. > Go also has somewhat better control over data layout How? C# supports structs, ref structs (stack allocated only structures), explicit stack allocation (`stackalloc`), explicit struct field layouts through annotations, control over method local variable initialization, control over inlining, etc. Hell, C# even supports a somewhat limited version of borrow checking through the `scoped` keyword. > This is meant to be something of a 1:1 port rather than a rewrite, and the old code uses plain functions and data structures without an OOP style. C# has been consistently moving into that direction by taking more and more inspiration from F#. The only reasonable reason would be extensive usage of structural typing which is present in TS and Go but not in C#.
- neonsunset 2y ago
  Chances are it was just personal preference of the team and decades of arguing about language design have worn out Anders Hejlsberg. I don't think structural typing alone is enough of an argument to justify the choice over Rust. Maybe the TS team thought choosing Go would have better optics. Well, they won't have it both ways because clearly this decision in my opinion is short-sighted and as someone aptly pointed on twitter they will be now beholden to Google's control over Go should they ever need compiler to support a new platform or evolve in a particular way. Something they would've gotten easily with .NET.
  - vips7L 2y ago
    On the topic of preference, this thread has really shown me that there is a HUGE preference for a native-aot gc language that is _not_ Go. People want AOT because of the startup and memory characteristics, but do not want to sacrifice language ergonomics. C# could fill that gap if Microsoft would push it there.
    - pebal 2y ago
      Just use the fast GC library in C++.
      - vips7L 2y ago
        I don't think C++ has good language ergonomics.
        pebal 2y ago
        I don't think there is anything faster.
        vips7L 2y ago
        I highly doubt that bolting a GC on to C++ is going to be any faster than the equivalent C# or Java code.
        pebal 2y ago
        Doubt is human, but it isn’t always warranted. In C++ can use a concurrent, completely pause‐free garbage collector, where the programmer decides which data is managed by the GC. This enables code optimizations in ways that aren’t possible in C# and Java.
        vips7L 2y ago
        You realize that is literally not the same thing? I said equivalent code. The whole reason of using a managed language with GC is to not think about those things because they eat up thought and development time. Of course the language that will let you hand optimize every little line will eventually be more performant. I really think you’re discounting both C#’s ability to do those things and just how good Java’s GCs are. Anyway, thats not the point. The point is C++ sucks dude. There is no way that you can reasonably think that bolting a GC on to C++ is going to be a pleasurable experience. This whole conversation started with _language ergonomics_. I don’t care that it’ll save 0.5 milliseconds. I’d rather dig holes than write C++.
  - neonsunset 2y ago
    To correct myself, someone pointed out a commit graph which indicates Anders Hejlsberg's heavy involvement with the ongoing port efforts: https://github.com/microsoft/typescript-go/graphs/contributors https://github.com/microsoft/typescript-go/graphs/contributo...
- foobarbaz33 2y ago
  > C# supports structs, That's sort of the problem with C#. It couples the type (struct vs class) with allocation. C# started life by copying 1990's Java "everything-is-a-reference". So it's in a weird place where things were bolted on later to give more control but still needs to support the all-objects-are-refs style. C# is just not ergonomic if you need to care about data layout in memory. Go uses a C-like model. Everything is a value type. Real pointers are in the language. Now you can write a function that inputs pointers and does not care whether they point to stack, heap, or static area. That function can be used for all 3 types, no fuss.
  - valcron1000 2y ago
    > It couples the type (struct vs class) with allocation Agree. Where things are allocated is a consumer decision. > C# is just not ergonomic if you need to care about data layout in memory I disagree. I work on a public high performance C# code and I don't usually face issues when dealing with memory allocations and data layout. You can perfectly use structs everywhere (value types) and pass references when needed (`ref`). > Now you can write a function that inputs pointers and does not care whether they point to stack, heap, or static area. You can do this perfectly fine in C#, it might not be what some folks consider "idiomatic OOP" but I could not care less about them.

Honest q, which part is out of date and why? Thanks

by thund 2y ago

Honest q, which part is out of date and why? Thanks

Pretty much everything: > While C# does have AOT capabilities nowadays this is not as mature as Go's and not all platforms support it https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=windows%2Cnet9plus https://learn.microsoft.com/en-us/dotnet/core/deploying/nati... Only Android is missing from that list (marked as "Experimental"). We could argue about maturity but this is a bit subjective. > Go also has somewhat better control over data layout How? C# supports structs, ref structs (stack allocated only structures), explicit stack allocation (`stackalloc`), explicit struct field layouts through annotations, control over method local variable initialization, control over inlining, etc. Hell, C# even supports a somewhat limited version of borrow checking through the `scoped` keyword. > This is meant to be something of a 1:1 port rather than a rewrite, and the old code uses plain functions and data structures without an OOP style. C# has been consistently moving into that direction by taking more and more inspiration from F#. The only reasonable reason would be extensive usage of structural typing which is present in TS and Go but not in C#.

neonsunset 2y ago
Chances are it was just personal preference of the team and decades of arguing about language design have worn out Anders Hejlsberg. I don't think structural typing alone is enough of an argument to justify the choice over Rust. Maybe the TS team thought choosing Go would have better optics. Well, they won't have it both ways because clearly this decision in my opinion is short-sighted and as someone aptly pointed on twitter they will be now beholden to Google's control over Go should they ever need compiler to support a new platform or evolve in a particular way. Something they would've gotten easily with .NET.
- vips7L 2y ago
  On the topic of preference, this thread has really shown me that there is a HUGE preference for a native-aot gc language that is _not_ Go. People want AOT because of the startup and memory characteristics, but do not want to sacrifice language ergonomics. C# could fill that gap if Microsoft would push it there.
  - pebal 2y ago
    Just use the fast GC library in C++.
    - vips7L 2y ago
      I don't think C++ has good language ergonomics.
      - pebal 2y ago
        I don't think there is anything faster.
        vips7L 2y ago
        I highly doubt that bolting a GC on to C++ is going to be any faster than the equivalent C# or Java code.
        pebal 2y ago
        Doubt is human, but it isn’t always warranted. In C++ can use a concurrent, completely pause‐free garbage collector, where the programmer decides which data is managed by the GC. This enables code optimizations in ways that aren’t possible in C# and Java.
        vips7L 2y ago
        You realize that is literally not the same thing? I said equivalent code. The whole reason of using a managed language with GC is to not think about those things because they eat up thought and development time. Of course the language that will let you hand optimize every little line will eventually be more performant. I really think you’re discounting both C#’s ability to do those things and just how good Java’s GCs are. Anyway, thats not the point. The point is C++ sucks dude. There is no way that you can reasonably think that bolting a GC on to C++ is going to be a pleasurable experience. This whole conversation started with _language ergonomics_. I don’t care that it’ll save 0.5 milliseconds. I’d rather dig holes than write C++.
- neonsunset 2y ago
  To correct myself, someone pointed out a commit graph which indicates Anders Hejlsberg's heavy involvement with the ongoing port efforts: https://github.com/microsoft/typescript-go/graphs/contributors https://github.com/microsoft/typescript-go/graphs/contributo...
foobarbaz33 2y ago
> C# supports structs, That's sort of the problem with C#. It couples the type (struct vs class) with allocation. C# started life by copying 1990's Java "everything-is-a-reference". So it's in a weird place where things were bolted on later to give more control but still needs to support the all-objects-are-refs style. C# is just not ergonomic if you need to care about data layout in memory. Go uses a C-like model. Everything is a value type. Real pointers are in the language. Now you can write a function that inputs pointers and does not care whether they point to stack, heap, or static area. That function can be used for all 3 types, no fuss.
- valcron1000 2y ago
  > It couples the type (struct vs class) with allocation Agree. Where things are allocated is a consumer decision. > C# is just not ergonomic if you need to care about data layout in memory I disagree. I work on a public high performance C# code and I don't usually face issues when dealing with memory allocations and data layout. You can perfectly use structs everywhere (value types) and pass references when needed (`ref`). > Now you can write a function that inputs pointers and does not care whether they point to stack, heap, or static area. You can do this perfectly fine in C#, it might not be what some folks consider "idiomatic OOP" but I could not care less about them.