https://opennet.me/openforum/vsluhforumID3/118183.html Опубликован (https://blog.rust-lang.org/2019/08/15/Rust-1.37.0.html) релиз языка системного программирования Rust 1.37 (http://www.rust-lang.org), основанного проектом Mozilla. Язык сфокусирован на безопасной работе с памятью, обеспечивает автоматическое управление памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime. <br><br><br><br>Автоматическое управление памятью в Rust избавляет разработчика от манипулирования указателями и защищает от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей, выход за границы буфера и т.п. Для распространения библиотек, обеспечения сборки и управления зависимостями проектом развивается пакетный менеджер Cargo (http://blog.rust-lang.org/2014/11/20/Cargo.html), позволяющий получить нужные для программы библиотеки в один клик. Для размещения библиотек поддерживается репозиторий crates.io (ht https://opennet.me/openforum/vsluhforumID3/118183.html#142 Sat, 25 Jan 2020 16:31:43 GMT букинист&#8482;-&gt;любитель покупать книги по программированию.<br><br>Если вышеизложенный комментарий - не удовлетворяет,<br>тогда можно Клонировать текст программы по другому.<br>Например в стиле 60-х годов:<br><br>&lt;...... Но снова качает, качает.<br>Задира-ветер фонари над головой.<br>И снова шагает, шагает.<br>Весёлый парень по весенней мостовой.<br><br>Листает, листает, листает.<br>Учебник JAVA он листает на ходу.<br>Не знает, не знает, не знает.<br>Что каждым утром он читает "Лабуду".<br><br>Пройдет много лет и поймет наш студент.<br>Что формулы счастья у JAVA уж - Нет.<br><br>Есть в книжках твоих много истин таких.&#128126;<br>А формула счастья Давно у Других!&gt;&#129408;<br><br>Автор исходника: Куклин Л. жив 86 лет<br>Композитор: Колкер А.<br>Исполняет: Мария Пахоменко.<br>Год: 1964<br> https://opennet.me/openforum/vsluhforumID3/118183.html#141 Sat, 25 Jan 2020 16:21:07 GMT Написание программ исходит из сочинительства.<br>Андрей Макаревич был бы отличным программистом.<br><br>Вот море молодых. Айфоны их дороги.<br>Мне триста лет, я выполз из тьмы.<br>Они "торчат от GO".<br>Скриптами "пудрят мозги".<br>Они не такие как мы.<br>Я не горю желаньем лезть в чужой монастырь.<br>Я видел COM на C без прикрас.<br>Не стоит прогибаться под изменчивый мир.<br>Ну вот и всё!<br>Мы пишем на RUST.<br><br>Теперь, всё мы пишем на RUST.<br><br>Один мой друг.<br>Он стоил двух.<br>И не букинист&#8482;.<br>Всегда везде "решётку" хвалил.<br>Работал он на Гейтса, как C# программист.<br>А тот взял да "свалил".<br>Ну, что же.<br>Спи спокойно. Ведь на C ты "забил".<br>И брал свои вершины не раз.<br>Не стоит прогибаться под изменчивый мир.<br>Ну вот и всё!<br>Мы пишем на RUST.<br><br>Теперь, всё мы пишем на RUST.<br><br>Другой, держался русла.<br>И течение ловил.<br>Подальше от "плюсовых" кодов.<br>Он был как все.<br>И плыл как все.<br>И вот он приплыл.<br>Ни ядер. Ни клонов. Ни BoF.<br>И жизнь его нагнула в этот "JAVA-кефир".<br>Где KOTLIN не поможет за раз.<br>Не стоит прогибаться по https://opennet.me/openforum/vsluhforumID3/118183.html#140 Fri, 23 Aug 2019 12:14:18 GMT Не сильно лучше? Ну-ну. У меня в Rust проекте на 6000 строк за все время не было ни одного сегфолта и ни одной утечки памяти. При этом писать такой код намного легче, чем на C++. И Rust сделан совершенно не по образу и подобию C++. Извините, но вы несёте чушь. Фактически Rust - это современный ML без GC и с низкоуровневыми фичами. На C++ он похож только если сильно прищуриться и попрыгать.<br> https://opennet.me/openforum/vsluhforumID3/118183.html#139 Fri, 23 Aug 2019 12:06:11 GMT Rust мирно развивается, C++ агрессивно извивается.<br> https://opennet.me/openforum/vsluhforumID3/118183.html#138 Tue, 20 Aug 2019 16:39:13 GMT Я знаю, если что. Их поделкой (чистым хромом) не пользуюсь, поэтому о его стабильности ничего не скажу.<br> https://opennet.me/openforum/vsluhforumID3/118183.html#137 Tue, 20 Aug 2019 08:58:59 GMT На знаю что там была за удалённая нить, но вообще сед и авк в винде норм. BusyBox называется. Я так кросс-платформенные скрипты делаю. И не для себя, а для гигантских компаний по всему миру.<br> https://opennet.me/openforum/vsluhforumID3/118183.html#136 Mon, 19 Aug 2019 20:26:00 GMT &gt;&gt; Ты путаешь с динамическим связыванием.<br>&gt; Может быть.<br><br>"Может быть". =/<br><br>&gt;&gt; Динамическое связывание -- это во-первых зло, <br>&gt; Да ладно. Я не считаю себя фанатом динамического связывания, но это очень удобная фишка.<br><br>Скажем так, у него и правда есть область применения. Тем не менее, в CL "ушки" таким символам ставят не просто так, а как раз потому, что именно этим способом большинство лисперов отстреливают себе ноги.<br> https://opennet.me/openforum/vsluhforumID3/118183.html#135 Mon, 19 Aug 2019 18:08:10 GMT &gt;&gt; Скажем в lisp'е нет понятия "переменная" в смысле других языков. Там есть символы.<br>&gt; Вообще-то сравнивать символ с переменной не корректно. Наиболее близким аналогом переменной <br>&gt; в лиспах является связывание.<br><br>Может быть. Попробуй объяснить человеку далёкому от lisp'а эти нюансы.<br><br>&gt; Ты путаешь с динамическим связыванием.<br><br>Может быть.<br><br>&gt; Динамическое связывание -- это во-первых зло,<br><br>Да ладно. Я не считаю себя фанатом динамического связывания, но это очень удобная фишка.<br><br>&gt; во-вторых диалекты scheme (которые таки да, тоже обычно подразумеваются, когда мы <br>&gt; говорим о lisp) его либо вообще не поддерживают, либо поддерживают через <br>&gt; явное декларирование в каждом месте, где используются, что это не лексические <br>&gt; связывания. Как пример можешь посмотреть на parameters в Racket.<br><br>Да, я знаю. Поэтому моя попытка освоить схему с ракетом закончилась неполным чтением вводной документации. Нахрен нужен лисп без динамического связывания? Можно ещё lisp без скобок сделать, можно сделать lisp без макрос https://opennet.me/openforum/vsluhforumID3/118183.html#134 Mon, 19 Aug 2019 18:03:54 GMT &gt; Все вами описанное в личпе как раз и является "zero cost", так <br>&gt; как реализовано естественным для рантайма образом.<br>&gt; Выравнивание объектов в памяти по границе слова (двойного слова)? Любой язык, кроме <br>&gt; специально оговоренных программистом случаев, это делает за вас - напомню, что <br>&gt; обращение к невыровненным словам до сих пор влечет за собой CPU <br>&gt; пенальти.<br><br>К невыравненным байтам тоже пенальти? А в lisp'е байт будет занимать четыре а то и восемь байтов памяти. И будут огромные проблемы сделать упакованный массив байтов или упакованную структуру, потому что будут огромные проблемы со ссылками на эти упакованные байты.<br><br><br>&gt; А в лиспе (и других языках со сборкой мусора) это <br>&gt; выравнивание дополнительно используется для элегантного 0-cost выделения объектов в куче, <br>&gt; где выделение объекта, это просто увеличение внутреннего указателя на N слов. <br><br>Куча -- это не zero-cost абстракция. Она отъедает процессорное время и изменяет объём расходуемой памяти, причём как именно она будет это делать зави