«Ржавая» IP-камера: прошивка на Rust

Я не сам пилю. После эрланга очень сложно, потому что после простого как топор эрланга, что угодно сложно.

Но раст выглядит именно как сложная и продуманная программа на С.

Он явно не про embedded и не про компьютеры из прошлого века.

при том что наследование реализации.

Вы что-то путаете.

QML прибит гвоздями к Qt.

HMTL прибит гвоздями к WebKit.

ЯП нужен не для разметки

Хочу раскрасить строки таблицы случайными цветами. Как язык разметки тут поможет?

отказ от наследования реализации сомнительная вещь оказалась,

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

Первый вариант - это то, за что в приличном обществе бьют канделябром по голове. Если что-то такое нужно, то рекомендуют наследоваться от интерфейса, а объект старого типа прятать внутри и делегировать всё что надо руками. Такой вариант недружественен играм с instanceof и прочим dynamic_cast'ам, но ООП такие вещи противоречат и в расте оно вынесено в типы суммы и патернматчинг. Раст сделал такой вариант «наследования» через композицию единственно возможным.

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

Раст всё это лечит

Примерно как гильотина лечит перхоть.

Раст всё это лечит, внутри каждой структуры только те данные, что ей надо.

Я правильно понял, что это означает «в расте единственный выход - копипастить общий код»?

надо было на dev-lang/go писать c gc и статикой

не смешивай тёплое и мягкое.

Не совсем. Если код очень общий, то есть процедурные макросы, на которых сделан тот же serde.

HMTL прибит гвоздями к WebKit.

Чо, правда штоле? Разве что в твоей вселенной. А в нашей HTML универсальный язык разметки, в который умеет любая кофеварка, а QML какое то проприетарное УГ для ублажения крестофанов.

Раст всё это лечит, внутри каждой структуры только те данные, что ей надо.

Я правильно понял, что это означает «в расте единственный выход - копипастить общий код»?

Вроде бы, пока да. Но есть issue с предложением улучшить эту ситуацию, емнип (поправьте, если не прав).

процедурные макросы

что означает в данном случае «compile-time копипаста» :)

таки да. что не сказать что так уж плохо.

это ты пилишь dpi на расте, что бы нам на рутрекер не ходить? =)

Нет, я решал обратную задачу =).

Это не плохо в том смысле, что решает проблему. Плохо тем, что заметает под ковёр факт отсутствия поддержки фундаментальной фичи в компиляторе. И такой макрос - это не часть Раста, в Rust Book о нём не напишут.

Хочу раскрасить строки таблицы случайными цветами

тут тебе только тёма поможет

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

Это просто пример того, что без ЯП от разметки толку мало.

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

хотя тот же qml позволяет javascript^W qtscript встраивать емнип

Где-нибудь можно про это почитать?

Про такие макросы там сказано. И называть «наследование» фундаментальной фичей - некорректно. Нет ООП в расте в привычном понимании, by design.

Где-нибудь можно про это почитать?

К сожалению нет, так как заказчик просил не выкладывать исходники. На самом деле я приукрасил и ничего хитрого или сложного не было =). Я просто написал небольшую тулзу, которая позволяет обманывать p0f. Ящик для прикручивания nfqueue к tokio может когда-нибудь выложу отдельно, если будет время его доработать (сейчас в коде только минимальная поддержка - только то, что было нужно лично мне). То, что сейчас есть для nfqueue на crates.io - ИМХО очень криво и неюзабельно.

QML какое то проприетарное УГ

проприетарное

Чего-чего?

Я правильно понял, что это означает «в расте единственный выход - копипастить общий код»?

Что ты имеешь в виду?

Эта модель, замещающая ООП, благородно стыбрежена из Haskell, и там как-то пишут без копипасты)

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

А должны были что ли? Зачем это делать?

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

Я правильно понял, что это означает «в расте единственный выход - копипастить общий код»?

Если «общий код» = «общие данные в объекте» то да. Ну, разве что объединять по смыслу, например вместо полей ширина и высота запихать одно поле типа Size. Или даже WidgetCommon. Если «общий код» = «методы» , то либо реализуется как шаблон от родительского трейта, либо в отдельной приватной функцией, которая вызывается из реализаций методов. В общем примерно как в крестах, только вместо BaseClass::foo() будет smth::foo(&mut field1, &field2). В общем почти то же, только нет автоматической делегации вызовов базовому классу и придётся ссылки на поля вручную передавать.

Где? Разве что на лоре всех фанбоев собрать. Но у них домашка, егэ, занятой народ.

отличная_шутка.jpg

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

Взлетает идея, а не код.

GO, этот к слову уже сливается

Несите другого «аналитика», этот порвался.

Взлетает идея, а не код.

Ты мысль не понял или просто придираешься? Если первое, то уточняй - я её раскрою.

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

Если еще поглубже, то сисярп. Там целая мегакорпа нешмогла, так то.

Всем бы так «не смочь».

Заменить C++ не смогла. Вытеснила его немного из прикладухи, не более того. И то, МС столько усилий вложили в раскрутку этого гогна, работа велась на уровне правительств. И все равно дотнет живет в узенькой нише. А тут нам рассказывают как хипсторская поделка завоюет мир, ага, щаз.

И все равно дотнет живет в узенькой нише.

Большой вопрос какая ниша уже: плюсовая или джаво-шарповая.

А тут нам рассказывают как хипсторская поделка завоюет мир, ага, щаз.

Глупая постановка вопроса, но ты ведь всё равно (бездарно) троллишь.

работа велась на уровне правительств

Есть кулстори? На ночь почитать)

Большой вопрос какая ниша уже: плюсовая или джаво-шарповая.

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

Есть кулстори?

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

а тебе шапочка из фольги не жмет?

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

Кому лучше и почему?

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

А ты вообще похоже не думал. Зачем в вузах и правительственных учреждениях плюсы?

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

Пример: dropbox, у которого всё на python. Даже автор питона у них работает. Говорят, у них 0.5B пользователей. И они сейчас активно переписывают бекенд на Go и клиент на rust.

А питон чем не угодил? Самый нормальный среди скриптоты же.

Питон всем угодил. Но шарп всё же лучше

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

Быстро ты переобулся.

Крутой, современный язык. Джава нормального человека

Практика показывает...

Практика - она разная. Повторюсь: ты мысль понял или как?

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

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

Идея - кто лучше: новички плюсовики или новички растоманы? Эта идея?

Никакой статистики и у меня нет. Языку всего ничего. Но вот некоторые гоферы уже начинают писать слезливые посты о сложности поддержки go кода.

Идея - кто лучше: новички плюсовики или новички растоманы? Эта идея?

Примерно. А вообще можно посмотреть на какой пост я отвечал и выше.

Я уже потерял нить разговора.

немного странная фраза. Это же лор, тут, вроде, так и норм?

Но вот некоторые гоферы уже начинают писать слезливые посты о сложности поддержки go кода.

Шо, опять серебра в пулю не доложили? Одна надежда осталась на руст!