391–400 of 943 posts
Earlier quoted context omitted.
Why not AOT compiled C#, given the team's historical background?
Anders explained his reasoning in this interview (transcript): https://github.com/microsoft/typescript-go/discussions/411#d...
[flagged]
I don't think this is accurate. Javascript is not slow because of GC or JIT (the JVM is about twice as fast in benchmarks; Go has a GC) but because JS as a language is not designed for performance. Despite all the work that V8 does it cannot perform enough analysis to recover desirable performance. The simplest example to explain is the lack of machine numbers (e.g. ints). JS doesn't have any representation for this…
> By far the most important aspect is that we need to keep the new codebase as compatible as possible, both in terms of semantics and in terms of code structure. We expect to maintain both codebases for quite some time going forward. Languages that allow for a structurally similar codebase offer a significant boon for anyone making code changes because we can easily port changes between the two codebases. In contrast…
TSC doesn't use many union types, it's mostly OOP-ish down-casting or chains of if-statements.
One reason for this is I think performance; most objects are tagged by bitsets in order to pack more info about the object without needing additional allocations. But TypeScript can't really (ergonomically) represent this in the type system, so that means you don't get any real useful unions.
A lot of the objects are also secretly mutable (for caching/performance) which can make precise union types not very useful, since they can be easily invalidated by those mutations.
Earlier quoted context omitted.
he went into more detail about C# in this one: https://youtu.be/10qowKUW82U?t=1154s
He says: - C# Ahead of Time compiler doesn't target all the platforms they want. - C# Ahead of Time compiler hasn't been stressed in production as many years as Go. - The core TypeScript compiler doesn't use any classes; Go is functions and datastructures whereas C# is heavily OOP, so they would have to switch paradigms to use C#. - Go has better control of low level memory layouts. - Go was ultimately the path of le…
Opened discussion [1]
- [0] https://github.com/microsoft/typescript-go/discussions/410
- [1] https://github.com/microsoft/typescript-go/discussions/467
Earlier quoted context omitted.
I personally find Go miles easier than Rust. Is this the ultimate reason,Go is fast enough without being overally difficult. I'm humbly open to being wrong. While I'm here, any reason Microsoft isn't sponsoring a solid open source game engine. Even a bit of support for Godot's C#( help them get it working on web), would be great. Even better would be a full C# engine with support for web assembly. https://github.com/…
> Even a bit of support for Godot's C#( help them get it working on web), would be great. They did that. https://godotengine.org/article/introducing-csharp-godot/ At least some initial grant to get it started. Getting C# working on web would be an amazing. It is already on the roadmap but some sponsorship would help tremendously for sure.
Earlier quoted context omitted.
This is shockingly out-of-date statement by Anders. I'm not sure what's going on, I guess he's just not involved with the runtime side of .NET at all to actually know where the capability sits circa 2024/2025. But really, it's a terrible situation to be in. Especially just how worse langdev UX in Go is compared to C#, F# or Rust. No one would've batted an eye if either of those was used.
> Especially just how worse langdev UX in Go is compared to C#, F# or Rust. Can you explain why the DX in Go is "worse"? I've seen the exact opposite during my professional work.