Вышел Rust 1.0

вычислительные задачи, которые решаются с помощью C++.

Математика на плюсах - на мой взгляд от безысходности. Всё равно если нужна быстрая числомолотилка имеет смысл взять либо OpenCL, либо если ещё нет реализации, написать на SIMD через интринсики компилятора, либо в экзотических случаях типа моего - сгрузить на DSP. На плюсах остаётся только логическая группировка данных и возможно некоторая подготовка входных данных. ИМХО конечно. Олдовые товарищи могут помянуть фортран, но я фортран не умею.

Пакеты вроде Photoshop/Lightroom разрабатываются на C++. Серьезные CAD-системы.

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

Телеком. Там так же требования к производительности. Плюс байты в каналах на C++ удобнее перепаковывать, чем на Java.

В телекоме «своя атмосфера». Там есть erlang, который свою нишу тоже имеет.

Компиляторы.

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

Ядра СУБД.

Тут пожалуй тоже соглашусь.

Долго ты мялся, стесняешься?

Ну знаю я твой racket. Хорошая игрушка. А схему даже можно сказать люблю. Но совершенно не пригодная для работы вещь. Самое полезное из чего-то подобного, что мне удалось применять на практике - гнутый guile. И то потом заменили универсальным движком, умеющим питон и js(v8) и всем стало только лучше...

Common Lisp тоже пробовал. Все, что в нем полезно на практике, относится к обычному императивному программированию. Макросы хороши, но почему-то потом они куда-то ушли из кода(где-то полгода). А итоговую версию проекта писали на питоне с крестовыми модулями...

Ну emacs lisp ещё адекватно, но это язык не для того=)

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

Если бы знал, то тебе вряд ли пришло бы в голову их сравнивать.

Там есть erlang, который свою нишу тоже имеет.

Слухи о засилье erlang-а в телекоме, боюсь, несколько преувеличены со времен триумфа AXD301. Хотя даже при этом забывают, что в софтовой начинке AXD301 кроме кучи строк на Erlang-е было еще приличное количество кода на C++ и С (и даже чуть-чуть на Java).

Но Ericsson был не единственным производителем телеком-оборудования. Alcatel и Lucent использовали в своих продуктах C и C++.

На серверах это произошло еще раньше.

Но и сейчас сервера пишут на C++ и даже на Си. Задачи разные бывают. Иногда эти старички оказываются дешевле.

Но и сейчас сервера пишут на C++ и даже на Си. Задачи разные бывают. Иногда эти старички оказываются дешевле.

Я знаю :)

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

Разница в том, что в С++ надо явно указывать, как ты захватываешь окружение ([=], [&], [x=std::move(x)] ), а Rust выводит это сам.

Он умеет читать мысли?

Уже даже этого достаточно, чтобы плеваться. :-)

Если не знать, где применять кресты нужно, а где нет, то да. Придётся плеваться.

У C++ нет единого сообщества.

Согласен, компиляторы с чистого си начали переезжать на плюсы

Кто-то еще переехал кроме gcc?

Назвать C++ спорным инструментом для разработки компилятора - это ничего не сказать. Разве что преследуется скорость компиляции как в случае clang, и то хотелось бы сравнить с реализацией на каком-нибудь MLton. Ну и собственно Rust здесь выглядит на голову перспективнее.

Я пока недостаточно знаю Rust, чтобы аргументировать это субъективное ощущение :(

На мой взгляд в расте «всё подходящее» есть. Ну кроме библиотек, но это тоже понятно. А так есть всякие удобные возможности: матч, алгебраические типы данных, модули, «всё выражение» и т.д.

Из «неудобных» моментов: макросы не супер понятные, но это для написания, пользоваться вполне нормально. Опять же, в плюсах макросы и того хуже, а использование шаблонов для мегапрограммирования тоже не для слабых духом. Ансейф может потребоваться для «простых» (в плюсах) случаев. Тут опять же, библиотеки спасать должны. Разве что исключений может не хватать тем, кто к ним привык (как я).

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

Акробатика это.

Чем плоха «акробатика»? Что ты в это понятие вкладываешь?

И почему тут раст не годится?

П.С. Пдфку (пока) не читал.

Он умеет читать мысли?

Не совсем. В расте нет необходимости (и возможности) перечислить, что захватывать - оно само выводится по использованию. Если тип не копируемый, то будет автоматически перемещён (обычное поведение раста «при присваивании»). Если замыкание мутабельное, то может менять «захваченные» переменные, то есть они будут захвачены по мутабельной ссылке (если не были перемещены).

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

Шланг и подозреваю что MS компилятор.

И почему тут раст не годится?

Я так понял, там матрицы на шаблонах с размером в качестве параметра, что позволит компилятору при желании разворачивать любые циклы. На Rust-е такое в лучшем случае через макросы и отдельные типы типа Matrix_4x4 можно сделать. Если нужно будет перемножение матриц разных размеров, придётся руками «инстанцировать» нужные функции и тд.

Подёргай себя за конец уже и расслабся, эксперт ты наш. :-) То, что Common Lisp императивен и без сопливых все знают, так же, как и годности Elisp. Правда, последний знают единицы, зато кукарекают про крутость Emacs. :-)

Если бы ты знал, тебе бы в голову не пришлось так сливать и лажаться :-)

Проблема в том, что без C++ можно обойтись везде. Абсолютно везде. :-)

На Rust-е такое в лучшем случае через макросы и отдельные типы типа Matrix_4x4 можно сделать.

Ну макросы - да, придётся использовать, но не вижу в этом проблемы.

Если нужно будет перемножение матриц разных размеров, придётся руками «инстанцировать» нужные функции и тд.

В смысле, в расте не получится инстанцировать при использовании? Да, забавно. Интересно можно ли как-то через макросы извернуться и решить это. Хотя на первый взгляд, без дополнительных ручных указаний и правда не получится.

Кстати о геймдеве: движок на Rust'е http://www.piston.rs/

Кстати, о геймдеве. Очень бесполезная индустрия, придуманная во имя золотого тельца ради того, чтобы в конечном счёте заставить прожигать чьё-то время.

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

Единственное без чего толком не обойтись - это асм для архитектуры. Без всего остального можоно обойтись. Только вот нужно ли?

А, да, без ассемблера тоже можно обойтись.

Обобщим - «НИНУЖНА ФСЁ!»

Пока это всё эксперименты энтузиастов.

Слова типичного потребителя, который всегда ждёт всего готовенького и популярного.

Обобщим - «НИНУЖНА ФСЁ!»

Так даже с цепепе головного мозга не обобщают.

В плане игр да, я потребитель.

Жизнь — очень бессмысленная штука, придуманная во имя золотого тельца ради того, чтобы в конечном счёте заставить всех прожигать своё время. Пожалуйста, не живите.

У меня embedded головного моска, мне можно.

Жизнь — очень бессмысленная штука, придуманная во имя золотого тельца ради того, чтобы в конечном счёте заставить всех прожигать своё время.

Это только у тебя и таких как ты так, и у геймдевелоперов - тоже.

Юноша, ты ошибся. Эмбедщики так не рассуждают.

поддержу этого оратора. 20 лет на плюсах - любой мазохист дитё рядом с этим

И что же ты такого делаешь из того, что может оказаться полезным человечеству после сброса разжирневшим Солнцем своей оболочки?

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

глянь на чем сейчас пишут СУБД и удивись, ключевое слово hadoop

Чем плоха «акробатика»? Что ты в это понятие вкладываешь?

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

И почему тут раст не годится?

1) потому что для Rust нет blitz++ и прочих либ, на которых основываются библиотеки из доклада 2) то ли на users, то ли на internals.rust-lang.org я встречал жалобы на то, что Rust в нынешнем виде плохо приспособлен к трюкам, с помощью которых реализуется Си++-акробатика с матрицами.

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

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

Ну если её можно упрятать внутрь, а наружу выставить простой интерфейс, то она очень даже полезна.

В остальном понятно.

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

Фреймворк - это больше, чем просто движок, так?

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

Во-вторых, «на чем сейчас» — это, блин, смешно. СУБД всегда писали на чем угодно. Например, GemStone, одна из первых ООСУБД, была написана на SmallTalk почти 30 лет назад. А до этого существовали сетевые и иерархические СУБД, которые появились еще до того, как Страуструп начал работать над C++.

Воу, батя, откуда ты это знаешь?

Так можно вспомнить про CouchDB и заявить, что «СУБД сейчас пишут на Erlang». Все это не изменит того факта, что Oracle, MySQL, MS SQL Server и MongoDB написаны на С++.

пойду расскажу кармаку, что он просрал свою жизнь, и только какой-то анонимный чушок может помочь ему осознать тщетность прошедших лет :D

но я не удивлюсь, если гуй современного фотошопа уже накорябан на чём-то типа C#

Вроде как, адоби с 6-ых версий использует Lua для этого ;-)

Да он, вроде, и сам это уже осознает.

А я где-то встречал, что Qt во все поля.

Всё это писалось на Си++ только потому, что из двух распространенных нативных языков один (Си) был совсем убогим.

Не совсем так.

Если судить по документам эпохи, которые попадались мне на глаза - именно так.

Кроме C и C++ были еще и Ada, различные варианты Pascal, Modula-2 и Objective-C.

Из всех этих языков только Си++ был очевидным upgrade path из Си - Objective-C был анально оккупирован то ли Apple, то ли NeXT.

Modula-2, Pascal и прочие - они все проиграли к середине 80-х по одной простой причине: UNIX означал Си, а большинство продуктов, которые ты упомянул, имеют UNIX-корни. Последним гвоздем в крышку гроба был выход GNU C, дальше доминирование Си++ как upgrade path из Си было предрешено.

Ada стоит немного особняком - ее финальную ненужность (при всех крутых концепциях) я могу объяснить только одним - никому не нравится писать огромные портянки текста %) Ну и компиляторы Ады стоили дорого и появились уже после того, как Си зохавал весь мир.

MongoDB is implemented in C++.

интринсики, SIMD, DSP, OpenCL - это всё финишная прямая, когда уже задача развёрнута к такому виду, что можно сделать одну групповую операцию на пачкой данных. Т. е. уже не математика, и до этой части ещё нужно добраться, что совсем на так просто, а то вовсе не разрешимо. Фортран по нынешним временам просто невообразимо убог, даже против сишки - ну самый натуральный каменный топор. При этом у него нет абсолютно никаких преимуществ ни перед Ц ни перед крестами, в т.ч. по производительности. Зато на крестах можно в компайл-тайме проворачивать некие финты ушами, дающие прирост перфоманса до 40 - 60 % от пиковой теоретической, даже в ситуациях, когда реализацией алгоритма в лоб даже на интринсиках/ассемблере такого не достигнешь. А на сишке или, боже упаси, фортране эквивалентную простыню (которая на крестах компилятором генерится из шаблонов) ручонками набивать - издохнешь.

Нет. Смотри, есть, к примеру, UE4. В нем есть всё: и графический движок, и физика, и ввод-вывод, и всё остальное. В piston'е же нет практически ничего, даже собственной поддержки OpenGL, а в самом крэйте piston нет вообще ничего.
Зато всё заготовлено для того, чтобы прикрутить всё нужное. Графика? Вот вам PistonDevelopers/gfx_graphics. Текст? gfx_text. Камера? cam. Гуйни захотелось? conrod. От майнкрафта голова идёт кубом? gfx_voxel. Ввод, события, кватернионы — для всех этих вещей есть крэйты, которые образуют единое целое, но сам игровой движок при этом всё-таки нужно пилить самому.

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

Зачем вообще кому-то нужен был upgrade path из Си?

Если этот upgrade path был нужен и C++ стал таковым, то зачем сейчас еще один upgrade path (как из С, так и из C++)?

Является ли Rust таковым upgrade path? Тем более, что C-шные программы переделывались в C++ посредством нескольких #ifdef-ов. А простое линкование C-шного и C++ного кода и сейчас является большим подспорьем и позволяет переиспользовать чужой код. Тогда как Rust — это другой язык, другой синтаксис, другие механизмы работы с памятью (в смысле контроля со стороны компилятора)...