Продемонстрирована возможность разработки частей Linux на Rust

от повторений должно спасать ide

При чтении тоже? Я хоть и сам считаю, что правильная IDE кучу времени экономит, но все проблемы языка/синтаксиса ей не заткнёшь.

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

даже если портить человеку зрение кавычками и однобуквенными обозначениями типа 'a)

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

вот только обсуждение проблем с объектами нулевой длины меня как-то насторожило — сыроват язык еще

Ну и какие проблемы и «сырость» ты тут видишь? Ну кроме «непривычности».

когда в жабке пишут public static final Борщ борщ = new Борщ() то тут повторение идиотское, так как все рядом

В твоём примере тоже всё рядом:

f(x,y) = int { x = int(?); y = int(2);

При чтении тоже?

если в abstract-е статьи все 3 фразы будут без изменений взяты из основного текста статьи, ты тоже будешь недоволен?

это я к тому, что как раз таки такой подход помогает чтению

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

именно в таком случае они смотреться будут лучше, так как объявление функции в одну строку таки влезет

плюс к этому — многие пишут доки на параметры, и там опять придется повторять его, а здесь — нет; как это может выглядеть:

do_something_interesting( parameter1, parameter2, parameter3 ) = void { // делает что-то такое этакое (сюда можно впихнуть и длинное описание)

    parameter1 = &%%\$%^('a) SomeClass(?); // тут описание параметра1 для доков 
    parameter2 = &%%\$%^('a) SomeClass(?); // тут описание параметра2 для доков 
    parameter3 = &%%\$%^('a) SomeClass(?); // тут описание параметра3 для доков 

    // тело функции

    really_do_something( parameter1+parameter2 ); 
    really_do_something( parameter3+3 ); 

}

&%%\$%^('a) это подколка, если че

кстати, часто исходя из названия параметров более-менее понятен их тип, так что читать

select_log_enties( start_time, end_time, criteria ) = array(String) {

можно не глядя вовнутрь

при этом тип возвращаемого значения важен, т.к.

select_log_enties( start_time, end_time, criteria ) = array(ParsedLogEntry) {

В твоём примере тоже всё рядом

 f(x,y) = какой-то-охрененно-сложный-тип(с несколькими параметрами, но в одну строку) { x = int(?); y = int(2);

Ну и возвращаемое функцией значение как-то выбивается из остального синтаксиса.

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

если в abstract-е статьи все 3 фразы будут без изменений взяты из основного текста статьи, ты тоже будешь недоволен?

Я «буду недоволен» из-за использования кривых аналогий.

это я к тому, что как раз таки такой подход помогает чтению

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

именно в таком случае они смотреться будут лучше, так как объявление функции в одну строку таки влезет

Ты издеваешься? Я специально говорю об особом случае когда параметров много и/или имена у них длинные. И такие случаи, наверняка, будут.

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

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

это идет из математики, и иногда уместно в программировании, а иногда нет; я протестовал не против однобуквенности вообще, а против кавычки в левом верхнем углу

Другое дело, что они придумали where костыль из-за которого имеется и так нелюбимое мной «повторение» (при объявлении типов в дженериках)

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

два вида синтаксиса на ровном месте

да, это плохо

Как последний аргумент: наверняка у твоего примера из джавы найдутся защитники. Мол ну и что, что повторяется, зато точно глаз зацепится и т.д.

гы-гы, зацепится

на самом деле часто тип локальной переменной только засоряет восприятие

не, ты давай серьезно

есть определенные критерии, в которых в общем-то есть согласие, и есть достаточно субъективные границы их применимости; о местоположении границ могут быть уже субъективные разногласия (ну не всегда скажем совсем субъективные — зависит, например еще и от используемого стиля в работе — документирует ли чел параметры функций и т.д.)

Я «буду недоволен» из-за использования кривых аналогий.

аналогия прямая

есть общепризнанный критерий DRY; я утверждаю, что у него имеется граница применимости (после пересечения которой DRY полезно именно нарушать), для доказательства чего и привел пример с abstract-ом

Ты издеваешься? Я специально говорю об особом случае когда параметров много и/или имена у них длинные. И такие случаи, наверняка, будут.

?

что тебе не понравилось в функциях do_something_interesting и select_log_enties?

С документированием параметров идея интересная

тут eao197 тебе явно бы сказал что-нить резкое про тех, кто их не документирует

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

кстати, иногда текст все же нужен, т.к. не очевидно, почему на параметр наложено какое-то ограничение

но со своими недостатками.

какими?

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

и в чем здесь проблема?

скорее наоборот — проблема это когда комменты к функции лежат где-то вне ее тела

нихрена у вас там спарта. вот говорил я что растаманы это люди, измученые сегфолтами.

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

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

аналогия прямая

Ну я не согласен.

Ладно, мы зашли в тупик. Ты уверен, что повторение «в нужных местах» идёт на пользу. Я не согласен, что список параметров и их типы - то самое «нужное место».

что тебе не понравилось в функциях do_something_interesting и select_log_enties?

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

do_something_really_really_interesting(very_descriptive_parameter_name, another_important_parameter, dont_forget_about_me_too)

тут eao197 тебе явно бы сказал что-нить резкое про тех, кто их не документирует

Так ты сам не согласен, к чему тогда этот аргумент?

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

Традиционно оно как раз перед функцией описывается и форматирование функции не затрагивает.

проблема это когда комменты к функции лежат где-то вне ее тела

«Какие?»

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

но. вот такой нюанс: на с++ можно писать так чтоб сегфолтов не было. умные указатели, блаблабла. можно weakptrы и sharedptrы «как в glib» запилить, тоже мегавещь. вместо массивов контейнеры и доступ через методы с проверкой. но так бывает неудобно. поэтому оно и падает.

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

вот такой нюанс: на с++ можно писать так чтоб сегфолтов не было. умные указатели, блаблабла. можно weakptrы и sharedptrы «как в glib» запилить, тоже мегавещь.

в расте есть reference counting, так что все эти тормоза (которые ты называешь мегавещи) из с++ тоже доступны

но так бывает неудобно. поэтому оно и падает.

вот это уже ближе, но недостаточно конкретно, и я попробую внести ясность (хотя это скорее тема для обсуждения, чем ясность)

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

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

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

свое_растовское_ооп там есть, но оно афайк вопрос с unsafe никак не регулирует

Ты уверен, что повторение «в нужных местах» идёт на пользу.

слово «повторение» по-русски означает как процесс повторения, так и его результат; слово «оглавление» по-русски означает только результат, но я его применю в смысле «процесс»

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

Я не согласен, что список параметров и их типы - то самое «нужное место».

ну тут знаешь в определенной степени привычка, в математике пишут f(x,y) = ... и я считаю такого рода оглавление (даже если потом потребуется повторить названия переменных) разумным (а не только привычным)

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

Так ты сам не согласен, к чему тогда этот аргумент?

для меня истиной являет не то, с чем я согласен, а истина (сюрприз?)

к чему

это провокация к тому, чтобы прояснить этот вопрос

Традиционно оно как раз перед функцией описывается и форматирование функции не затрагивает.

смотря где традиционно; в питоне например doc string внутри функции

«Какие?»

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

в принципе, отсутствие doc string в стандарте языка это не совсем правильно (хотя и не сказать, что совсем не правильно), а вот то, что они болтаются где-то вне функции — это совсем неправильно

do_something_really_really_interesting(very_descriptive_parameter_name, another_important_parameter, dont_forget_about_me_too)

тут да, описание вида

do_something_really_really_interesting(
    very_descriptive_parameter_name, 
    another_important_parameter,
    dont_forget_about_me_too
)

будет более читабельным, и читабельность не ухудшится, если мы сделаем там же описания

do_something_really_really_interesting(
    very_descriptive_parameter_name, // дополнительное описание этого параметра
    another_important_parameter, // дополнительное описание этого параметра
    dont_forget_about_me_too // дополнительное описание этого параметра
)

и даже так

do_something_really_really_interesting(

    very_descriptive_parameter_name, // дополнительное описание этого параметра
                                     // в несколько строчек
    another_important_parameter, // дополнительное описание этого параметра
                                 // в несколько строчек
    dont_forget_about_me_too // дополнительное описание этого параметра
                             // в несколько строчек
)

хотя я бы предпочел все равно

do_something_really_really_interesting($$$) = void {

    very_descriptive_parameter_name = MyClass(?); // дополнительное описание этого параметра
                                                  // в несколько строчек
    another_important_parameter = int(?); // дополнительное описание этого параметра
                                          // в несколько строчек
    dont_forget_about_me_too = bool(true); // дополнительное описание этого параметра
                                           // в несколько строчек

    ...
}

к чему

да, еще к тому, что я и сам думаю над этими вопросами

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

все эти тормоза

походу ты кроме shared_ptr ничего больше не знаешь. неудивительно что С++ срет тебе в шаровары

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

походу ты кроме shared_ptr ничего больше не знаешь. неудивительно что С++ срет тебе в шаровары

телепат из тебя явно никакой; а по сути дела какие-то возражения будут?

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

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

вторая претензия в том, что он не готов принять от меня имеющуюся у меня информацию, но с этим частично можно бороться кодогенерацией

Эт точно, даже в стандарте написано: «Все фекальные массы

ты говоришь это так, как будто в расте ситуация чем-то лучше

Уже и посмеяться нельзя. Впрочем, стандарта у Rust'а нет.

Да, если safe Rust'у удастся насрать вам в шаровары, то можете писать баг репорт.

я тебе уже сказал, что кроме shared_ptr ты ничего не знаешь. поэтому «тормоза». не пиши на С++, пиши на жабе.

т.е. кто и когда имеет право поставить unsafe компилятору совершенно пофиг

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

т.е. если переменная ранее не упоминалась, она становится параметром первой объемлющей ее функции

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

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

В расте они формально «в стандарте».

а вот то, что они болтаются где-то вне функции — это совсем неправильно

Не убедительно. Как насчёт атрибутов? Они ведь тоже «где-то вне функции».

а вот то, что они болтаются где-то вне функции — это совсем неправильно

Не убедительно. Как насчёт атрибутов? Они ведь тоже «где-то вне функции».

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

если бы докстринг был в грамматике языка до функции (и отличался от комментариев) — тогда твое возражение имело бы смысл

В расте они формально «в стандарте».

где конкретно?

я тебе уже сказал, что кроме shared_ptr ты ничего не знаешь. поэтому «тормоза». не пиши на С++, пиши на жабе.

гыгыгы

да ты упорный как я погляжу

ну расскажи мне, как на жабе делать ассемблерные вставки AVX... только не надо втирать мне про jni, т.к. там, в общем-то, main из одного вызова jni и будет состоять

еще мне интересно, как на яве сделать L0/L1/L2 cache pin (в том смысле, что мне нужно, чтобы никто определенный кусочек кэша не засирал, несмотря на то, что общий объем обмена с памятью будет исчисляться терабайтами)

и наконец, как на яве написать что-то вроде something<512> — там же дженерики, а не шаблоны (а про отсутствие в яве перегрузки операторов сам догадаешься, или как?)

Более того, это ЯП и ОС.

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

нет, я про другое — вызов какого-то средства unsafe (ну там transmute) это у нормальных людей был был вызов приватного/protected/friend метода memory_object, box_object, rc_object и т.д.

где конкретно?

https://doc.rust-lang.org/1.13.0/reference.html#comments

у нормальных людей был был вызов приватного/protected/friend метода memory_object, box_object, rc_object и т.д.

И как это работало бы? Если надо именно дать возможность снаружи такие методы дёргать.

https://doc.rust-lang.org/1.13.0/reference.html#comments

ок

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

И как это работало бы? Если надо именно дать возможность снаружи такие методы дёргать.

те которые приватные требовали бы изменения в коде стандартной библиотеки и ее перекомпиляцию для данного проекта (btw, 2 перекомпиляции для разных проектов вполне могут быть несовместимы, что можно *так* обнаружить, но хрен обнаружишь если просто лепить unsafe); те, которые protected и friend — там нет проблемы дергать снаружи (хотя friend тоже перекомпиляцию потребует, но 1 раз)

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

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

ну так это же я так в ответ мщу ему... разве не ясно?

кстати, я если он не образумится, я его и дальше троллить попробую — лет 5 назад плюсовые компиляторы генерили такой тормозной код для исключений, что жабские исключения работали в 10-100 раз быстрее

не знаю правда как щас

этап «Б» — это привести этот код, замеры времени, и долго рассказывать о том, как я ему благодарен за отличный совет «переписать все на жабе», гы-гы-гы

те которые приватные требовали бы изменения в коде стандартной библиотеки и ее перекомпиляцию для данного проекта

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

Сейчас unsafe вполне себе работает. Да, можно назвать это «костылём» нужным там, где раст в «безопасной» части оказывается недостаточно гибок, но какая разница. Для библиотеки использовать внутри unsafe и выставлять безопасный интерфейс - это очень даже правильных подход. Пользователям не нужно знать об этом. Да, может быть баг, но как будто в библиотеке не может быть логических багов или утечек памяти без всякого ансейфа.

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

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

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

*именно поэтому* иногда надо библиотеку именно перекомпилировать

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

раст, конечно, может претендовать на выработку стандарта стандартной библиотеки, которая используется си-подобными языками без перекомпиляции — но надо учитывать, что от системного языка ожидается в том числе и возможность кастомной стандартной библиотеки (раст на это рассчитывает? или как?)

Для библиотеки использовать внутри unsafe и выставлять безопасный интерфейс - это очень даже правильных подход.

я подозреваю, что это в принципе невозможно по той причине, что две (или три) разных библиотеки, использующие unsafe, могут быть 100% безопасны по отдельности, но опасны вместе

это может произойти потому, что у них несовместимые assumptions относительно чего-то, что они все вместе пытаются модифицировать

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

я подозреваю, что это в принципе невозможно

Существует много библиотек у которых нет общих глобальных переменных или общего глобального состояния.

раст на это рассчитывает?

«Отключить» (и соответственно подменить) стандартную библиотеку возможно.

это может произойти потому, что у них несовместимые assumptions относительно чего-то, что они все вместе пытаются модифицировать

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

в ооп частично делается проверка на совместимость

Нее, если мы начинаем фантазировать о несовместимости библиотек по «непонятным причинам», то ООП тут никак не помогает.

я подозреваю, что это в принципе невозможно по той причине, что две (или три) разных библиотеки, использующие unsafe, могут быть 100% безопасны по отдельности, но опасны вместе

Один вариант: две библиотеки используют третью, предоставляющую мутабельную ссылку на синглтон. Совместное использование этих библиотек приведёт к UB. Но тут не все библиотеки предоставляют безопасный интерфейс.

Другой вариант: библиотека с помощью unsafe лезет в приватные данные структур другой библиотеки, нарушает какие-то инварианты, которые не важны для её правильной работы, но эти инварианты важны для другой библиотеки. Такую библиотеку сложно назвать 100% безопасной.

Пока больше ничего не придумывается.

Существует много библиотек у которых нет общих глобальных переменных или общего глобального состояния.

проблема с unsafe в том, что он вообще говоря позволяет двум разным библиотекам иметь общие instance-переменные, что не позволяет даже ооп (хотя этого тоже можно добиться, но упорядоченно, через protected скаже)

этими instance-переменными могут быть например 2 младших бита указателя — они большей частью равны нулю, поэтому одна библиотека может 100% надежно заняться их полезным использованием, и вторая библиотека может 100% надежно заняться их полезным использованием, но 2 библиотеки вместе приведут к коллизии

но чтобы это заработало, 2 библиотеки должны например как-то хитро перегрузить Deref, так, чтобы компилятор согласился с их совместным существованием — м.б. 2 библиотек не хватит и потребуется 3-я

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

две библиотеки В и С через unsafe лезут в приватные данные третьей библиотеки А, при этом лезут совместимо с А, но несовместимо друг с другом

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

Нее, если мы начинаем фантазировать о несовместимости библиотек по «непонятным причинам», то ООП тут никак не помогает.

эээ... ммм... кому непонятные, а кому...

так что испортить А с помощью 100% безопасных по отдельности В и С это мне раз плюнуть, проблема в другом:

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

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

зачем выкидывать? использовать по отдельности — вполне рабочий вариант

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

Другой вариант: библиотека с помощью unsafe лезет в приватные данные структур другой библиотеки, нарушает какие-то инварианты, которые не важны для её правильной работы, но эти инварианты важны для другой библиотеки. Такую библиотеку сложно назвать 100% безопасной.

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

В Rust assumptions принято выражать с помощью системы типов. Так что не представляю как такой вариант может пройти.