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)

Я много ругал Раст, по делу и без дела.

Хоть кто-то честно признался. Дальше можно не читать.

Virtuos86 ★★★★★
()

попыткой рукожопов отомстить своим кривым рукам

Хорошо сказано, не конкретно про Rust, а про некоторые современные тенденции.

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

Раст все равно shit в его текущем виде. Гарантирует что память не утечет и что то там про указатели и на этом всё.

Зато все UB из C++ встроены(спасибо llvm), куча всяких эвристических какашек вроде тех же операторов.

Это не win. Это просто очередной нишевой язык, надуваемый фанатами

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

Я первее родился так что буква моя

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

Раст все равно shit в его текущем виде. […] Это просто очередной нишевой язык, надуваемый фанатами

Хорошо, что есть еще железные люди, которые не поддаются хайпу.

Virtuos86 ★★★★★
()

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

Мы как раз представляем. А самой идее уже лет 40-50 (с момента первой реализации).

Например включить в себя конечные автоматы на уровне языка

Не надо. Я думаю, хватит такого подхода (ссылка, ссылка) и макросов.

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

Зато все UB из C++ встроены

Неверно. Учи язык дальше.

tailgunner ★★★★★
()

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

Это план или у тебя уже есть реализация всего этого (или хотя бы пейпер)?

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

Интересно. По одному описанию трудно понять, как именно эта штука работает.

quantum-troll ★★★★★
()

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

Такое впечатление, что для тебя это что-то новое и ранее неизвестное. Если так, то «пилить свой язык» тебе явно рановато.

Zenom ★★★
()

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

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

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

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

Можно вот тут чуть подробней?

Его нельзя распечатать, потому что у него лапки.

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

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

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

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

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

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

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

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

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

В начале коментария не хватает «суть такова» :)

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

Если его нельзя распечатать, то его нельзя и прочитать,

«Не пытайтесь понять! Понять - невозможно!» (ц)

tailgunner ★★★★★
()

поддержку диаграмм

wut? Для этого уже есть Jupyter и Julia.

Давайте ещё рефлексию, GC, гринтреды, constexpr и прочее притянем и получим очередной C++. Разве что на адекватной основе, а не на сишке.

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

Давайте ещё рефлексию, GC, гринтреды, constexpr и прочее притянем и получим очередной C++

Получим Rust образца 2011 года :)

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

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

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

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

Гарантирует что память не утечет

Нет такой гарантии. Его цель отсутствие sigsegv. Утечку памяти там вполне можно организовать намеренно. Как циклическими ссылками, так и std::mem::forget.

И об этом прямо сказано:

forget is not marked as unsafe, because Rust's safety guarantees do not include a guarantee that destructors will always run. For example, a program can create a reference cycle using Rc, or call process::exit to exit without running destructors. Thus, allowing mem::forget from safe code does not fundamentally change Rust's safety guarantees.

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

Только что написал про это и привёл цитату почему. :)

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

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

пишу я допустим

шина А;
шина В;
шина C;
шина D;

и так тестирую. а потом уточняю что шина одна, но провода дифференциальные одна а частота учетверённая. ей просто довольно далеко бежать по чипу - 0.2мм или 0.3 даже. и все тесты остаются как есть, всё работает.

а про программы потом пришло в голову. что АЛУ на асике, что микруха К580ВМ80А в спектруме, что какой нибудь класс в программе - это все конечные автоматы. и подход можно генерализовать.

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

если такое будет в расте, Раст начнет теснить и то нагибать плюсы

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

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

«стандартный» ABI вовсе не идеален. я бы даже сказал что он антиидеален.

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

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

Стандартный для кого? Для сишечки?
Он тащемта очень ограничен и тем же плюсам пришлось костыли прикручивать.

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

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

А «стандартный» - это какой? Сишный ABI поддерживается в расте из коробки. А стандартного плюсового в принципе не существует, насколько мне известно.

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

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

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

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

Разве? Я всегда считал, что нельзя просто так взять, собрать разные куски плюсокода в разные объектники разными компиляторами (gcc, icc и msvc++, например) и скомпоновать из вместе. В каких-то случаях это может даже и работает, но железных гарантий и 100%ной совместимости никто не даёт.

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

в некоторых пределах llvm и gcc совместимы. расхождения там в каких-то хитрожопых новых наворотах, но кто пишет с наворотами тот сам себе дурак.

хотя С++ я защищать в этом вопросе не стану. нагородили там шоажпц

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

в некоторых пределах llvm и gcc совместимы

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

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

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

просто один хер вызовы в библиотеку все непрямые - прыгают в .rel, оттуда делают jmp [.got + offset]. а то что сейчас есть - это гомосексуализм какой-то.

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

Манглинг тут не причем. В отличие от маздая, на юниксах ABI это такая толстая книжечка, не имеющая прямого отношения к компилятору, но имеющая отношение к версии юникса и версии железа.

Один из действующих стандартов «SYSTEM V APPLICATION BINARY INTERFACE. Edition 4.1». Суть проблемы в том что ребята разрабатывающие rust положили болт почти на все из них, тоесть своеобразный NIH syndrome.

ckotinko WatchCat mironov_ivan

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

Разве? Я всегда считал, что нельзя просто так взять, собрать разные куски плюсокода в разные объектники разными компиляторами (gcc, icc и msvc++, например) и скомпоновать из вместе. В каких-то случаях это может даже и работает, но железных гарантий и 100%ной совместимости никто не даёт.

Зато это можно сделать со всеми остальными языками. У тех же Ады и Objective-C никаких проблем в смешивании с чем угодно. Малину тут портят только C++, Rust и Go. Ну возможно еще Objective-C++, но с этим я не в теме.

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

Суть проблемы в том

Расскажи почему это проблема, и почему repr(C) ее не решает?

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

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

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

Идеи летают в эфире воздухе, я в этом же направлении думаю...

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

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

И близко такого не реализовано. Это тебе не графическое программирование от хипстеров, тут будущее ИТ. И как минимум новый ЯП нужно продумывать, но по сути это будет даже не ЯП, а комплекс из ЯП+IDE.

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

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

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

Вот напишут они что надо жопой дышать и что теперь молиться на них?

В линуксе к стандартизации таковых не подпускают

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

Манглинг тут не причем. В отличие от маздая, на юниксах ABI это такая толстая книжечка, не имеющая прямого отношения к компилятору, но имеющая отношение к версии юникса и версии железа.

Не ожидал от тебя такого фейспалмного заявления.

Один из действующих стандартов «SYSTEM V APPLICATION BINARY INTERFACE. Edition 4.1». Суть проблемы в том что ребята разрабатывающие rust положили болт почти на все из них, тоесть своеобразный NIH syndrome.

А давай конкретно - что именно предписывает SVID, а Rust не делает? По пунктам.

P.S. кстати, за системный ABI в компиляторе Rust отвечает LLVM. Так что если NIH и есть, то у них.

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

На самом деле есть пара реализаций. Одна из них используется в реализации опен-сорсных LADSPA-плугинов. Лет 10 назад здесь был тред на лоре. Плюс еще есть коммерческая реализация. Главная проблема с этими изобретениями - таже, что и с VIM - от пользователя требуется хотябы базовая квалификация.

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