Тут и думать не надо. Только C#. Если ты просто HWar, тогда любой.

JVM-платформа, конечно. Можно писать не только на Java, но и на Scala, Kotlin, Groovy, Clojure, и др. Функциональные IDE, крутые фреймворки, нет зависимостей от винды, полноценная кросс-платформа.

Вот о том и речь: одни пишут «конечно, C#», другие - «конечно, JAVA» (ну, JVM, не суть). Но то, что нет зависимостей от винды - это классно, конечно. Правда некоторые утверждают, что ASP.NET Core от неё тоже не зависит, отсюда вопрос и возник.

ASP.NET

Кор. ИМХО, он побыстрее джавы.

Начни изучать отсюда: https://www.eclipse.org/webtools/

Оба - говно. На Go, конечно же, и писать! На Java пишут легаси или обёртки REST/CRUD над Legacy и никто тебе не даст использовать никакой Kotlin, завернут тебя на Java 6-8, это предел мечтаний.

А C# - это платформа для тех, у кого всё пишется на винде и для винды, но вдруг решили, что хостить по Linux и всякие Docker/Kubernetes тупо выгоднее и удобнее, только по этой причине портанули C# с ASP на линь, под линем никто и не пишет в этих корпорациях, тупо хостят свои жирные монолиты. Да и вообще, все эти ASP/Spring - концептуально устарели и узкое место - долгий старт VM с кишками веб приложения. Щас самый писк - это быстрый старт, быстрая обработка запроса и смерть, в Docker контейнерах и в AWS Lambda и аналогах… Дёшево и сердито. Вот тут то Go, Node.js, Python - на коне

Спасибо, но я спрашивал не про то, с чего начать изучать (в университете основы JAVA изучал). Вопрос у меня заключается в том, какой из этих двух вариантов выбрать, исходя из того, что сейчас 2021-й год и исходя из того, что не хочу возвращаться на Windows.

Побыстрее в чём? В вебе ж всё в сеть и базу упирается.

только по этой причине портанули C# с ASP на линь, под линем никто и не пишет в этих корпорациях, тупо хостят свои жирные монолиты

Вот это не знал. Поэтому и интересно было, юзает кто-то ASP под Linux или нет.

Только если у вас нет вычислений.

Честно говоря, ни разу в API не видел сколь угодно тяжёлые вычисления. Точнее видел, но они были сделаны через очереди (то есть юзерский запрос не висел в ожидании завершения обработки)

Время отклика АПИ может быть снижено из-за нагрузки из-за сложных вычислений.

Это всё к тому, что выбор более быстрого языка не будет недостатком.

Товарищ почти все правильно написал. На Java не все легаси, но 90% это унылые CRUD. И быстрый старт это не про java, но т.к. на ней пишут больше банковский софт то такой проблемы не стоит, банки и фин.организации облачными платформами не пользуются. В общем писать CRUDы скучно, если умеешь их писать на python,php,go то зачем изучать как делать тоже самое на java?

И я сомневаюсь что те кто пишет бэк на C# пишут код в linux. Кого не спрашивал, все больше теорию рассказывали про то как можно использовать .NET Core под linux, и никто не сказал что он пишет под linux.

Можешь начать изучать фреймворк JPA, раз Java знаешь по школьному курсу.

Было бы здорово, если бы каждый, отметившийся в комментариях, также указывал свой опыт, а также решения (либо коммерческие, либо с открытым кодом, но известные), к созданию которых он был причастен.

Глядь — и понтов бы поубавилось. Да и бестолковых комментариев (на тему, кто «побыстрее») тоже.

Я в настоящее время пишу на Kotlin (JVM), и результат моих трудов работает в т. ч. под Linux. А вообще на Java пишу уже больше 20 лет — с конца 90-х. В основном Solaris и Linux.

В то же время, стек .NET Core вызывает интерес, а то, что Майкрософт даже выпускает пакеты для Debian, — подогревает интерес ещё больше. Там же можно писать под Linux на F#, а это, практически, тот же OCaml, только с нормальной стандартной библиотекой и работающим параллелизмом!

Я бы рекомендовал попробовать решить простую задачу (так, чтобы уложиться в выходные) двумя способами, используя обе технологии. Под JVM я бы рекомендовал, наверное, таки Kotlin, благо обучающих материалов масса (после трёх лет работы с Kotlin возвращаться на Java не хочется).

А потом проанализируй собственный опыт и выбери между JVM и ASP.NET Core сам.

Сергей, если бы я не опасался показаться пристрастным, то плюсанул бы =)

А вообще (хотя это оффтопик) хочу сказать тебе спасибо. Давеча раскопал в хламе два старых Z10 (вернее, один старый, а один в масле), нашёл в сети firmware — а там в README ты упомянут. Ну и инструкции по прошивке на motofan.ru, я так понимаю, в основном тобой писаны. В общем, спасибо.

Спасибо за ответ! Абсолютно согласен по поводу указания опыта. Последую вашему примеру: мой опыт разработки - 10 лет.

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

Вопрос по большей части не в том, что именно выбрать, а что имеет смысл использовать/изучать. Исходя из того, что пишут выше, получается, что C# под Linux особо смысла использовать вообще нет.

Если не секрет, какого плана софт на Kotlin пишете? (Интересует, веб или нет)

если умеешь их писать на python,php,go то зачем изучать как делать тоже самое на java?

php: динамическая типизация, отсутствие асинхронности (можно рассуждать долго на тему нужна она там или нет, но лично мне иногда её не хватает при написании тех же грабберов, из-за чего приходится юзать python/go)

python: динамическая типизация, дофигища магии, отсутствие нормальных ORM типа TypeORM и отсутствие хотя бы одного квери-билдера, кроме Pypika. Sqlalchemy - монстр с кучей магии и очень далёкий от SQL (глядя на эти конструкции, вообще не ясно, что там в базу уйдёт и в каком количестве)

go: всё классно, но чтобы написать нормальное юзер френдли API, надо весьма сильно постараться. Как минимум, валидация JSON с фронта - боль и страдания. Если с фронта прилетает неправильный тип (вместо {"age":10} приходит {"age":"10"}), то обработать это нормально (указать юзеру, в каком именно поле ошибка, когда их куча) невозможно без кучи самописных костылей. То есть всё как-то слишком уж деревянненько.

nodeJS: юзабельно только в связке с тайпскриптом, поэтому из фреймворков остаётся лишь один NestJS - выбора особого нет. Так или иначе, всё равно приходится окунаться в js с его убогой типизацией и проблемами.

Так что по сути и остаётся либо C#, либо Java.

У меня дежавю. На обоих можно «писать под Линукс». Для этого же ничего не надо делать(если не дёргаешь нативные либы). У .NET, к примеру, официальные репы для популярных дистров.

Вопрос по большей части не в том, что именно выбрать, а что имеет смысл использовать/изучать. Исходя из того, что пишут выше, получается, что C# под Linux особо смысла использовать вообще нет.

Я бы сказал, что C# под Linux – это новая и пока что недооценённая экосистема. В целом, Microsoft породил немало революционных технологий, но не все из них «взлетели».

Как следствие новизны экосистемы – на Linux почти наверняка будут наблюдаться специфичные баги, которые будут портить прикладным разработчикам (т. е. вам) кровь и которые отнюдь не сразу будут исправлены. Если интересно – взгляните на багтрекер WSL2.

Т. е., я бы сказал, что работа JVM на Linux (и не только) уже буквально вылизана за годы использования.

Если не секрет, какого плана софт на Kotlin пишете? (Интересует, веб или нет)

Прямо сейчас – desktop. Но на Kotlin можно писать всё ровно то же самое, что пишут на Java. Голову на отсечение не дам, но рискну предположить, что в продукте TeamCity (в котором присутствует веб) есть часть кода на языке Kotlin. Ну хотя бы потому, что код на Java может быть преобразован в Kotlin автоматически, средствами IDE.

Более того, если использовать Kotlin multiplatform, то часть кода на Kotlin можно вообще «разделить» между frontend (JavaScript) и backend (JVM).

Если все перечисленное тобой сравнить с Java:

динамическая типизация

Статическая типизация конечно благо, на стороне C# еще null safety, в актуальных версиях C# информацию о nullablity переменной/поля можно указать при декларировании типа - String? name. В java этого не хватает, но зато в Kotlin с этим все хоршо, и там еще есть куча интересных абстракций которые позволяют писать очень выразительный код, или же код который будет выглядеть как магия (Мощь языка располагает писать свой DSL, и это нужно вовремя останавливать).

отсутствие нормальных ORM

Есть несколько хороших ORM, Hibernate самый известный из них.

хотя бы одного квери-билдера

Query builder, их почти нет, я думаю ты не найдешь ничего подходящего.

Если с фронта прилетает неправильный тип (вместо {«age»:10} приходит {«age»:«10»}), то обработать это нормально (указать юзеру, в каком именно поле ошибка, когда их куча) невозможно.

Если мы говорим про Java на backend то почти любой жаба разраб положится на фреймворк. Если он не делает что нужно, то придется гуглить. Библиотек сериализации/десериализации JSON две - Jackson и Gson (конечно их больше, но 95% случаев одна из этих двух работают под капотом любого фреймворка), про них тоже придется гуглить. Короче, вместо написания кода будет гуглинг.

дофигища магии

spring framework не использует магию, он состоит из магии.

P.S. Коммерческий опыт на Java с 2007 года.

Query builder, их почти нет, я думаю ты не найдешь ничего подходящего.

Для java есть JOOQ, в php есть Doctrine с классным квери билдером, в Go есть squirrel, в js есть TypeORM, где квери-билдер тоже классный и достаточно низкоуровневый. А вот в Python низкоуровневых квери-билдеров по сути и нет.

Насчёт остального понял - спасибо!

Понял, спасибо. А есть смысл ковырять Котлин, обладая базовыми знаниями Java?

Простите, не удержусь... =)))

Щас самый писк - это быстрый старт, быстрая обработка запроса и смерть,

Мне это до невозможности напомнило CGI на С. Тот же жизненный цикл процесса. Потом изобретут web-приложения на FastCGI и будем считать что всё вернулось на круги своя. =))) Между CGI на С и веб-аппликухами с FastCGI мимоходом опять прикрутят какой-нибудь язычёк типа Perl к разработке бекэндов и до кучи изобретут ещё один язычёк типа php… Где-то я это уже видел, знаете ли… =)))

Обо мне. Порядка 20 лет в разработке всякой вебни от случая к случаю, в т.ч. и RESTful API на С. Слезать с С не собираюсь. =)

А есть смысл ковырять Котлин, обладая базовыми знаниями Java?

Да.

Короче, вместо написания кода будет гуглинг.

Актуально что у жабы, что у дотнета.

Делал дискорд бота с веб-админкой для него же на netcore/aspcore 3.0, свежак был на то время. С документацией было паршиво, много устаревшей инфы (о некоторых ломающих изменениях можно реально было только прочитать у них на гитхабе, предварительно подорвавшись). По неопытности залез в виндоспецифичные API (да они у кросплатформенного неткора есть из коробки, в частности примитивы синхронизации). Но в итоге сделал, развернули под линуксом, работает

На жабе пришлось читать исходники Spring Security, чтобы понять как реализовать кастомный бекенд для аутентификации - документация реально по верхам, примеров нигде нет, максимум примитивные скопипащенные туториалы из 2010 года от Mr. Dr. Raja Kumar.

(но вообще фичу оценил, у дотнета нормально возможности провалиться в исходники 3rd party библиотек тупо нет, по крайней мере в vs, не знаю как там у rider)

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

Сейчас компилируемые в натив языки снова в моде, как и JIT, а на си писать без libuv и аналогов никто не будет в здравом уме, для этих целей сейчас есть Go

Судя по обилию синтаксического сахара, c# – это своего рода c++ современности. Не стоит вскрывать эту тему без реальной необходимости.

Ну и по классическому определению анонимных экспертов, раз на условном солярисе не работает, значит на самом деле не кроссплатформенное.

Да, на С не все.

Сейчас компилируемые в натив языки снова в моде, как и JIT, а на си писать без libuv и аналогов никто не будет в здравом уме, для этих целей сейчас есть Go

Просто, libuv/libevent это для случая, если мы хотим запилить ещё и свой веб-сервер до кучи. А так-то, если использовать nginx (равно как и любой другой веб-сервер), то с начала 2000-х (или конца 90-х, уже не помню), когда разработали FastCGI и спеку на них, на С или С++ можно было создавать persistent web-applications. Основных отличий от CGI-приложений было два. Это то, что приблуды с fastcgi взаимодействовали с сервером не через stdin/stdout/stderr как CGI, а через сокеты и можно было не запускать-останавливать приблуду на каждый CGI-запрос, а запустил (в т.ч. и на удалённом хосте) и пусть работает. Это было дешевле чем запускать-останавливать при каждом запросе, т.к. существовали проблемы с производительностью например при логине в СУБД и работе с нею. В персистент это решается проще. Ну и получалось поставить nginx, apache, lighttpd как фронтенд и отправить всю обработку на бэкэнд в виде своих приложений.

Фронтэндом в данном случае выступает тот же nginx (в принципе, почти все серваки поддерживают эту технологию). Он получает запросы от браузера как обычно и возвращает клиенту то, что ему выплюнуло fastcgi-приложение, которое работает как бэкэнд и где происходит обработка пользовательского запроса. А уж что именно там за запросы, это дело вообще десятое. С микросервисами там тоже проще было. Одно приложение в бэкэнде по сути и есть именно такой «микросервис».

Это потом уже прикрутили fastcgi к php. Ровным счётом ничего нового кроме громадного оверхеда по отношению к С. Но людям нравится, почему бы и нет? =)

Для С++ всё было несколько хуже, т.к. изначально FastCGI это «чистый» С, там внутри были редифайны того же printf(), потоков не было в принципе, но сейчас вот Yandex намутил вариант FastCGI Daemon для С++. Не мой вариант, т.к. я по-проще как-то справляюсь, но есть, можно пользоваться.

Ненужно писать сервер, можно упростить себе жизнь. Точнее, не всегда нужно писать сервер. =)

Вот я и улыбнулся когда прочёл Ваше описание того, что сейчас снова в моду входит. Уж больно знакомо. Колесо совершило очередной оборот. =)))

Так что ты не указал то проекты в которых участвовал? Не здорово, не круто.

главное не php, а все остальное без разницы

О...

Очередной мамкин теоретик-недопрограммист. Всё что ты перечислил, все это говно. Есть только Си.

Почему?

но я спрашивал не про то, с чего начать изучать

Давай не тупи? А то я Криса достану! ©
Слабай тестовый проект и всё станет на свои места.

MS сделала очень развитую инфраструктуру.
Код лаконичный, с новыми плюхами (чтобы всем угодить), в Net ты можешь тоже писать на чём угодно.

Быстрый старт вполне понятен. Зачем смерть постоянно?

С точки зрения стабильности и «дубовости» лучший вариант это JVM/Java. Также есть варианты JVM/Kotlin, JVM/Scala, которые заменяют Java на более развитые языки. У JVM кросс-платформенность с рождения, качество виртуальной машины за десятки лет отточено до идеала.

.NET Core это рабочий вариант, C# как язык получше Java, но не факт, что лучше Kotlin/Scala. Но в первую очередь он сделан для тех, кто годами сидел на Windows и сейчас хочет деплоить на Linux. Лично я не вижу никаких существенных преимуществ у .NET перед JVM.

Java не умирает, на ней начинают новые проекты.

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

Лично я бы советовал изучить Rust. Он принципиально быстрей и он может решать те задачи, которые не решаются на Python/Go.

Так что ты не указал то проекты в которых участвовал? Не здорово, не круто.

Да, самому стыдно. Наверное, это потому, что я дешёвый понтовила.

P.S. JetBrains/TeamCity, JetBrains/CLion. Это из того, что используется прямо сейчас.

По теме - такие вопросы задают со времён появления ЯП как таковых.

Единственный нормальный ответ - попробуй все, сформируй свое мнение

Насчёт «серьезности» Go вообще не парься. Несерьёзный язык это какой-то Nim, VLang на полтора разработчика. Go вообще не из той категории

Я бы плюсанул Go и Rust, но исключил Python. Ибо, чем больше работы (благодаря статической типизации) может сделать за инженера компилятор, тем меньше инженеру придётся писать тестов. Т. е. тесты, безусловно, нужны, но можно сконцентрироваться на более важных/осмысленных тестовых сценариях.

Время отклика АПИ может быть снижено из-за нагрузки из-за сложных вычислений.

Ну тогда на сишечке надо считать.

Не понимаю, что именно встанет на свои места. Вот сделаю я, скажем, на Net приложение, запущу под Linux. И как я выясню, что никто из C#-разрабов, например, под Linux код не пишет, ибо есть какие-то там проблемы и неудобства (с которыми я просто не столкнулся ещё)?

spring framework не использует магию, он состоит из магии.

Лорчую. Когда трогаешь его впервые, кажется, что это чистая магия.

Насчёт всего понял, спасибо!

Кроме «Лично я бы советовал изучить Rust». А смысл? Задач, где он бы пригодился, у меня нет (производительности Go хватает), да и вакансий (если припрёт искать работу с ним) вообще, считай, нет.

В Python есть зачаточная типизация (тут), которая покрывает большинство нужд.

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

А какие проблемы должны тебя ждать?
Сферический конь в вакууме?

Ты такие вопросы задаёшь странные. В web будешь писать? Там с этим всё прелестно. GUI в процессе. Но ты и сам можешь всё почитать.

Java не умирает, на ней начинают новые проекты.

https://dou.ua/lenta/articles/language-rating-jan-2021/

Для хомячков джава слишком сложная.

Такие опросы ничего не показывают. Среди тех, кто в них голосует, технологии выбирают дай бог 10%, а остальные пишут на том, на чём им сказали. Его можно оценивать, как мечты джуниоров (которые, скорей всего, изменят своё мнение со временем), а не как что-то, показывающее реальное положение дел.

Среди тех, кто в них голосует, технологии выбирают дай бог 10%, а остальные пишут на том, на чём им сказали

Smalltalk был убита джавой из-за того, что энтерпрайз выбрал джаву (она была быстрее). Это всё равно имеет значение.

Кроме того, там есть

личные предпочтения

.

Вот о том и речь: одни пишут «конечно, C#», другие - «конечно, JAVA» (ну, JVM, не суть)

Лол, ну а чего ты ожидал?