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

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

0

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

Бек на питоне, отдельные сервисы обработки мультимедийного контента на плюсах, клиенты под iOS на свифте, под андроид на Java. Или весь бек на PHP, сервисы на Java, веб-приложение на JS\TS. В чём противоречие-то?

0

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

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

0

Сообщение от Usaga Аргументация кончилась?

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

0

Сообщение от Curry Для крупного бизнеса "языки эти, всякие", это всё технология, она их мало интересует.

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

0

Сообщение от Fulcrum_013 Ну вообще то это правильно.

А я и не писал что это не правильно. Это правда жизни.

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

А Usaga, пишет что все крупные проекты крупных фирм гетерогенные. Т.е. лепят из кусков, что насобирали для проекта. И авторов этих кусков.

0

Сообщение от Curry Т.е. лепят из кусков, что насобирали для проекта

Не ну говноляпство то оно всегда процветает в тех кругах где Usagи прозябают. Особенно в опенспейсах и опенсорсах. Ляп-ляп и в продакшин. Они потому в опенспейсах и сидят что в кабинетах запах от кода невыносимый будет. Вообще серьезные разработки большой толпой не делаются в принципе.

0

Сообщение от Curry Я привожу это как пример неэффективности. Для крупного бизнеса "языки эти, всякие", это всё технология, она их мало интересует. Для них важны совсем другие вещи - поиск партнёров, экономика (привлечения инвестиций, IPO всякие), реклама. В программировании они не разбираются, они не в этом специалисты. И удачный бизнес проект не столько от технологий зависит, сколько от вышеперечисленного. По этому, аргументы "крупные фирмы используют то то" не катит. Они сами не знают чего используют (ан масс). И это не только в IT сфере.

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

Сообщение от Curry крупные проекты крупных фирм гетерогенные. Т.е. лепят из кусков, что насобирали для проекта.

Не лепят, а выбирают то, что подходит к задаче наилучшим образом. Я уже приводил пример: PHP для фронт-серверов, плюсы или ещё чего для каких-то отдельных специализированных сервисов. Да, может быть и легаси, но, в основном, это обдуманные шаги.

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

Это вы в зеркале увидели своё отражение. Доказать тут ничего не можете вы. И вы же чушь оголтелую несёте, чуть что.

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

Сообщение от Fulcrum_013 Не ну говноляпство то оно всегда процветает в тех кругах где Usagи прозябают.

Сказало пугало лесное, которое GC ненавидит, а показать примером почему - не может.

0

Сообщение от Usaga Сказало пугало лесное, которое GC ненавидит, а показать примером почему - не может.

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

0

Fulcrum_013, вы ничего не показали. Где код на C# или Java, где будет видно, что GC бесполезен или вообще сам язык? Где, Карл? Нету нифига. А то, что вы показывали я уже опроверг.

Всё, сдулись?

0

Сообщение от Usaga А то, что вы показывали я уже опроверг.

Не видел.

Сообщение от Usaga вы ничего не показали.

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

Сообщение от Usaga Где код на C# или Java, где будет видно, что GC бесполезен или вообще сам язык?

А где математический пруф пригодности JAva или C# Или вообще GC к автоматическому управлению временем жизни объектов и ресурсов по правилам ООП?
Нету? И не будет.
Так что вы сдулись по самые немогу.

0

Сообщение от Fulcrum_013 Не видел.

Правильно, иначе пришлось бы признать, что не прав.

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

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

Сообщение от Fulcrum_013 А где математический пруф пригодности JAva или C# Или вообще GC к автоматическому управлению временем жизни объектов и ресурсов по правилам ООП? Нету? И не будет. Так что вы сдулись по самые немогу.

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

0

[ni

Сообщение от Usaga Код на управляемых языках прекрасно работает и позволяет решать сложные задачи. Обратного доказать вы не можете.

Значит как примеры в студию средствами только GC которых вы :
1. Своевременного автоматического высвобождения ресурсов (вышел из скопа/обнулил ссылку в массиве/поле объекта/вышел из скопа объект владеющий объектом содержащим ресурс и т.д. - ресурс инстантно высвобоился).
2. Корректной (без висячих зомбаков) работы слабых ссылок.
3. Двойной/множественной композиции. Это когда разрыв любой из нескольких слабо-владеющих ссылок должен инстантно уничтожить объект

С четкими алгоритмическими обоснованиями как именно GC это автоматически обработал.

Ни одного рабочего примера я от вас так и не увидел. Так же как и каких то потуг обосновать каким именно образом ваш GC способен это разрулить.

Так что харе звиздеть. Идите учите матчасть и не мелите глюпости . Потому что ничего из этого вы предоставить не сможете.

0

Сообщение от Fulcrum_013 1. Своевременного автоматического высвобождения ресурсов (вышел из скопа/обнулил ссылку в массиве/поле объекта/вышел из скопа объект владеющий объектом содержащим ресурс и т.д. - ресурс инстантно высвобоился).

Причём тут GC?

Сообщение от Fulcrum_013 2. Корректной (без висячих зомбаков) работы слабых ссылок.

Вы пытались привести такой пример завязывая модель на контролы в форме и обозвать это "зомбаками". Я эти зависимости развернул и "зомбаки" пропали.

Сообщение от Fulcrum_013 3. Двойной/множественной композиции. Это когда разрыв любой из нескольких слабо-владеющих ссылок должен инстантно уничтожить объект

"Инстантное" уничтожение объекта не является вменяемым требованием. Когда придёт его время уничтожаться, тогда GC и соберёт его.

Сообщение от Fulcrum_013 Ни одного рабочего примера я от вас так и не увидел. Так же как и каких то потуг обосновать каким именно образом ваш GC способен это разрулить. Так что харе звиздеть. Идите учите матчасть и не мелите глюпости . Потому что ничего из этого вы предоставить не сможете.

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

А всё то, что приводили вы я кодом же и опроверг.

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

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

0

Сообщение от Usaga Вы пытались привести такой пример завязывая модель на контролы в форме и обозвать это "зомбаками". Я эти зависимости развернул и "зомбаки" пропали.

А кто вам сказал что ее разворачивать корректно? Покажите как GC решит именно эту задачу потому что в реальном пименени ни о каком развоачивании речи быть не может в принципе.

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

Сообщение от Usaga "Инстантное" уничтожение объекта не является вменяемым требованием.

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

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

Сообщение от Usaga А всё то, что приводили вы я кодом же и опроверг.

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

0

Сообщение от Fulcrum_013 А кто вам сказал что ее разворачивать корректно?

Потому, что UI должен ссылаться на бизнес-логику, а не бизнес-логика должна держать ссылки на UI. Вы этого не знали? Ну да, о чём это я. Вы же деструктор руками вызываете в плюсах...

Сообщение от Fulcrum_013 Абсолютно вменяемым. Для ООП важно своевременное логическое удаление объектов из модели.

Так логическое или физическое в памяти? Вы определитесь, это же разные вещи.

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

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

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

Это и есть опровержение. Больше никакого кода вы родить не смогли. Значит и подтвердить свою правоту вы не можете.

0

Сообщение от Usaga Потому, что UI должен ссылаться на бизнес-логику, а не бизнес-логика должна держать ссылки на UI.

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

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

Сообщение от Usaga Я требовал от вас практических примеров кода. То дерьмо (именно дерьмо), что вы показать смогли, я опроверг небольшими правками этого же самого кода. И всё начинало работать, утечки пропадали, сборка шла.

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

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

Сообщение от Usaga Так логическое или физическое в памяти?

Так GC ни то ни другое своевременно не умеет. Но именно задачу логического удаления в первую очередь предназначена решать современная автоматика. Хотя ООП в принципе без разницы когда как и будет ли вообще переиспользована память удаленного объекта. Но вот необходимость делать обход мусора для решения задач именно инстантного логического удаления объектов позволяет и задачу управления памятью решать на несколько порядков более эффективным способом чем GC. Это уже не говоря о статической композиции,(по сути автоматической имплементации управления на основе регионов для частных случаев), которой манаджед лишен напрочь, и экземпляров классов на стеке и т.д. Это уже не говоря о том что ни композицию GC не умеет в принципе (владеющая ссылка при композиции не препятсвует удалению, но при ее разрыве объект на который ссылаютс безоговорочно удаляется) ни агрегацию корректно.

0

Сообщение от Usaga Конечно, самим директорам это всё до фонаря, но на авось там ничего не оставляется.

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

Насчёт GC. Я не утверждаю что на языках с GC нельзя написать то же что на языках без GC (за исключением скорости/времени отклика). Однако, он чаще усложняет код. Возьмём граф в каждой вершине которого есть объекты захватывающие неуправляемые ресурсы. То есть ресурсы освобождаются не при выходе из скопа, а по какому то сложному алгоритму исключения вершин. Тогда для объектов вершин нужно поместить код освобождения ресурсов в некую функцию, скажем, Dispose. А при исключении вершины самим нужно убедится что она никак в программе не используется и вызвать для неё Dispose. GC тут не помощник.
А теперь, господа присяжные заседатели, объясните мне чем это лучше механизма автовызова деструкторов С++ ?
Вероятность забыть, не освободить ресурс, во втором случае меньше. Используя механизм автовызова деструкторов строятся смартпоинтеры, которые значительно автоматизируют управление любыми ресурсами включая память.

Почему же GC так распространён?
Известно (хотя бы по киберфоруму), что начинающие изучать программирование на неуправляемом языке вначале учатся рулить памятью (программы со множеством октрытых хендлов у них будут много позже) и путаются в собственном коде, забывают удалять выделенную память, злоупотребляют арифметкой указателей. Языки c GC лишают их возможности сделать такие элементарные ошибки, такие языки можно уподобить детским ходункам. Они позволяют им пройти первые азы программирования , приучая к себе. Потом ходунки начинают мешаться, но привычка уже выработана. Те кто поумнее потом и рады бы отбросить ходунки, но их наниматели и сами в ходунках. Приходится приспосабливаться.

p.s. Если бы в учебниках по C++ начинали бы учить работать с памятью со смартпоинтеров, возможно, желающих использовать его было бы больше. Может такие учебники и есть, но я про них не знаю. Во всех что знаю учат рулить памятью вручную, и это легко объяснимо - иначе пришлось бы с начала объяснять как устроены смартпоинтеры, а это требует многих отдельных тем; либо давать смартпоинтеры как некий чёрный ящик обещая объяснить как это работает позднее. Я думаю, что такой подход был бы лучше.

0

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

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

Сообщение от Curry Если бы в учебниках по C++ начинали бы учить работать с памятью со смартпоинтеров, возможно, желающих использовать его было бы больше.

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

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

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

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

Добавлено через 35 минут
Вот именно поэтому околовсячексие конторы очень не любят проектную документацию и делают ставку на неквалифицированных спецов. Они возразить начальству не в состоянии а тем более аргументированно. Т.е. главная цель в таких конторах - распил бабок бюжета/инвесторов, раз уж на з/п спецам способным сделать все как положенно не нашкребли. Ну и менеджеры того же пошиба.

0

Сообщение от Fulcrum_013 Вот именно поэтому околовсячексие конторы очень не любят проектную документацию и делают ставку на неквалифицированных спецов.

Именно так.

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

Сообщение от Fulcrum_013 Гораздо важнее научить работать с памятью именно вручную.

Это при систематическом обучении. А большинство понятно как учатся, или их учат. Вот у них и получается неприязнь к неуправляемым языкам поскольку обилие шишек на лбу к этому располагает. Отсюда гладенько вытекает объяcнение распространённости языков с GC.

0

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

Сообщение от Curry Однако, он чаще усложняет код.

Когда же из Haskell'а GC уберут?

0