Почему крупный бекенд пишут на C#/Java?

Java EE вроде уже убрали из стандарта

Кто? Oracle?

теперь оно называется Jakarta EE и перешло под управление Eclipse Foundation.

Реализация сути не меняет.

Потому что среди джава/сишарпа нет идиотов, кто будет пилить код в Vi и рефакторить грепом. Такого просто на мороз сразу отправят.

Бред, вообще аргумент мимо кассы. Лично знаю в enterprise-секторе кучу программистов на Java которые довольно активно пользуются Vim’ом, особенно если нужно что-то быстро поправить и провести мелкий рефакторинг. Пока у коллег запустится тормозная IDEA – пользователь Vim’а уже сделает коммит. Но это ещё что, я знавал и людей, которые работали в крупнейших IT-гигантах и банковской сфере и для разработки на Java активно использовали Emacs, особенно для рефакторинга. Писали специально-заточенные под задачи текстовой обработки сценарии на Emacs Lisp’е и вполне себе результативно и качественно выполняли свою работу.

Так что не нужно ударяться в фанатизм. IDEA и подобные инструменты конечно удобны и очень сильно экономят время, но они не покрывают всех кейсов. Хороший специалист всегда использует то, что удобно для быстрого и эффективного решения задачи вместо слепого надрачивания на инструмент. Поэтому многим разработчикам удобнее запустить Vim, быстро сделать правку и отправить изменение на билд-ферму, пока у джунов с приросшими к мышке пальцами открываются окна IDEA/Eclipse.

Пока у коллег запустится тормозная IDEA – пользователь Vim’а уже сделает коммит.

И сломает сборку.

Не ломает. Тот кто использует Vim на проекте обычно очень хорошо разбирается в кодовой базе и помнит где что находится. Да и не голый Vim подобные разрабочики обычно запускают, а обмазанный всякими LSP.

У меня была ситуация на JS, когда в БД лежал VARCHAR, а мой код ожидал BIGINT. В TypeScript (а куда без него и нормального автокомплита в IDE) всё было прекрасно проаннотированно как number, а по факту приезжал string. И проблема в том, что код работал. Просто странно. А в Java он бы сразу упал с ошибкой преобразования типов. Люди ошибаются (а те кто уверяют, что не ошибаются, ошибаются на порядок чаще), но если код упадёт, то его просто откатят на прошлую версию и создут новую таску в джире. А если код работает, но странно, то последствия могут быть любыми вплоть до многомиллиардных убытков, которые когда будут замечены уже будут слишком поздно.

На Java результатом будет «11».

Пока у коллег запустится тормозная IDEA

А зачем её запускать? На ноуте она у меня всегда запущена, как и у линукса аптайм под месяц, пока не прилетит обновление.

А на 16 ядерном райзене и памятью с низкими таймингами, не замечаешь, что оно жирное.

многим разработчикам удобнее запустить Vim, быстро сделать правку и отправить изменение на билд-ферму, пока у джунов с приросшими к мышке пальцами открываются окна IDEA/Eclipse

И в IDE есть горячие клавиши не хуже Vim.

обработки сценарии на Emacs Lisp’е и вполне себе результативно и качественно выполняли свою работу

Ну, есть поехавшие и упоротые. Те самые незаменимые. Исключение подтверждающее правило.

Тот кто использует Vim на проекте обычно очень хорошо разбирается в кодовой базе и помнит где что находится

И каждый день вдумчиво просматривает все коммиты десятка других членов команды в проекте на несколько сотен тысяч строк кода?

Такая система будет не масштабироваться горизонтально, потому что у такого программиста будет падать производительность пропорционально количеству разработчиков в команде.

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

Почему производительность будет падать? Из-за vim? Обоснуй.

Из-за ручного труда.

В IDE видно глазами, где что не так. А в Vim надо барабанить по клавиатуре со скоростью бешеного кролика, чтобы разузнать подноготную проблемы.

в Vim надо барабанить по клавиатуре

а в IDE нужно судорожно дергать мышкой

Ну так в vim же обычно набивают всякими плагинами для выполнения аналогичных ide задач. Кроме того, при исправлении бага или разработке фичи все равно нужно большинство времени читать и вводить код. И чем тут ide принципиально отличается?

Я про «знает кодовую базу». Кодовую базу меняет не один разработчик, а множество, каждый из которых имеет разный уровень скиллов и разное понимание проекта.

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

А можно просто держать в голове общую архитектуру проекта, а детали вспоминать через автокомплит и подсказки IDE. Тогда у тебя будут всегда актуальные данные. «Вкалывают роботы, счастлив человек» (c)

При этом в языках без аннотаций типов в том или ином виде автокомплит выдаёт погоду на марсе.

Тогда чем Vim отличается от IDE и зачем противопоставляется?

Код вводит все равно быстрее тот, кто банально печатает быстрее (при том, что и тот и тот знают, что вводить).

Так же, как и на js и на c#

Без автокомплита и подсветки всяких сомнительных мест

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

А что за подсветка сомнительных мест? Ошибки/предупреждения? Разве в vim нет плагинов для этого, как и для автодополнения?

Хз. Я бы не противопоставлял.

Тогда чем Vim отличается от IDE и зачем противопоставляется?

В IDE фокус внимания следует за взглядом. В Vim — за печатаемым символом.

В IDE фокус внимания следует за взглядом

Это еще что за фича?

Поэтому оно не особо нужно, когда хорошо знаешь кодовую базу, используемые фреймворки и т.п.

Сколько человек работает с тобой в команде?

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

ChatGPT?

электрическими сигналами с толстенным кабелем прямо в биржу

енто как? В любом случае такое не доступно простым торгашам, а профи, квази сам себе брокер.

Нет. Я.

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

8

Так или иначе вакансии на эту тему на C++ есть.

Это решается современными средствами и культурой разработки. Если база своя то интроспекция схемы prisma сгенерирует типы точно по базе. Если данные из неподконтрольных источников то все входы проверяются схемами (например на zod) и типы выводятся по ним же.

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

Это решается современными средствами и культурой разработки. Если база своя то интроспекция схемы prisma сгенерирует типы точно по базе. Если данные из неподконтрольных источников то все входы проверяются схемами (например на zod) и типы выводятся по ним же.

Т.е. в случае отсутствия статических типов мы вынуждены использовать стороние инструменты для компенсации отсутствия этих типов и вот этот знаменитый инструмент «культура разработки» (который пронизан человеческим фактором). И в чем тогда пофит? Может взять изначально статически типизированный язык?

Системы типов имеют свои ограничения как и по сложности компилятора и обучения, так и по необходимости загрязнять ими код и обходить отсутствующие вещи вроде зав. типов. Также в практических языках система типов легко обходится и не имеет достаточную мощность чтобы выразить все инварианты так что проверка их адекватности ложится на ревьювера (человека). У статической типизации есть своя область применимости, где-то оптимальней без нее (тесты + более читаемый код), где-то с ней. В современных проектах у всех typescript который применяется как линтер и используется только там где его применение повысит качество кода и продуктивность разработки.

культурой разработки

Видел вот недавно целых две культуры - в одной запихали числа строками в JSON, в другой отдали Питону самому подбирать тип целого для строки, он и рад подбирать наименьшее подходящее - то int2, то int4.

У нас с вами разное понимание культуры разработки. Мое понимание не включает наличие этой культуры у всех существующих разработчиков.

Пока у коллег запустится тормозная IDEA – пользователь Vim’а уже сделает коммит.

Дикий Запад, грязная улица какого-то городишки с населением 40 человек. На улице стоят два погромиста, руки которых замерли над клавиатурами. Играет тревожная музыка, откуда-то прокатилось по своим делам перекати-поле. Погромисты угрюмо смотрят друг на друга из под широполых шляп.

У вас там действительно счет идёт на доли секунд?

а те кто уверяют, что не ошибаются

Или врут или просто дураки.

Ну это прямо адский код ревью, как же я его не люблю, а вот когда все автоматизированно, на статических анализаторах то это замечательно (когда сделано не для галочки).
Внедряется новый чек, анализируется командой, команда голосует за/против новых правил в коде, на CI работает какой-нибудь sonar, в IDE плагины, все пишут код так чтоб не добавлять новых warnings, а на старый код (уже написанный когда-то) заводятся минорные баги на правку стиля. Язык Java позволяет накрутить кучу статического анализа на почти все возможные случаи. Код стилесткически становится очень стройным, до того что ты сам не сможешь отличить свой код от кода коллеги, и при вызове blame удивляешься результату :)

То же самое происходит в хорошей команде на любом языке. Это не означает что статическая типизация это серебряная пуля и отменяет необходимость писать нормально код, проверять входные данные и заботится о том что вливается в мастер.

С java у меня контрпример когда 3 человека на бэке за месяц даже форматирование кода не настроили у себя и мешают табы с пробелами, не говоря про постоянно мертвый стэнд т.к. в CI только у фронта настроены линтеры.

Системы типов имеют свои ограничения как и по сложности компилятора

Так эта слодность перемещается в интерпретатор

по сложности обучения

В динамически типизированном языке все равно есть типы. То, что их можно менять в прлцессе исполнения, а в статически типизирлванном нет - не большой объем знаний.

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

Как и в динамически типизированных языках - все один хрен. Однако в статически типизированных языках по крайней мере часть ошибок несоответствия исключит компилятор.

тесты + более читаемый код

Хм. Очень притянуто за уши. Читаемость нарушается больше за счет запутанных нелогичных действий, а не за счет объявления типов.

статическая типизация предпочтительнее, так как упрощает рефакторинг

Вот это я щас орнул в голосину.

числа строками в JSON

Это же JSON, там разве не всё - строка?

Почему нельзя взять тот же Python,PHP, Ruby, Golang?

Взять можно, но зачем? Уже есть тонны кода на жабе, проще продолжать на жабе. Тем более что под JVM щас тоже полно модных язычков. Жаба это такой КОБОЛ 2.0, не надо тут искать сакрального смысла.

Написать можно. И даже поддерживать, наверное, можно. Но вот только усилий это потребует больше

Да откуда вы лезете? На практике доля ошибок, когда используется несовместимый тип параметра функции ничтожна. Причём такая ситуация всё равно приводит к ошибке и т.о. выявляется ещё в процессе разработки, не говоря уже про разные виды тестирования.

Наверно я недостаточно точно выразил свои мысли. Я хотел сказать скорее то что ошибка то что с базы пришел не тот тип и никто это не проверил это не столько проблема TS или JS, а сколько качества кода что к типам было беспочвенное доверие. Такая же проблема могла быть и в java если бы поля в модели писались вручную и падение было бы только при вызове кода ее использующую.

После чтение TAPL/ATTAPL и игр с написанием своего языка и добавления туда системы типов начинаешь видеть насколько небесплатные типы. Но также небесплатные и эти неявные преобразования в JS и он далеко не идеальный язык.

В clojure с этим сильно лучше и если JS без TS использовать это сумашествие, то clojure вполне приятно. Но из-за того что это лисп, еще и поверх jvm в прод его тащить это слишком серьезное решение.

Вот это я щас орнул в голосину.

Ори громче. Большинству людей удобнее обнаруживать ошибки на стадии компиляции, а не отлавливать их в рантайме. Я вот хорошо помню времена, когда в С++ не было override, и в результате изменения сигнатуры виртальной функции какой-то редко используемый код запросто мог перестать вызываться. А в языке с динамической типизацией таких граблей гораздо больше.

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

Система типов, это не только ценный мех параметры функций. Тип определяет набор операций разрешённых над объектом, а системой типов определяются правила преобразования типов, их интерпретации и взаимодействия.

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

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

Без сомнения всё это можно осуществить и на языках со слабой системой типов. Но усилий это потребует больше.

Даже на Brainfuck, теоретически, можно писать и поддерживать программные системы для Ынтырпрайза, но на Java это делать просто удобнее.

В clojure с этим сильно лучше и если JS без TS использовать это сумашествие, то clojure вполне приятно.

Приятно? А ничего что в clojure уже с какой-то версии из коробки поставляется с type hint, и в частности хинты (явное задание типа) позволяют в некоторых случаях повысить производительность, потому как вместо рефлекшена будет прямой вызов метода, как в нормальных языках.

Это же JSON, там разве не всё - строка?

Ждал, что в БД лежит int2 внутри JSON. Там другого и лежать-то не должно было.

Получил примерно такое:

SELECT * FROM json_to_recordset('[{"a":40000},{"a":null}]'::json) AS (a int2);
ERROR: value "40000" is out of range for type smallint

SELECT * FROM json_to_recordset('[{"a":"1"},{"a":""}]'::json) AS (a int2);
ERROR: invalid input syntax for type smallint: ""

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

Ну как Ъ вимер, начну с простого - когда в вим (неовим) запилят автоматическое переключение раскладки на английский язык с последнего языка ввода и обратно при переходе в режим команд и выходе из него соответственно?