Комментарии 48
Какая-то необычайно странная статья.

Делать выбор только на основании «хайповости» технологии (а все выбранные метрики так или иначе про это) — это умиляет, мягко говоря.

Я понимаю, что количество вакансий, зарплаты, перспективы — хоть какие-то критерии.
Трудоемкость разработки и сопровождения, вопросы производительности — это если вспомнить, про что вообще изначально был Хабр.

А так… смузи какое-то.
Это кликабельная статья рекламирующая RUVDS – хостинг, 99% статей у них примерно так и выглядят, одна вода
Ну да. Тем не менее, можно же для перевода что-нибудь нормальное найти.

Рувдс публикует по 2 статьи в сутки.
Сложновато находить стабильно столько качественных статей для перевода

Хабр изначально был про хайповость конечно. Система инвайтов, поощрение переводных неоригинальных статей… (если бы статью перепечатывали на оригинальном языке, это называлось бы плагиатом). Были оригинальные интересные глубокие статьи, но исчезающе мало и в основном на geektimes.
Появление гиктаймс — это попытка реанимации уже к тому моменту издохшего хабра. Такой себе референс к «изначальности».
А так… смузи какое-то.

Носители брекетов смотрят на Вас с неодобрением )
Я понимаю, что количество вакансий, зарплаты, перспективы — хоть какие-то критерии.


Если мы говорим о выборе языка, то значит мы и говорим об его изучении.
А тут зарплата начинающего и зарплата опытного, количество вакансий разного уронвня — разные вещи.

То есть go это C подобный яп, а JS выходит, что нет?
Итого, рулит php. А пайтон… Через совсем небольшое время превратится в php, ибо толпы говнокодеров рассматривают программирование не с позиции алгоритмической красоты, продуманости и техник исполнения, многообразия задач и инструментов, а с точки зрения "как поскорее выучит язык программирования".

А причём тут толпы говнокодеров? Они вроде как влияния на дизайн самого языка и его библиотек не оказывают.
Через совсем небольшое время превратится в PHP


Ну во первых, язык Python уже сложился. Сам язык уже ни во что иное не превратится.
Во вторых, PHP как раз превратился в нормальный язык с годами.
Из Node сейчас происходит существенный отток разработчиков в Deno. Через несколько лет он начнёт попадать в подобные таблицы. Это тот-же JavaScript, а Core разработчик — тот же что в своё время начинал делать node. Кардинальное выкидывание legacy и учёт ошибок\современных реалий (async, ES6).
Ага, только к теме не относиться, будет вместо JavaScript (нода) стоять JavaScript (дено)
Существенный отток? Нет ни одного крупного проекта, который бы мигрировал на Deno. Нет ни одной крупной компании, которая бы заявила что используют Deno в продакшене. Вы выдаете желаемое за действительное.
Для тех, кто так же, как и я, пойдет по ссылке возле первого графика на исследование стэковерфлоу и НЕ НАЙДЕТ там диаграммы из статьи — это раздел Most Loved, Dreaded, and Wanted Languages. вкладка Wanted. График отражает долю ответивших «who do not yet use it say they want to learn it». Т.е. количество людей, которые НЕ ИСПОЛЬЗУЮТ язык, но не прочь его выучить. А совсем не «лидера среди языков программирования».

Лидер по "слышал, но никак руки не доходят пощупать"

Давно сижу на c#. Поглядываю на другие яп. Но они не цепляют.
Скажите что-нибудь плохое про c#.

Система сборки MSBuild не настолько продвинутая, как Gradle. Причем, если в Maven, хотя бы, порог входа низкий, то в MSBuild он как и в Gradle немаленький.
Как следствие — меньшее число дополнительных плагинов. Например, в Maven/Gradle есть плагин для Artifactory, который позволяет не только залить бинарники строго после всех тестов по всем платформам, но и отправляет метаданные на сайт, так что можно понять — где, когда и с помощью каких зависимостей был собран тот или иной пакет.
Как следствие из предыдущего пункта — новым языкам под CLR сложно появиться, так как их непросто встраивать в build pipeline. Я думаю, в том числе и по этой причине для JVM есть Scala, Groovy, Kotlin, тогда как для .Net их не адаптировали.


Хотя архитектурно CLR, конечно, на голову обходит JVM — есть struct'ы, честные generic'и, Span и пр. Так что узкие места разгонять проще. JVM, правда, здесь догоняет.

Стоит заметить, что с выходом .NET Core MSbuild стал на порядок проще и *.csproj читаются не хуже pom.xml

мне когда говорят что msbuild скрипты стали проще (применительно к платформе .net в целом) я прошу объяснить мне пару вещей (код ниже):
1) откуда новые файлы
2) как влиять на их генерацию (напишите мне «в блокноте/на память/без гуглежа»)
3) каких ещё вещей мне ожидать в следующие релизе .net5/6/7… в выхлопе моего софта, непосредственно к нему (к его работе) не относящегося и как мне обеспечить приемлемую скорость обновления этих версий с учётом правок билд конвейерных скриптов всявзи с этими изменениями.
4) а ещё помнится был (а может и есть?) SOS_README.md в зависимостях (попадал в deps.json) и приятно удивлял своей «необходимостью» при развёртывании («мусор, а приятно»)…

короче в msbuild очень много всяких «нюансов» и «сделали по-умолчанию, потому что это устраиват 99% юзеров, прочитавших книжку `.net за 21 час`» (кто там помнит на память содержимое и назнчение файла «PackageOverrides.txt» ?) И не стал он проще — он стал сложнее, и то как его используют делает его всё более запутанным. А «перезагрузку» (отказ от msbuild) M$ так и не осилили и похронили идею («прощай project.json»).

# представим что у нас netcoreapp3.1
mkdir c
cd c
dotnet new console
touch some.config
dotnet publish
ls -l bin/Debug/netcoreapp3.1/publish/
.....   c.deps.json
.....   c.dll
.....   c.pdb
.....   c.runtimeconfig.json
cd ..

# now web ....
mkdir w
cd w
dotnet new web
touch some.config
dotnet publish
ls -l bin/Debug/netcoreapp3.1/publish/
..... appsettings.Development.json  
..... appsettings.json              
..... some.config                   <== wow
..... w.deps.json
..... w.dll
..... web.config                    <== wow
..... w.pdb
..... w.runtimeconfig.json

Вот пожалуйста, csproj из моего последнего проекта. Это единственный файл для сборки проекта, других не нужно.


<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp2.1</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Flurl.Http" Version="2.4.2" />
    <PackageReference Include="Microsoft.Extensions.DependencyInjection" Version="3.0.1" />
    <PackageReference Include="Microsoft.Extensions.Logging.Abstractions" Version="3.0.1" />
    <PackageReference Include="System.IO.Packaging" Version="4.7.0" />
    <PackageReference Include="VkNet" Version="1.52.0" />
    <PackageReference Include="VkNet.AudioBypassService" Version="1.6.0" />
  </ItemGroup>
</Project>
Это чудесно, что ваш большой и отличный проект состоит из одной сборки и вам ничего не надо менять из того, что делает msbuild «из коробки выбранной вами SDK» (и вы никогда не обновляли этот SDK так, что это сломало вам сборку). А, к примеру, когда этих сборок хотя бы 20-30 (даже в рамках одного solution), и надо менеджерить зависимости (версии) — начинается «DirectoryBuild.props» и другие «веселые друзья».

Почитайте о проекте Paket и про транзитивные зависимости например…

А уж какая веселуха у тулинга .net с теми же цифровыми подписями бинарей (не под виндой, хотя и под ней не без нюансов) и nuget пакетов — цельный issue года этак с 2016 открытый имеется — страниц на 200…

А проблема со внешними *.json решается сборкой в один исполняемый файл, а какие они там и сколько их это "внутренняя кухня" .NET

один исполняемый файл — это, конечно, отлично, пока вы не задумываетесь о том, как именно он работает с учетом таких вещех как, скажем, SELinux (и о безопасности в целом).

Внутреняя кухня до тех пор «внутреняя», пока вам не надо там что-то менять или вы не натыкаетесь на баги в этой внутрянке.

Про простоту — согласен. Про функциональность — нет.


В Maven/Gradle компилятор языка — это плагин проекта. То есть проект требует "java plugin", "scala plugin", "kotlin plugin" и так далее, а уже билд система скачивает необходимое из репозиториев. В MsBuild версия компилятора прибита гвоздями к самому MsBuild по сути (хоть сейчас это уже не на 100% верно, с появлением compiler services, однако, насколько я видел, их не особо используют).


Maven/Gradle сейчас не требуют никакого предварительного скачивания, так как присутствует Maven Wrapper/Gradle Wrapper. Так что на машине разработчика/на билд машине достаточно просто установить JVM. Для .Net это не так.


Тесты, линтеры и аналоги nuget в Maven/Gradle — это плагины по сути (хоть часть из них встроенные). Так что Вы можете заменять их на более удобные. MsBuild является, по сути, монолитом. Что тормозит развитие платформы.

Сравнили Go с питоном и JS но при этом не упомянули никаких его отличительных черт
Судя по hh, еще бы добавил Java. Интересно было бы разобрать причины применения того или иного языка в бекенде (ну кроме «исторически так сложилось»).
оффтоп — у яндекса/mail значительная часть бекенда на С++. Но у них это скорее наследие нулевых годов (или нагрузки такие?). Получается С++ для бекенда скорее мертв?

Небольшой оффтоп: у меня про Java только нецензурные слова. Я понимаю, что все зависит от софта, но все же. Пишу на JS под VSCode, все хорошо. Надо поправить что-то в Андроид-приложении и запускаю Андроид Студию и на макбуке можно жарить яишницу, притом, что оно просто запущено (макбук 2014 года, но под VSCode загрузка околонулевая). Еще и после закрытия надо процессы java прибивать.

Но если проанализировать рейтинги языков программирования, взглянув на таблицу, расположенную ниже графика, то окажется, что популярность Go растёт, а популярность JavaScript и Python падает.

А если посмотреть на TypeScript в этой же таблице, то видно, что его популярность почти в 2 раза больше выросла по сравнению с Go
Не буду спрашивать почему Вы считаете, что TypeScript это не язык, но приведу цитату с офф сайта
TypeScript is an open-source language which builds on JavaScript, one of the world’s most used tools, by adding static type definitions.
TypeScript сильно улучшает JS, но отдельным языком его сложно называть. Можно установить в проект TypeScript и выполнить проект, не написав на TypeScript ни одной строчки.

По определению любая строчка на JS является строчкой на TS :)

Преимущество питона как серверного языка перед nodejs в наличии одного единственного полноценного фреймворка с удобной ORM, в nodejs такого единообразия нет. Есть express, поверх которого если не хотим писать запросы руками, нужно использовать отдельно орм фреймворк — typeorm или не сильно удобный и по моему короткому опыту использования весьма глючный sequelize. Это признаться отталкивает.

NestJS + TypeORM. Полгода использую, в основном положительные впечатления. Про Express не вспоминаю даже.

Раньше активно его использовал, как раз когда пользовался express'ом. У тайпорма хорошая интеграция с nestjs, поэтому такая связка мне больше нравится. Ну и аннотации выглядят гораздо чище, чем возня с sequelize.define.

Один парень писал все на JavaScript, и клиент, и сервер, говорил что нравится, удобно, читабельно. Потом его в дурку забрали, конечно.

А зачем в статье 2020 года про языки 2021 года использовать статистические данные опроса Stack Overflow 2019 года?
Чем плох опрос 2020 года?

Потому, что это статья с Медиума, скажите спасибо, что этот автор не только про JavaScript слышал. Совсем недавно другой, ещё более одарённый, автор вычислял умирающие языки по популярности случайных роликов с Ютуба.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.