LINUX.ORG.RU

Rust 1.6

 ,


2

3

Команда разработчиков Rust рада представить первый в этом году релиз Rust — 1.6. Rust — это системный язык программирования, при разработке которого внимание сосредоточено на безопасности, скорости и параллелизме. Как обычно, вы можете установить Rust 1.6 с соответствующей страницы на официальном сайте, а также посмотреть примечания к выпуску на GitHub. Выпуск включает в себя около 1100 патчей и содержит ряд небольших улучшений, одно важное изменение, а также изменение на Crates.io.

Стабилизация libcore

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

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

Стабилизации библиотеки

Около 30 библиотечных функций и методов теперь являются стабильными в 1.6. Заметные улучшения включают в себя:

  • Семейство функций drain() для коллекций. Эти методы позволяют перемещать элементы из коллекций, сохраняя память, в которой они размещены, тем самым снижая выделение памяти в некоторых ситуациях.
  • Ряд реализаций типажа From для конвертирования между типами стандартной библиотеки, в основном между целочисленными типами и числами с плавающей точкой.
  • Наконец, Vec::extend_from_slice(), ранее известный как push_all(). Этот метод существенно быстрее, чем более общий метод extend().

Crates.io запрещает использование масок в версиях зависимостей

Если вы являетесь мейнтейнером контейнера на Crates.io, возможно вы видели следующее предупреждение:

новые контейнеры более не могут использовать маски при описании зависимостей.

Другими словами, это запрещено:

[dependencies]
regex = "*"

Вместо этого вы должны указать конкретную версию или диапазон версий, используя одну из опций: ^, ~, или =.

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

>>> Официальный анонс

★★★★★

Проверено: Klymedy ()
Последнее исправление: Klymedy (всего исправлений: 6)
Ответ на: комментарий от anonymous

Да уж, выдающееся творение. https://drmeister.wordpress.com/2015/07/30/timing-data-comparing-cclasp-to-c-...

I’m calculating the 78th Fibonacci number 10,000,000 times in each case. For these integer arithmetic heavy functions, CClasp performs pretty well (~4x slower than C++).

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

eao197 ★★★★★
()
Ответ на: комментарий от eao197

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

Не совсем. Заявленная бесшовная интеграция с С++ позволяет вынести весь тяжеловесный код в С++, оставив в Lisp только высокоуровневую компоненту (и REPL). Вполне себе стандартный подход. Python именно так и живет, и здравствует. Julia идет ему на смену. Довольно много областей, где нужен эффективный REPL. А в Big Data это вообще must have.

//Психиатр

anonymous
()
Ответ на: комментарий от eao197

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

Как не красиво выдирать фразу из контекста :-) Смысл сей статьи в другой фразе, которую ты оставил за кадром:

my point is that CClasp has come a long way from being hundreds of times slower than C++ to within a factor of 4.

Не подскажешь, сколько человеко-лет потребовалось, чтобы появился GCC 5? :-)

anonymous
()
Ответ на: комментарий от anonymous

my point is that CClasp has come a long way from being hundreds of times slower than C++ to within a factor of 4.

Это не CClasp прошел путь, это мужик научился пользоваться LLVM

Не подскажешь, сколько человеко-лет потребовалось, чтобы появился GCC 5? :-)

Тот же вопрос про LLVM.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Смысл сей статьи в другой фразе

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

Тогда как за это время на обычном C++ можно было решать прикладные проблемы не имея тормозов со скоростью выполнения.

А если нужен клей, который бы позволял дергать что-то, написанное на C++, то можно было не делать новый Lisp, а взять Lua, Python, Ruby или еще что-нибудь в таком роде.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

то можно было не делать новый Lisp, а взять Lua, Python, Ruby или еще что-нибудь в таком роде.

Можно было бы. Но человек взял Лисп. Это значит, что он из академической среды. Простим ему это.

Clasp exposes the Clang AST library and the Clang ASTMatcher library. This allows programmers to write tools in Common Lisp that automatically analyze and refactor C++ programs. Clasp can be used to automatically clean-up and refactor large C++ codebases!

Может оказаться очень полезной вещью даже для тех, кто шаблоны не пишет))

anonymous
()
Ответ на: комментарий от tailgunner

Это не CClasp прошел путь, это мужик научился пользоваться LLVM

Это проблема восприятия :-) Мужик написал, что «CClasp прошёл путь» :-) tailgunner прочитал это как «научился пользоваться LLVM» :-)

Тот же вопрос про LLVM.

Ну да :-) И тот же вопрос про SBCL, который вообще со времён CMUCL :-) Мой поинт в том, что мужик фактически в одиночку проделал за относительно короткий срок работу, продемонстрировав отличный результат :-)

anonymous
()
Ответ на: комментарий от anonymous

мужик фактически в одиночку проделал за относительно короткий срок работу

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

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Может оказаться очень полезной вещью даже для тех, кто шаблоны не пишет

Думаю, что там дергаются методы, который LLVM выставляет наружу. И которые используются штатными инструментами из LLVM, вроде clang analyzer и clang-tidy.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

за это время на обычном C++ можно было решать прикладные проблемы

А несравненная сложность разработки? А сегфолты? А тормоза на действительно больших приложениях?

Oxdeadbeef ★★★
()
Ответ на: комментарий от tailgunner

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

Оттуда же:

Our goal is to make Clasp the fastest and most capable dynamic scripting language for C++ libraries.

anonymous
()
Ответ на: комментарий от Oxdeadbeef

А несравненная сложность разработки?

Несравненная с чем - с божественным Лиспом? Ну тут-то вообще все сливают, это да.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

А я говорю о результатах.

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

Разница в 4 раза — это уже очень хорошо.

//Психиатр.

anonymous
()
Ответ на: комментарий от Oxdeadbeef

А несравненная сложность разработки?

Почему вы думаете, что в C++ сложность разработки обязательно гораздо выше?

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

А сегфолты?

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

А тормоза на действительно больших приложениях?

А уж какие тормоза случаются в больших приложениях на JVM...

Тут выше пеняли на качество Firefox. Покажите аналог на CL, сравним. И по надежности, и по потреблению ресурсов.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

дергать что-то, написанное на C++, то можно было не делать новый Lisp, а взять Lua, Python, Ruby или еще что-нибудь в таком роде.

Правило Гринспуна же.

Oxdeadbeef ★★★
()
Ответ на: комментарий от Oxdeadbeef

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

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Разница в 4 раза — это уже очень хорошо.

Хорошо для чего? Если для клея, то пофиг; если для основного рабочего языка - ну, nice try, да.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Нехорошо коверкать цитаты.

это не я, это спеллчекер, который думяет, что умнее меня.

Oxdeadbeef ★★★
()
Ответ на: комментарий от anonymous

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

Почему не стоит? :-) В Common Lisp есть декларации типов, декларации оптимизации, декларации проверок времени выполнения, применяя которые можно ожидать ровно того, на что способен компилятор Лиспа в машинный код :-) На практике, скорость очень близка к C, а иногда даже превосходит C - простой пример - парсер заголовков/multipart HTTP :-)

anonymous
()
Ответ на: комментарий от anonymous

In this benchmark, fast-http is 1.25 times faster than http-parser, a C equivalent.

anonymous
()
Ответ на: комментарий от tailgunner

Если для клея, то пофиг;

Для клея, конечно же. У динамически-типизированных языков есть своя надежная ниша, в которой они незаменимы, — это быстрое прототипирование и всякий ad-hoc. Всё это над библиотеками, написанными на сильно-типизированных языках. Если кто-то пытается всё-всё-всё писать в динамической типизации, то это от избытка энтузиазма, порождаемого недостатком опыта.

//Психиатр

anonymous
()
Ответ на: комментарий от eao197

Тут выше пеняли на качество Firefox. Покажите аналог на CL, сравним

Этот продукт пишут десятилетия за зарплату многомиллионными корпорациями.

Oxdeadbeef ★★★
()
Ответ на: комментарий от Oxdeadbeef

Этот продукт пишут десятилетия за зарплату многомиллионными корпорациями.

ЕМНИП, CommonLisp появился задолго до Netscape. И уж тем более до Mozilla. Что помешало выбрать для реализации браузера такой замечательный язык, как CommonLisp?

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

eao197 ★★★★★
()
Ответ на: комментарий от Oxdeadbeef

Этот продукт пишут десятилетия

Лиспы гораздо старше С++.

за зарплату

trollface.png

многомиллионными корпорациями

Netscape был основан, что называется, на коленке, Firefox его наследник, в коде до сих это отчетливо видно.

anonymous
()
Ответ на: комментарий от eao197

Что помешало выбрать для реализации браузера такой замечательный язык, как CommonLisp?

Цена на качественные компиляторы и недальновидность манагеров — вендоров этих компиляторов.

Oxdeadbeef ★★★
()
Ответ на: комментарий от Oxdeadbeef

Цена на качественные компиляторы

Visual C++ в 1993-м стоил 500$. AllegroCL под Win - 595$. Практически одинаково. Так что это отмазки для бедных.

anonymous
()
Ответ на: комментарий от anonymous

AllegroCL под Win - 595$.

Не очень давно делали запрос в Franz :-) ACL 9 x86_64 стоил 8 тыс. у.е. одной копии компилятора, который сможет генерировать программы на ACL для распространения :-) (Т.к. любая программа на CL включает в себя и компилятор, то распространение программ должна позволять лицензия.) :-)

anonymous
()
Ответ на: комментарий от anonymous

Не очень давно делали запрос в Franz :-) ACL 9 x86_64 стоил 8 тыс. у.е. одной копии компилятора

Все верно, лохов-фанатиков надо стричь, в то время как всякие Apple и MS дают бесплатные инструменты.

anonymous
()
Ответ на: комментарий от anonymous

Там и еще и рантайм должен лицензироваться.

Oxdeadbeef ★★★
()
Ответ на: комментарий от anonymous

Ну вот, о чём я и говорил - лицензия на распространение программ, включающих компилятор/рантайм ACL 3 в 90-хх «A Professional version with royalty free runtime distribution and source code is available for $2495.» :-)

anonymous
()
Ответ на: комментарий от anonymous

Это не то, а:

«A Professional version with royalty free runtime distribution and source code is available for $2495.»

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

Oxdeadbeef ★★★
()
Ответ на: комментарий от anonymous

Ну вот, о чём я и говорил - лицензия на распространение программ, включающих компилятор/рантайм ACL 3 в 90-хх «A Professional version with royalty free runtime distribution and source code is available for $2495.» :-)

Ну так ее одну надо было всего - для сборки релизной версии. А все разработчики могли пользоваться версией за $449. В итоге разница не такая большая.

anonymous
()
Ответ на: комментарий от Oxdeadbeef

Цена на качественные компиляторы и недальновидность манагеров — вендоров этих компиляторов.

Цена на инструмент напрямую связана с востребованностью инструмента. Чем выше объемы продаж, тем ниже цена и наоборот. Так что даже про недальновидность манагеров вы правы (что вряд ли), то проблема скорее в том, что на компиляторы лиспа цена была слишком высока по причине слишком низкого спроса. Т.е. CL мало кому был нужен.

Собственно, не только он. Такая же история была и у коммерческих SmallTalk-ов. И у нынешнего Eiffel-я.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Ну так ее одну надо было всего - для сборки релизной версии. А все разработчики могли пользоваться версией за $449. В итоге разница не такая большая.

История не знает сослагательного наклонения :-) И вопрос «почему Netscape не стал писать браузер на Common Lisp» так же глуп как «почему Линус Торвальдс не стал писать Git на C++» :-)

anonymous
()
Ответ на: комментарий от anonymous

как всякие Apple и MS дают бесплатные инструменты.

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

Oxdeadbeef ★★★
()
Ответ на: комментарий от Oxdeadbeef

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

Уже ответил выше. А вообще, ну очевидно же почему CL не мог даже рассматриваться, - он слишком жирный и тормозной. Браузер на CL, запущенный на PC с 4-8Мб ОЗУ, ушел бы сразу навечно в своп.

anonymous
()
Ответ на: комментарий от anonymous

Все верно, лохов-фанатиков надо стричь, в то время как всякие Apple и MS дают бесплатные инструменты.

Бугага :-) Так лохи как раз холопы, кто не видят альтернатив говну, которое они вынуждены жрать, будучи плебеями :-)

anonymous
()
Ответ на: комментарий от Oxdeadbeef

Ага, сначала купи либо мак, либо винду.

Ты их в любом случае купишь, если будешь под них писать. Даже если это будет не C#, Swift, C++ etc., а CL.

anonymous
()
Ответ на: комментарий от anonymous

И вопрос «почему Netscape не стал писать браузер на Common Lisp» так же глуп как «почему Линус Торвальдс не стал писать Git на C++»

На самом деле вопрос про Git на C++ отнюдь не праздный. Но в контексте разговоров о неоспоримом преимуществе Lisp-ов над всем остальным миром гораздо интереснее, почему Линус не стал писать Git на Lisp-е.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

На самом деле вопрос про Git на C++ отнюдь не праздный. Но в контексте разговоров о неоспоримом преимуществе Lisp-ов над всем остальным миром гораздо интереснее, почему Линус не стал писать Git на Lisp-е.

Ответ очевиден - Линус мастер по C :-) Не нужны ему ни цепепи, ни лиспы :-)

anonymous
()
Ответ на: комментарий от anonymous

Бугага :-) Так лохи как раз холопы, кто не видят альтернатив говну, которое они вынуждены жрать, будучи плебеями :-)

Ну покритикуй F#, например.

anonymous
()
Ответ на: комментарий от anonymous

Браузер на CL, запущенный на PC с 4-8Мб ОЗУ, ушел бы сразу навечно в своп.

не факт

Хотя сейчас это делать проще и даже намного легче, чем JVM.

Oxdeadbeef ★★★
()
Ответ на: комментарий от eao197

почему Линус не стал писать Git на Lisp-е.

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

Oxdeadbeef ★★★
()
Ответ на: комментарий от Oxdeadbeef

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

Это был бы не Линус :-) Ибо как мог бы сишник до мозга костей создать лиспось, чтоб потом писать Git на Лиспе, если он сишник? :-)

anonymous
()
Ответ на: комментарий от Oxdeadbeef

По факту мы живем в реальном мире, в котором о преимуществах Lisp-а догадываются отдельные адепты, об адекватности которых можно судить просто по факту их участия в спорах о Rust и C++. А если еще и учесть, что они при этом говорят...

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

Указывать на формальные преимущества Lisp-ов по отношению к этим инструментам адептам, наверняка, приятно. Но пользы от этого ни для кого нет.

eao197 ★★★★★
()
Ответ на: комментарий от Oxdeadbeef

нет, только над цепепе в данном треде.

Где эти преимущества? Что такое есть в вашем CL, что позволило кому-то где-то создать конкурента Chrome, Firefox, Photoshop, MySQL, MSSQL, Oracle и т.д. И этом речь только про C++. Можно глянуть в сторону Java. Не говоря уже в сторону совсем древнего и убогого C. Вот придурочный смайлик все время PostgreSQL в пример приводит. Где что-то калибра PostgreSQL на CL?

eao197 ★★★★★
()
Последнее исправление: eao197 (всего исправлений: 1)
Ответ на: комментарий от anonymous

Кстати да :-) Почему до сих пор нет браузера на F#? :-)

Заговор корпораций, слишком дорогая цена бесплатной Visual Studio, язык не для быдла, нет F#-машин, т.к. у них нет шансов перед попсовым железом и т.д. Очевидно же.

anonymous
()
Ответ на: комментарий от eao197

Но пользы от этого ни для кого нет.

Ну уж прям никакой пользы нет: кто-то узнает о альтернативах не уступающих (и даже лучших чем) C++.

Oxdeadbeef ★★★
()
Ответ на: комментарий от eao197

Где что-то калибра PostgreSQL на CL?

Самое смешное, что изначально PostgreSQL был на лиспе, но его авторы не выдержали жевать кактус и перешли на более практичный С, ЛОЛ.

anonymous
()
Ответ на: комментарий от Oxdeadbeef

psql изначально был написан на нем.

И это же можно назвать эпитафией ему. Печать наискось - не годится для серьезной СУБД.

anonymous
()
Ответ на: комментарий от Oxdeadbeef

Где что-то калибра PostgreSQL на CL?

psql изначально был написан на нем.

На Лиспе была написана экспериментальная СУБД Postgres, которая потом стала POSTGRES95, а потом - PostrgeSQL. Так что никогда не было PostgreSQL на CL.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Так что никогда не было PostgreSQL на CL.

На Лиспе была написана экспериментальная СУБД Postgres

А без нее не было бы PostgreSQL.

Oxdeadbeef ★★★
()
Ответ на: комментарий от Oxdeadbeef

Ну уж прям никакой пользы нет: кто-то узнает о альтернативах не уступающих (и даже лучших чем) C++.

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

А в полку языков с GC есть много достойных языков, которым CL в силу своей маргинальности, сольет по полной программе.

eao197 ★★★★★
()
Ответ на: комментарий от Oxdeadbeef

Ну так на CL написали прототип, потом на Си - реальную систему. Всё правильно.

tailgunner ★★★★★
()
Ответ на: комментарий от Oxdeadbeef

Не SQL но AllegroGraph.

Да уж, примеров хоть завались. Выше уже приводилось достаточное количество СУБД разных типов на C++.

eao197 ★★★★★
()
Ответ на: комментарий от Oxdeadbeef

А без нее не было бы PostgreSQL.

LOL, авторы выбирали из:

C C++ MODULA 2+ LISP ADA SMALLTALK

Причем С++ не был выбран только из-за того, что в 1985 не было достаточно стабильного компилятора. В итоге начали писать на связке С и лисп. Но после признали, что «the use of LISP has been a terrible mistake», по тем причинам, что он тормозной, жирный, GC только мешал, а связка С/Lisp была крайне неудобной. Если бы С++ тогда уже вылез из пеленок, то и PostgreSQL вполне вероятно был бы на нем.

anonymous
()
Ответ на: комментарий от Oxdeadbeef

Причем здесь GC? Это детали реализации.

«Any response time sensitive program must therefore allocate and deallocate space manually» (c) авторы POSTGRES, отказавшиеся от лиспа.

anonymous
()
Ответ на: комментарий от Oxdeadbeef

Причем здесь GC? Это детали реализации.

Звиздец, занавес.

Простите мне мой французский, но нет смысла продолжать разговор.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

«Any response time sensitive program must therefore allocate and deallocate space manually» (c) авторы POSTGRES, отказавшиеся от лиспа.

Они не осилили писать не лиспе без консинга? А как же ынтырпрайз на Жабе?

Oxdeadbeef ★★★
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от Oxdeadbeef

Не о том вопрос.

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

Судить о языках, не понимая таких элементарных вещей, это мощно.

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

eao197 ★★★★★
()
Ответ на: комментарий от Oxdeadbeef

Что мешает управлять GC в определенных точках выполнения вручную, если очень надо?

В каких-таких точках? И что в это время будут делать ждущие клиенты?

// captcha: boontu

anonymous
()
Ответ на: комментарий от Oxdeadbeef

Что мешает управлять GC в определенных точках выполнения вручную, если очень надо?

Ничего не мешает. Только смысла в этом нет никакого. GC вносит недетерминизм, который быстро растет с ростом размера кучи и (в случае Java) становится слишком большим уже на нескольких GB. В случае других рантаймов всё еще хуже. Покури алгоритмы GC и поймешь, что вызывать его вручную бесполезно.

//Психиатр

anonymous
()
Ответ на: комментарий от eao197

Отсутствие GC в C++ делает C++ тем языком, которым он является

Строго говоря, отсутствие GC и присутствие деструкторов, чувствительных к границам видимости объектов.

А ручное управление памятью и в С есть.

//Психиатр

anonymous
()
Ответ на: комментарий от eao197

Блин, человеческой тупости не перестаешь удивляться.

Это точно :-)

А в полку языков с GC есть много достойных языков, которым CL в силу своей маргинальности, сольет по полной программе.

Какому именно достойному языку с GC сольёт CL? :-) И в чём сольёт конкретно? :-)

anonymous
()
Ответ на: комментарий от anonymous

Строго говоря, отсутствие GC и присутствие деструкторов, чувствительных к границам видимости объектов.

Плюс совместимость с языком C и завязанность на стандартную библиотеку языка C.

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

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Какому именно достойному языку с GC сольёт CL? :-)

Scala, C#, Haskell. Да имя им легион. Даже Java 8.

И в чём сольёт конкретно? :-)

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

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Только смысла в этом нет никакого. GC вносит недетерминизм, который быстро растет с ростом размера кучи
Покури алгоритмы GC и поймешь, что вызывать его вручную бесполезно.

Для этого как раз и имеет смысл запускать сборщик мусора вручную - чтобы сделать поведение более предсказуемым, систему более стабильным :-) Для этого в Лиспах и есть возможность дёргать GC, скажем, каждые t секунд :-)

anonymous
()
Ответ на: комментарий от Oxdeadbeef

А тормоза на действительно больших приложениях?

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от eao197

Scala, C#, Haskell. Да имя им легион. Даже Java 8.

где бенчмарки?

Haskell

В количестве готовых и качественных инструментов

сомневаюсь

Oxdeadbeef ★★★
()
Ответ на: комментарий от eao197

Scala, C#, Haskell. Да имя им легион. Даже Java 8.

И чем же эти языки лучше Common Lisp? :-)

В количестве готовых и качественных инструментов

Так в количестве и в качестве :-) У нас вот есть SLIME - качественный инструмент :-)

, в развитости инфраструктуры

Что под этим понимать? :-) Тонны говённых библиотек? :-)

, в размерах коммьюнити.

Тут CL сольёт любому языку :-) Ты прав, Женя :-)

Даже в стоимости средств разработки.

SLIME бесплатен :-) Макросы бесплатны :-) Любой язык тут сольёт CL :-)

anonymous
()
Ответ на: комментарий от eao197

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

А потом через 25 лет он, наконец, осмелился и сделал auto :-) И рукоплескали адепты дедушке, и были радостны и благодарны! :-) Бугага :-)

anonymous
()
Ответ на: комментарий от Oxdeadbeef

Или ты про кастомные аллокаторы, которые их не дергают?

В основном, про них. Писать на С++ и не писать/не использовать готовый кастомный аллокатор — а зачем тогда писать на С++?

//Психиатр

anonymous
()
Ответ на: комментарий от anonymous

И чем же эти языки лучше Common Lisp?

Достаточно уже того, что это не Lisp-ы. Но вы не поймете.

Тонны говённых библиотек?

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

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Достаточно уже того, что это не Lisp-ы. Но вы не поймете.

А, понятно :-) Аргументов нет в силу не знания ни одного из тех самых языков :-) Слив засчитан :-)

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

Я делаю софт не для того, чтобы им или мной восхищались :-)

anonymous
()
Ответ на: комментарий от anonymous

Писать на С++ и не писать/не использовать готовый кастомный аллокатор — а зачем тогда писать на С++?

Понт защитан %)

tailgunner ★★★★★
()
Ответ на: комментарий от eao197

В интернетах, вестимо.

То есть, не пруфа. Ок.

Да кто ж вам запретит.

Написал ли ты большое приложение на Haskell используя эти прелестные инструменты опять же на Haskell, чтобы мнение не было голословным?

Oxdeadbeef ★★★
()
Ответ на: комментарий от anonymous

Для этого в Лиспах и есть возможность дёргать GC, скажем, каждые t секунд :-)

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

anonymous
()
Ответ на: комментарий от Oxdeadbeef

То есть, не пруфа. Ок.

А вы здесь прям одоказывались и подкрепили каждое свое слово ссылкой на десяток авторитетных источников. На Great Language Shootout Game загляните, если совсем ничего не умеете.

Написал ли ты большое приложение на Haskell используя эти прелестные инструменты опять же на Haskell, чтобы мнение не было голословным?

Примечательно, что из всего списка вы решили доколупаться именно к Haskell-ю. Ok.

Сам я ничего большого ни на Haskell-е, ни на Scala, ни на C#, ни на Java 8 не писал. Можно ли по этому факту судить об отсутствии подобных разработок на этих языках?

eao197 ★★★★★
()
Ответ на: комментарий от tailgunner

Понт защитан %)

Благодарю :)

//Психиатр

anonymous
()
Ответ на: комментарий от anonymous

Я делаю софт не для того, чтобы им или мной восхищались

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

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Ответ очевиден - Линус мастер по C :-) Не нужны ему ни цепепи, ни лиспы :-)

Тем не менее, С++ у него в репе имеется.

DarkEld3r ★★★★★
()
Ответ на: комментарий от eao197

На Great Language Shootout Game загляните

Это все игрушки на локалхосте.

вы решили доколупаться именно к Haskell

потому что комьюнити не сравнимо с Scala, C#, и Java 8 — маргинальщина как и лисп.

Можно ли по этому факту судить об отсутствии подобных разработок на этих языках?

они конечно есть, только почему то вы решили, что на лиспе их нет или они хуже.

Oxdeadbeef ★★★
()
Ответ на: комментарий от Oxdeadbeef

Это все игрушки на локалхосте.

Да, бл*, по сравнению с этим результаты замеров Clasp-а — это что-то запредельно объективное. Причем, что забавно, эти замеры здесь отнюдь не лисперы упомянули.

потому что комьюнити не сравнимо с Scala, C#, и Java 8 — маргинальщина как и лисп.

Не льстите себе. Haskell уже давно намного ближе к мейнстриму, чем Lisp.

eao197 ★★★★★
()
Ответ на: комментарий от Oxdeadbeef

Ну уж прям никакой пользы нет: кто-то узнает о альтернативах не уступающих (и даже лучших чем) C++.

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

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от Oxdeadbeef

Что мешает управлять GC в определенных точках выполнения вручную, если очень надо?

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от Oxdeadbeef

С++ используют, когда:

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

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

//Психиатр

anonymous
()
Ответ на: комментарий от anonymous

Математически смысла в этом никакого. Для отладки разве или еще каких инструментальных вещей.

Это ты так думаешь :-)

А так, он и так дергается каждые t секунд.

Эти t секунд определяются рантаймом по многим факторам - в зависимости от стратегии GC :-) За эти t секунд мусора может сгенерироваться разное количество и стратегия рантайма не всегда будет оптимальной для всех случаев :-)

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

Если интересно, то вот про ручное дёрганье GC в SBCL с практической т.з. - https://habrahabr.ru/post/262225/ :-)

anonymous
()
Ответ на: комментарий от anonymous

Если интересно, то вот про ручное дёрганье GC в SBCL с практической т.з. - https://habrahabr.ru/post/262225/ :-)

Ну ладно, убедил. Кому-то это помогло. После того, как размер кучи выставили в 10 раз больше рабочего множества. Совсем не тот случай, на который алгоритмы управления GC затачиваются)))

//Психиатр

anonymous
()
Ответ на: комментарий от eao197

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

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

anonymous
()
Ответ на: комментарий от Oxdeadbeef

Ну раз сомневаешься то не используй, твоё право.

Не надо видеть везде врагов. Тем более, что я тебя, отчасти, понимаю (наверное). Как «сторонник раста», в смысле. Люди, конечно, инертны в своей массе, но надо признавать, что у того же С++ есть вполне объективные преимущества. Даже если это, по твоему мнению, такие «мелочи» как библиотеки, тулзы, готовые специалисты и т.д. Плюс ГЦ далеко не всегда можно объявить «деталью реализации» и закрыть на это глаза.

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

такие «мелочи» как библиотеки

Их тонны на цепепе :-) Но ты посмотри на современные либы цепепе-14 :-) Пишут их кто во что горазд :-) Понятно, что на цепепе можно писать по-разному, но любой код ещё надо и сопровождать :-) А сопровождать тонны библиотек, написанных по-разному (ковыряться в исходниках чужих либ тебе все равно придется, т.к. нет софта без ошибок), искать в них баги, это трата многих месяцев :-) Тебе нравится тратить годы на поиск багов в тонне либ? Мне - нет :-) Чтобы реально красиво писать на Си++, чтобы научиться эффективно с ним работать, с теми самыми либами, чтобы не писать ещё одну унылую и неразберимую лапшу, нужен такой уровень мастерства, которого нужно достигать десятками лет :-) Это тяжёлый язык, с тяжёлым наследием, в его т.н. наворотах пользы меньше, чем проблем :-)

anonymous
()
Ответ на: комментарий от anonymous

Насчёт говняных библиотек - это чисто субъективно

Ну вот и по поводу ваших творений будет точно так же, чисто субъективно. А судя по качеству C-шого кода, который вы на LOR-е демонстрируете, то и объективно.

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

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

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Ну вот и по поводу ваших творений будет точно так же, чисто субъективно

Почему будет? :-) Именно так и есть :-)

А судя по качеству C-шого кода, который вы на LOR-е демонстрируете, то и объективно.

Те два жалких куска кода я написал на 15 минут в общей сложности забавы ради :-) Последнее говно trim написал на коленках как попало :-) И то, судя по тестам, эта реализация оказалась быстрее, чем trim из boost :-) Оказалась, оказалась :-)

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

Это точно :-) Но в Лиспе есть REPL :-) За счёт этого, отладка в Лиспе считается дурным тоном :-) Инрементальная разработка способствует тому, что за время написания код отлаживается самим автором поневоле - в REPL, путём экспериментов :-) Можно так писать и в цепепе, и в це, но в Лиспе это из коробки, без лишних телодвижений :-) Сделал изменение в ф-ии - перекомпилил только ф-ю за 0.0001 сек и тестируй дальше :-) Не надо ждать 10 секунд :-) 7 секунд - это то время, за которое человек уже выпадает из т.н. «состояния потока», т.е. отвлекается от workflow :-) Поэтому Лисп - рульнейшая вещь для хакеров, а не для карьеристов программистов :-)

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

Мне это не надо :-)

anonymous
()
Ответ на: комментарий от DarkEld3r

Не надо видеть везде врагов.

Да нет, я всех люблю, какие враги? 😘😍

Oxdeadbeef ★★★
()
Ответ на: комментарий от anonymous

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

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

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Детский сад, младшая ясельная группа.

Ага :-)

Простенький GUI, может, вы так и напишете.

Значит и всё остальное напишу :-)

Детский сад, младшая ясельная группа. Простенький GUI, может, вы так и напишете.

Так я и сам цепепешник, если кто не понял :-)

anonymous
()
Ответ на: комментарий от anonymous

Значит и всё остальное напишу

Когда напишете, тогда и возвращайтесь.

Так я и сам цепепешник

С чего бы? Сами же про себя говорили, что лиспер, но агитируете за C.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Так я и сам цепепешник, если кто не понял :-)

Str *str_init(const char *value)
{
     Str *result = NULL;
     size_t size = 0;
     if (result = malloc(sizeof(Str))) {
          memset(result, 0, sizeof(Str));
          size = strlen(value);
          if (result->value = malloc(size + 1)) {
               result->size = size;
               memset(result->value, 0, size + 1);
               strncpy(result->value, value, size);
          }
     }
     return result;
}

Ага,цепепешник уровня «сделал две лабы, и они даже сконпелировались».

anonymous
()
Ответ на: комментарий от anonymous

Тебе нравится тратить годы на поиск багов в тонне либ? Мне - нет :-)

Мне тоже нет. Но точно так же, мне не нравится тратить годы на собственноручное написание «тонны либ». Опыт показывает, что зачастую подходящее решение достаточного качества найти можно.

DarkEld3r ★★★★★
()
Ответ на: комментарий от anonymous

Ага,цепепешник уровня «сделал две лабы, и они даже сконпелировались».

Ну а чем не цепепешный ОО-стиль в этом примере сишного кода? :-) Пара ф-й конструктор/деструктор str_init/str_free, структура Str с членами size и data :-) Конечно, это не конкурент <string> из стандартной либы, но и набросал её я практически не думая за 10 минут :-) И какие у тебя претензии к этому коду? :-) То, что init не на стеке аллоцирует структуру? :-) Так зато я могу эту ф-ю дёрнуть из того же Лиспа, чего не смог бы, если бы не malloc :-) И представь себе, оно заработало с 1-го раза :-) Так что давай, до свидания :-)

anonymous
()
Ответ на: комментарий от anonymous

я бы даже сказал statically. Но это видимо отголоски опыта с RTOS.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от anonymous

Справедливости ради, есть real-time GC, которые позволяют уменьшить недетерминизм и время остановки до некоторой заданной величины.

Dark_SavanT ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.