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..
I've been pretty impressed with static duck-typing and miss it when I'm in Java.
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.
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.
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.
> 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.
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).
How about memory safety and type inference?
I'm not aware of any place where C++ is taught. (And in fact C++ programmers are very hard to find.)
C is very common and anybody with even a bit of format education has been exposed to C.
Then you get people who know a bit of C and throw in a couple 'class' and a couple 'cout', and call it 'C++' for some reason.
Which is wrong, obviously.
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.
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.
Oh the humanity!
I weep for mankind and for the industry if this is where we have fallen.
Quick question: are you a Javascript programmer?
It is also an essential understanding for writing quality, performant code in any context--web development included, even frontend.
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.
And knowing that MS Devs are not far Java devs in their mentality, they will follow wherever their stomach guides them.
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.
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.