LINUX.ORG.RU

Пробую разные программы, написанные на Rust

 ,


4

2

Решил попробовать и посмотреть, как там поживает Rust. Ведь все хвалят его. Так что с помощью rustup.rs установил его. Установка пошла успешно. Установщик даже сам прописался в $PATH. Неплохо так.

Потом решил опробовать тайлинговый wm, который тоже создан на Rust. Так что, сделал git clone https://github.com/leftwm/leftwm и cargo build --release. Все установилось. Правда, по дефолту меня встретил чёрный супрематический квадрат (как и в xmonad). Да, я знаю, что фишка этого wm-темы, но я хотел посидеть на дефолте (ненужны мне панельки). Так что, свои программы (feh, compton и setxkbmap -layout) я прописал в .xinitrc. Все завелось, но compton и feh начал плодить зомби. В чем проблема? А в том, что все завязано на так называемых темах. В них присутствуют скрипты, в которых прописанный авто запуск feh и compton, плюс еще что-то по мелочам…и сразу хочется задать вопрос, почему так усложнять жизнь? Все завязано на темах…ну да ладно. Установил я xmobar (данный wm поддерживает lemonbar и polybar), командой создал нужную директорию mkdir -p ~/.config/leftwm/themes, поместил туда темы, и выбрал тему с xmobar-ln -s basic_xmobar/ current. Все заработало. Правда пришлось внести корректировку в файл xmobar-config.hs, отключив кое какие модули. После недельного юзания мой вердикт-работать можно, wm стабильный и предсказуемый, имеет много лайаутов, хорошо дружит в мультимониторной конфигурацией. Мне он понравился.

Также установил эмулятор терминала, под названием wezterm. Терминал хорош, не очень то и прожорлив («кушает» меньше, нежели terminator), gpu-accelerated, хорошо дружит с emoji и другими модными приблудами. Подробнее, можно почитать вот тут. Как запасной вариант еще имеется старый добрый alacritty. Тут я поменял цветовую палитру и шрифты. Смею заметить, что шрифты в wezterm отображаются лучше, нежели в alacritty, хотя последний тоже gpu-accelerated. Как то так.

Другая программа-аналог tmux. Тоже написанная на rust, и по моему субъективному ощущению, работает быстро, имеет кучу опций и настроек

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

Другая cli программа, это простой и легкий клиент irc, под названием tiny. Тоже на rust. Легкая и шустрая, с понятным конфигурационным файлом, приятными цветами и т.п. Пользуюсь на постоянной основе.

Для cat, тоже нашел замену. Название bat. Вещь очень удобная. Комментарии ненужны…

Для замера дискового пространства, использую bat. Это аналог duf, но с более приятным выводом информации.

Использую, (как замену rm) rip. Интересная и удобная утилита, про которую можно почитать вот тут

Shell prompt это starship. Он тоже на rust, а за процессами слежу с помощью bottom.

Вместо браузера используется qutebrowser, который установленный в virtualenv, так как в репах Дебиана он старый как мамонт, а в новой версии много чего исправлено. Так я получил отличную комбинацию стабильности и функционала.

С почти полным списком (неофициальным) программ, написанных на rust, можно ознакомится вот тут.

>>> Просмотр (1920x1080, 441 Kb)

★★★★★

Проверено: cetjs2 ()
Последнее исправление: Odalist (всего исправлений: 3)

Ответ на: комментарий от bread

Ждем когда

Долго ждать придется.

Odalist ★★★★★
() автор топика

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

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

из сидорепы, в тестовой репе арча то же самое

amd_amd ★★★★★
()

Еще одна утилита для просмотра содержимого вашего диска. Это diskonaut. Данная утилита сканирует указанный путь и индексирует его метаданные в памяти, чтобы вы могли изучить его содержимое (даже во время сканирования!). Выглядит вот так.

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

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

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

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

В чём принципиальность?

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

Пока что wezterm сыроват. Окно конвульсивно дёргается при изменении размера.

У меня он нормально работает. Правда, я сижу на xorg с открытыми дровами (nouveau).

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

Успехи у растофанов только в переписывании cat.

Список говорит иначе.

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

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

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

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

А это, в свою очередь, обусловлено тем, что?..

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

Код у меня как раз отторжения не вызывает. Интересно, а что ты скажешь о перспективе лазить по коду на Хаскелле, он гораздо дальше от привычного нам мира, чем бедный Раст — а на Хаскелле, между прочим, целый pandoc написан…

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 2)

Я вот посмотрел на Rust — если сравнивать с сишечкой, то синтаксис приятнее, возможностей больше.

Другое дело, что я, например, сравниваю не с сишечкой, а с плюсами. И вот тут у меня вопрос: почему было не сделать классическое наследование, как в C++? Оно в целом хорошо себя зарекомендовало, его перенесли из плюсов с минимальными изменениями, например, в Java, в C# и в Object Pascal (с поправкой на синтаксис последнего). Зарубили при этом множественное наследование, но оставили возможность создания интерфейсов (которая покрывает где-то 90% случаев применения множественного наследования, а то и больше).

Я знаю, в расте аналогичные возможности делаются через типажи, но всё это как-то более… тяжеловесно, что ли.

Что не понравилось:

  1. Язык разрабатывается, как ни крути, одной командой. То есть шансов «утонуть» у него намного больше, чем у C++, который продвигается несколькими разнонаправленными командами и стандартизуется комитетом (на C тоже есть стандарты). @Croco вот считает комитеты злом, в чём-то он прав, комитеты далеко не всегда принимают лучшее решение — но если язык неиллюзорно может помереть из-за того, что хозяин наигрался, это куда большее зло. На том же паскале не слишком хорошо отразилось то, что долгие годы им никто, кроме Борланда, по сути не занимался. Да, возможно, в эпоху копроэкономики я слишком много хочу — но вот код на C++ 20-летней давности, если он не завязан на гуёвые тулкиты и другие быстропротухающие библиотеки, я могу и сейчас спокойно использовать. Будет ли такое через 20 лет с сегодняшним кодом на Rust?..

  2. Разрабатывая программу на Си, я могу заранее надёргать из интернета пакетов типа libFooBar-dev и обеспечить себе возможность для автономной работы. Более того, я их и файлами могу натаскать. В rust же всё слишком завязано на собственный онлайновый менеджер пакетов. Впрочем, возможно, это болезнь роста и хотя бы для популярных библиотек со временем тоже сделают dev-пакеты…

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

В rust же всё слишком завязано на собственный онлайновый менеджер пакетов.

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

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

Это еще сравнительно ничего, ведь он не пробовал собрать termonad….

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

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

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

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

кучу всего

Список в студию.

Поддержка всего этого в си,

Да? foot легкий, быстрый, с чистой кодовой базой. На сишке. Нет там никакой занозы.

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

Другое дело, что я, например, сравниваю не с сишечкой, а с плюсами. И вот тут у меня вопрос: почему было не сделать классическое наследование, как в C++?

Бог бы с ним, с классическим наследованием. Это одна из наименьших проблем.

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

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

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

В rust же всё слишком завязано на собственный онлайновый менеджер пакетов.

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

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

почему было не сделать классическое наследование, как в C++? Оно в целом хорошо себя зарекомендовало, его перенесли из плюсов с минимальными изменениями, например, в Java, в C# и в Object Pascal

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

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

Язык разрабатывается, как ни крути, одной командой.

Организационно это одна команда, но спонсируется разработка несколькими корпорациями: https://foundation.rust-lang.org/members/

То есть, если условный гугл наиграется и выйдет из этой организации, то останутся другие.

Будет ли такое через 20 лет с сегодняшним кодом на Rust?..

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

Разрабатывая программу на Си, я могу заранее надёргать из интернета пакетов типа libFooBar-dev и обеспечить себе возможность для автономной работы.

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

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

Мне в крейтах больше всего нравится то, что для сборки какой-нибудь фигни прилетает и вырабатывается файлов на кучу Гб и вот это мягко говоря жесть как пугает, т.к. если для сборки фигни(консольного текстового редактора) 40 крейтов отжирают 2-3 гб места на диске, то спрашивается что будет если что-то серьёзное будет создаваться. Плюс сам факт то, что крейты на каждый чих делают это для питонячих модулей не страшно, но для компилируемого языка это очень как страшно особенно, если полетит совместимость, с другой стороны если считать крейты юнит-тестами, то всё становится на свои места. Единственная прога на расте, которую нашёл реально прикольной это mdbook, но всё остальное либо недоделки jff, либо обвязки или порты к существующим библиотекам.

AKonia ★★
()
Последнее исправление: AKonia (всего исправлений: 2)
Ответ на: комментарий от DarkEld3r

Опять же, наследование данных (чего в расте как раз нет) хорошей практикой и не считалось.

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

hobbit ★★★★★
()

Хорошо, просветил, а alacritty мне не понравился в сравнении с urxvtd + urxvtc, что то тормозной или настроить не смог, какая там акселерация, стартовал заметно кусками слева-направо и сверху-вниз.

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

обоина не ахти

Скриншот не ради обоины. Я писал, что это почти дефолт. А обоину можно и менять, но смыла в ней не вижу.

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

стартовал заметно кусками слева-направо и сверху-вниз

А фиг его знает. У меня он стартует нормально, но есть другая проблема. Прозрачность не работает. А в других терминалах работает…соглашусь. Этот alacritty не самый лучший вариант.

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

для консоли интерфейс ncdu

Тут фишка в другом. Как пишет разработчик (мне лень переводить)

scans it and indexes its metadata to memory so that you could explore its contents (even while still scanning!)

Это приводит к тому, что утилита работает молниеносно.

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

А другие употребляют haskell.

У меня C + Lua, так что твои данные слегка неверны.

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

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

Вопрос в том как часто оно нужно. Тут ведь палка о двух концах: ограничения подталкивают сделать «правильно».

Ну и RFC на эту тему есть, так что вопрос не совсем закрыт. Опять же, есть «костыли» позволяющие не писать этот код руками.

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

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

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

И вот тут у меня вопрос: почему было не сделать классическое наследование, как в C++?

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

Оно в целом хорошо себя зарекомендовало, его перенесли из плюсов с минимальными изменениями, например, в Java, в C# и в Object Pascal (с поправкой на синтаксис последнего).

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

Minoru ★★★
()

Спасибо, проблевался. Завязывай с чёрным фоном, глаза не восстановить.

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

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

Про наследование. Я пишу на жаве и считаю наследование антипаттерном.

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

Это diskonaut

Выглядит вот так.

Вау! Классический вложенно-прямоугольный интерфейс а-ля DiskMapper / QDirStat / Konqueror plugin, только для консоли! Надо будет заценить, мне такой вид всегда нравился больше всяких баобабов и секвой.

P.S. Хотя как раз на этом скриншоте я вложенности не наблюдаю. Но может просто каталог надо взять другой?..

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

вот

В foot нет поддержки лигатур (хотя есть MR на тему). Не знаю, что за SGR-style mouse, гугл молчит. Вкладок в foot нет, как и ssh-клиента – это задача не терминала. Остальные пункты – чек.

Wayland ненужен.

Спасибо за ценное мнение.

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

Да, можешь его опробовать сам. Тем более, что его и устанавливать ненужно. Просто скачиваешь бинарник, и закидываешь в $PATH.

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

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

Как пишет сам разработчик

you can navigate through subfolders, getting a visual treemap representation of what’s taking up your disk space. You can even delete files or folders and diskonaut will track how much space you’ve freed up in this session.

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

В foot нет поддержки лигатур

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

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

Остальные пункты – чек.

Я пробовал его. Как потом выяснилось, это он виновник того, что вся сессия фризилась.

Спасибо за ценное мнение.

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

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

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

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

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

du — это классика, но чтобы от неё был толк, её надо несколько раз вызывать из разных мест с разными max-depth и анализировать результат каждой итерации. Это как раз тот случай, когда второе измерение — благо.

P.S. score=2022, на дворе 2022 год…

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

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

Ты, наверное, путаешь find и du? du обходит директории, делает это рекурсивно, файлы обрабатывает лишь если они явно в командной строке даны. Это дефолтное поведение. Т.е. никакого размазанного вывода не будет, на выходе список из директорий (рекурсивно) и их размеров, потом уже можно прицельно просканить файлы в нужной жирной директории. Кстати, скан через du также кэшируется, никаких доп телодвижений для этого делать не надо, это на более низком уровне происходит. А если ssd, то вообще пофиг.

Я честно считаю du удобнее, и выглядит на мой взгляд это всё примерно как - «не осилил по-нормально».

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