This language is quite striking! TypeScript is a superset of JS but here we're going from the other direction. Make a language that is only the TypeScript extensions to JS, and drop all the JS parts.
No Object (!!), no Date, TypedArray, RegExp, almost all the mainstays are gone. It's Java 1.0: static offsets and vtables.
This feels like the beginning of TypeScript throwing its weight around. It has the momentum to supplant JS and this is an exploratory compatibility-breaking step.
> Make a language that is only the TypeScript extensions to JS, and drop all the JS parts.
So? Is there a reason left then to use Typescript instead of C or C++? I cannot think of one. Especially for education you better use a real language that will stay for more than 10 years at least. Microsoft is doing a great job taking over the Javascript community, and now this.., would love to see their hidden agenda.
IMAO Typescript is only interesting as a (painful) intermediate solution for large Javascript code bases until there is a serious replacement for Javascript through WebAssembly. I'd never choose Typescript as a language, even stronger, I recently moved away from full-stack web development partly because of it. Back to C++, what a relief..
Typescript has a unique typesystem that embraces duck typing. This is quite different to how you would type e.g. a scala program. C++ adds a load of additional burden on the programmer (memory) and has a relatively weak typesystem. Clearly Typescript has a niche, has familiarity to subset of programmers, so there are plenty of reasons for this to have its place.
Definitely painful. After trying to get a team to adopt and gradually type a large codebase for the last 2.5 years I can say that gradual typing is a dream. In practice you write more code than you end up typing as you go and the project is never 100% complete.
If something gets typed as `any` all bets are off and there are no benefits. So people don't end up running the type checker during development anyway. Which defeats the purpose.
There are small places where it is useful -- some developers on the team had never used a type system before and found that it helped them eliminate errors from their code before they even ran the program.
But overall... agree, Typescript/Flow -- they were great experiments and useful -- but I'd rather see ways for us to adopt better languages. Elm, Purescript, Haskell, F# -- Javascript is great for projects of a certain size... but once you get to a large team and many tens-of-thousands of lines of it... discipline will only get you so far.
> If something gets typed as `any` all bets are off and there are no benefits.
Then why allow `any`? Using TS without the compiler and linter configs tuned to your benefit is like trying to use a plane only as a car. No discipline required if you let yourself fly with settings that set you up for long term success later.
Also, Flow is not on the same level as TS. It's a dead project and was never fully baked.
Because sitting around and typing tens of thousands, maybe hundreds of thousands of lines of code is not super productive?
That was the whole sell of "gradual typing," was it not? That you could turn it on, type everything as `any` then add better types as you go with the goal of eventually having a fully typed code base.
Except in our experience you'll always be playing catch up and never get to the promised land.
Don't do gradual typing, is what I'm saying. Start a project with the compiler and linter tuned strict and you'll do well. But if you have to go gradually and you have a goal of typing an untyped codebase, then just introduce a rule at a time from a list of rules you'd like in the end. Each rule should be a single commit or single PR (or Epic, or whatever granularity required)
> Because sitting around and typing tens of thousands, maybe hundreds of thousands of lines of code is not super productive?
Your project either doesn't benefit from static types or you're not seeing the benefits. I agree it's annoying to convert a JS project to TS, but TS in the end has been a huge boon to our overall velocity (long term) considering bugs, refactoring, and service to service edges.
> But if you have to go gradually and you have a goal of typing an untyped codebase, then just introduce a rule at a time from a list of rules you'd like in the end.
This was the plan. In a similar fashion to bringing a legacy code base under test we would commit to bringing this code base under type coverage. We started by adding explicit type signatures at the start and refining the types as we worked on the modules. What we ended up with is an archipelago of typed modules.
This has the consequence of forcing the developer to be aware of the coverage of the module they're working with. On our team I don't think there were enough people who had experience with strongly typed languages on board -- we're a JS shop. This meant we had to teach our teams how to think and design with types as we went along... and as deadlines approach and teams work towards their goals sometimes... that escape hatch is too tempting.
So your archipelago spends most of its time shifting. Some old, crufty modules never end up getting typed. New modules are well typed. And there are too many of the former to enable strict checking without overloading the developers.
It's not simply a technical problem but a social one too.
> Your project either doesn't benefit from static types or you're not seeing the benefits.
I believe types benefit the programmer and help us reason about programs. We've been seeing benefits there. It has helped some of the more junior developers learn how to write better code.
One boost has been that I started teaching a weekly class in Haskell that some of our developers opt into and that has had a positive effect. A more strict language has helped demonstrate how to structure programs and think in types. Which has helped them, they say, write better Javascript (even though I'd never recommend learning Haskell to "become a better programmer," you'll walk away frustrated).
I'm mostly on board with the idea of moving away from the mess of the Javascript ecosystem. But going back to C++ doesn't really get you away from the big mess problems!
I am not sure where you are going with that. C++ is largely popular and enduring for the same reasons as Java: institutionalization (taught in school).
This isn't wrong and that is one of the largest issues people have with C++: if something is syntactically correct in a language, chances are you'll find it in any relatively big codebase - and with C++ there are a LOT of things that are syntactically correct.
It may feels nice preaching that C++ is only whatever subset you may like (and there are a LOT of C++ programmers, or "programmers who write code that happen to be accepted by C++ compilers" if you prefer, that do that - personally i like pre-C++98 subset that was implemented in Borland C++ Builder 1) but in practice when you have to deal with a real world big C++ codebase (especially something you didn't write yourself and didn't start last month) you'll see all the faces of C++ at the same time, either you like it or not.
C++ is the biggest cancer in the industry. I can't really understand how people can easily say its name. A C++ programmer needs to understand not only language syntax but also underlying operating system and its internals. This is completely different job and therefore needs completely different expertise. I don't even want to mention hardware limitations, cpu architectures, etc. So, don't use C++. It is not mainstream anymore and hopefully it will be a thing of past.
I guess we have been using different platforms, so is the bubble of web development.
Just for your education, Python ML research, is just glue for GPGPU libraries written in C++, NVidia nowadays specifically targets their GPGPU designs to match C++ semantics, Apple, Google and Microsoft use C++ for their drivers, Metal shaders use C++, AAA game industry breathes C++, Fintech uses a mix of Java/.NET and C++, LLVM and GCC, the beloved FOSS compiler stacks are written in C++, AUTOSAR requires C++14, Arduino Sketch is actually C++,…
C++ might have a couple of flaws, not being mainstream is certainly not one of them.
It seems like the main market for the language is education, specifically a high-level language for ARM-based arduino-compatibles, but with an SDK that can be hosted on a browser for easy distribution on school computers. Microsoft can use the nuts and bolts of their existing typescript compiler, which happens to be able to run in a browser, to implement the language.
> This feels like the beginning of TypeScript throwing its weight around. It has the momentum to supplant JS and this is an exploratory compatibility-breaking step.
If this dream will come true, we will have both broken JS development space, and not much better TS developer ecosystem.
The creation of TypeScript is Microsoft's doing its trick called "Extend Embrace Extinguish."
They see that their captive developer community of VB and C# devs is trying to migrating to more sane scripting languages, and they want to cauterise the bleeding with TS.
The moment TS will gain steam, they will very likely add some extensions that will finally break any form of reverse compatibility, and make TS a standalone language. And few years down the line they will put a lid on it too.
Who on earth is moving from the well-typed, statically compiled world of C# to some dynamic scripting language? I mean, not to besmirch the merits of scripting languages, but C# and, ex, JS excel in very different domains.
I wouldn't say all the JS mainstays are gone. In fact, most STS programs have little to no type annotations, so it very much looks like javascript still. The dynamic parts like eval() and "new function" are gone, but the others you mentioned could likely be added in the future. Date() for example isn't added because STS mostly targets MCUs which don't typically have persistent time.
STS was designed and built to target MCUs for educational purposes. It's actually incompatible with pretty much every NPM package out there TypeScript or not, because 99% of those can't fit or run on an MCU.
Subsets of TypeScript are an interesting idea. If you could remove mutation and push imperative APIs into a library that calls you, you might wind up with something like Elm.
Nothing is wrong with TypedArray. This might be added in the future. Currently it hasn't been necessary for the use cases STS is going for (educational programming for MCUs).
From the title it would seem it is boiled down to a completely statically-typed language, but it isn't.
e.g. type casts are no-ops. Instead, every object access is type-checked at runtime. `any` still exists and for unions and complex types it still performs full lookup by name (instead of RTTI/tagged unions or such).
So it's not really a static language, but a cut-down JavaScript runtime that instead of optimizing objects with hidden classes at runtime, does similar thing with vtables ahead of time.
Exactly. 'Static' refers to control flow which is static (no eval etc.). Handling of data is dynamic, with static types used as hints.
It's also meant to run on a very constrained microcontrollers (think a few kB of RAM), and compile inside of a client-side webapp (both of which make it hard to use things like AssemblyScript).
In its current state, Static TypeScript is a toy compared to AssemblyScript.
It doesn’t support much of the original TypeScript features, while AssemblyScript is getting pretty close to the original TypeScript.
AssemblyScript was also specifically designed to target WebAssembly. For example, it supports 64 bit types and has builtins that directly map to WebAssembly opcodes.
Static TypeScript would have to be repurposed as explicitly targeting WebAssembly in order to become a viable alternative.
And Static TypeScript is part of a set of projects with very different goals.
That being said, it could indeed be turned into something targeting WebAssembly. And unless Microsoft goes that route, it may happen as a fork. Still, I’m not sure of the benefits compared to AssemblyScript. I’d rather see Microsoft contribute to AssemblyScript.
Like you said, STS and AssemblyScript have very different goals. In fact, STS is generally not faster than vanilla JS on V8. STS is primarily targeted at MCUs which need a low space and memory footprint while still being reasonably performant.
The main use case for STS is https://makecode.com which is a CS EDU platform for physical computing.
Assemblyscript targets webassembly, while Static Typescript is designed for ARM microcontrollers. The main sell for static typescript seems to be that it provides a compiler, linker, and SDK for arduino-alikes that can be hosted on a client-side webapp for easy cross-platform distribution
Given that they're both TypeScript subsets with similar goals, how close is STS to AssemblyScript? And is WebAssembly also a planned or possible compilation target of STS?
There are no goals to target WebAssembly right now. STS is currently targeted towards MCUs, which makes it more comparable to uPython or AVR than AssemblyScript.
Extremely interesting idea. Sounds like many of the things they get rid of are some of the more problematic features of JS anyway. The end result is fairly Swift-y; a loosely OOP static language that has closures and really convenient hash-map syntax.
Hey HN, I work at MSFT on MakeCode.com [5] which is the primary user of Static TypeScript. Happy to answer questions. Michal and others who worked on STS more directly will probably be online in a couple hours.
One important clarification:
So far STS has been built specifically to target microcontrollers/MCUs. Initially it was targeted at the BBC micro:bit [0] for educational purposes and has since grown to support many more targets ([1],[2],[3],[4],[5]). The other dominant languages in this space are MicroPython and the AVR/Arduino language. The advantages of STS are beginner friendliness (makecode is a CS EDU platform), low-memory, small size and performance (relative to MicroPython). It's worth noting that in general STS is NOT faster than running JS in V8.
How does it compare to MicroPython?
- Error reporting: Because STS is statically typed and compiled, most program errors are caught in the editor before the program is loaded on the device. Furthermore, STS comes with a simulator that runs in the browser and so programs can be tested there before they run on hardware. For educational purposes, we found diagnosing issues on hardware to be really hard for students, so we try to catch and present errors as early as possible.
- Performance: [3] is the best example of this. Usually we notice STS is ~10x faster than uPython while having a smaller flash and memory footprint. This makes running a game loop at 30FPS feasible on a 120x160 display (e.g. this [6] $25 device).
How does it compare to AVR/Arduino/C/C++?
- Modern language: STS, like TypeScript, heavily uses type inference, supports advanced types constructs like algebraic types (i.e. sum/union and product/tuples), supports ducktyping, has easy to use lambdas, has a light-weight syntax, and favors event-based programming.
- Teachability: Because of the heavy use of type inference, most beginner programs have no type annotations and it looks just like Javascript. So we essentially teach JS to users after they want to move on from blocks.
- In general STS is not faster or smaller than AVR code!
STS has at runtime four kinds of unrelated
object types:
1. a dynamic map type has named (string-indexed) properties that can hold values of any type;
2. a function (closure) type;
3. a class type describes instances of a class, which are
treated nominally, via an efficient runtime subtype
check on each field/method access, as described below;
4. an array (collection) type.
Ok, I did not read the specifications yet and just refered to the other comment. But your quote gives no indication of (prototyp or classical) inheritance?
Python was first created in 1991 where a top of a line computer ran at 50mhz and had 50 MIPS. A current generation MCU - ATSAMG51 easily runs at 120mhz, and devices are quickly moving up to the 500mhz range (https://groboards.com/giant-board/). There clearly is enough processor power to Python. StaticTypescript isn't even running scripted, it is compiled to native and has performance close to C/C++ developed code.
No Object (!!), no Date, TypedArray, RegExp, almost all the mainstays are gone. It's Java 1.0: static offsets and vtables.
This feels like the beginning of TypeScript throwing its weight around. It has the momentum to supplant JS and this is an exploratory compatibility-breaking step.