
Thinscript: language that compiles to both WebAssembly and JavaScript - DAddYE
https://github.com/evanw/thinscript
======
constexpr
Oh wow I did not expect this to be up here this soon. Warning: two-week-old
project. I've got a lot of plans for this but it'll take at least a few months
for this to be anywhere near useful. Right now it's just an experiment!

~~~
pookeh
Please don't add type inference. Coming from Scala it seems such a beautiful
concept and a productivity booster when you are writing code but then you come
back a few months later / see someone else's code and quickly figure out what
a time waste and a productivity drain it really is.

~~~
Drup
If I may, that just means that either 1) your tooling is bad 2) Scala's type
system is too complex.

I don't know scala much, but it's not a problem in other languages with full
inference (particularly OCaml, but it's not a huge problem in Haskell either).

------
oldmanhorton
This looks a lot like typescript. Is there any particular reason for not
either 1) adding a wasm backend to tsc (which tsc may or may not allow), or 2)
implementing a strict subset of typescript? It just seems like piggybacking
off of a larger language would help this sort of idea gain traction.

~~~
constexpr
Yes. TypeScript doesn't have a sound type system and it comes with a lot of
baggage:

* Using hashtables in TypeScript relies on the representation of JavaScript objects with strings as properties. Emulating JavaScript's in-memory representation in an ahead-of-time compiled language isn't a good idea for performance reasons.

* TypeScript only has a single number type (double) which is pretty slow if you actually need to work with integers. JavaScript VMs do a lot of work to figure out which numbers are integers using information that's only available at runtime. Using explicit integer types means the generated code is a lot tighter.

* A lot of existing TypeScript code uses structural typing to model dynamic type contracts present in today's JavaScript code, but this is usually a loosely-typed approximation and not something that a compiler can rely on. It's more just to improve tooling for developers.

* TypeScript uses exceptions which are hard to emulate efficiently in native code.

* I want to be able to add certain things and extend the language, so I don't want to limit myself to TypeScript. For example, I'm considering a preprocessor for conditional compilation and something similar to C#'s unsafe syntax for pointer manipulation.

~~~
pookeh
All these reasons in Typescript are intentionally designed so that it's easy
to work with the rest of the JS ecosystem. Good tooling + rapid prototyping is
a strength not a weakness.

~~~
constexpr
I don't consider the design of TypeScript a weakness at all. TypeScript is
really well designed and is great at what it does. The type system they came
up with is pretty optimal for modeling real-world JavaScript code. But the
tuning they did around the JavaScript ecosystem means it's not a great
language to use for generating efficient native code. I started ThinScript in
part for exactly that reason. I want good tooling and rapid prototyping, just
for native development instead of web development. That requires a different
set of trade-offs and design decisions.

------
ZenoArrow
Thinscript looks interesting, aside from coding in it directly it could prove
to be a useful transpiler target, allowing non-web-languages to make better
use of WebAssembly as both WebAssembly and Thinscript mature.

~~~
constexpr
Yes! I considered this and it's an interesting idea. ThinScript may end up
being pretty opinionated about memory allocation though (I'm not sure yet if
I'm doing pure reference counting, pure garbage collection, or some
combination of both) so it could be a useful higher-level target language.

------
asb
I wonder if there's a plan for generics support?

~~~
constexpr
I plan to do it eventually. I've implemented generics before so that's not the
issue. It's just hard to get the design of generics right when the compiler
has multiple targets. You want to emit compact JavaScript code and at the same
time support the generation of efficient machine code. C++ does generic code
through template expansion but that ends up generating a ton of code, which is
bad for code delivered in a network environment. It may make sense to make
different tradeoffs given the context of this project. I'm planning on putting
off generics for a while though until more pieces fall into place.

