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

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

0

Сообщение от Curry Отсюда гладенько вытекает объяcнение распространённости языков с GC.

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

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


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

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

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

0

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

Я сравниваю императивные языки. Однако в Haskell из за GC всё та же проблема с автоматизацией управлением ресурсами кроме памяти. И решений этого там тоже нет, кроме как освобождение при выходе из скопа.

0

Сообщение от Curry И решений этого там тоже нет, кроме как освобождение при выходе из скопа.

А другого решения для инстантного высвобождения вообще нет. Т.е. в принципе нет. И именно оно в сочетании с правилами взаимосвязей ООП делает GC ненужным от слова совсем.

0

Сообщение от Fulcrum_013 Так GC же никоим образом тех же самых граблей не отменяет.

Отменяет. Исключает ошибки типа забыл вставить delete или ошибки с арифметикой указателей исключая её как таковую.

Сообщение от Fulcrum_013 Ну поигрались бородатые дядьки с ленивыми вычислениями в чистой среде ... и выбросили.

Нет. Продолжают играть (выпускать новые версии с новыми фишками). Придумывать новые языки (Idris).
С эффективностью выполнения, там, действительно плохо. Со скоростью разработки на нём неплохо, хотя и не без недостатков. Сложная система типов и вывод типов по Хиндли-Милнеру усложняет поддержку языка со стороны IDE.
Зато код компактный и весьма типобезопасный. Там где скорость не решает вполне приемлем, но понять достоинства не изучая его сложно.
https://code.fb.com/security/f... h-haskell/

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

Сообщение от Fulcrum_013 А другого решения для инстантного высвобождения вообще нет. Т.е. в принципе нет.

Тут я под скопом имею ввиду освобождение при выходе из блока или из функции.

0

Сообщение от Curry Исключает ошибки типа забыл вставить delete

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

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

Сообщение от Curry ошибки с арифметикой указателей

Ну как бы сам по себе GC арифметику указателей не исключает. Да и пользуют ее новички очень редко, вообще практически никогда. У нее очень специфичная область применения до которой еще дорасти надо. Причем не до самого применения а до идеи куда это приткнуть. Зато оптимизатор ее во всю пользует в любом языке.

0

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

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

Сообщение от Fulcrum_013 Ну как бы сам по себе GC арифметику указателей не исключает. Да и пользуют ее новички очень редко, вообще практически никогда.

Ещё как используют. Посмотрите вопросы начинающих. Классика: выделяет память, начинает туда писать инкриментируя указатель, потом сдвинутый пытается освободить.
А арифметика указателей в управляемых языках, как минимум, не приветствуется, и начинающим её не (препо)дают.

0

Сообщение от Curry Нужно что бы ссылка где то осталась, то есть, требуются некие структуры данных из которых элементы удаляются частично

Хватит банального вектора указателей в который указатели только засовываются а обратно никогда не высовываются.

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

Сообщение от Curry Классика: выделяет память, начинает туда писать инкриментируя указатель, потом сдвинутый пытается освободить.

Это не классика. Это клиника.

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

От симптомов болезни под названием "недопонимание задачи" ни один язык избавить не способен. А сокрытие симптомов всеми этими "безопасными для неучей" языками вообще переводят эту болезнь в разряд хронических.
Разве что только плюсы способны ее полностью вылечить, если конечно пациент выживет после прилетающих в результате недопонимания задачи граблей.

0

Сообщение от Fulcrum_013 Хватит банального вектора указателей

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

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

Сообщение от Fulcrum_013 сокрытие симптомов всеми этими "безопасными для неучей" языками

Арифметика указателей действительно потенциально опасна и её лучше избегать. Например заменить заинлайненой (де)сериализацией в бинарный поток.

0

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

Ахахаха. Ну знаю я правила оформления html/css, например. И на каждый чих мне надо рыться в сети искать ответы на вопросы. ТРАТИТЬ ВРЕМЯ, которого у Вас, видимо, предостаточно. И не надо говорить что достаточно потратить время один раз, а потом сразу в рай. Когда не специализируешься, то всегда на каждую мелочь будешь часами искать решение.

Сообщение от korvin_ В цивилизованных странах какие-то там социалочки не банят

Украина банит ватоглазники, вконтазик, яндекс. Вроде mail ru тоже. Да скоро сами себя забаним от всех =)) Кто в Китае был. признавайтесь, как вам неделя работы без гугла?

0

Сообщение от Curry Когда ссылок на вектор не останется, GC его удалит.

Только ссылок на него не останется тогда когда хеллоуверд доработает. В плюсах его точно так же ось удалит.

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

Сообщение от Curry Арифметика указателей действительно потенциально опасна и её лучше избегать.

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

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

Сообщение от Curry Арифметика указателей действительно потенциально опасна и её лучше избегать.

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

0

Сообщение от Fulcrum_013 А он то кому интересен?

Твоё мнение никому не интересно.

Сообщение от Curry Однако в Haskell из за GC всё та же проблема с автоматизацией управлением ресурсами кроме памяти. И решений этого там тоже нет, кроме как освобождение при выходе из скопа.

Ну ты напиши об этом разрабам GHC. А лучше, сразу решение предложи.

0

Сообщение от korvin_ А лучше, сразу решение предложи.

Решения нет.

0

Сообщение от zeroalef Ахахаха. Ну знаю я правила оформления html/css, например. И на каждый чих мне надо рыться в сети искать ответы на вопросы. ТРАТИТЬ ВРЕМЯ, которого у Вас, видимо, предостаточно. И не надо говорить что достаточно потратить время один раз, а потом сразу в рай. Когда не специализируешься, то всегда на каждую мелочь будешь часами искать решение.

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

0

Сообщение от Катафалк Ну так свиньи тоже очень любят в грязи часами бултыхаться

Это ложь. Свиньи -- животные чистоплотные. Неожиданно, правда?

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

Спорное утверждение =)

Сообщение от Катафалк А меж тем создание ui - это самое примитивнейшее, что только можно себе представить себе в it.

Вот видите? По мне так это ад и израиль. Никакой мыслительной работы, прожигание времени впустую. Только дурак может отождествлять примитивизм и простоту его реализации.

Сообщение от Катафалк И то, что эта задача до сих пор не автоматизирована - первейший признак того, что все современное it наводнено говнокодерами

Что касается веба (ведь я именно о нем говорил), то здесь вы кидаете камень совсем не в тот огород. Что мешает заплатить за какой-нибудь конструктор сайтов и клепать их пачками? Все равно конторы нанимают специалистов. Может автоматизировать просто невозможно из за неоднородности самого веба? В остальном чем вам RAD'ы не угодили?

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

Сообщение от korvin_ Да ты упорот

Не согласен. т а л и б а н тр а к т к а б у л + это свидетельствует об обратном. О том что фурклум прав.

0

Сообщение от Curry Решения нет.

Т.е. твой посыл: GC — херня, но лучше ничего нет. Я правильно понимаю? В премьеры-министры метишь?

0

Сообщение от korvin_ GC — херня, но лучше ничего нет.

GC — херня, но языков понаделали именно с ним (почему, я выше попытался объяснить), так что пользуемся тем что есть.
По той же причине (большинство не осиливает), не взлетел и rust, хотя вы ему пророчили некоторый взлёт. Впрочем, трудно быть Вангой.

Сообщение от korvin_ В премьеры-министры метишь?

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

0

Сообщение от Curry GC — херня, но языков понаделали именно с ним

Ну так сделай Хаскелл без GC.

Сообщение от Curry По той же причине (большинство не осиливает), не взлетел и rust, хотя вы ему пророчили некоторый взлёт.

1) По какой той?
2) Я ему точно ничего такого не пророчил. Скорее наоборот.

Сообщение от Curry Видимо, какой то премьер что то такое сказал. А я зомбоящик не смотрю, по этому смысл вашего, наверняка тонкого и едкого, замечания, возможно, достойного Вольтера, пролетел мимо меня. Ну и ладно.

Оно не тонкое и не едкое. Но вполне известное. Один известный премьер кого-то процитировал. И зомбоящик тут совершенно ни к месту:

Демократия – наихудшая форма правления, если не считать всех остальных

— подробней.

0

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

В данном случае абсолютно нетрудно было предсказать полный фейл rust. Если люди взялись лечить "ужасные проблемы" плюсов то это просто неосилянты которые как результат не понимают что они пытаются спроектиовать. Если же при этом они начали загонять под капот то что должно быть кастомизируем на уровне библиотечных средств - ну это огромный шаг назад в 60-е и фейл просто гарантирован.

Сообщение от Curry GC — херня

GC - фигня для ООП. Потому что спроектирован был для архаичного ФП как отложенный коммпрессор стека. Так что в ФП языках он в общем то на своем месте, при этом лямбды без GC пока что умеет только С++ и научился он этому очень недавно.
Но как бы с учетом того что не ООП разработка - абсолютная фигня уже лет 60 то и GC превращается в полную фигню вместе со всеми ФП-языками.
Будущее же за генерацией кода императивным кодом. Т.е. наращивание императивных средств работы со справочниками для шаблонов и т.д. т.е. дальнейший и практически полны отказ от архаичного ФП.
И с огромной вероятностью это будет сделано на базе именно С++. Единственное что для этого не хватает - JIT компилятора, для кода работающего в компайл-тайме, и нового Страуструпа. Учитывая что первое вообще не проблема, второе очень скоро появится.

0

Сообщение от korvin_ Ну так сделай Хаскелл без GC.

rust близок к тому.
А выдумывать новые языки - этим я давно переболел. Кол-во языков сокращать пора.

Сообщение от korvin_ 1) По какой той?

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

Сообщение от korvin_ Я ему точно ничего такого не пророчил.

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

Сообщение от korvin_ Но вполне известное.

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

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

Не реализуется на плюсах владение с заимствованием с нулевой стоимостью. Смысл в этом. Вы берётесь судить о том, в чём мало разбираетесь, включая и rust и ФП.

0

Сообщение от Curry Не реализуется на плюсах владение с заимствованием с нулевой стоимостью.

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

Сообщение от Curry и ФП

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

0