Proposal: Static Typing

Andrea Giammarchi andrea.giammarchi at gmail.com
Mon Mar 25 10:41:24 UTC 2019


> WASM interoperability and optimiser efficiency instead of developer
productivity.

I've personally always seen types useful **only** for typed languages
interoperability and/or optimization/performance hints to engines/runtimes,
but since many developers apparently experience some productivity boost
though typed languages oriented tools, why not having all the three checked?

   - WASM interoperability (a TC39 effort)
   - more efficient runtime (a runtime/engine effort)
   - boosted productivity (a third parts tools effort)

That doesn't look too bad to me, as possible JS' future.

Regards


On Mon, Mar 25, 2019 at 11:19 AM Bergi <a.d.bergi at web.de> wrote:

> Hi,
>
> > I am having hard time understanding the counter argument "you need a
> > transpiler anyway".
>
> Sorry, I agree it's a bad argument, I should have just omitted it.
> It was meant to support "If you are only looking for development-time
> benefits, you have to install a static toolchain anyway - which might as
> well transpile away the annotations".
>
> >> the real value of strict types, in my view, is at development time,
> > not at run time.
> >
> > This is not correct. Check what AssemblyScript managed to do via types,
> > targeting WASM instead of non-typed JS
> >
> >> I would be curious to know if anybody has a usage for them at run time
> >
> > Developers might not have such usage, but V8 / Chakra / JSC /
> > SpiderMonkey might spin up optimizations ahead of time, enabling right
> > away hot code.
>
> ...or at least allow throwing exceptions instead of having to
> de-optimise a JITted code, which allows simpler & better optimisation
> algorithms.
>
> These are the kinds of arguments I want to hear, reasons for sending
> type annotations to the client/runtime. And such a goal puts a very
> different focus on what the type system should look like: WASM
> interoperability and optimiser efficiency instead of developer
> productivity.
>
> kind regards,
>   Bergi
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190325/a021691b/attachment.html>


More information about the es-discuss mailing list