Комментарии 48
Делать выбор только на основании «хайповости» технологии (а все выбранные метрики так или иначе про это) — это умиляет, мягко говоря.
Я понимаю, что количество вакансий, зарплаты, перспективы — хоть какие-то критерии.
Трудоемкость разработки и сопровождения, вопросы производительности — это если вспомнить, про что вообще изначально был Хабр.
А так… смузи какое-то.
А так… смузи какое-то.
Носители брекетов смотрят на Вас с неодобрением )
Я понимаю, что количество вакансий, зарплаты, перспективы — хоть какие-то критерии.
Если мы говорим о выборе языка, то значит мы и говорим об его изучении.
А тут зарплата начинающего и зарплата опытного, количество вакансий разного уронвня — разные вещи.
То есть go это C подобный яп, а JS выходит, что нет?
Итого, рулит php. А пайтон… Через совсем небольшое время превратится в php, ибо толпы говнокодеров рассматривают программирование не с позиции алгоритмической красоты, продуманости и техник исполнения, многообразия задач и инструментов, а с точки зрения "как поскорее выучит язык программирования".
Через совсем небольшое время превратится в PHP
Ну во первых, язык Python уже сложился. Сам язык уже ни во что иное не превратится.
Во вторых, PHP как раз превратился в нормальный язык с годами.
Давно сижу на 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
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>Почитайте о проекте Paket и про транзитивные зависимости например…
А уж какая веселуха у тулинга .net с теми же цифровыми подписями бинарей (не под виндой, хотя и под ней не без нюансов) и nuget пакетов — цельный issue года этак с 2016 открытый имеется — страниц на 200…
А проблема со внешними *.json решается сборкой в один исполняемый файл, а какие они там и сколько их это "внутренняя кухня" .NET
Про простоту — согласен. Про функциональность — нет.
В 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 является, по сути, монолитом. Что тормозит развитие платформы.
оффтоп — у яндекса/mail значительная часть бекенда на С++. Но у них это скорее наследие нулевых годов (или нагрузки такие?). Получается С++ для бекенда скорее мертв?
Но если проанализировать рейтинги языков программирования, взглянув на таблицу, расположенную ниже графика, то окажется, что популярность Go растёт, а популярность JavaScript и Python падает.
А если посмотреть на TypeScript в этой же таблице, то видно, что его популярность почти в 2 раза больше выросла по сравнению с Go
TypeScript is an open-source language which builds on JavaScript, one of the world’s most used tools, by adding static type definitions.
Преимущество питона как серверного языка перед nodejs в наличии одного единственного полноценного фреймворка с удобной ORM, в nodejs такого единообразия нет. Есть express, поверх которого если не хотим писать запросы руками, нужно использовать отдельно орм фреймворк — typeorm или не сильно удобный и по моему короткому опыту использования весьма глючный sequelize. Это признаться отталкивает.
Один парень писал все на JavaScript, и клиент, и сервер, говорил что нравится, удобно, читабельно. Потом его в дурку забрали, конечно.
Чем плох опрос 2020 года?
JavaScript, Python или Go: что лучше всего подойдёт для бэкенд-разработки в 2021 году?