On Wednesday, 15 February 2017 at 11:14:11 UTC, John Colvin wrote:
On Tuesday, 14 February 2017 at 10:22:26 UTC, Ola Fosheim
Grøstad wrote:
But, the way I see it TypeScript + "native libraries" has the
potential for covering a lot of ground. The eco system is
exploding.
Having done a fair amount of professional development in
typescript over the last 6 months, I have to say I'm not as
excited about it as I used to be. Don't get me wrong, I still
think it's the best language in its space, but the javascript
underneath it shows through in a lot of bad places and the lack
of real meta-programming makes it hard to get your types
exactly how you want them. Overall I've found it a frustrating
when I compare it to working in D, despite it having a bunch of
cool features I'd love to use in D.
The structural flow type-system of TypeScript takes time to get
used to and it only provides limited static type checks, so it
has rather limited generating capabilities (typing is primarily
for correctness checks and IDE-text-completion support). The
template-expansion area is a field where D is better off,
certainly.
What MS did right though was to create something that is not too
unfamiliar for people that know languages like JavaScript, C#,
Java or Swift, yet they absorb trendy frameworks like React and
Angular as well as all existing JavaScript libraries. Not having
a fixed build system is a weakness, and a bit frustrating, but I
guess this is deliberately done to absorb as many developers as
possible with their existing preferences. Objectively a competing
language like Dart is better, but Dart is different enough to not
having the ability to absorb developers.
My viewpoint is that this ability to absorb existing practices
(like build systems and code bases) is probably where TypeScript
is gaining traction from.
I think D might be a bit like Dart in this regard. It is closely
related to, but yet too different from C/C++ to absorb the
existing practices.
Another example is Swift. Swift managed to take over Objective-C
rather quickly IMO, but Swift has also absorbed the non-C
semantics of Objective-C, thus it did not require changing
existing practice significantly.
