Мы избегаем прямых сравнений с основным конкурентом в таком формате (когда инициатива идет от нас), т.к. оно по определению не могло бы быть беспристрастным ввиду очевидного конфликта интересов, и будет воспринято как самореклама. :)
В идеале, хорошо бы, если бы детальное сравнение по фичам сделал кто-то из пользователей обоих продуктов (а еще лучше добавить в сравнение и PyDev, Wing, Spyder...). Думаю, это была бы интересная статья для Хабра. И я с удовольствием бы ответил на все вопросы, которые появились бы после такого сравнения.
Впрочем, я могу ответить на такие вопросы и здесь, лишь бы они были конкретными — т.е. не общее сравнение продуктов, а по конкретным фичам и сценариям.
В PTVS нет своего интерпретатора Питона — он использует то, что у вас уже есть. Поэтому все, что работает в обычном Питоне (или IronPython, который тоже поддерживается), будет работать и здесь. С другой стороны, никакой особой интеграции с WinForms и прочим на уровне кода нет — хотя, разумеется, вы можете использовать существующие библиотеки вроде Tk и pythonnet. В IDE есть поддержка визуального редактора форм WPF при использовании IronPython.
Что касается кроссплатформенности — сама VS не кроссплатформена, к сожалению. Поддержки кроссплатформенной VS Code у нас пока нет, но работа над этим уже началась. При этом сам код, который ви пишете, разумеется, может быть кроссплаформенным, и PTVS поддерживает удаленную отладку кода на любых платформах.
В отличие от гитхаба, который все-таки сайт «для работы», скажем так, Реддит — это, по сути, гигантский форум. И у его сообщества есть вполне определенное и очень ярко выраженное мнение по вопросам вроде свободы слова. Так что shitstorm будет гарантированный, и я думаю, что блокировку на стороне сервера скоро уберут.
Вы почитайте описание на GitHub. К JS это все не имеет никакого отношения, основная цель — задать кроссплатформенный, портабельный IR, в который можно будет компилить (для начала) C и C++.
Для локальной переменной нет никакого смысла ограничивать её тип интерфейсом — она не более чем деталь реализации метода. Интерфейсы имеет смысл использовать на границе API, но как раз там var в C# недоступен.
>> в развитии C# выбрали модель «добавить как можно больше фич и сахара как можно быстрее»,
Это в равной степени миф. Я вам советую почитать записи в блоге Эрика Липперта про дизайн языковых фич, и design meeting notes из страницы Roslyn на GitHub. Там можно увидеть, насколько нещадно на самом деле режутся списки предлагаемых фич.
В C++ можно было и раньше, интерпретатор на шаблонах пишется на коленке. Правда, отжирает по паре гигабайт памяти на мало-мальски сложных программах, но, право же, это такая мелочь по сравнению с улучшенной читабельностью.
А теперь, когда у нас есть еще и user-defined literals…
Если сразу писать код с ConfigureAwait, то ваш воркараунд не нужен. Причем профит этим не ограничивается — не будет ненужных переходов на главный поток, вне зависимости от контекста вызова, и не будет разницы в поведении из-за неизвестного начального шедулера.
Отлично, т.е. у вас вызывающий код должен быть в курсе деталей реализации DoSomeWorkAsync, чтобы знать, нужно его оборачивать в Task.Run или нет.
Или вы всерьез предлагаете вообще все таски так оборачивать «на всякий случай»?
Не лучше ли делать так, как рекомендуют авторы всего этого дела, и по возможности писать контексто-независимый асинхронный код (т.е. — с ConfigureAwait), особенно в библиотеках, где его планируется повторно использовать?
Обратите внимание — тот же офис (с которого компания традиционно рубит больше всего денег) уже несколько лет как продается в т.ч. как сервис, с годовой подпиской.
Кстати, очень похожим образом работал класс XPathDocument. Там после парсинга все XDM-дерево хранится именно вот так, отображением на большие массивы байт индексацией. И обход дерева через XPathIterator ходит по этим байтам (в которых хранятся и относительные сдвиги на соседние узлы по разным осям).
У качественных литиевых батареек AA - напр. Energizer Ultimate Lithium - срок хранения 25 лет "по паспорту".
G-Shock у людей и по 20 лет живут без смены аккумулятора.
У меня есть один экземпляр, которому уже почти 10 лет. Тоже заряжается "на подоконнике".
DALL-E 3
В идеале, хорошо бы, если бы детальное сравнение по фичам сделал кто-то из пользователей обоих продуктов (а еще лучше добавить в сравнение и PyDev, Wing, Spyder...). Думаю, это была бы интересная статья для Хабра. И я с удовольствием бы ответил на все вопросы, которые появились бы после такого сравнения.
Впрочем, я могу ответить на такие вопросы и здесь, лишь бы они были конкретными — т.е. не общее сравнение продуктов, а по конкретным фичам и сценариям.
Что касается кроссплатформенности — сама VS не кроссплатформена, к сожалению. Поддержки кроссплатформенной VS Code у нас пока нет, но работа над этим уже началась. При этом сам код, который ви пишете, разумеется, может быть кроссплаформенным, и PTVS поддерживает удаленную отладку кода на любых платформах.
В плане написания — возможно. В плане чтения, особенно когда активно используются дженерики, и там еще что-то вложенное — var проще.
>> Всё становится сложнее, когда программист автоматом добавляет return из метода, IDE выводит возвращаемый тип из типа переменной
А вот тут я уже замечу, что нехорошим в данном случае является именно автовывод типа возврата. Границы метода — они неспроста.
(Как показывает практика, в 99% случаев — не понадобится, и по умолчанию имхо стоит исходить из этого.)
Это в равной степени миф. Я вам советую почитать записи в блоге Эрика Липперта про дизайн языковых фич, и design meeting notes из страницы Roslyn на GitHub. Там можно увидеть, насколько нещадно на самом деле режутся списки предлагаемых фич.
А теперь, когда у нас есть еще и user-defined literals…
Или вы всерьез предлагаете вообще все таски так оборачивать «на всякий случай»?
Не лучше ли делать так, как рекомендуют авторы всего этого дела, и по возможности писать контексто-независимый асинхронный код (т.е. — с ConfigureAwait), особенно в библиотеках, где его планируется повторно использовать?
И что, вы думаете, это как-то поможет с описанным в статье дедлоком?