Зачем делают backend на разных языках?

Question

[PRAIT]

Доброго часа.
Подскажите зачем пишут backend на нескольких языках? Я понимаю что в больших проектах java и с++ это замена классическому php но нельзя ли реализовать например backend только на java или c++? Зачем писать на двух языках?

Например backend
MSN.com написан только на ASP.NET
YouTube.com написан на C, C++, Python, Java, Go

За что отвечает например C++, JAVA и GO на YouTube?
Понимаю, вопрос общий, но все же, хотя бы в теории объясните.

Спасибо!

Comments

[Pantene742]

Отвечают за то что написали на них.
Все можно на писать на C++(На этом точно все) и на Java. Все что реально физический. Ноо... На Java не все будет работать из за производительности ниже чем у первого в 40 раз. а в редких случаях 400. Но это не делает Java хуже так как то что на ней будет работать.(неважно у юзера или на сервере) будет работать хорошо. если это не что то сферх нагруженное. На Go будет работать почти как на C++ но там пока нет так много подходящих библиотек. Хотя для бэкенда уже мощные CMS. Вообще походу Go занял место в Decentralized Apps как Python в Data Analiz. Почему на нескольких одновременно. Есть такая штуковина Rebbit MQ и много похожих. На различных языках некоторые вещи очень (надежно, быстро, качественно, с возможностью дальнейшего развития можно реализовать. Наявность технических ньюансов, готовых либ. У гугла в стенах есть знатоки чего либо нами перечисленного которые берут деньги по времени работы. Гуглу надо быстро и качественно.

[PRAIT]

Pantene742,

Хотя для бэкенда уже мощные CMS.

что вы имеете ввиду? На GO уже существуют какие то cms?

Decentralized Apps как Python в Data Analiz

и вот об этом если не сложно, можно подробнее?

[PRAIT]

Sha644, Ахаха, я имел ввиду что мелкие проекты на php не пишут. :D

[Pantene742]

PRAIT, просто погуглите екзамплы децентрализованных APP. Все на Go. Да и самая популярная опен сорс библиотека для блокчейна Ethereum может быть контролируемая из Go. (Там и Java,Py,Node)
В книге "Децентрализованные приложения " также все примеры на Go. Также он очень хорошо взаимодействует с каким то плагином к докеру и можно очень круто настраивать микросервисы на Go в серверLESS.

Answer 1

[InoMono]

Возьмем например Дропбокс.

Изначально был написан на Python - это быстрее для прототипирования.
Потом был переделан на Go - для предсказуемости и скорости. Но зачем переделывать полностью? Многие куски на Python существуют там до сих пор. И работают.
И маааалюсенький кусочек был переделан на Rust - для ускорения самого узкого места.

Вот вам и 3 языка работающих одновременно в Дропбоксе на бэке.

Или имеется в данный момент свободен тот или иной специалист, который лучше знает тот или иной язык. Ему поручили - он сделал на том, что лучше знает, чтобы сделать быстрее и качественнее.

Или такова была особенность задачи. Пример с комбинацей Rust/Go выше приведен. Где то может быть лучше один язык, где то другой.

А если мы вспомним, что проект не только пишется, а еще и готовые компоненты применяются - то автоматически к любому почти проекту добавляются С/С++ те что в БД к примеру и пр. и пр. SQL - тоже язык бэкенда. И пр. и пр.

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

Answer 2

[Stalker_RED]

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

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

Comments

[PRAIT]

Спасибо за ответ, но я очень сомневаюсь что вы сможете построить дом одним лишь топором.

[Stalker_RED]

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

[InoMono]

PRAIT,

Спасибо за ответ, но я очень сомневаюсь что вы сможете построить дом одним лишь топором.

то есть вы понимаете, что нужны разные инструменты?

наши предки строили одним топором успешно. и сложные весьма строительные объекты.

да и сейчас иногда люди практикуют такое.

[mafia8]

Скорее первый этаж из камня, а второй - из дерева.

Answer 3

[Станислав Макаров]

Подскажите зачем пишут backend на нескольких языках?

Почему-то никто не сказал главный аргумент - в больших проектах понятие бэкенда весьма условно. В больших проектах уже нет одного веб-приложения, которое написано на одном языке и выполняется на одном-двух серверах. В больших проектах бэкенд - это уже набор сервисов, зачастую разнородных, иногда даже не общающихся между собой, а работающих непосредственно с клиентом (гуглите микросервисную архитектуру). Пример из нашей компании:
- веб-приложение на джанге, отдающее html-контент - тут авторизация юзеров, хранение пользовательских настроек и данных;
- сервис данных чарта - написан на Erlang для предельной стабильности и предсказуемости, а также из-за легковесных потоков (в BEAM неплохой вытесняющий планировщик);
- сервис расчёта фин. индикаторов - написан на Java, данные отдаёт через сервис на Эрланге;
- сервис сканирования бирж - написан на Go (много новых сервисов на нём пишем).
- и ещё несколько более мелких сервисов.

Каждый из этих сервисов - это даже не отдельные люди, это целые команды со своей историей, со своими требованиями к надёжности и производительности и со своей культурой в конце-концов. Сервисы очень крупные, даже если что-то не устраивает и хочется переписать на другой платформе (например, с Эрланга на Го), никто не будет этого делать просто потому что хочется, это огромные деньги и куча человеко-лет.

Answer 4

[pfg21]

тот же контактик был написан на php.
когда встала проблемма тормознутости php был написан инструмент kphp по переводу php в С++ с последующей компиляцией.
скорость работы пот очетов админов контактика выросла в два (!!) раза, для высоконагруженного сайта это очень много, в том числе и в денежном эквиваленте.
фейсбук тоже сделал подобное штуковину. это про пыха.

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

Comments

[Adamos]

Строго говоря, это ВК "тоже" - FB открыл свой HipHop за три года до KPHP.

[pfg21]

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

[Adamos]

pfg21, вы, видимо, имеете в виду виртуальную машину на базе того же HipHop.
Я с FB не общаюсь вовсе, да и с ВК минимально. Присматривать за технологиями не обязательно изнутри ;)

[pfg21]

Adamos, да. помню что фб чтото там наворотил в нескольких последующих за хипхипом проектах. но рабочий профиль далек, не изучал :)

Answer 5

[Adamos]

C++, Java, Go, PHP, Python.
Это популярные в вебе языки, выстроенные по принципу "сначала самый эффективный, но сложный в разработке и поддержке код, в конце - самый легкий в написании и правке, но наименее эффективный".
Нет никакого смысла писать весь проект на С++ - затраты будут дикими, и тебя просто обгонят конкуренты, состряпавшие работающий чуть хуже аналог из говна и палок.
Нет ничего страшного в проекте на Python - пока он не ложится под нагрузкой, и переписать часть сервиса на С++ оказывается дешевле, чем покупать новые сервера.
Вот так и получается смешение языков. Благо принципы эффективного общения отдельных сервисов друг с другом давно известны, и что у сервиса "под капотом" - совершенно не играет роли в общей архитектуре.

Comments

[0x131315]

Принцип Парето (80/20) наглядно.
Основу разрабатываем с минимальными затратами сил и времени.
По мере роста нагрузки оптимизируем некоторые наиболее медленные части, переносим на другие языки если так нужно.
Доля оптимизируемого кода от всего кода минимальна - минимальны и затраты.

[Adamos]

0x131315, на самом деле, все сложнее. В современном вебе сплошь и рядом 80% ТЗ возникает только после того, как проект запущен. Поэтому делается MVP на том, на чем получится быстрее, а потом принимается решение, нужно ли менять архитектуру целиком или только латать критичные места.

[0x131315]

Adamos, это так. Но во многих случаях это не норма, а косяк.
Если внятного ТЗ нет на старте разработки - значит постеснялись "дожать" заказчика.
Из-за кривого ТЗ время разработки увеличивается в 2-3 раза, растет риск срыва сроков.
Оно того не стоит. Проще "дожать" заказчика и родить ТЗ.

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

[Adamos]

0x131315, если делается не "еще один магазин", а что-то новое - дожимать нечего, заказчик сам узнает, что ему нужно, только после первых откликов и косяков.