Язык программирования для Backend

Здравствуйте.
Халивар неизбежен, однако, мне следует задать этот вопрос.
Что сейчас лучше использовать для Backend?
Конкретнее:
1) Из того, что востребовано;
2) Из того, с чем будет проще разработка крупных проектов, включая разработку API;
3) Не JS.
Прошу конкретизировать вашу позицию.
Всем спасибо!

0

Добавлено через 40 минут
PHP vs Python для Backend в 2019
PHP vs Python для карьеры
Выбор между PHP и Python+Django
Социальная сеть. PHP vs Python+Django
Вы правда думаете, что чем больше создать одинаковых тем, тем больше вероятности что вас убедят выбрать какой то язык?

0

jonikster, я правильно понимаю, что вам совершенно пофигу на то, что лучше использовать для Backend и вы просто разводите холивары от скуки? Типа зашёл, вбросил на вентилятор и можно сидеть и смотреть на шоу? Вы ещё про GC упомяните и дельфи, чтобы прямо с конями и акробатами было, что уж...

0

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

0

Сообщение от Катафалк никакого программиста бекенда, программиста фронтенда и так далее по отдельности не существует.

Правда чтоли? Кардиохирурга и пластического хирурга тоже не бывает? Это тоже происки трепачей? Специализация только для лохов?

Сообщение от Катафалк А те, кто говорят, что они якобы программисты бекенда - это обычные недоучки с двухнедельных курсов

Угу. Ведь все системы в мире настолько крохотные, что с ними и один человек спокойно справляется, да? Бекэнд же не может быть настолько здоровенным и сложным, что на него просто отдельный человек\команда нужен?

0

Usaga, специализация разумеется бывает. Однако нельзя специализироваться на бекенде и не знать ничего про смежные области. Я сильно сомневаюсь, что кардиохирург знает все про сердце, но ничего не знает про легкие. А уж чтобы заявил - а зачем мне знать, где у человека печень? Я ж кардиохирург, зачем мне эта ваша печень. А вот среди трепачей-программистов почему то считается совершенно нормальным заявлять подобное. Я ж бекендер, зачем мне ваш фронтенд, хтмл, жаваскрипт.
На самом деле, невозможно спроектировать бекенд отдельно, фронтенд отдельно. Разработчик, даже если он пишет код только для бекенда, обязан представлять, как работает фронтенд и наоборот, это же касается всех остальных участников проекта. А если он пишет свою жаву или сишарп и понятия не имеет, что там происходит на фронте, то в итоге получится то, что и получается - тормозящее и глючащее говно, потому что система спроектирована совершенно не оптимально, интерфейсы взаимодействия не продуманы и т.д. А в таких условиях спроектировать что-то качественно совершенно невозможно, потому что так называемые бекендеры и фронтендеры будут говорить каждый на своем языке, не понимая друг друга. А потом еще в этот процесс залезут тестировщики, которые программировать даже на уровне детского сада не умеют, и будут требовать еще и для них интерфейсы адаптировать, а то им видите ли тестировать неудобно. Ну и т.д.
Все эти проблемы уже никто даже не пытается скрывать, изобретают очередной фреймворк над фреймворком и стандарт над стандартом, чтобы то фронтенд с бекендом не подрался, то тестировщиков они вместе не побили. А решение то на самом деле только одно - проектировать и разрабатывать любую систему должны люди, которые понимают ее функционирование со всех сторон и во всех подробностях. Тогда никаких проблем, для решения которых наизобретали уже десятки фреймворков и стандартов, не будет даже возникать.

0

Катафалк, во-первых, кто вам сказал, что человек специализирующийся на фронтенде\бекэнде совершенно ничего в противоположной части не смыслит? Во-вторых, попробуйте представить себе систему сложнее hello world'а или бложика. Я понимаю, что это будет трудно, но вы постарайтесь. Такую систему неизбежно придётся разделять не только на фронтенд и бекенд, но и сами стороны резать на отдельные модули, настолько всё большое. Взаимодействие этих модулей\сервисов, естественно, проектируется. Т.е. формируется API. Всё. А дальше уже идёт специализация. Как с кардиохирургом.

Повторюсь ещё раз: существуют систему сильно сложнее того, что может сделать один человек (за приемлемое время). Поэтому и начинается разбивание на фронтенды и бекенды. И видит Бог, лучше пуйскай будут два очень хороших специалиста, качественно и быстро делающих свою часть работы, чем человек-оркестр знающий всё, но хреново.

Такое разделение - естественный процесс специализации. Никакие мифические трепачи тут не имеют место быть. Технологии и сложность решаемых задач продиктовала необходимость такого разделения. И не только на эти две части, но ещё и DBA, дизайнеры, архитекторы, QA (тестировщики).

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

0

Сообщение от jonikster Что сейчас лучше использовать для Backend?

Наиболее перспективно - плюсы. Из того что сейчас в этом плане имеет наиболее развитый набор готовых либ - С++ Builder.

Сообщение от jonikster Прошу конкретизировать вашу позицию.

Веб завершает переход от пакетного режима обработки к интерактивному. А соответственно бэк переходит от короткоживущих скриптов генерирующих один ответ на один запрос к долгоживущим демонам/службам обеспечивающим работу с клиентом в режиме двусторонней инициаиции передачи. А соответственно архаичный GC и виртуальные машины в таких условиях не жизнеспособны. Кроме того все что имеет GC к ООП пригодно чуть менее чем никак потому что никаких средств автоматики годных для ООП GC не имеет от слова совсем. А ООП в подобных демонах рулило и рулить будет всегда в отличии от одноразовых скриптов где оно если и нужно то постольку поскольку.
Т.е. годится только нэтив и языки с современной автоматикой управления жизненным циклом объектов. Ну а это как ни крути но плюсы.

0

Сообщение от Fulcrum_013 Наиболее перспективно - плюсы.

Нет, не перспективно. Иначе бы давно уже использовались.

Сообщение от Fulcrum_013 А соответственно архаичный GC и виртуальные машины в таких условиях не жизнеспособны.

O, really? Доказать можете?

0

Сообщение от Usaga O, really? Доказать можете?

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

0

Fulcrum_013, но почему, тогда, управляемые языки всё равно используются в бекенде и такой бекенд всё равно прекрасно работает?

Сообщение от Fulcrum_013 бесполезный оверхед

Не имеющий никакого значения, настолько он незначительный.

0

Сообщение от Usaga Нет, не перспективно. Иначе бы давно уже использовались.

Так во всю пользуются. Все скриптовые языки только оборачивают плюсовые/сишные либы и ничего сами по себе не делают. И родилось это оборачивание только потому что на момент его рождения с динамическими библиотеками под всякими линухами и никсами было вооще никак а линковать клиента БД и прочие либы в каждый обработчик каждой сраной кнопки как это заставляет делать CGI было слишком пухло для хостингов тех времен. При этом скрипт гораздо удобнее в плане запуска в песочнице шареного хостинга. Вот и изобрели способ прилинковать все нужные либы к одному обработчику. Но CGI доживает последние дни с dll все в порядке и демон он один а соответственно и проблема исчезла в принципе, так же как и шареный хостинг уходит в небытие. Так что эта примитивная тормозная скриптопрослойка давно никому не нужна.
Он даже топик стартер говорит - только не нода. А это та же скриптопрослойка над плюсовыми либами.

Добавлено через 1 минуту

Сообщение от Usaga Не имеющий никакого значения, настолько он незначительный.

Угу. Вот к примеру сервера чатов ВК с 96-ю ГБ обрабатывают в среднем по 75 запросов в секунду на сервер и тормозят во всю. А все потому что манаджед.

0

Fulcrum_013, реализация бизнес-логики это ничего не делание и оборачивание сишных библиотек? Это новая форма бреда?

Добавлено через 1 минуту

Сообщение от Fulcrum_013 Угу. Вот к примеру сервера чатов ВК с 96-ю ГБ обрабатывают в среднем по 75 запросов в секунду на сервер и тормозят во всю. А все потому что манаджед.

Где они тормозят? Откуда информация? И по вашему, разработчики ВК такие дебилы, что нормально сделать не могут? Давайте сравним: ВК - есть и отлично работает, а ваши бредни вы чем подкрепить можете? Ничем.

0

Сообщение от Usaga управляемые языки всё равно используются в бекенде и такой бекенд всё равно прекрасно работает

Он работает пока в пакетном режиме. Т.е. пока GC вообще не успевает запускаться (т.е. выжрать предвыделенные 50-100 метров) до завершения скрипта. При этом в пакетном режиме особено при серверном рендеринге ООП для генерации страницы нужно постольку поскольку. В случае же двусторонней инициации связи и переходу к событийному оповещению клиента о изменении двнных и т.д. со стороны серва ситуация резко меняется. Здесь для внутрянки нужна вся мощь ООП.

Сообщение от Usaga Не имеющий никакого значения, настолько он незначительный.

Запустите ваш незначительный оверхед в цикле. Он начинает очень сильно возрастать. А именно в таком режиме работает демон.

0

Сообщение от Fulcrum_013 Он работает пока в пакетном режиме. Т.е. пока GC вообще не успевает запускаться (т.е. выжрать предвыделенные 50-100 метров) до завершения скрипта. При этом в пакетном режиме особено при серверном рендеринге ООП для генерации страницы нужно постольку поскольку. В случае же двусторонней инициации связи и переходу к событийному оповещению клиента о изменении двнных и т.д. со стороны серва ситуация резко меняется. Здесь для внутрянки нужна вся мощь ООП.

Что за бред? Про полнодуплексные соединения, в том числе и поверх WebSocket или WCF вы не слышали? И какая связь между GC и серверным рендерингом?

Сообщение от Fulcrum_013 Запустите ваш незначительный оверхед в цикле. Он начинает очень сильно возрастать. А именно в таком режиме работает демон.

Ниочём выполняемое в цикле остаётся ниочём. Простой пример - весь веб на управляемых языках. Всё прекрасно работает.

0

Сообщение от Usaga Где они тормозят? Откуда информация?

https://habr.com/ru/company/vk/blog/342570/

Сообщение от Usaga И по вашему, разработчики ВК такие дебилы, что нормально сделать не могут?

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

Добавлено через 1 минуту

Сообщение от Usaga Простой пример - весь веб на управляемых языках

Доля работы по обработке данных в вебе управляемыми языками составляет не боле 0,1%. И этот 0,1% дает до 90% времени выполнения. Так что эта скриптопрослойка давно лишняя. А при переходе к демонам в принципе недопустима.

Добавлено через 1 минуту

Сообщение от Usaga И какая связь между GC и серверным рендерингом?

Она в первую очередь с пакетным режимом причем очень простая. За время генерации страницы в подавляющем большинстве случаев GC просто не успевает запустить уборку ни разу.

Добавлено через 45 минут

Сообщение от Usaga Про полнодуплексные соединения, в том числе и поверх WebSocket или WCF вы не слышали?

Вот как раз для работающих с ними демонов и нужен нетив и современная автоматика.

0

Сообщение от Fulcrum_013 https://habr.com/ru/company/vk/blog/342570/

По ссылке история о том, как ребята существенно переработали архитектуру за счёт чего и получили выигрыш. Где там говорится, что о недовольстве PHP? Где там говорится, на каком языке были реализованы новые сервисы? Или вы хотите сказать, что подобные вещи реализованные на Си\С++ позволили бы вывезти бесконечную нагрузку на виртуалочке за 160 рублей?

Сообщение от Fulcrum_013 А с каких делов им вообще уметь ее делать? Все кто умеет давно деньги зарабатывают в хайтеч-конторах а не примитивными веб-хеллоувердами занимаются.

Ну так ВКонтакте вполне себе не примитивный веб-хеллоуворлд. По ссылке-то своей же сходите, да почитайте. Вконце концов они в разы больше ВКонтактов сделали, чем вы вообще считать умеете.

Сообщение от Fulcrum_013 Доля работы по обработке данных в вебе управляемыми языками составляет не боле 0,1%. И этот 0,1% дает до 90% времени выполнения. Так что эта скриптопрослойка давно лишняя. А при переходе к демонам в принципе недопустима.

Опять высосанные из пальца числа? Откуда данные?

Сообщение от Fulcrum_013 Она в первую очередь с пакетным режимом причем очень простая. За время генерации страницы в подавляющем большинстве случаев GC просто не успевает запустить уборку ни разу.

Не успевает потому, что не зачем? И где связь между серверным рендерингом и GC?

Сообщение от Fulcrum_013 Вот как раз для работающих с ними демонов и нужен нетив и современная автоматика.

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

0

Сообщение от Usaga И где связь между серверным рендерингом и GC?

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

Добавлено через 55 секунд

Сообщение от Usaga Не успевает потому, что не зачем?

Да. 50-100 метров отведенных скрипту со старта выжрать успевают только в исключительных случаях.

Добавлено через 26 секунд

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

Пруф в студию. GC не пригоден для многопоточных задач от слова совсем. А для бека в виде демона мультипооток как воздух.

Добавлено через 4 минуты

Сообщение от Usaga о ссылке история о том, как ребята существенно переработали архитектуру за счёт чего и получили выигрыш.

Естественно. Потому что алгоритмическая оптимизация всегда дает выигрыш. Но как бы там и причина проблем обрисована. А она именно в манаджед языках которые не способны обработать 75 сообщений в секунду на серве с 96ГБ памяти. Так что ап алгоритма управления памятью до ручного и алгоритмов работы со строками и прочими буферами без генерации мусора вообще все проблемы порешал бы.

Добавлено через 17 минут

Сообщение от Usaga Ну так ВКонтакте вполне себе не примитивный веб-хеллоуворлд.

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

0

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

Если под скриптами вы подразумеваете PHP, то там уже давно есть JIT и компиляция одноразовая. А даже, если и нет, то что это должно доказать? Оверхед от таких вещей ничего не значит и никого не пугает.

Сообщение от Fulcrum_013 Да. 50-100 метров отведенных скрипту со старта выжрать успевают только в исключительных случаях.

Какие 50-100 метров? Кем отведённых? Кто отжирать это собрался?

Сообщение от Fulcrum_013 Пруф в студию. GC не пригоден для многопоточных задач от слова совсем. А для бека в виде демона мультипооток как воздух.

Пожалуйста: зайдите во вконтактик и откройте чатик. И смотрите, как открывается соединение по WebSocket, которое обрабатывается фронт-сервером на PHP. С ваших слов оно работать не должно.

Сообщение от Fulcrum_013 Естественно. Потому что алгоритмическая оптимизация всегда дает выигрыш. Но как бы там и причина проблем обрисована. А она именно в манаджед языках которые не способны обработать 75 сообщений в секунду на серве с 96ГБ памяти. Так что ап алгоритма управления памятью до ручного и алгоритмов работы со строками и прочими буферами без генерации мусора вообще все проблемы порешал бы.

Там обрисовано только то, что с ростом системы текущая архитектура перестала устраивать. Её переделали и всё завертелось. Где там жалобы на управляемую природу языка? И вы можете заявить, что если бы всё сделано было на С++, то работало бы на калькуляторе обрабатывая бесконечную нагрузку?

Сообщение от Fulcrum_013 В блогах и мессенджерах смесью которого и является контакт непримитивных задач нет в принципе. Существуют большие объемы информации но не более того. Т.е. достаточно просто использования производительных алгоритмов управления памятью и параллельной обработки данных. Манаджед языки производительностью не страдают ни в одном из аспектов а вместо мультипотока имеют эмуляцию последовательного выполнения средствами мультипотока, в следствие неумения работать с аппаратным стеком и субкучами. Они даже не понимают того элементарного факта что пых не тот язык на котом возможна производительная обработка. Куда им вообще в хайтеч то с такими знаниями?

Знаете. Если судить о том, кто больше понимает, авторы ВКонтакта или ботало с КБ, то угадайте, кому я отдам предпочтение?

0

Сообщение от Usaga Пожалуйста: зайдите во вконтактик и откройте чатик.

Он у нас забанен.

Добавлено через 1 минуту

Сообщение от Usaga Если под скриптами вы подразумеваете PHP, то там уже давно есть JIT и компиляция одноразовая. А даже, если и нет, то что это должно доказать? Оверхед от таких вещей ничего не значит и никого не пугает.

Та ладно. Лучше купить сервов на 5 лямов чем алгоритмы апнуть и устранить горы ненужной работы по вашему? Ню ню.

Добавлено через 1 минуту

Сообщение от Usaga И вы можете заявить, что если бы всё сделано было на С++, то работало бы на калькуляторе обрабатывая бесконечную нагрузку?

На кулькуляторе врядли. Но спокойно бы обрабатывало куда поболе 75 сообщений на серв в секунду.

Добавлено через 45 секунд

Сообщение от Usaga И смотрите, как открывается соединение по WebSocket, которое обрабатывается фронт-сервером на PHP. С ваших слов оно работать не должно.

ТАк и не работает на одном серве. Их там под этот чатик тыщу припахали не считая серверов БД.

Добавлено через 3 минуты

Сообщение от Usaga Где там жалобы на управляемую природу языка?

Так они до них не доросли. Знаний не хватило понять откуда грабли такие растут.

Сообщение от Usaga авторы ВКонтакта

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

0