There are key differences though. What tsonic offers: (0) broad data type support, stack allocated types etc (1) nodejs and js compatibility libs, (2) the availability (in tsonic) of the entire .Net BCL, Asp.Net and EF Core as d.ts files (for example, in @tsonic/dotnet) so that tsc would still run, (3) bindings generator (tsbindgen) for any .net dll etc.
What tsonic is missing: (1) interpreter, (2) compile to .Net IL. Tsonic will only do native code; and does so by converting ts to c# and then using the NativeAOT chain on generated C#. SharpTS is compiling straight to IL (I think), something I considered but decided not to for the time being.
I think these are two different approaches. With pros and cons for both.
Well, there are some additions - thought it can be compiled via tsc into js that would never run. This is still useful though for IDE and tooling support, language servers etc.
The most important thing is that you have these types you can import. For example the "int" below:
import { int } from "@tsonic/core/types.js";
function fibonacci(n: int): int {
if (n <= 1) {
return n;
}
return fibonacci(n - 1) + fibonacci(n - 2);
}
Instead of making it a keyword, I decided to export these from core/types.ts - so that the code can still be compiled with tsc, and all the tooling would still work. Similarly (among others), you'd use ptr<long>, if you wanted a pointer to a long.
There are key differences though. What tsonic offers: (0) broad data type support, stack allocated types etc (1) nodejs and js compatibility libs, (2) the availability (in tsonic) of the entire .Net BCL, Asp.Net and EF Core as d.ts files (for example, in @tsonic/dotnet) so that tsc would still run, (3) bindings generator (tsbindgen) for any .net dll etc.
What tsonic is missing: (1) interpreter, (2) compile to .Net IL. Tsonic will only do native code; and does so by converting ts to c# and then using the NativeAOT chain on generated C#. SharpTS is compiling straight to IL (I think), something I considered but decided not to for the time being.
I think these are two different approaches. With pros and cons for both.
I've just improved it, but still more to do. Will look at it this week.
So, not a separate language.
The most important thing is that you have these types you can import. For example the "int" below:
Instead of making it a keyword, I decided to export these from core/types.ts - so that the code can still be compiled with tsc, and all the tooling would still work. Similarly (among others), you'd use ptr<long>, if you wanted a pointer to a long.