Здравствуйте, Somescout, Вы писали:

V>>Он еще чуть больше TS чем сам TS. ))
V>>Плюс еще немножко удобств и синтаксического сахара.
S>Если правда что "Utilizing existing JavaScript code and libraries is more difficult, you need to access them through an interoperability library.", то не взлетит

Дело в стоимости разработки таких оберток. Для сравнения, если писать JNI — это муторно, то и Java-оберток над имеющимися нейтивными библиотеками немного. А если .Net Interop простой как число 7, то наблюдается тонна дотнетных оберток над имеющимся кодом.

К тому же, имеется два сильно разных сценария — когда dart переводится в JS и когда работает на собственной VM. В первом случае интеграция очень дешевая, во втором — невозможна. Лично я тут вижу "трамплин" для взлёта языка, как С++ когда-то взлетел из-за простой интеграции с С.


S>(да, собственно, уже не взлетело) — Гугля радостно наступает на те же самые грабли, что и с GWT.

Если ключевые два продукта adWord и adSense, приносящие Гуглу львиную долю заработка, уже переведены и работают на дарте, то "не взлетело" — это инсинуации. ))


S>ЗЫ. Кроме того Dart это гугль. Кому-то МС не нравится, кто-то Эппл не переваривает, а кого-то от гугли тошнит.

Это да. Но что делать?
NIH он такой, угу, но от него не убежишь.
Опен-сорсные поделки в 99% случаев вообще кошмар.

Здравствуйте, Lloyd, Вы писали:

V>>В присутствии dart нет никакого смысла продолжать писать на TS.
L>А по какой причине тогда google пишет angular на ts?

Для "других".
Я уже напоминал, что проект Angular-2 был начат сугубо для "причесывания" его под идиомы dart.
Поэтому, сейчас есть две зеркальные ветки Angular-2 — на TS и на Dart, где последний выступает в роли "диктатора" ТЗ для обоих.

Здравствуйте, gandjustas, Вы писали:

V>>Вот есть сетевые задачи, которые достоверно на C# или Джаве решаются проще и лучше, чем на node.js.
V>>Т.е. проблема потом установить такое серверное приложение у клиента?
G>Да, зачастую деплой java или C# это не только перекинуть файлы.

Ну, поставить node.js нужной версии — это тоже "не только перекинуть файлы".
А когда нужный фреймворк уже стоит, то деплой сводится к "просто перекинуть".

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Serginio1, Вы писали:

V>>>В присутствии dart нет никакого смысла продолжать писать на TS.
S>>А чем он лучше? Мне TS нравится больше.

V>Он еще чуть больше TS чем сам TS. ))
Например? Мне интересно.
V>Плюс еще немножко удобств и синтаксического сахара.
MS сделал TS таким каким его хотел Гугл для Angular 2. Именно по этому он и основной.

А можно поподробнее на счет сахара. То, что я видел ничего нового от TS не увидел.
в TS те же async await, гибридные типы, очень близок к C#. Даже в C# не ввели рекорды, а в TS аналог записи есть через конструктор, появился Deconstruct.
Так, что по сахару и TS и C# идут в одном направлении.

При этом я в VS пишу одновременно как серверный код на C# так и клиентский на TS, с интеллисенсе, проверкой типов.


Кстати интересная статья История о том, как мы перевели проект в почти четверть миллиона строк на TypeScript и остались в живых

Здравствуйте, vdimas, Вы писали:

L>>А по какой причине тогда google пишет angular на ts?

V>Для "других".
V>Я уже напоминал, что проект Angular-2 был начат сугубо для "причесывания" его под идиомы dart.
V>Поэтому, сейчас есть две зеркальные ветки Angular-2 — на TS и на Dart, где последний выступает в роли "диктатора" ТЗ для обоих.

Вы меня прям заинтриговали. Где можно посмотреть на "зеркальную" ветку?

Здравствуйте, Serginio1, Вы писали:

V>>Он еще чуть больше TS чем сам TS. ))
S> Например? Мне интересно.

Ну я-то небольшой специалист по обоим, много на них не писал, просто пару раз пробовал из любопытства.
Впечатление такое, что TS — это чуть продвинутый JS, а Dart — это чуть продвинутый TS.


V>>Плюс еще немножко удобств и синтаксического сахара.
S>MS сделал TS таким каким его хотел Гугл для Angular 2. Именно по этому он и основной.

Разработчик C# единолично сделал пруф типизированного JS, затем подключилось коммьюнити и "одобрило".
В этом месте Гуглу ничего не оставалось делать, если коммьюнити одобряэ.
Гугл попросил добавить еще фич в TS для совместимости по возможностям с Dart (MS включила фичи из гуглового AtScript в TS).

Вот теперь всё сошлось, в итоге у Гугла появился конвертер из TS в Dart:
https://github.com/angular/ts2dart


S> А можно поподробнее на счет сахара. То, что я видел ничего нового от TS не увидел.

Что касается синтаксиса, то да, в ES6 тоже уже много чего есть от обоих.

Но дело не в этом.
Dart более строгий язык, более интересный, как по мне.
Под такие языки от IDE больше пользы.
Язык с нормальной системой модулей, а не эмулируемой, как в JS, когда для эмуляции модульности иcпользуется динамический eval.
Нормальная модульность позволила сделать для Dart мощную стандартную библиотеку — а это самое первое для любого языка.
В этом смысле в JS всё очень и очень печально...

Однако, на нашей памяти было уже столько раз повторений одной и той же истории, когда выигрывала не лучшая технология, а худшая, но оказавшаяся в нужное время в нужном месте...
Посмотрим.
Ведь не исключается возможность дальнейшего развития TS, вплоть до нормального компиллируемого кода, как Dart, C# или Джава.
Так же не исключается появление сугубо TS-библиотек, а не только их оберток над имеющимися JS.
Как раз Angular-2 как пример.

Тут разработчик Шарпа поступил хитро — дал людям эдакий "мостик" м/у хаосом скриптового мира и мира, основанного на контрактах. Почему "мостик" — код JS одновременно является валидным TS-кодом, в этом суть трюка.
Точно так же когда-то С++ взлетел поверх уже ставшего стандартом де-факто С.

На эту тему есть интересная статья:
https://habrahabr.ru/company/wrike/blog/323550/

А вот для Dart-а всё это не так. На Dart надо как бы "перепрыгивать", а не плавно переходить, повторно используя уже имеющиеся наработки "as is". Вот принципиальное отличие, ИМХО.

Да, эти наработки для Dart можно портировать автоматически. Но, как показывает практика, всегда лучше сделать их с 0-ля на "нормальном" языке. Плюс сама необходимость портирования — это тоже психологический барьер.


S> в TS те же async await, гибридные типы, очень близок к C#. Даже в C# не ввели рекорды, а в TS аналог записи есть через конструктор, появился Deconstruct.
S> Так, что по сахару и TS и C# идут в одном направлении

А интерполяция строк в TS изкаробки есть?

(e, stackTrace) => print('Oh noes! $e $stackTrace'))

В C# 6.0 тоже есть.

И вообще, Dart имеет мейнстримовый сишный синтаксис:

class User {
    num id;
    string name;

    User(this.id, this.name);

    string getInfo() {
        return "id: $id name: $name";
    }
}

var tom = new User(1, "Tom");

Этот же пример на TS:

class User {
    id: number;
    name: string;

    constructor(userId: number, userName: string) {
        this.id = userId;
        this.name = userName;
    }

    getInfo(): string {
        return "id:" + this.id + " name:" + this.name;
    }
}

let tom: User = new User(1, "Tom");

Комментарии излишни, как по мне.
На Dart может писать сходу человек с бэкграундом C/C++/C#/Java.
Всё будет ложится гладко чисто на уровне рефлексов.

На другой стороне идут сторонники ключевого слова function и аннотаций типов через ':', типа TS/Swift/Nemerle


S> Кстати интересная статья История о том, как мы перевели проект в почти четверть миллиона строк на TypeScript и остались в живых

Дык, в этом и суть, пока JS будет являться валидным TS.
Можно переводить пошагово, с вменяемым объемом изменений на каждом шаге.

Здравствуйте, Lloyd, Вы писали:

V>>Последние серьезные изменения были в 2011-м, они упёрлись в "непреодолимые проблемы" и выступили с инициативой NaCL.
L>Каждые 6 недель (+/-) у v8 выходит новый стабильный релиз.

Это багфиксы в основном.
Плюс поддержка новых фич языка.
Мы же говорили о движке исполнения, верно? А ему на фичи языка немного покласть, он байт-код исполняет.
До 2011-го активно изменялся именно движок, в него добавлялись новые принципы ускорения — например, типизазия на исскуственно-вводимых структурах, "мемоизация" такой типизации до тех пор пока в ф-ию подают аргумент такого же типа и т.д. Собсно, это был потолок, поэтому они стали тратить усилия на NaCL/WebAssembly.

Здравствуйте, Lloyd, Вы писали:

V>>В присутствии dart нет никакого смысла продолжать писать на TS.
L>А по какой причине тогда google пишет angular на ts?

Ты лучше спроси, по какой причине Гугл пишет angular-2.
http://www.rsdn.org/forum/flame.comp/6728684.1

Здравствуйте, gandjustas, Вы писали:

V>>Ну что тебе мешает показать мои ошибки?
V>>Ля-ля — не мешки ворочать? ))
G>В общем — ты не знаешь современного JS.

Но показать ты этого не в состоянии, я правильно тебя понимаю?


G>Ты все время делаешь утверждение, которые были актуальны лет 10-15 назад.

Так в этом и проблема JS.
Никакой новый сахар из до сих пор не устаканившегося ES6 ничего не изменит.
Не, ты всерьёз считаешь, что =>/async/await/yield что-то серьезно меняют?
Бог с тобой ))


G>В конкретные места тебя тыкнуть?

Ну конечно, если ты обвиняешь человека в ошибке, то надо эту ошибку показать или немедленно извиниться.

Здравствуйте, gandjustas, Вы писали:

V>>VB в интранете прекрасно работал и на серверной стороне.
G>В теории работал. На практике 99,9% приложений VB — формочки.

Это клиентская морда, а серверная?
На практике серверный DCOM компонент создаётся разработчиком в VB6 двумя щелчками мышки (указываешь аппартмент и степень параллелизма по независимым процессам).

А его прокси на клиенте и того проще:

dim obj as MyType
set obj = CreateObject("MyType", "HostName")
obj.someMethod x, y, z

В общем, не в пример проще и удобнее, чем ремоутинг на C# или Джаве.
Просто ты ввиду своего возраста не застал те времена с необходимым для понимания происходящего багажом знаний, вестимо.

DCOM умер по одной простой причине — плохо пролазит через firewall.
Но для интранета был просто находкой.


V>>Похоже, ты страшно далёк от этой темы.
V>>Курить DCOM — он целиком и полностью, считай, был заточен под компоненты VB.
G>Ты теоретизируешь только.

Тут тебе лучше внимать, чем спорить.


G>>>А Java пробралась на сервера и выкинула оттуда C++.
V>>Да никого она оттуда не выкидывала. 3-хуровневых приложений тогда толком еще не было, кроме специализированных систем управления предприятием (ERP), коих было мало. И то, никого из крупных Джава никуда не выкинула. А мелкие системы сплошняком были клиент-серверные, т.е. клиент обращался непосредственно к базе. И в этом месте Джава тоже никакой С++ никуда не выкинула, бо мейнстримом для этих вещей был VB и Дельфи.
G>Это в России не было, потому что у нас очень прижилось delphi (потому что все беслпатно ставили).

Не только в России. Скайп не из России пришел. ))
Да, в Штатах больше юзали VB, в Европах и то и то и еще кучу всякого: FoxPro, Paradox и прочие.
Тот же MS Access имел возможность работать с SQL-серваком и не только — это вообще технология-хаб для всевозможных разнородных источников данных.
В общем, Java вытеснила именно эти системы.
И уже после 2000-го.
Но в этих системах отродясь серьезного С++ никогда не было.
Ну кроме той тонкости, что "движок" таких систем был писан на С++, ы-ы-ы.

Поэтому, твоё исходное утверждения якобы о том, что Джава потеснила С++ — оно дилетанское, ангажированное.


V>>А на чем были писаны первые Axapta и Navision, кста?
G>Хз, очень старые системы. С тех пор как МС купили — на .NET.

Это клиенты к ним на Net переписали, а сам сервак?
А сервер Exchange на чем написан?
А сервер Sharepoint на чем написан?
Видишь — как ни копнёшь более-менее серьезное серверное приложение, так оно на плюсах.
IIS, ngix, Apache — везде плюсы.

Одно время были популярны Tomcat, JBoss, но их популярность резко стала снижаться уже в конце 2000-х.
Системы на таких платформах — они одноразовые, не коробочные нифига.
В коробочном мире рулит нейтив.
(Это если перестать быть ангажированным и посмотреть правде в глаза.)

Здравствуйте, vdimas, Вы писали:
V>В C# 6.0 тоже есть.

И вообще, Dart имеет мейнстримовый сишный синтаксис:

class User {
    num id;
    string name;

    User(this.id, this.name);

    string getInfo() {
        return "id: $id name: $name";
    }
}

А вот как на TS

class User {
    constructor(public id:number, private name:string);

    string getInfo() {
        return `id: ${this.id} name: ${this.name}`;
    }
}

По мне так у TS лучше

Да конечно this напрягает. Возможно в будущих версиях от него избавятся.

А вообще почитай на досуге

TypeScript Basic Types

You can also use template strings, which can span multiple lines and have embedded expressions. These strings are surrounded by the backtick/backquote (`) character, and embedded expressions are of the form ${ expr }.

let fullName: string = `Bob Bobbington`;
let age: number = 37;
let sentence: string = `Hello, my name is ${ fullName }.

I'll be ${ age + 1 } years old next month.`

Здравствуйте, vdimas, Вы писали:


S>> Кстати интересная статья История о том, как мы перевели проект в почти четверть миллиона строк на TypeScript и остались в живых

V>Дык, в этом и суть, пока JS будет являться валидным TS.
V>Можно переводить пошагово, с вменяемым объемом изменений на каждом шаге.

К тому времени и TS будет другим. Проблема Dart в том, что у Ts уже большой комьюнити. А значит и примеры и прочее.
Переписывать на Dart ради синтаксиса?
Dart не предлагает, что то такого из-за чего нужно на него переходить. Я вижу.

То что мне понрапвилось это

https://www.dartlang.org/guides/language/language-tour

Initializer list

Besides invoking a superclass constructor, you can also initialize instance variables before the constructor body runs. Separate initializers with commas.

class Point {
  num x;
  num y;

  Point(this.x, this.y);

  // Initializer list sets instance variables before
  // the constructor body runs.
  Point.fromJson(Map jsonMap)
      : x = jsonMap['x'],
        y = jsonMap['y'] {
    print('In Point.fromJson(): ($x, $y)');
  }
}

Ну еще перегрузка операторов. Но это уже малоиспользуемая фича.

Хотя здесь выкручиваются
https://github.com/Microsoft/TypeScript/issues/6936
https://github.com/kushal-likhi/operator-overloading-js

через прототипы

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, gandjustas, Вы писали:

V>>>Вот есть сетевые задачи, которые достоверно на C# или Джаве решаются проще и лучше, чем на node.js.
V>>>Т.е. проблема потом установить такое серверное приложение у клиента?
G>>Да, зачастую деплой java или C# это не только перекинуть файлы.

V>Ну, поставить node.js нужной версии — это тоже "не только перекинуть файлы".
V>А когда нужный фреймворк уже стоит, то деплой сводится к "просто перекинуть".

Это только в самых примитивных случаях.
Вот у меня есть проект, который работает на 8 серверах, перезапуск app pool — простой несколько секунд, который нельзя допускать.
Обновление клиентского JS гораздо менее болезненное. И если накосячишь чего, то не упадет все приложение.
Поэтому проще написать JS и дергать api из браузера, чем писать серверный код. Как раз по причинам деплоя.

Здравствуйте, gandjustas, Вы писали:

V>>Ну вот ты пользуешься им, насколько я понял, т.е. должен понимать, верно?
G>Это совершенно пофиг, ты можешь пользоваться паттерном и не знать как он называется. Название в данном случае искусственное.

Дело не в названии, а в гарантиях.
node.js помимо всего прочего, что операции ввода-вывода для каждого отдельного файлового хендла будут привязаны к одному и тому же потоку.
Тут на сайте был разбор примеров, где это имело значение (разбирал я с Ikemefula). Т.е., человек работает с языком, а что там на самом деле происходит — понятия не имеет.

В итоге мне надоели эти бодания:
http://www.rsdn.org/forum/humour/6444719.1
))


V>>Это путь вполне определённого слоя коллег, которые дальше сугубо прикладной области принципиально не заходят.
V>>Именно в среде этих программистов живут и разможаются всевозможные мифы и заблуждения о собственных технологиях, которыми они оперируют.
G>Среди C++ников таких сильно больше, чем среди тех, кто знает делфи, C# и JS.

Агащаз.
С++ бъет по рукам за ошибки, вызванные непониманием происходящего.


V>>>>Но никогда не JS -> Джава/C# -> С++. ))
G>>>Это путь падения продуктивности. Никто в здравом уме не станет решать задачу на C++ и даже на C#, если может её же решить на JS.
V>>Речь не шла об одной и той же задаче, заметь.
G>Тогда непонятно что ты хочешь сказать.

Я уже всё сказал:

Я так думаю, что программист с ростом должен уметь решать всё более сложные задачи.

G>Сложность задач ограничена сверху, а продуктивность — нет. Поэтому программист должен именно продуктивность повышать.

Да-да.
Можно научиться быстро работать руками на конвейере, а можно сделать робота вместо десятка таких "ловких на руки" человек.
Оформившиеся принципы разработки на С++ — именно такие, заключаются в "роботизации" и это даёт дикий профит.

Ну и еще в 2002-м году, с выходом первого дотнета, уже тогда всё было сказано — "разгадка" продуктивности джавы и дотнета заключается больше в мощных библиотеках, поставляемых с языком, чем в св-вах языка. Просто св-ва языка позволили участвовать в разработке этих либ "дешевым" разрабтчикам, поэтому и получилось сделать такие либы бесплатными. А как только С++ оброс кучей бесплатных либ (это ж важно, бо платных на него хватало во все времена), так сразу разработка на нём стала куда как более продуктивной, чем на шарпе (кроме сценариев linq-выражений).

Собсно, на сегодня это даже не сравнимо, бо в скорости написания кода C# уже резко отстаёт, хотя еще в 2005-м резко обгонял плюсы.

Просто посмотри на вот эту библиотеку: http://www.rsdn.org/forum/prj.codejam
Для современного С++ ничего подобного уже не нужно.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, gandjustas, Вы писали:

V>>>Ну что тебе мешает показать мои ошибки?
V>>>Ля-ля — не мешки ворочать? ))
G>>В общем — ты не знаешь современного JS.

V>Но показать ты этого не в состоянии, я правильно тебя понимаю?
Я могу тебя потыкать в каждое твое ошибочное утверждение, но мне лень.
Я искренне надеюсь, что ты сам пойдешь почитаешь.


G>>Ты все время делаешь утверждение, которые были актуальны лет 10-15 назад.

V>Так в этом и проблема JS.
В чем? Что он развивается?

V>Никакой новый сахар из до сих пор не устаканившегося ES6 ничего не изменит.
Уже изменил.

V>Не, ты всерьёз считаешь, что =>/async/await/yield что-то серьезно меняют?
Я серьезно считаю что TS изменил многое. Поднял продуктивность в разы, приблизил JS к современным языкам.



G>>В конкретные места тебя тыкнуть?
V>Ну конечно, если ты обвиняешь человека в ошибке, то надо эту ошибку показать или немедленно извиниться.
Ты, как и многие, утверждал, что модульности нет. А она внезапно есть. Причем дольше чем ты знаком с JS.
Ты утверждал что v8 не развивается, в чем ошибся.

Ты даже не удосужился зайти на страницу обсуждаемых проектов. О чем с тобой говорить вообще?

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, gandjustas, Вы писали:

V>>>VB в интранете прекрасно работал и на серверной стороне.
G>>В теории работал. На практике 99,9% приложений VB — формочки.

V>Это клиентская морда, а серверная?
V>На практике серверный DCOM компонент создаётся разработчиком в VB6 двумя щелчками мышки (указываешь аппартмент и степень параллелизма по независимым процессам).

Еще раз. 99,9% — формочки. Серверный vb может и был где-то, но я его в глаза не видел ни разу.


V>>>Похоже, ты страшно далёк от этой темы.
V>>>Курить DCOM — он целиком и полностью, считай, был заточен под компоненты VB.
G>>Ты теоретизируешь только.
V>Тут тебе лучше внимать, чем спорить.
Мне теория не интересна. В теории бывает столько всего, что не случается на практике в силу многих причин. Мне скорее интересны эти причины, потому что они показывают как реально работают технологии, а не теоретические изыскания.


G>>>>А Java пробралась на сервера и выкинула оттуда C++.
V>>>Да никого она оттуда не выкидывала. 3-хуровневых приложений тогда толком еще не было, кроме специализированных систем управления предприятием (ERP), коих было мало. И то, никого из крупных Джава никуда не выкинула. А мелкие системы сплошняком были клиент-серверные, т.е. клиент обращался непосредственно к базе. И в этом месте Джава тоже никакой С++ никуда не выкинула, бо мейнстримом для этих вещей был VB и Дельфи.
G>>Это в России не было, потому что у нас очень прижилось delphi (потому что все беслпатно ставили).

V>Не только в России. Скайп не из России пришел. ))
Одно приложение не показатель. Если посмотреть вакансии 2000-х годов, то там огромный спрос на delphi.

V>Но в этих системах отродясь серьезного С++ никогда не было.
V>Ну кроме той тонкости, что "движок" таких систем был писан на С++, ы-ы-ы.
На каждый Access приходилось по несколько десятков самописной фигни на C++. Потом пришла java и всю фигню начали писать на Java.

V>Поэтому, твоё исходное утверждения якобы о том, что Джава потеснила С++ — оно дилетанское, ангажированное.
Ты хочешь сказать не потеснила?
Доля кода, написанного за деньги на Java росла как раз за счет доли C++. Все твои рассказы про access тут никаким боком.
У нас тот же самый путь с 1995 по 2005 был у Delphi.


V>>>А на чем были писаны первые Axapta и Navision, кста?
G>>Хз, очень старые системы. С тех пор как МС купили — на .NET.

V>Это клиенты к ним на Net переписали, а сам сервак?
Сервак в первую очередь. Клиент сначала написали .NET формочках, потом WPF, а теперь все в браузере.
Но причины тут вовсе не технологические. А ровно те же, по которым гугл продвигает dart.

V>А сервер Exchange на чем написан?
На .NET, кроме пары компонент.

V>А сервер Sharepoint на чем написан?
На .NET, кроме пары компонент.

V>Видишь — как ни копнёшь более-менее серьезное серверное приложение, так оно на плюсах.

Как раз наоборот. Плюсы бывают по историческим причинам в малом количестве.

V>IIS, ngix, Apache — везде плюсы.
Ты сравниваешь серверы и приложения?

V>Одно время были популярны Tomcat, JBoss, но их популярность резко стала снижаться уже в конце 2000-х.
V>Системы на таких платформах — они одноразовые, не коробочные нифига.
Ты же понимаешь, что в заказной разработке денег больше, чем в продуктовой? В смысле программист может заработать, а не компания, продающая продукт.
Именно для заказной разработки имеет смысл повышать продуктивность, а не для продуктовой.

V>В коробочном мире рулит нейтив.
Подавляющее большинство (больше 95% точно) корпоративных систем уже 10+ лет на managed языках написано. Это я про коробочные как раз. Заказные не нативные 100%.
Софт для телефонов пишется на Java, iOS, .NET\Xamarin. Из них нативный только iOS с натяжкой.

V>(Это если перестать быть ангажированным и посмотреть правде в глаза.)
Если смотреть правде в глаза, то в основном нативный софт — системный, который не нужен пользователю или покупателю сам по себе, но помогает решать задачу. Задача системного софта — быть полезным и жрать меньше ресурсов, чтобы оставалось для решения прикладной задачи.

Здравствуйте, vdimas, Вы писали:

V>Впечатление такое, что TS — это чуть продвинутый JS, а Dart — это чуть продвинутый TS.
И оно неправильное.
TS это JS+типы. Любой код на JS превращается в TS путем добавления аннотаций, чтобы удовлетворить компилятор.
Dart — отдельный язык, который не похож на JS своими правилами и идиомами.



S>>MS сделал TS таким каким его хотел Гугл для Angular 2. Именно по этому он и основной.
V>Разработчик C# единолично сделал пруф типизированного JS, затем подключилось коммьюнити и "одобрило".
V>В этом месте Гуглу ничего не оставалось делать, если коммьюнити одобряэ.
V>Гугл попросил добавить еще фич в TS для совместимости по возможностям с Dart (MS включила фичи из гуглового AtScript в TS).
AtScript с dart не связан от слова вообще.
Изначально Angular2 писали на AtScript, который внезапно оказался очень похож на TS. Послы доброй воли пришли в гугл и уболтали не рожать еще один язык, а писать на TS. В TS специально для этого ничего не добавляли.
Dart появился потом.

V>Вот теперь всё сошлось, в итоге у Гугла появился конвертер из TS в Dart:
V>https://github.com/angular/ts2dart
Это сделали чтобы не переписывать Angular2 на дарт руками.



V>Dart более строгий язык, более интересный, как по мне.
Он не взлетел уже. То что гугл его пушит вряд ли ему поможет.

V>Так же не исключается появление сугубо TS-библиотек, а не только их оберток над имеющимися JS.
V>Как раз Angular-2 как пример.
Сейчас много библиотек пишется на TS. Поищи на GitHub.


V>На Dart надо как бы "перепрыгивать", а не плавно переходить
Кому это надо?
Какой профит?


V>А интерполяция строк в TS изкаробки есть?
Есть.

V>И вообще, Dart имеет мейнстримовый сишный синтаксис:
V>

V>class User {
V>    num id;
V>    string name;

V>    User(this.id, this.name);

V>    string getInfo() {
V>        return "id: $id name: $name";
V>    }
V>}

V>var tom = new User(1, "Tom");
V>

V>Этот же пример на TS:
V>

V>class User {
V>    id: number;
V>    name: string;

V>    constructor(userId: number, userName: string) {
V>        this.id = userId;
V>        this.name = userName;
V>    }

V>    getInfo(): string {
V>        return "id:" + this.id + " name:" + this.name;
V>    }
V>}

V>let tom: User = new User(1, "Tom");
V>

Вообще-то на TS надо писать так:

class User {
    constructor(public userId: number, public userName: string) {}
    getInfo = () => `id: ${this.userId} name: ${this.userName}`;
}

V>Комментарии излишни, как по мне.
Именно.

V>На Dart может писать сходу человек с бэкграундом C/C++/C#/Java.
На TS может писать сходу человек с бэкграундом на JS, а также C/C++/C#/Java.
Ключевое выделено. Поэтому dart не взлетел.


S>> Кстати интересная статья История о том, как мы перевели проект в почти четверть миллиона строк на TypeScript и остались в живых
V>Дык, в этом и суть, пока JS будет являться валидным TS.
Так будет всегда. Такова политика TS.

Здравствуйте, Serginio1, Вы писали:

S> Ну еще перегрузка операторов. Но это уже малоиспользуемая фича.
S> Хотя здесь выкручиваются
S>https://github.com/Microsoft/TypeScript/issues/6936
S>https://github.com/kushal-likhi/operator-overloading-js
S>через прототипы

Операторы можно перегружать только в типизированном контексте, а не в контексте связки объекта/прототипа.
Потому что концов не словишь — где и откуда растут ноги. ))

Перегрузка операторов — это весьма популярный приём в С++, т.е. фича востребованная, при её наличии.

Посмотрим.
Я еще толком не щупал генерики Дарта на предмет полнофункциональной поддержки параметрического полиморфизма (руки не дошли).

Потому что в TS параметрического полиморфизма нет, есть "шаблоны" — синтаксический сахар, а не система типов.
В C# параметрический полиморфизм тоже не полноценен — он не отличает типы аргументов по их ограничениям.

Здравствуйте, Lloyd, Вы писали:

V>>Поэтому, сейчас есть две зеркальные ветки Angular-2 — на TS и на Dart, где последний выступает в роли "диктатора" ТЗ для обоих.
L>Вы меня прям заинтриговали. Где можно посмотреть на "зеркальную" ветку?

https://github.com/dart-lang/angular2

Здравствуйте, gandjustas, Вы писали:

G>Вот у меня есть проект, который работает на 8 серверах, перезапуск app pool — простой несколько секунд, который нельзя допускать.
G>Обновление клиентского JS гораздо менее болезненное. И если накосячишь чего, то не упадет все приложение.
G>Поэтому проще написать JS и дергать api из браузера, чем писать серверный код.

Кошмар ))