3 ms·

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 h

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.)

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.)