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

Сила привычки.

Python,PHP, Ruby, Golang

Говно без статической типизации.

Golang
без статической типизации

Погуглил бы сначала, что ли.

Т.е крупный проект, используя динамическую типизацию написать чтобы он работал отлично нельзя? Звучит как-то нелепо.

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

Если не знаешь в чем причина, причина в деньгах.

Мне видятся тут следующие причины:
* маркетинг, куда же без него. И за Java и за C# стояли большие компании и вливали деньги
* статическая типизация, которая позволила сделать IDE, что сильно облегчает работу с кодовой базой.
* для работы с ними разработчикам нужно сильно меньше мозгов, в сравнении с главным конкурентом С++. А в ряде случаев то и совсем мозгов не нужно.
* как ни крути, они безопасней того же С++. Тем более С++ средины 90-х

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

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

Код, написанный 20 лет назад на Java или C# скорее всего без всяких изменений заработает и на совремённых платформах. Или с косметическими изменениями, причём есть руководства по миграции, в тех случаях, когда всё же необходимо, что-то подточить.

Теперь сравни это с Python,PHP, Ruby, Golang...

Да можно, кто тебе запретил-то.

Наверно, он имел ввиду слабую типизацию. Когда позволительно 1+'1' с неочевидным для наследников Алгола результатом. А иногда и с шокирующим.

Батарейки (как минимум, у C#) забыл.

Вообще мне C# показался лёгким-гладким как python, только ещё и c полным microsoft и любителям паскаль/цэ хорошо заходит.

крупный бекенд

потому что там где нужны жилые кварталы и промзоны - там железо и бетон.

а говнецо и палочки - не то чтобы из этого совсем нельзя ничего строить, но желательно не выше второго этажа.

Golang

Он только вчера появился.

Python, Ruby,

Они медленнее, надо учитывать что java ввалилась в корпоративный рынок в начале 2000-х, процессоры тогда были другие. JVM платформа предложила кучу батареек типа JSP, Servlets, Applets, кросс-платформенный GUI.
Потом сторонние вендоры наделали кучу новых батареек, Tomcat, Spring, GWT, парсинг PDF, несколько бесплатных IDE и т.д.

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

Потому что всякая скриптота не годится для серьёзных проектов. Хотя, иногда, они таки оказываются написанными на ней (всякие вконтакты например на пхп), но это только потому что начиналось оно с несерьёзного.

Именно так.

Именно так, от того и появились type hinting в том же python и других динамических языках.

Код, написанный 20 лет назад на Java или C# скорее всего без всяких изменений заработает и на совремённых платформах. Или с косметическими изменениями, причём есть руководства по миграции, в тех случаях, когда всё же необходимо, что-то подточить.

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

А вот код написанный 10 лет назад на Го до сих пор работает.

Честно говоря, я на С# ничего никогда не писал. Не знаю как там с этим. :)
В Жабе то такие себе батарейки. Только низкоуровневые.

Ну когда я писал (начало 10-х), прям всё хорошо было. Но под винду.

Ну и когда году в 2017 понадобилось поправить кусок кода сайта, пришлось ставить старую версию VS на древний ноут с XP и пересобирать.

Исторически сложилось. В бородатые времена всякие клиент-банки были написаны сплошь и рядом на java-апплетах. Я даже как-то застал этот период, когда сисадминил. Требовался вроде IE7+ и JRE с плагином для браузера. Потом уже перекатили на новомодный фронт-энд, а не выкидывать же готовую команду бэк-энда, которая еще и будет все помогать переводить на новые рельсы.

Чо за батарейки такие?

Ха. Я мигрировал проект на JDK17 (с 11). Так половина проекта тупо развалилась — старый Спринг с ней не работает, а все остальное с новым спрингом.

я хз, всё для http, разные парсеры, матан всякий. Всё очень удобно на тот момент было.

А вот код написанный 10 лет назад на Го до сих пор работает.

А 10 лет назад на Го было что-то, кроме хелловорлдов?

Публично? Не помню. Но из серьезного был уже vitess в YouTube.

Потому что обычно не пишут с нуля, а берут древнее но рабочее.

В итоге все равно падает периодически, но особых косяков нет и sla в норме.

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

Какое отношение жаба апплеты у клиентов имеют к кишкам банка?

Вопрос риторический.

Апплеты это внешнее проявление внутреннего образа мыслей.

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

Потому что Rust, Lisp и Haskell круче

Наверно, он имел ввиду слабую типизацию. Когда позволительно 1+‘1’ с неочевидным для наследников Алгола результатом. А иногда и с шокирующим.

Никогда не писал на ЯП с сильной типизацией. Можете пояснить, в чём проблема слабой типизации? Если я пишу на js, то знаю, что 1+‘1’ = 11) В какой гипотетической ситуации это может выйти боком?)

Ты путаешь сильную и слабую типизацию со статической и динамической.

JavaScript - Динамическая | Слабая | Неявная
Ruby - Динамическая | Сильная | Неявная
Python - Динамическая | Сильная | Неявная
Java - Статическая | Сильная | Явная
PHP - Динамическая | Слабая | Неявная
C - Статическая | Слабая | Явная
C++ - Статическая | Слабая | Явная
Perl - Динамическая | Слабая | Неявная
Objective-C - Статическая | Слабая | Явная
C# - Статическая | Сильная | Явная
Haskell - Статическая | Сильная | Неявная
Common Lisp - Динамическая | Сильная | Неявная
D - Статическая | Сильная | Явная
Delphi - Статическая | Сильная | Явная

старый Спринг с ней не работает, а все остальное с новым спрингом.

Это вот проблема выбора нестандартного решения (Spring Framework). С Java EE такого быть не может - там почти всё гладко прошло (заменяли постепенно, по частям).

Если я пишу на js, то знаю, что 1+‘1’ = 11

На Java и C# будет такой же результат.

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

«Кто выще бье, тот краще грает?».

Т.е крупный проект, используя динамическую типизацию написать чтобы он работал отлично нельзя? Звучит как-то нелепо.

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

И Java, и C# делают упор на надёжность и лёгкость написания сложных программных систем. Выявление большого объёма ошибок ещё на стадии компиляции, за счёт сильной статической типизации. Наличие автоматической сборки мусора, что уменьшает количество проблем с доступом к памяти. Механизмы перехвата и обработки возникших исключительных ситуаций. Исполнение программ в полностью контролируемой среде виртуальных машин, с автоматическим контролем доступа на уровне абстракций объектов, а не областей памяти.

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

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

Четвёртая причина, это техническая поддержка. За Java и C# стоят такие компании как Oracle и Microsoft. К ним, в случае возникновения проблем всегда можно обратиться за платной консультацией. В случае отсутствия технической поддержки, с проблемами придётся разбираться своими силами.

Наконец не последнюю роль играет уровень абстракции языка. И Java, и C# ограничены рамками виртуальной машины. В идеале, программы пишутся и работают в рамках абстракций предоставляемых виртуальными машинами. Это приводит к нескольким последствиям:

• Для запуска уже имеющихся программ на новой программно-аппаратной платформе, достаточно дождаться переноса на эту платформу виртуальной машины и стандартных библиотек. Сколько разных машинных архитектур появлялось в серверном сегменте за последние 30 лет? x86, x86-64, SPARC, DEC Alpha, POWER, Intel Itanium, etc…
• Обеспечивается относительная лёгкость и предсказуемость масштабирования: для увеличения мощности программно-аппаратного комплекса, достаточно переместить софт на более быстрое железо. Производительность программной подсистемы увеличится безо всякой низкоуровневой оптимизации исходного кода, и его перекомпиляции на величину, приблизительно равную инкременту производительности аппаратной платформы, вне зависимости от того произошла ли смена одной машинной архитектуры на другую, или нет.
• Если спецификации виртуальной машины остаются обратно совместимыми, то появляется возможность продолжительного использования программы, даже при утере её исходного кода.

Но крупные проекты пишутся не только на Java, или C#, несмотря на предоставляемые ими преимущества. К примеру, по данным Википедии, YouTube написан на Python и Go, а Facebook на C++ и Hack.

Да вполне можно, и пишут.

Сложно назвать Spring нестандартным решением. Но, думаю, на практике, с JEE у тебя будет примерно то же самое, так как тебе, все равно, придется тащить кучу других библиотек. Если это 5 лет не обновлять то... Проблема же не только в SpringMVC была, но и с Hibernate, Mockito, Junit.

Сложно назвать Spring нестандартным решением.

Отчего же? Spring нестандартен. Все его идеи реализованы в Java EE и стандартизованы JCP. Дальше он не нужен.

Когда я пишу на каком-либо ЯП, я делаю это механически. А при проектировании алгоритма контроля типов нет, знаете ли.

Если я пишу на js, то знаю, что 1+‘1’ = 11) В какой гипотетической ситуации это может выйти боком?)

Когда у тебя a+b о типе которых ты знаешь примерно нифига.

Почему … ?

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

Не знаю отчего, но это де факто стандарт в индустрии.

Написать проект можно на любом языке, но вот поддерживать проект, который пишут 6 человек (из которых два джуна, двое пришли недавно, а оставшиеся двое «старичков» на проекте - всего лишь год) на статически-типизированном языке в разы проще, чем на динамическом. Если что, устриц ел (работаю с круптыми проектами и на Java, и на Javascript).

JavaScript - Динамическая | Слабая | Неявная

PHP - Динамическая | Слабая | Неявная

Если у них одинаковая типизация, тогда почему 1 + ‘1’ в php ошибку выдаст, а в js нет?

Пока писал, подумал, что возможно дело в том, что в js сложение и конкатенация делаются одинаково)

С Java EE такого быть не может - там почти всё гладко прошло (заменяли постепенно, по частям).

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

Потому что среди джава/сишарпа нет идиотов, кто будет пилить код в Vi и рефакторить грепом. Такого просто на мороз сразу отправят. Люди пишут и рефакторят крупный код в профессиональной IDE. А среди скриптоты и голанга таких полно (да и IDE им никак не поможет уйти от рефакторинга через греп). Поэтому выбор очевиден.

Да, джава с сишарпами изначально позиционировалась как замена крестам. А вся твоя скриптота непонятно чему позиционировалась. Голанг позиционировался как ЯП для табуна макак не умеющих писать код. PHP так вооще Personal Home Page расшифровывается. И вот с таким бекграундом ты предлагаешь на таких ЯП пилить крупный бекенд для банковского сектора?

Если у них одинаковая типизация, тогда почему 1 + ‘1’ в php ошибку выдаст, а в js нет?

Одинаковая по сути, но в деталях конечно же есть различия.