Для сравнения, вот аналогичный код на C# под .NET Core 1.0
using System;
using System.Linq;
using System.Threading;
namespace Go_comparison
{
class Program
{
static void Main(string[] args)
{
var jobs = Enumerable.Range(1, 5);
jobs.AsParallel().WithDegreeOfParallelism(3)
.Select(x =>
{
Console.WriteLine($"Starting work on iten {x}");
Thread.Sleep(1000);
Console.WriteLine($"Finished work on iten {x}");
return x * 2;
})
.ForAll(Console.WriteLine);
Console.ReadLine();
}
}
}
Google — GWT помните? А Kotlin пока очень экзотичен, спецов под него не найдёшь, и если помет — вы застряли с приложением на нем написанным.
У TS тут два основных преимущества:
— готовые спецы уже есть, да и прочие хорошие программисты JS легко осваивают, ибо суперсет;
— в самом худшем случае «TS помер», у вас на руках остался странспиленный JS, который легко читается человеком.
Когда уже есть 250к строк кода, переписать будет довольно долго.
По опыту, TS полезен на проектах любого размера, поскольку позволяет крайне быстро рефакторить, что важно на ранних стадиях проэктировки, и поскольку напоминает про корнер кейсы и особенности JS.
jsdoc был сносен в 2012-ом, поскольку не было альтернатив. Однако, само его наличие это признание необходимости возможности иметь типизацию. Ни один язык, который проектировался с наличием такой возможности изначально, не пошёл по пути вынесения её описания в комментарии. Объявление типа члена всегда неразрывно в них с объявлением самого члена. Их ведь не глупые люди проектировали? И команда Angular ведь не просто так решила перейти на TS с jsdoc.
П.С. за почти 4 года работы с TS я знаю лишь одно реальное препятствие его внедрить — команда ленива и не любит JS как таковой. Но наличие добротного jsdoc-а намекает, что ваша команда явно с отдачей подходит к делу, сомневаюсь, что на внедрение TS у вас ушло бы больше пары дней.
Нокаут это верная рабочая лошадка в современном мире JS хайп-библиотек со средним сроком жизни в два года. Таким бы был angular 1, если бы не полагался на дико тормозной digest cycle. К счастью, крупный Enterprise с историей существования больше 20 лет это понимает и скептически смотрит на Facebook дары приносящий.
П.С. самое забавное, что хорошие паттерны типа Redux и Immutability воплощаются на Knockout даже лучше чем в оригинальном родоначальник Хайфа по ним.
Да, Королев не свалил из России. Наградой за это ему стал арест в 1938, сломанная челюсть, ссылка на прииски, еще 8 лет срока в 1940-ом. Хотели бы повторить его путь?
https://github.com/scottksmith95/LINQKit? (Создал библиотеку автор LINQPad)
С ней можно писать
.Where(p => NiceRating.Invoke(p.Categoory)
и ещё много полезных дополнений.
«Стали бы Вы использовать Kotlin в своих проектах?»
Да, стал бы. По опыту, я вижу большие перспективы у подхода «одна VM — много языков» или даже Язык++ с удобным сахаром транспилируемым в просто Язык. Самым ярким примером для меня стал TypeScript, который позволял использовать плюшки ES2015 еще в 2013-ом году на продакшене, не говоря уже о его собственных плюшках. Потом появился Roslyn, сделав C# раширяемым (хотя тут главное не переборщить). Для банковской сферы, где новый код должен быть совместим со старым без вариантов, это пока единственный жизнеспособный подход что я видел чтоб не застревать на старых версиях языков годами.
Окей, но речь ведь не только о нас с вами? Я сейчас оглянулся вокруг себя и вижу около 50 разработчиков на Java / C#. Захотят ли они после Visual Studio / IDEA работать через консоль? По опыту — нет, вообще никак. Привычка к этому есть только у самых матерых JS разработчиков, но даже в этих командах их зачастую 1-2 из 5.
Ну уж нет почему? И кто допилит? На VS Code потому и надежда что его уже сейчас двигают разработчики из Гугла и Микрософта. Вот что называется «опенсорс объединил непримиримых».
Кроме того, суть не в самом IDE, главное — стандарт плагинов. С учетом того, что и VSC и Atom базируются на Electron, есть все предпосылки для совместимости.
А как таким тулингом может быть что-то еще? Большинство разработчиков консоль не особо любит. Даже когда такой проблемы нет, нажать F5 быстрее и проще чем вбивать «npm install --dev http-server», «node bin/http-server». Быстрее даже чем «http-server», если машина ваша и он уже стоит. В более сложных примерах UI будет еще удобней (IMHO). И это только верхушка айсберга. Можно ведь сразу открывать роут контроллера в редактируемом файле, если плагин под Express установлен. Yeoman это как раз первый шаг, он вполне может занять место кнопки «new project», а после и «new controller», «new directive», «new component» и т.д.
В первую очередь, нужен тулинг, который мягко но настойчиво приведет большинство к конвенциям взяв на себя создание бойлерплейта. В этом плане у меня большие надежды на VS Code, как среду которую сами же JS разработчики смогут расширять с использованием всех привычных им инструментов. Несколько лет назад большой скачок в инструментах разработки JS и фронт-энда вообще произошел когда JS разработчики получили одну платформу для инструментов в лице NodeJS. Теперь дело за общим IDE (если быть точным, за IDE который закрепит стандарт для расширений на базе NodeJS).
Чувак просто еще не дорос до Тех Лида (что довольно странно с учётом заявленного опыта).
Тех Лид понимает, что зачем, он не обращает внимания на шелуху, он умеет говорить 'нет'. Потому как он уже все эти мучения прошел не по разу и звоночки в технологиях видит. Это я к тому, что учиться надо не ноя а стиснув зубы и думая головой.
П.С. В TS упаковка в один файл это удобство для редких случаев, когда именно что надо упаковать все или ничего. Это не его задача, в первую очередь он выдает файлы .ts => .js один к одному, потому и настройки упаковки там особой не будет.
П.П.С. Ну и еще автор оригинала просто и привык к C# где экосистема слаженная и 90% боилерплейта за тебя уже написано. JS к этому тоже идет, но понадобится пару лет пока все индастри стандарты и конвенции утрясутся.
Как насчет литературы? Если опытный разраб хочет прочесть 1 книгу (на английском), чтоб полностью освоить Go (за редельку свободного времени), то что вы порекомендуете?
А что необычного? Дофига банков запрещают скайп, потому что трафик идёт через сервера третьих лиц. А MS как раз пушит Lync для таких случаев — поставил свои сервера, и не паришься.
У TS тут два основных преимущества:
— готовые спецы уже есть, да и прочие хорошие программисты JS легко осваивают, ибо суперсет;
— в самом худшем случае «TS помер», у вас на руках остался странспиленный JS, который легко читается человеком.
П.С. за почти 4 года работы с TS я знаю лишь одно реальное препятствие его внедрить — команда ленива и не любит JS как таковой. Но наличие добротного jsdoc-а намекает, что ваша команда явно с отдачей подходит к делу, сомневаюсь, что на внедрение TS у вас ушло бы больше пары дней.
П.С. самое забавное, что хорошие паттерны типа Redux и Immutability воплощаются на Knockout даже лучше чем в оригинальном родоначальник Хайфа по ним.
С ней можно писать
.Where(p => NiceRating.Invoke(p.Categoory)
и ещё много полезных дополнений.
Да, стал бы. По опыту, я вижу большие перспективы у подхода «одна VM — много языков» или даже Язык++ с удобным сахаром транспилируемым в просто Язык. Самым ярким примером для меня стал TypeScript, который позволял использовать плюшки ES2015 еще в 2013-ом году на продакшене, не говоря уже о его собственных плюшках. Потом появился Roslyn, сделав C# раширяемым (хотя тут главное не переборщить). Для банковской сферы, где новый код должен быть совместим со старым без вариантов, это пока единственный жизнеспособный подход что я видел чтоб не застревать на старых версиях языков годами.
И в руках у сообщества остается форк, как было с IO.js
По вашей логике выходит, что никакой опенсорс нельзя использовать.
А мыть руки после вскрытия перед принятием родов не обязательно, если они не выглядят грязными.
Изолированный scope это даже не вопрос, это должно быть доведено до автоматизма даже у новичка.
Кроме того, суть не в самом IDE, главное — стандарт плагинов. С учетом того, что и VSC и Atom базируются на Electron, есть все предпосылки для совместимости.
Тех Лид понимает, что зачем, он не обращает внимания на шелуху, он умеет говорить 'нет'. Потому как он уже все эти мучения прошел не по разу и звоночки в технологиях видит. Это я к тому, что учиться надо не ноя а стиснув зубы и думая головой.
П.С. В TS упаковка в один файл это удобство для редких случаев, когда именно что надо упаковать все или ничего. Это не его задача, в первую очередь он выдает файлы .ts => .js один к одному, потому и настройки упаковки там особой не будет.
П.П.С. Ну и еще автор оригинала просто и привык к C# где экосистема слаженная и 90% боилерплейта за тебя уже написано. JS к этому тоже идет, но понадобится пару лет пока все индастри стандарты и конвенции утрясутся.
П.С. это про телевидение. А софт для дистанционного обучения — всегда +.
П.С. Lync 2013 тормозит адово.