Подскажите перспективный ЯП, которому требуются батарейки

+1 к Racket

Надо голосовалку сделать. «Какой язык перспективный?»

P.S. +1 к Racket

Ну, раз про Си++ больше никто не хочет спросить, то начну я. А как бы ты «продал» этот язык? Что в него интересного, чего нет в других? Какая может быть причина начинать на Си++ новый проект в 2017 году?

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

Движок для AAA игры писать больше не на чем.

А Rust?

У раста батареек мало. Ну и вопрос в компиляции под всякие приставки, в том числе мобильные, типа switch.

Ну и я сомневаюсь, что кто-то возьмёт язык, которому всего 2 года, для разработки игры за десятки миллионов. Риски слишком большие. Проще писать на C++, как и прежде.

Принимается. А еще что можно начать писать на Си++?

Батарейки для С++ только ленивый еще не писал.

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

Какая может быть причина начинать на Си++ новый проект в 2017 году?

Причины такие же, как и 10, и 15, и 20 лет назад. Язык позволяет писать на высоком уровне, но при этом держать все под контролем, плюс опускаться на самый низкий уровень, если это необходимо.

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

Огромное количество литературы. Каким бы сложным C++ не был, сколько бы в нем не было граблей, это все уже многократно описано. Существует несколько широко и не очень широко известных гайдов о том, как писать на C++, чтобы не отстреливать себе ничего. Какие-то из них (тот же MISRA-C++) являются промышленными стандартами. Новым языкам до всего этого еще идти и идти.

Плюс к тому, какая бы ущербная не была стандартная библиотека у C++, вокруг написано много всего, что можно брать и использовать как есть (ACE, Boost, POCO, ICU — яркие примеры), либо из чего можно брать либо готовые куски, либо идеи.

Что до прикладных областей, то различные околосистемные вещи, ПО промежуточного слоя (СУБД, MQ-шные брокеры), САПР и пр. ресурсоемкие приложения (вроде Lightroom/Photoshop/FinalCut и т.д.), большие и тяжелые расчеты (вроде расчетов прогнозов погоды, моделирования химических реакций, деформация упругих тел, термодинамика и т.д.), имитационное моделирование в больших масштабах... Вот тоже игростроение выше в качестве примера привели.

Upd. Еще задачи из области промышленной автоматизации. А так же сложные встраиваемые системы (вроде управления бортовым оборудованием для авионики, автомобилей и т.д.).

Ну или несколько лет назад сам был удивлен, когда узнал, что некоторые крупные компании (вроде Dropbox-а и Microsoft-а) используют C++ для разработки ядер своих мобильных приложений. Мол, ядро делается на С++ и в одном и том же виде работает на разных платформах, а GUI уже делается нативным (на Android-е с помощью Java, на iOS с помощью Objective-C). И выбор этот был сделан не просто так, а потому, что другого такого языка на тот момент просто не нашлось. Да и сейчас ситуация принципиально не изменилась.

Сам C++ уже сильно изменился, C++98 и C++11 — это уже как два совсем разных языка, хотя портирование с C++98 на C++11 зачастую происходит без особых проблем. При том, что многие, кто хает C++, и C++98 толком не видели, скорее опираются на какие-то байки из самого начала 90-х.

Поэтому C++ и требуется больше батареек, хороших и разных. Кому-то, например, нужен http-сервер с поддержкой исключений, кому-то — без оных. И делать один проект, который удовлетворит и первых, и вторых, слишком затратно. Пусть будет два независимых.

Всегда поражало, что Си++ - один из редких языков, по которому достаточно много книг, где описано то, как не надо писать код. Взять книги тех же Саттера или Мейерса. Если говорить о других языках, то там обычно показывают, как писать код. Хотя вспомнил. У меня была такая советская книжка «Ошибки-ловушки при программировании на Фортране». Больше ничего вспомнить не могу по другим языкам.

имитационное моделирование в больших масштабах...

А что здесь имеется в виду? Ты про HLA?

вроде Dropbox

Ходят слухи, что ядро клиента переписывают на Rust. Поживём - увидим.

Про зоопарк систем сборки забыли. Вот где собака зарыта.

Больше ничего вспомнить не могу по другим языкам.

Так другие языки не дают прямой доступ к памяти.

С другой стороны, в расте часто ругают за unwrap в примерах. Мол не учите плохому. Про unsafe вообще молчу.

Про книжки конечно не скажу, но достаточно загуглить на тему: как сделать, чтобы питон(другая скриптота) не тормозил. Вам сразу расскажут, что ваш код говно и так писать на питоне не нужно.

Уже выше расписали, но повторю свою привычную мантру: AAA игры, сложный прикладной софт (фотошопы, кады, браузеры, ...), БД и прочее.

PS: я хоть и не люблю C++, но факт остаётся фактом.

В го нет нормального парсера json yaml

В этом нет проблемы, проинсталлил зависимость и тебе пофиг. Или вообще включил в свой проект, если библиотека маленькая и просто собирается

Всегда поражало

Это к теме разговора не имеет отношения.

А что здесь имеется в виду? Ты про HLA?

What is HLA?

Речь про отдельные виды имитационного моделирования (в частности actor-based model), в которых проводятся эксперименты с большим количеством элементов в моделях. И когда модели обсчитываются часами, если не сутками. ЗЫ. Сам с такими вещами дела не имел, только наслышан, в том числе и об использовании С++ в качестве языка реализации.

Кому как. Для меня это одна из важнейших проблем C++.

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

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

Может быть, agent-based modeling?

Тут, кстати, такая интересная вещь. Если там создается много-много кратко-живущих объектов (агенты, состояния, события, задержки и т.п.), то мы сразу попадаем в область, где царят языки со сборщиком мусора, которые и заточены на такой сценарий. Как бы тут Си++ не плелся в самом конце по скорости. Есть у меня большие сомнения на сей счет...

Для меня это одна из важнейших проблем C++.

Это как «кто-то в интернете не прав» что ли? :)

HLA - High Level Architecture

Ну так это не я отрицаю существования проблемы.

Границы ответственности системы сборки заканчиваются вместе со сборкой проекта и его установкой. Какая мне разница чем собирается библиотека, скажем openssl, когда она предоставляет заголовки и либы, и даже файлы pkg-config, которые поддерживают все мейнстримные системы сборки

Это становится проблемой, когда нам нужно собирать прогу/либу не под линем и/или с конкретными версиями зависимостей.

В других языках эту проблему хоть как-то решают.

Более того, если у библиотеки интерфейс на C, то даже нет видимой пользователю разницы на каком языку она реализована: на C, C++, Fortran, ... (не то, что чем ее собирали)

При чём тут С?

Это становится проблемой, когда нам нужно собирать прогу/либу не под линем и/или с конкретными версиями зависимостей.

Используй метасборочную систему по вкусу, или репоизторий вроде vpckg или msys. Кстати они языконезависимые

Вы предлагаете использовать разные системы сборки для каждой ОС?

Может быть, agent-based modeling?

Agent-based model — это официальное название, насколько я понимаю.

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

Опять городские легенды.

Необязательно, их полно кросс-платформенных, например conan или craft. Для cmake есть встроенный ExternalProject и hunter

Kotlin

Всякие Racket, D и прочие существуют уже давольно давно и прошли пик своих возможностей как по мне. Реально перспективный язык - Red и возможности батареек неограничены. Две особенности - придется неплохо попотеть чтобы понять что и как работает, взрыв мозга уровня хаскеля и лиспа обеспечен. Во вторых в языке GC и I/O до сих пор не готовы, то есть уровень пока еще добатареичный.

Pony, Chapel

Язык годный, спору нет, но зачем ему батарейки, если он без проблем интегрируется с любой нижележащей платформой?

Вот если бы микрософтовский компилятор был хотя по основным флагам совместим с gcc (или его перестали бы использовать:), это было бы полезнее

Ага, и apple бросила бы свой форк clang. Мечты-мечты. К счастью, мне хватает mingw под виндой.

Ага, и apple бросила бы свой форк clang.

У него флаги те же самые, так что какая разница

К счастью, мне хватает mingw под виндой.

Ну тогда выбор мета-сборщиков увеличивается, можно использовать например jhbuild и spack

Agent-based model - это собственно имитационная модель, а agent-based modeling - это парадигма, в рамках которой создаются модели.

Почему троллмоде? Там что ни либа - то говно от студента-недоучки,

То, что Страуструп - это как полтора человека - я понял. А кого из K&R в получеловеки записали?

Яр конечно

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

Лол :-) Ну и на каком таком высоком уровне позволяет писать цепепе? :-) Цепепе как был низкоуровневым, таким как Си, так и остался, несмотря на новые стандарты :-)

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

Лол :-) Всё смешалось - уровень оптимизаций компиляторов и инструментарий :-) Инструментарий - это IDE :-) Ну и какими такими «развитыми» IDE для цепепе пользуешься лично ты? :-) Нет сомнения, что пользуешься ты каким-нибудь Vim :-)

Огромное количество литературы. Каким бы сложным C++ не был, сколько бы в нем не было граблей, это все уже многократно описано. Существует несколько широко и не очень широко известных гайдов о том, как писать на C++, чтобы не отстреливать себе ничего. Какие-то из них (тот же MISRA-C++) являются промышленными стандартами. Новым языкам до всего этого еще идти и идти.

При этом, чтобы осилить эти тонны литературы, нужно лет 10 :-) Речь не о том, чтобы прочитать десятки тысяч страниц под тортик с чаем, а о том, чтобы после прочтения этой макулатуры суметь это всё логично применить :-) Лол :-)

Плюс к тому, какая бы ущербная не была стандартная библиотека у C++

Стандартная библиотека цепепе не такая уж и плохая :-) Правда в ней нет даже банального HTTP-сервера с банальной схемой «трэд на коннекшн» :-) И это в 2017 году, когда всем рулит веб, а не какой-то там куте :-) Лол :-)

При том, что многие, кто хает C++, и C++98 толком не видели, скорее опираются на какие-то байки из самого начала 90-х.

Лол :-) Ну кто не видел цепепе, не в самом то деле? :-) Хахаха :-)

Подскажите перспективный ЯП

Самый перспективный язык программирования - JavaScript :-) Нравится это, или не нравится, но это единственный язык, который действительно имеет большие перспективы :-) Даже несмотря на всякого рода ахинею о том, что вот вот уже скоро на подходе WebAssembly и, что настанет, наконец, эпоха, когда JS будет ненужен, а все станут писать вэб на каком-нибудь кулязычке вроде цепепе :-) Лол :-)

Любая программа на C++ где есть хоть один вызов new (явный или нет) использует исключения.

Red это у которого офиц. учебник начинается с rebol? Перспективный? Старый мертвый язык из 90х.

У Страуструпа в TС++PL 3rd ed. во введении всё показано и рассказано.

-fno-exceptions

Любая программа на C++ где есть хоть один вызов new (явный или нет) использует исключения.

Очередная ахинея от любителя цепепе, который не знает элементарных основ этого пресловутого цепепе :-) Вот тебе код на цепепе с new и без исключений, и без всяких -fno-exceptions:

#include <new>

int main()
{
  delete new (std::nothrow) int(5);
}

У Страуструпа в TС++PL 3rd ed. во введении всё показано и рассказано.

Во-первых, это издание посвящено цепепе-98 :-) С другой стороны, цепепе-17 ни на миллиметр не стал более высокоуровневым по сравнению с цепепе-98 :-) Добавили груду костылей, это да :-) Про высокоуровневые абстракции - не, не слышали :-)

Во-вторых, там, во введении, рассказывается про парадигмы программирования касаемо цепепе :-) Итогом является парадигма обобщённого программирования :-) На цепепе это означает шаблоны :--) Как шаблоны цепепе делают из цепепе высокоуровневый язык программирования, и с какого перепуга так вообще, не понятно :-) Лол :-)