4 ms·

I don't think this can work. JavaScript and the CLR are very different runtime environments that make different kinds of things available at runtime, and the wo

I don't think this can work. JavaScript and the CLR are very different runtime environments that make different kinds of things available at runtime, and the workarounds for this will have different tradeoffs that will require programmer judgment to resolve. They will never be able to interoperate completely seamlessly. By contrast, TypeScript at runtime just is JavaScript, so there's no gap to bridge.

rco8786 5y ago
That’s the point of compiling one language to the other. We do this all the time. And yea, you wouldn’t have access to the .NET standard library but you would have access to the JS standard library via some interopability mechanism. Lots of languages compile to other languages with different runtimes.
- tluyben2 5y ago
  Yep, it works for clojure and clojurescript like that. They are enough the same to feel good while not having the same libs/runtime.
- ameliaquining 5y ago
  I can't think of a language that compiles to a runtime that it wasn't originally designed to target, in a way that permits interop with code written in a different language targeting that runtime, without requiring the programmer to maintain constant vigilance against interop-related bugs. In particular, either the same code has different semantics depending on which runtime it's targeting, or some data types have multiple different not-quite-100%-compatible runtime representations. Kotlin/JS, Kotlin/Native, GWT and its successor J2CL, ClojureScript, etc., all seem to have this problem.
  - fulafel 5y ago
    Direct calls between languages is always going to have some friction because languages have their own data types and cultures, it's unavoidable, but I think many of those systems make it work as well as can be reasonably expected. Meanwhile you have the option of specifying a language neutral protocol for invoking public interfaces across languages, or reuse a wire protocol. Not many people seem to make this tradeoff though, it would usually be a bigger pain than to live with the limitations of cross language direct calls.
    - ameliaquining 5y ago
      Yeah, but the top-level comment was asking why C#-to-TypeScript can't be as smooth as TypeScript-to-JavaScript. This is why. (Also, I've definitely seen Protocol Buffers used successfully as a means of cross-language interop. But I suppose this works better if you already have really strong tooling support for them.)
3np 5y ago
I think it's the other way around. C# is a much stronger language than JS. It shouldn't be a big deal (theoretically) to transpile C# to JS (though you'd have to provide interfaces for any existing JS code you'd like to interact with). The other way - JS->C# - is a lot hairier. Compare compiling a typed language to bytecode vs "decompiling" from bytecode to an unavoidable plate of spaghetti.
- ameliaquining 5y ago
  If by "stronger" you mean "less expressive", then I think there are a number of things in the CLR, like value types and reflection, that pose tough tradeoffs if you try to express them in JavaScript.
  - 3np 5y ago
    Types can safely be erased on compilation, so that needn't be an issue. A bit too foggy right now to have any valid thoughts on reflection, but I intuitively imagine strings can be abused to that end.
    - ameliaquining 5y ago
      Sorry, what do you mean by "types can safely be erased on compilation"? What would be the runtime representation of a C# struct in JavaScript?
      - tluyben2 5y ago
        There are and have been quite a few efforts[0] that 'transpile' c# to js and they worked pretty well (I used bridge.net on a large project and it was nice, but the tooling sucked), but without full support (aka a smooth vsc experience like TS which is simply quite bad for c#, the regular version, already, let alone derivatives) it died. Guess people who worked on it dumped it and moves to TS for client/Server. Seems a waste but whatever; nothing to do about it. [0] https://stackoverflow.com/questions/16434389/javascript-and-c-sharp-cross-compiling-and-conversion https://stackoverflow.com/questions/16434389/javascript-and-...

rco8786 5y ago

That’s the point of compiling one language to the other. We do this all the time. And yea, you wouldn’t have access to the .NET standard library but you would have access to the JS standard library via some interopability mechanism. Lots of languages compile to other languages with different runtimes.

tluyben2 5y ago
Yep, it works for clojure and clojurescript like that. They are enough the same to feel good while not having the same libs/runtime.
ameliaquining 5y ago
I can't think of a language that compiles to a runtime that it wasn't originally designed to target, in a way that permits interop with code written in a different language targeting that runtime, without requiring the programmer to maintain constant vigilance against interop-related bugs. In particular, either the same code has different semantics depending on which runtime it's targeting, or some data types have multiple different not-quite-100%-compatible runtime representations. Kotlin/JS, Kotlin/Native, GWT and its successor J2CL, ClojureScript, etc., all seem to have this problem.
- fulafel 5y ago
  Direct calls between languages is always going to have some friction because languages have their own data types and cultures, it's unavoidable, but I think many of those systems make it work as well as can be reasonably expected. Meanwhile you have the option of specifying a language neutral protocol for invoking public interfaces across languages, or reuse a wire protocol. Not many people seem to make this tradeoff though, it would usually be a bigger pain than to live with the limitations of cross language direct calls.
  - ameliaquining 5y ago
    Yeah, but the top-level comment was asking why C#-to-TypeScript can't be as smooth as TypeScript-to-JavaScript. This is why. (Also, I've definitely seen Protocol Buffers used successfully as a means of cross-language interop. But I suppose this works better if you already have really strong tooling support for them.)

3np 5y ago

I think it's the other way around. C# is a much stronger language than JS. It shouldn't be a big deal (theoretically) to transpile C# to JS (though you'd have to provide interfaces for any existing JS code you'd like to interact with). The other way - JS->C# - is a lot hairier. Compare compiling a typed language to bytecode vs "decompiling" from bytecode to an unavoidable plate of spaghetti.

ameliaquining 5y ago
If by "stronger" you mean "less expressive", then I think there are a number of things in the CLR, like value types and reflection, that pose tough tradeoffs if you try to express them in JavaScript.
- 3np 5y ago
  Types can safely be erased on compilation, so that needn't be an issue. A bit too foggy right now to have any valid thoughts on reflection, but I intuitively imagine strings can be abused to that end.
  - ameliaquining 5y ago
    Sorry, what do you mean by "types can safely be erased on compilation"? What would be the runtime representation of a C# struct in JavaScript?
    - tluyben2 5y ago
      There are and have been quite a few efforts[0] that 'transpile' c# to js and they worked pretty well (I used bridge.net on a large project and it was nice, but the tooling sucked), but without full support (aka a smooth vsc experience like TS which is simply quite bad for c#, the regular version, already, let alone derivatives) it died. Guess people who worked on it dumped it and moves to TS for client/Server. Seems a waste but whatever; nothing to do about it. [0] https://stackoverflow.com/questions/16434389/javascript-and-c-sharp-cross-compiling-and-conversion https://stackoverflow.com/questions/16434389/javascript-and-...