Простые вопросы о Rust и проектах его экосистемы.

Покажи мне нормальный код. Только не проекты RazrFalcon, он исключение %)

Да любой прикладной код. Например https://github.com/BurntSushi/ripgrep https://github.com/jwilm/alacritty

А что нибудь сложнее есть?

https://github.com/redox-os/kernel

Компилятор Раста начали писать, когда ещё и Раста в сегодняшнем виде не было, так что там много доисторического кода и кода выдержанного в том же стиле.

https://github.com/redox-os/kernel

Hello World какой то.

Компилятор Раста начали писать, когда ещё и Раста в сегодняшнем виде не было, так что там много доисторического кода и кода выдержанного в том же стиле.

Вот оно как, ну окей.

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

- Вопрос: Есть ли в Rust какая-то мультиплатформенная библиотека (хотя бы в пределах unix, windows), позволяющая отлавливать событие терминирования выполняемой программы, я пока ничего не могу найти кроме очевидных способов сделать это через сигналы и winapi для каждой из платформ соответственно?

tokio_signal

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

Потому что Hello World на всем читаемый.

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

Это к царю, мне лень.

Нечитаемо можно написать почти что угодно, стоит только захотеть. Факт остается фактом, rust в принципе вполне читаем.

Вам не лень, вы просто так же как и царь не можете это сделать. Потому что, грубо говоря, есть «два путя» либо «описательный» как в rust, либо «это надо держать в уме@путь соглашений» как в С. Я конечно может чего-то не знаю, но фундаментально пока вроде ничего другого не придумали.

Подумаешь нечитаемо, можно и на самом убогом языке писать читаемо!

Вам не лень, вы просто не можете! Я лучше знаю!

Ну ты уж пойми меня.

Вам не лень, вы просто не можете! Я лучше знаю!

такого там не было, не выдумывайте :)

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

Большинство новых языков такое раздражение не вызывают. И ведь частенько про синтаксис раст можно услышать это. Язык-то для людей делается.

и это обычная закостенелая вкусовщина

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

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

Вы считаете, что нормальный синтаксис для этого нельзя придумать?

меня немного смущает описание в виде

tokio-signal

An implementation of Unix signal handling for Tokio

хотя есть зависимости на winapi ^0.3... это точно будет работать для windows? Я так понимаю ждать там каких-то специфичных для windows событий нет смысла и обрабатываться будут только «эмуляция» сигналов на всех платформах? Могли бы в двух словах описать принцип работы если не сложно?

Факт остается фактом, rust в принципе вполне читаем.

Так и brainfuck читаем так-то.

Я согласен с тем что у него мусорный синтаксис и вообще выглядит он визуально достаточно коряво, но опять же не вижу особо выходов из ситуации как от этого избавиться если только не идти по пути «соглашений» и не прятать это ручное тегирование времени жизни в компилятор на основе каких-то его внутренних правил его вычисления, но тогда в итоге получится та же джава (если еще забрать возможность работать с указателем) или си просто с альтернативным синтаксисом. Они и так уже делают поблажки в виде автоматизации вычисления времени жизни в простых случаях там где его явное описание и правда напоминает дурную работу. В общем-то надо просто ждать, если не загнется язык, то со временем его возможно причешут, возможно придумают какой-то способ как сделать его менее мусорным и более выразительным.

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

Так и brainfuck читаем так-то.

На фоне brainfuck что раст что питон да даже и лисп одинаково читаемы.

Вы считаете, что нормальный синтаксис для этого нельзя придумать?

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

Я согласен с тем что у него мусорный синтаксис и вообще выглядит он визуально достаточно коряво

В случае сложного кода не вижу принципиальной разницы в читабельности между rust и C++. Скажем (близкий к ним) D гораздо более читаем (именно на сложном коде).

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

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

Авторам*

Да, D читаем. Но он не взлетел по другим причинам. Хотя свое сообщество у него есть и на нем таки пишут.

дайте языку шанс

Пока непонятно зачем. Не тянут эти лайфтаймы и ограничения на использование ссылок на киллер-фичи. На современном C++ вполне можно писать нормальный безопасный код. Да и то для большинства задач хватит питона и чего-то для jvm (Kotlin, например). Для яблок swift'а хватает за глаза.

Да там и без лайфтаймов хватает херни.

Ладно есть на самом деле корявые макросы их с натяжкой можно отнести к херне. Что еще?

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

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

а так да там ничего принципиально нового нет, дали возможность самому рулить лайфтаймом в декларативном стиле + философия передачи владения. Сам по себе язык опять же пока не сильно переусложнен, что делает его более менее изучаемым за короткие сроки, приятная модель распространения стороннего кода и его сборка через cargo. Вменяемый выхлоп при сборке в котором действительно понятно сразу в чем проблема. На самом деле он очень неплох, имхо. Минусов тоже хватает, но по крайней мере он уже сейчас достаточно удобен для использования в практическом смысле, так почему бы не пользоваться для каких-то собственных проектов как альтернатива С с удобством той же джавы?

Ты теперь у нас на фуллтайме раст будешь пропагандировать?

Пропаганда если бы навязывал, так-то просто обсуждаем вроде, не?

так почему бы не пользоваться для каких-то собственных проектов как альтернатива С с удобством той же джавы?

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

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

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

Посмотри на D - вот где удобство для сишников и плюсовиков. Многим потом возвращаться не хочется.

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

стоит возможно, но там есть такая же проблема в «рукастости» экосистемы. И опять же я так понимаю D все же идейный наследник C и С++, а это значит это еще один язык в котором я должен держать в голове правила работы языка, вместо того чтобы самому указывать языку что я он него хочу в декларативном стиле, так? Или идейно он ближе к rust чем я думаю?

Ну я не знаю, что имеется в виду под рукастостью и декларативностью. Но у D есть пакетный менеджер dub, что делает работу с зависимостями заметно приятнее чем в плюсах. D также отлично поддерживает функциональщину. Последние стандарты плюсов некоторые важные улучшения взяли именно из D, правда я не понял почему тот же static if в плюсах стал вводить скоуп. Ну и один из разработчиков раста регулярно отмечается в темах D. Некоторые вещи в расте лучше реализованы, safety и иммутабельность по умолчанию, например.

Есть ли в Rust какая-то мультиплатформенная библиотека (хотя бы в пределах unix, windows), позволяющая отлавливать событие терминирования выполняемой программы

Крэйт graceful

Спасибо, это прямо как я и описывал в вопросе, наколеночная библиотека из одного файла в ~150 строк :) где в зависимости от платформы либо сигналы используются либо winapi. Хотя с другой стороны, не надо тянуть зависимости tokio. Надо еще будет посмотреть в tokio как оно там сделано, но видимо как-то так же если оно и в windows работает...

Единственный плюс, что самому писать не надо. Но таки да +\- будет так же я думаю

fn arg_local_refs<'a, 'tcx: 'a, Bx: BuilderMethods<'a, 'tcx>>(
    bx: &mut Bx,
    fx: &FunctionCx<'a, 'tcx, Bx>,
    memory_locals: &BitSet<mir::Local>,
    va_list_ref: &mut Option<PlaceRef<'tcx, Bx::Value>>,
) -> Vec<LocalRef<'tcx, Bx::Value>> {
   let ty = if let (true, &ty::Ref(_, ty, _)) = (by_ref, &ty.sty) {
       ty
   } else {
       ops = &ops[..ops.len() - 1];
       ty
   };
}

И что это за хрень? Раз приводишь пример - приводи корректный, а не компиляцию из понадерганных непойми откуда кусков. Где в теле функции используется хоть один из ее аргументов? А где возвращаемый вектор? А `ty`, который вычислен непойми из чего, где используется? Такой франкенштейн в Rust не скомпилируется.

Ахаха, проиграл с этих оправданий!

Кстати, а можешь ты или кто-то из растоманов объяснить, в чем соль примера с итератором вектора, которую так часто приводят - бежим итератором и удаляем(например) по нему объект из контейнера? Ведь стоит там заменить контейнер на list или set/map, то итераторы станут валидны и пример будет ни о чем, поскольку не имеет никакого отношения к ссылкам.

Речь о сравнении с C++

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

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

Конкретно в примере с set/map разница еще и в api. В расте есть метод OccupiedEntry::remove(), но в отличие от map.erase(it) в C++ он не возвращает ссылку на следующий итератор.

Так в том и дело, что это правило не имеет никакого отношения к валидности итераторов. И никакую проблему не решает. Это действительно похоже на обман какой-то или пропаганду. Ну или просто непонимание.

правило подсчета ссылок не имеет отношения к итераторам, являющимся обертками над ссылками? Вы у царя чтоли набрались таких «аргументов»?

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

И никакую проблему не решает. Это действительно похоже на обман какой-то или пропаганду. Ну или просто непонимание

точно, у царя. Зря отвечал на предыдущий коммент.

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

Если __очень__ нужно то unsafe никто ни отменял.

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

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

• Вопрос: Есть ли в Rust какая-то мультиплатформенная библиотека (хотя бы в пределах unix, windows), позволяющая отлавливать событие терминирования выполняемой программы, я пока ничего не могу найти кроме очевидных способов сделать это через сигналы и winapi для каждой из платформ соответственно?

что мешало создать отдельный топик для второго вопроса? no offense есличо

правило подсчета ссылок не имеет отношения к итераторам, являющимся обертками над ссылками?

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

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

Обобщенный и работает, как правило, через итераторы, а не контейнеры. Так что там подобное будет бросаться в глаза.

Тут как раз про особенность контейнеров речь.

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