Вышел Rust 1.0

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

А можно пруф? а то что-то слабо верится.

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

А почему бы тогда те же самые compile-time трюки не делать на каком-нибудь лиспе с его лютейшим метапоргоммированием и генерить, допустим, сишный выхлоп?

генерить, допустим, сишный выхлоп

Зачем он там нужен, сишный выхлоп? Думаешь, C-компилятору генерируют машинный код, который лучше того, что генерируют Lisp-компиляторы? Ты очень ошибаешься.

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

Потому что плюсы дали бОльшие возможности по структурированию кода?

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

Потому что плюсы дали бОльшие возможности по структурированию кода?

Спагетти-говнокода.

Потому что плюсы дали бОльшие возможности по структурированию кода?

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

Поэтому по мере усложнения задач усложняется и язык. При этом язык дает больше возможностей разработчику. Соответственно, С дал больше возможностей в сравнении с ассемблером, C++ дал больше возможностей по сравнению с C. В принципе, Java/C# дали больше возможностей по сравнению с C++. И т.д.

Проблема в ситуации с Rust-ом в том, что такое дробление на ниши и доминирующие языки в этих нишах уже произошло. Поэтому, если кого-то не устраивал C для каких-то задач, то можно было брать C++ (что, собственно, многие и делали) или Eiffel, или Ada. А если возможности уйти из C не было, то не факт, что такая возможность будет после появления Rust-а.

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

Вы вот выше интересовались, почему разработчики предпочитают связываться с шаблонной плюсовой магией, хотя многие вещи можно было написать на другом языке, из которого бы генерировался C++ный код. Даже в таких вещах очень сильно проявляется человеческий фактор. Например, у меня был опыт разработки eDSL на Ruby, из которых затем генерировался C++ный код. Когда об этом рассказываешь, очень многие смотрят на такие вещи негативно — мол, это же еще один язык нужно учить, нужно Ruby в уже имеющийся toolchain встраивать и т.д., и т.п.

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

Говнокод можно писать на любом языке.

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

Технологии развиваются и, по разным причинам, люди хотят их использовать. Использовать ООП в Си было неудобно, generic programming - почти невозможно.

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

Для Си - по тем же причинам, что и 25-30 лет назад; с Си++ сложнее - в нем есть многое из нужных фишек Rust, и тут уже скорее вспоминаются слова Страуструпа «Within C++, there is a much smaller and cleaner language struggling to get out». Rust очень похож на этот язык.

Является ли Rust таковым upgrade path?

Технически, для Си - да. Но это не чисто технический вопрос, так что темна вода в облацех.

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

Просто линкуется именно сишный код, а не цепепе код, благодаря name mangling.

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

Почему такое не делать на Лиспе - не знаю, может и можно, но ни разу не попадалось. Честно говоря, незнаком с лиспом, почти совсем.

Как в это описание укладывается смерть кобола? Тоже хороший был язык, написали уйму кода, по некоторым оценкам больше, чем на других языках. Но помер. То же про Perl. Про Delphi. И про множество других языков, которые были в своё время популярны, но выжить это им не помогло.

Какими бы ни были популярными языки, они умирают и на их место приходят более совершенные.

Просто линкуется именно сишный код, а не цепепе код, благодаря name mangling.

Если нужно в C использовать плюсовые библиотеки, то совсем несложно написать обертку, которая наружу будет выставлять plain C интерфейс. Выставить наружу C-шный интерфейс, скажем, из D, уже сложнее.

И совсем трэш когда нужно использовать бинарную плюсовую библиотеку и разгребать этот mangling вручную.

Как в это описание укладывается смерть кобола?

Кобол уже умер? Все, что было написано на Коболе уже переписали на чем-то другом?

Аналогично про Perl.

Тот же C++ своим появлением вовсе не убил C. Как и Java не убила C++, а C# не убил Java.

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

Хорошо помню, что происходило с Java. Сначала же ее пытались спозиционировать как более правильный C++ для встраиваемых устройств. Но тут подоспел интерес к Web-у и Java стали позиционировать как основной инструмент для Web-приложений. А уже потом Java переполз с клиента на сервер.

При этом на десктопе, особенно под Windows, Java так серьезно С++ и не потеснил. Сначала Java была слишком тормознутой для десктопа, затем там появился C#.

История Objective-C вообще показательна. Если бы не взрывная популярность iPhone и iOS, так и остался бы язык широкоизвестным в узких кругах.

Ну и по поводу Rust-а интересно, какую нишу он займет, чтобы его там не затерли те языки, которые уже существуют. А ведь это не только C и C++, но еще и куча других: D, Go, Java и даже Haskell с OCaml-ом.

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

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

Не надо заливать про extern «C». Не всё там так просто.

Обсуждая языки, программисты забывают об адекватном стиле разработки.

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

Если для вас адекватный C++ — это С с классами и деструкторами, то ограничьтесь этим подмножеством языка и не парьтесь.

На моей памяти Страуструп всегда говорил, что С++ — это мультипарадигменный язык. С++ поддерживает разные подходы. И никого не заставляет использовать их все. Как и использовать только какое-то жестко зафиксированное подмножество языка.

То, что при работе на C++ нужно использовать чуть больше, чем в Java — это да. Но это уже давно известно.

Для примера можно назвать библиотеку Eigen

Спасибо, посмотрю для общего развития.

Кобол уже умер?

Безусловно.

Все, что было написано на Коболе уже переписали на чем-то другом?

Конечно же нет. Но это не может считаться критерием того, что язык жив. Язык жив, если выходят новые компиляторы, дорабатывается старый код, молодые программисты его изучают, есть достаточно много вакансий. Я бы так определил актуальность языка. И по нему ни Кобол, ни Перл, ни Дельфи не проходят.

Тот же C++ своим появлением вовсе не убил C. Как и Java не убила C++, а C# не убил Java.

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

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

Я вот хорошо вижу эту нишу для Rust. Если человек более-менее знакомый с современными языками программирования захотел написать что-то, требующее производительности уровня C. Если он начнёт писать на C, наверное он в итоге напишет, но это будет долго, у него будет множество багов. Если он начнёт писать на C++, то либо он будет им пользоваться очень ограниченно и результат будет похож на C, либо он будет им пользоваться всерьёз и рискует просто закопаться в сложности языка, ну или потратит много времени и освоит язык. Если он начнёт писать на Rust, он получит рабочий результат, минимум проблем с памятью и минимум времени на освоение языка. Потому что Rust куда проще C++ и куда мощнее C. D, имхо, по сложности на уровне C++. Красивее, исторических проблем меньше, но в целом язык непростой. Да и выглядит загнивающим со стороны, может ошибаюсь. Go хороший язык, перспективный, поддерживаемый, быстрый, но это сборка мусора, это легкие потоки. Всё же это не C, это немного в другую сторону.

История Objective-C вообще показательна. Если бы не взрывная популярность iPhone и iOS, так и остался бы язык широкоизвестным в узких кругах.

Всё же маки были достаточно популярными компьютерами, чтобы Objective C был достаточно популярным языком. Свои 5-10% на самом платежеспособном рынке они имели уже давно. А так, конечно, да, iOS его вытолкнул очень сильно.

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

Такое не забывается.

На моей памяти Страуструп всегда говорил, что С++ — это мультипарадигменный язык.

Как ни крути, а он говорит: C++ could be called class oriented. А ещё он много говорил про «выражение идей прямо в коде», про «выражение независимых идей независимо прямо в коде», про «выражение отношений между идеями прямо в коде», а также, внимание про «выражение простых идей в простом виде». Только вот если взглянуть в какой-нибудь реальный код на C++, то никакой ясности идей и отношений между ними объективно не наблюдается. А уж про простое выражение идей простым способом в цепепе я вообще промолчу :-)

Если он начнёт писать на C++, то либо он будет им пользоваться очень ограниченно и результат будет похож на C

Да, это, пожалуй, самое адекватное использование C++. Примеры - gcc, nodejs.

Безусловно.

Очень сильно сомневаюсь, что за 6 неполных лет ситуация так кардинально для Кобола поменялась.

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

Это было верно для C++03. Сейчас, когда C++14 в нормальной степени поддерживается в clang и gcc, и даже MSVS2013 поддерживает более-менее вменяемое подмножество C++11 ситуация сильно изменилась.

Может, конечно, и не сильно. Но изменилась :)

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

Как ни крути, а он говорит

Так почитайте, что он говорит:

3. Myth 2: “C++ is an Object-Oriented Language”

No. C++ supports OOP and other programming styles, but is deliberately not limited to any narrow view of “Object Oriented.” It supports a synthesis of programming techniques including object-oriented and generic programming. More often than not, the best solution to a problem involves more than one style (“paradigm”). By “best,” I mean shortest, most comprehensible, most efficient, most maintainable, etc.

Я предпочитаю доверять мнению самого Страуструпа, а не ваших пересказов его слов.

Только вот если взглянуть в какой-нибудь реальный код на C++, то никакой ясности идей и отношений между ними объективно не наблюдается. А уж про простое выражение идей простым способом в цепепе я вообще промолчу

Может хватить выдавать свой собственный печальный опыт за истину в последней инстанции?

но сам игровой движок при этом всё-таки нужно пилить самому.

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

Выставить наружу C-шный интерфейс, скажем, из D, уже сложнее.

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

Разве?

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

В случае с C++ ситуация проще: наружу можно отдавать обычный указать на C++ный объект.

Да так, чтобы GC их не подчистил.

Действительно, не подумал об этом. Ну в расте нет ГЦ, так что должно быть даже проще, чем в D.

Так почитайте, что он говорит

Так почитайте, что он говорит в его TC++PL 4-й редакции.

Я предпочитаю доверять мнению самого Страуструпа, а не ваших пересказов его слов.

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

Может хватить выдавать свой собственный печальный опыт за истину в последней инстанции?

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

Да там вроде и просто до примитивности, разве что хидеры сам не генерит.

В случае с C++ ситуация проще: наружу можно отдавать обычный указать на C++ный объект.

Ну и как тогда пользоваться этими вашими смарт-поинтерами?

Да, должно быть проще. Но тут, как мне думается, нужно будет бороться с компилятором Rust, который не знает, что временем жизни конкретных объектов будут управлять снаружи.

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

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

раз он понятен только тебе, то ты тупой бездарь и никакой язык таких не спасет /thread

Ну и как тогда пользоваться этими вашими смарт-поинтерами?

http://ru.cppreference.com/w/cpp/memory/enable_shared_from_this

конструировать смартпоинтер из этого указателя, овеца

раз он понятен только тебе, то ты тупой бездарь и никакой язык таких не спасет

О, а вот и талантливый умница :-)

http://ru.cppreference.com/w/cpp/memory/enable_shared_from_this

Что ты мне тулишь этот шаредптр? Ты хоть понял о чём речь?

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

Уже одному анониму задавал вопрос, подозреваю, что вам. Но ответа не получил. Так что повторюсь. Если, по-вашему:

C++ далеко не всегда позволяет в достаточной для легкого восприятия степени абстрагироваться

и

C++ очень уродливая семантика.

то что вас держит в C++? Есть куча других языков с огромными экосистемами и толпами умных людей в коммьюнити. И вакансий открытых куча. Чего вы за C++ цепляетесь?

PS. Я вам дал точную цитату из Страуструпа. Так что это не пересказ.

Конечно, и умница тут - ты. :-)

хм, а ты не потерян окончательно. работай над собой!

конструировать смартпоинтер из этого указателя, овеца

Взвяк засчитан. Давай ещё раз прочитай о чём речь. :-)

так уж распоряжается жизнь и генетический набор, унаследованный от наших предков, у кое-кого предки из Гаскони, а остальные - просто бездарность :D

fixed :)

Д'Артаньян, ты? :-)

Руст - это самый затратный по времени для его разработчиков вброс!

Ну и как тогда пользоваться этими вашими смарт-поинтерами?

Вы не поняли, речь идет о том, чтобы отдать указатель на плюсовый объект в C-шный код. Т.к. в C нет никаких умных указателей, ответственность за корректную работу с этим указателем несет C-шный пользователь вашей библиотеки. Получается как с каким-нибудь FILE* — после успешного вызова fopen() нужно не забыть вызывать fclose().

Если такие вещи отдаются на откуп пользователю, то выставлять наружу C-шный интерфейс можно как-то так:

typedef void * CTX_HANDLE;

extern "C" CTX_HANDLE create_ctx() {
  auto ctx = new some_cpp_class();
  return ctx;
}

extern "C" int do_something_with_ctx(CTX_HANDLE handle) {
  auto ctx = reinterpret_cast<some_cpp_class *>(handle);
  return ctx->do_something();
}

extern "C" void close_ctx(CTX_HANDLE handle) {
  std::unique_ptr<some_cpp_class> ctx{ 
    reinterpret_cast<some_cpp_class *>(handle) };
  ...
}

На практике все будет несколько сложнее, но принцип такой.

Вы не поняли, речь идет о том, чтобы отдать указатель на плюсовый объект в C-шный код.

Я то понял о чём речь, это крикливый умница госконец не понял и облажался :-) Имелось в виду, если брать ваш пример, что использовать, например, shared_ptr<some_cpp_class> в коде C++ будет проблематично, если передать наружа голый указатель. :-)

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

В расте FFI и так ансейф, так что сильно бороться не придётся.

Имелось в виду, если брать ваш пример, что использовать, например, shared_ptr<some_cpp_class> в коде C++ будет проблематично, если передать наружа голый указатель.

Именно.

И что ты этим сказать-то хотел? Тебе анон тот все правильно расписал.

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

Где там слив? Люди удивляются, зачем ты сравниваешь лисп и C++. И при чем тут лисп вообще? C++ в теме про Rust понятно откуда. А лисп тут как нарисовался?