LINUX.ORG.RU
ФорумTalks

Доброе слово про раст

 ,


3

8

Я много ругал Раст, по делу и без дела. Но есть в расте нечто, что является его несомненным плюсом.

Так получилось, что я пилю свой «кисий» язык. Название выбрано таким потому что изначально я хотел сделать инструмент для моделирования микросхем вместо анального верилога. Ну чтоб сразу и топологию прикинуть можно было и шины в один тык менять например 2 параллельные на одну double data rate. В общем была такая задача, потом подумалось что с помощью небольших усилий можно из имеющегося супа сварить игру песочницу для симуляции 8битных компов. Прямо с платами, 3д модельками микрух. И назвать я ее решил к155ла3. Собственно язык был назван «к».

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

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

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

При чем же тут Раст, спросите вы? А вот я, хоть и считаю Раст попыткой рукожопов отомстить своим кривым рукам, почитал про этот самый раст. Некоторые концепции мне очень даже понравились. Например вот это impl. У меня та же срань сделана. И matching тоже збс идея. Вы даже не представляете насколько она тащит. Не сама реализация а идея о том, что переменная может быть больше чем просто сама она, а может также содержать например инфу об ошибке.

Например пусть у вас есть переменная Х. Пусть её тип не указан. То есть по факту переменная Х содержит два значения - адрес данных о типе и значение. Пусть Х = 5.4/0.0; давайте в Х добавим возможность посмотреть флаги операции: nan, денормализованное, и т.д. пусть Х=0х80000000+0х80000000. Давайте дадим возможность прочитать carry flag: Х.carry. Пусть Х = 0х80000000*0х80000000. Давайте дадим возможность прочитать старшие 32бита результата. Это лишние поля в большинстве случаев но оптимизация может херить неиспользуемые поля.

Я думаю что Раст это на самом деле хорошее явление. Люди ищут новые пути и решения и это можно только приветствовать. Беда Раста в том, что люди, создающие его, создают ещё один язык. Язык это текстовое представление. А если быть точным - то это представление двадцатого века как и блок схемы.

Это статичное представление: его можно напечатать на бумаге, отсканировать волшебным сканером с нейросеткой и получить обратно свой код. Кисий язык нельзя распечатать на бумаге, его видимое представление зависит от того, что ты сейчас исследуешь. Лишнее отфильтровается. Ну правда, кто лопатил сырцы на 5к+ строк поймет в чем профит.

Расту надо выйти за рамки статичного представления чтоб стать 'убийцей с++". Ему надо... Например включить в себя конечные автоматы на уровне языка, принудительно вычисляемые величины(как в верилоге assign x=...) и поддержку диаграмм. Чтоб автомат был именно что наглядным. Это довольно малая модификация языка но я вам прямо скажу: если такое будет в расте, Раст начнет теснить и то нагибать плюсы

☆☆☆

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

Не нашел, точнее нашел вот это http://faust.grame.fr, но так и не понял каким местом оно имеет отношение к выше обозначенной идее.

Главная проблема с этими изобретениями - таже, что и с VIM - от пользователя требуется хотябы базовая квалификация

Какая еще «базовая квалификация»? Тут речь и программистах идёт, если что.

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

У тех же Ады и Objective-C никаких проблем в смешивании с чем угодно.

Судя по всему, даже у разработчиков Objective-C не получилось с первого раза:

-fobjc-abi-version=n Use version n of the Objective-C ABI for the selected runtime. This option is currently supported only for the NeXT runtime. In that case, Version 0 is the traditional (32-bit) ABI without support for properties and other Objective-C 2.0 additions. Version 1 is the traditional (32-bit) ABI with support for properties and other Objective-C 2.0 additions. Version 2 is the modern (64-bit) ABI. If nothing is specified, the default is Version 0 on 32-bit target machines, and Version 2 on 64-bit target machines.

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

Суть проблемы в том что ребята разрабатывающие rust положили болт почти на все из них, тоесть своеобразный NIH syndrome.

А какая альтернатива? Впилить поддержку rust в «SYSTEM V APPLICATION BINARY INTERFACE. Edition N+1»? Просто так взять и натянуть чужеродное ABI на новый ЯП не выйдет. Если конечно этот новый ЯП - не всё тот же C/C++, только с новым нескучным синтаксисом. Куда девать фичи языка, которые существующий ABI не поддерживает?

Ну и к тому же, в расте ABI не стабилизировался ещё. А если посмотреть на C++, то видимо никогда и не стабилизируется =).

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

Не нашел, точнее нашел вот это http://faust.grame.fr, но так и не понял каким местом оно имеет отношение к выше обозначенной идее.

Стукни в личку на выходных - поищу

Какая еще «базовая квалификация»? Тут речь и программистах идёт, если что.

Попробуй человека после Вижуал Cтудии или Эклипса пересадить на VIM или Emacs. Обезянки пых-пых смогут выполнять свои обычные обязанности ой как не скоро ... С твоей идеей тоже самое - требуется повышение квалификации.

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

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

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

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

Ну и к тому же, в расте ABI не стабилизировался ещё.

Эххх ... Ты немного не о том подумал ... System V - это «низкоуровневое» ABI, а то о чем ты подумал «высокоуровневое».

А если посмотреть на C++, то видимо никогда и не стабилизируется =).

Насколько я знаю G++ версий 7.0 и выше в конце концов смог System V ABI, что доказывает весьма хороший дизайн System V ABI, а также то что в него теперь можно впихнуть все на что хватит фантазии ...

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

пересадить на VIM или Emacs

еще на кактус жопой можно пересадить. но зачем?

ckotinko ☆☆☆
() автор топика
Ответ на: комментарий от cvv

в линуксе разве есть стандартизация? ой вэй.

LSB делали в каком-то московском НИИ студенты за 22500 рублей во времена моей молодости. я даже сам чуть туда не устроился. отличный «стандарт» запилили, например «стандартизировали» rpm. я то думал, что стандарт описывает «интерфейсы», которые потом implemented программами а вот х

ckotinko ☆☆☆
() автор топика
Ответ на: комментарий от cvv

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

Тут недавно проскакивала статья от разработчиков JIT для JVM. Чтобы ввести новых разработчиков в курс дела может потребоваться 2-3 года. А переписав его с крестов на джаву новые разработчики втягиваются за 2-3 месяца (в том числе благодаря возможностям IDE)

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

Получается такой-себе Knowledge-Based System с заточкой на исходники, я правильно понимаю?

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

доморощенный, хипстерский ABI. Взяли бы стандартный - цены бы небыло.

И в чем профит?

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

А ещё был одноимённый язык от проекта deeptown.org, ныне загнувшегося. Букву K вообще многие любят и вносят путаницу.

hobbit ★★★★★
()

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

Я правильно понял, что его также нельзя целиком в текстовом виде поместить в VCS и получить при необходимости человекочитаемый diff? Если да, то это плохо, очень плохо.

Мне лет 20 назад довелось попрограммировать (к счастью, недолго) на недоразумении под названием Oracle Developer. Там как раз понятие исходного кода отсутствовало. Программисту показывались только кусочки кода в виде триггеров и функций. Всё остальное было зашито в сраный ублюдский блоб. И это очень сильно било по рукам.

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

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

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

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

В общем с просто текстом возникает много проблем за пределами самого текста. Мне бы пришлось по сути шланг с нуля писать. До

ckotinko ☆☆☆
() автор топика
Ответ на: комментарий от Deleted

Нет ничего плохого в нестабильном abi если оный версионирован, и в пределах одного дистра зафиксирован. Язык это инструмент типа молотка. Молоток апгрейдяд и иногда приходится менять и дизайн ручки молотка. Если её не делают в форме дилды и крючка то почему бы и нет?

ckotinko ☆☆☆
() автор топика

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

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

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

Пропускаем пятое поколение, лучше делать сразу шестое

Например пусть у вас есть переменная Х. Пусть её тип не указан. То есть по факту переменная Х содержит два значения - адрес данных о типе и значение. Пусть Х = 5.4/0.0; давайте в Х добавим возможность посмотреть флаги операции: nan, денормализованное, и т.д. пусть Х=0х80000000+0х80000000. Давайте дадим возможность прочитать carry flag: Х.carry. Пусть Х = 0х80000000*0х80000000. Давайте дадим возможность прочитать старшие 32бита результата. Это лишние поля в большинстве случаев но оптимизация может херить неиспользуемые поля.

Это сколько уже полей на одну(!) переменную? Сколько килобайт метаданных будет занимать полное описание сортировки пузырьком? Не во все компы возможно даже 16 Гб воткнуть. А теперь внимание вопрос: какой момент в сортировке пузырьком будет оптимизирован благодаря всему этому? И главное во что? Защитит ли этот «язык» от применения сортировки пузырьком вместо поиска максимума?

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

То есть текст-выборка из еще больше текста. Ясно-понятно.

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

t184256 ★★★★★
()

Меня начало напрягать в Rust последнее время эта тенденция. Чуть ли не 90% всех библиотек на Rust - это обертки поверх C.

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

Начал пряглядываться к различным бибилотекам - копии сишных API.

Например, есть реализация парсинга неких файлов на C, где есть условная функция void abc_func();. То зайдя на гитхаб к любому умнику, ты увидишь pub fn abc_func();.

Почему Wayland+Rust меня смутил. А потому что это просто протокол. Идея передачи туда-сюда сообщений. Но вместо этой идеи мы юзаем библиотеки libwayland-client.so и libwayland-server.so.

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

И самое смешное - дублируется цепочка зависимостей на C A -> B -> C в цепочку на расте A-rs -> B-rs -> C-rs.

Вместо того чтобы сделать POSIX обертку, а потом уже юзать раст библиотеку на самом расте(что очень удобно). Мы будем писать каждый раз обертку на каждый уровень абстракции.

В итоге ты задаешься вопросом, если раст просто повторяет API и юзает unsafe, тогда какого хрена я не пишу на C?

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

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

Например, есть реализация парсинга неких файлов на C

а что за файлы?

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

Тогда уж на c++: raii namespace и прочие н ништяки здорово упрощают программирование на плюсах как на си а есть не просят

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

Ну я ж типа такой модный - решил поднакопить опыта на новом языке + иметь свое(на Си wayland композитор со своими окошками и пнелькой на 40% готов). Ну как демка для портфолио.

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

ну во-первых, не обязательно текст.

есть выборка, например

class Foo 
 |
 +--int bar()
 |     |
 |     +---int arg0
 |     |
 |     +---float arg1
 |     |
 |     +---Lol arg2
 |     |
 |     +---{}
 |         |
 |         +----if (arg0 < arg1)
 |         |     |
 |         |     +----arg2.method()
 |         |     |
 |         |     ...
 |         ...     
 ...
}
Мы можем записать это как текст:
class Foo {
    int bar(int arg0, float arg1, Lol arg2) {
        if (arg0 < arg1) {
            arg2.method()
            ...
        }
        ...
    }
}
потом мы этот текст можем редактировать как текст. и он будет обратно в модель собираться и даже при этом помнить форматирование как отдельные строки.

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

ckotinko ☆☆☆
() автор топика
Ответ на: комментарий от pftBest

Утрирую. Вот пример https://github.com/baist0/x11-rs. Это мой репозиторий. Форкнул код. Я туда добавлял поддержку MIT-SHM который позволяет быстро рисовать на иксах всякую хрень попиксельно.

Понимаешь! Если ты решил на расте что-то большое и классное напедалить - начинается веселье с байндингами. Ты увидишь в моих репо posix.rs. Потому что если хочешь на иксах использовать расширение Shm, то тебе нужен посикс вызовы еще. А они отдельно от иксов идут. А сами библиотека писалась под старую, бэту версию раста. И получается собрать сразу никак. Приходится еще допиливать и переделывать под новый синтаксис.

Это маленький случай. А большой случай когда ты обнаруживаешь чтобы написать полноценный Wayland композитор(а там менеджер окон, shell, панель, отрисовка, поддержка X11 - Xwayland) то тебе нужен libinput - для мышки и клавы, тебе нужен waylandscanner - для протокола, тебе нужен libDRM - для работы с графикой в целом, тебе нужен cairo - для рисования, Unix file I/O - для открытия сокета дисплея. И ты смотришь чужие реализации. И ты видишь сплошные обертки с раздутым dependency.

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

Собственно я и есть тот самый неленивый человек. Я реализую native library wayland на ржавчине. Есть сишные примитивные вызовы ядра и всякий ввод/вывод (ядро имеет сишный интерфейс, тут никак), все остальное свое.

Преимущество в этом - нет зависимости от пакета libwayland*.so. У тебя голая система без GUI, ты качаешь код, собираешь и запускаешь и оно работает. А дальше используя библиотеку реализуешь свой тайловый или стековый менеджер, как хочешь.

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

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

Это даже хорошо, что MIT-SHM, вызывает страдания.

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

Поздравляю, ты изобрел манипуляции на уровне AST.

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

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

Вот, я полностью воспроизвел твой пример shm звездного неба:

https://github.com/pftbest/x11-rust-example

И даже починил ещё событие закрыть окно. Запусти, посмотри как оно работает. Команда cargo run --release --example xshm

У меня используются только две библиотеки: libc и bindgen. Никакие posix.rs тебе не нужны, все что есть в posix.rs уже и так есть в libc. А то чего нет в libc, например X11 и Xext генерируется при помощи bindgen из заголовочного файла.

То же самое и с libinput и libDRM, добавляешь их заголовочные файлы в bindgen и пользуешься. Unix file I/O есть в libc.

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

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

А если не делать IPC_RMID после attach, то работает и на macOS. Похоже это линукс специфическая фишка, что сегмент не удаляется пока все его не отдетачат.

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

Да я понмю! Я твой код у себя заюзал.

Я хочу уйти от зависиости к си библиотекам там где это возможно. Потому что Rust язык для написания всяких низкоуровневых вещей и библиотек.

Почему я не хочу писать на C!? Да потому что громоздко выходит работать с данными. C алгоритмический процедурный язык. На нем в кайф писать всякие сортировки, шифрование, делать хакерские трюки. Ну это хакерский язык созданный людьми из первых хакеров.

Но посмотри на работу со списками в Wayland - это ж просто кошмар. Просто зоопарк процедур ради того чтобы описать работу с контейнером std::list из C++ стандарта. Глобальные переменные. Хотя нормальные сишники редко используют глобальные вещи. То что твой «старшеклассник на летней практике» делает при изучении C++ в первые месяцы изучения, делают разработчики вяленого на последних этапах.

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