rust для микроконтроллеров уже готов?

atmel / microchip

Я ещё сейчас на STC начал смотреть. Для них есть нормальный инструментарий?

Интересует поддержка atmel / microchip дешевых, не ARM.

Наслушался сказок про то что Rust - замена Си ?

llvm бэкенд для avr и форк rustc, который его использует.

И всё-таки замена крестов, а не си.

Дешёвые чипы и кресты, ога (:

И всё-таки замена крестов

в Mozilla

Проходи дальше.

Сам пробовал? Какие минимальные требования по памяти?

Оно на 8051-м ядре? Ну вот зачем насиловать труп, скажите? Есть уже вполне адекватные как по цене, так и по периферии/энергопотреблению ARM-ы, под которые существует нормальный инструментарий.

И всё-таки замена крестов, а не си.

Где там тогда нормальный ООП или хотя бы наследование структур?

потому что он мамкин олдфаг, ему не для дела а для поиграться, такой персонаж

Дешёвые чипы и кресты, ога (:

А что дона смущает? Если знать, что делаешь, то разницы с С практически никакой.

Нет, не приходилось ещё. Оно вроде пока не совсем юзабельно, хотя и разрабатывается активно.

А откуда потребность в ржавчине аж на avr?

Там не нужен классовое ООП (то, что Вы называете «нормальный»), ибо там тайпклассы — инструмент в разы, если не на порядок мощнее классики.

хотя бы наследование структур

Нет и вводить не собираются. Это нужно разве что при написании обёрток к классике, ибо при АлгТД+тайпклассах код пишется иначе. Если Вы не знакомы с парадигмой, то объяснить с лёту я не смогу — просто начните писать что-то на rust'е (или haskell'е) и Вы удивитесь никчёмности классового (да и прототипного) ООП.

А откуда потребность в ржавчине аж на avr?

Да потому что всех (кроме отъявленных мазохистов) запарило писать код на C, в котором нормального тайпчекера нет и приходится использовать void* на каждый чих. С другой стороны, непонятно почему нельзя писать под AVR на том же хацкелле.

запарило писать код на C

Что это за масштабные проекты такие на avr?

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

GC жеж.

Что это за масштабные проекты такие на avr?

Дело не в масштабности, а в корректности. К хацкеллу приделать и использовать с ним SMT solver несколько проще (e.g. Liquid Haskell) чем в случае с C (Frama-C).

GC жеж.

eDSL жеж.

Дело не в масштабности, а в корректности.

Одно дело программка на 1к строк и совсем другое на 10к, согласись. Вряд ли ты будешь прикручивать в первом случае Frama-C. И да, есть полумёртвые Cyclone и D, если совсем припекает.

eDSL жеж

Не понял, как это к GC относится?

Не понял, как это к GC относится?

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

Одно дело программка на 1к строк и совсем другое на 10к, согласись. Вряд ли ты будешь прикручивать в первом случае Frama-C.

Если это программка, управляющая впрыском топлива с реактивном двигателе, то буду. Иначе меня повесят.

Иначе меня повесят.

Максимум уволят.

Это аллегория :)

... наследование структур ... Нет и вводить не собираются. ...

Вроде ж думают об анонимных полях или подобном, без полиморфизма, на манер Go.

А то лично я не знаю, как красиво избавиться в некоторых ситуациях от подобного:

pub fn is_tile_visible(&self, pos: &MapPos) -> bool {
    self.fow.is_tile_visible(pos)
}

pub fn is_tile_occupied(&self, pos: &MapPos) -> bool {
    self.state.is_tile_occupied(pos)
}

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

Да просто хочется знаний освежить на прикладной задаче.

хипстоты тред

rust для atmel / microchip

нет пути
Для этих МК писать на чем-то кроме ассемблера - моветон.

Можно имитировать наследование GameState от State через реализацию Deref. А вот от fow.is_tile_visible(pos) даже в ООП языках с множественным наследованием не избавился бы, ибо закон Деметры

Это нужно разве что при написании обёрток к классике

Так замена С++ или хипстерское поделие? Да, мне нужно поддерживать классику, на ржавом я это делать не могу. Тогда он идет в задницу и я продолжая работать на универсальном С++. Так рассуждает любой вменяемый программер.

Если это замена С, то вопросов не имею.

Вы удивитесь никчёмности классового (да и прототипного) ООП

Окей, покажи на примере как развернуть HTML страницу из файла в память на АлгТД+тайпклассах. Может какие-то либы есть готовые?

Так замена С++ или хипстерское поделие? Да, мне нужно поддерживать классику, на ржавом я это делать не могу

А «поддерживать» ты только на Си++ и можешь. Иначе это уже переписывание.

Когда у тебя зайдет речь о большой системе, ты поймёшь преимущество «классики». В твоих трейтах и АлгТД ты запутаешься со временем. trait'ы и отдельная реализация вынуждают разбивать систему на большее число компонент, чем требует логика предметной области. Открытые АлгТД удобны в одних ситуациях и неудобны(от слова совсем) в других.

Все это проверено на относительно большом проекте java + scala. Так же есть опыт работы с F#.

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

функциональщина*

Чем тебе Си не угодил? Асм лучше оставить на крайний случай.

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

На «высоком» уровне, чем «классика» отличается от «функциональщины»? Интерфейсы или трейты - большой разнцы нет. Или у вас на «высоком» уровне было именно наследование классов?

Так замена С++ или хипстерское поделие? Да, мне нужно поддерживать классику, на ржавом я это делать не могу.

Что-то логику не уловил. Ржавчина это замена крестам, о какой «поддерживать» идёт речь? Если Вам надо поддерживать кучу дерьма на крестах, то нефиг сюда ржавого тянуть, вот и всё.

Если это замена С, то вопросов не имею.

Это не замена си, ибо он отлично с ним уживается.

Окей, покажи на примере как развернуть HTML страницу из файла в память на АлгТД+тайпклассах.

Если речь идёт о представлении html в виде DOM, то тут классовое ООП подходит лучше именно из-за наследования (тут нет ничего удивительного, ибо DOM это объектная модель, она под классы отлично ложится, так что во всяких servo имитируют наследование.

Трейты(скаловские) использовались, да. Часто как раз для миксирования. Я бы не назвал это функциональным подходом.

Классика была в том смысле, что были классические иерархии, с наследованием классов(использовалось все это, конечно, через интерфейсы, но это тоже классика).

case class'ы(АлгТД) на «высоком уровне» использовались только там, где были удобны для выражения понятий предметной области, там, где вероятность появления нового варианта стремилась к нулю. И тут я бы не стал называть это уходом от классики, поскольку в проекте на чистой яве было бы что-то похожее, просто с менее удобным синтаксисом. На том же котлине(правда на практике я его не трогал) это выражалось бы вполне сносно, а в нём ФП и АлгТД нет.

В общем, я таки люблю scala больше java, но само по себе ФП ООП не заменяет, они используются на разных уровнях. Т.е. ФП может убрать ООП там, где оно не нужно и приводит к увеличению, а не уменьшению сложности. Но не везде. Потому мне не очень понятно, какой смысл отказываться от ООП в Rust, тем более, что чего-то большего, чем C++, от них и не требуют. А множественное наследование можно убрать, да, заменив примесями.

Потому мне не очень понятно, какой смысл отказываться от ООП в Rust, тем более, что чего-то большего, чем C++, от них и не требуют.

Да никто и не отказывался. АлгТД+тайпклассы на высоком уровне — тот же классовый ООП, только в профиль, как уже заметил tailgunner. А на низком уровне не совсем понятно, почему нужно отказываться от преимуществ таймпклассов? Реализовал нужный трейт для своего типа и он уже отлично вписывается в существующую систему. В итоге меньше адаптеров и т.д., т.е. упрощение, а не усложнение.

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

Немного тему раскрою. Открываю рандомную страницу документации stdlib ржавчины:

impl<T> Ord for Rc<T> where T: Ord + ?Sized
    fn cmp(&self, other: &Rc<T>) -> Ordering

Как это выразить в крестах? Плодить новый класс RcForMyT, наследующий Rc и Ord и реализовывать cmp? Заранее иметь RcOrd<T>?

А можно вопрос? А так ли необходимо это выражать? Какую проблему это решает? В случае шаблонов вполне сработает operator < или свой компаратор(см. стандартные алгоритмы и контейнеры в STL). В случае иерархии, вполне можно сделать метод cmp или ему подобный, если он так уж нужен.

Как это выразить в крестах? Плодить новый класс RcForMyT, наследующий Rc и Ord и реализовывать cmp? Заранее иметь RcOrd<T>?

А в сиплюсе такое и не нужно выражать, там идиоматический код:

template<class T>
bool operator<( Rc<T> a, Rc<T> b );

А еще там есть перегрузка функций.

Ага, т.е. если там будет не <, а какой-то конкретный метод, то

там идиоматический код

сведётся к шаблонизированной функции? Отличное ООП получается.

А при чем тут ООП? В ОО-иерархии это будет просто метод(если нужен).

stm32 дешевле и толще avr/pic

Ага, т.е. если там будет не <, а какой-то конкретный метод, то
сведётся к шаблонизированной функции? Отличное ООП получается.

Шаблон там исключительно из-за того, что Rc сам параметризован по типу. А то, что ты показал на rust - костыль, т.к. rust не умеет в перегруженные функции. Вот попробуй минимальными усилиями изобразить аналог:

void A( T1& t );
void A( int v = 0 );

И поймешь что как и где.

просто начните писать что-то на rust'е (или haskell'е) и Вы удивитесь никчёмности классового (да и прототипного) ООП.

это интересное заявление, смелое.

trait Animal {
    // Static method signature; `Self` refers to the implementor type
    fn new(name: &'static str) -> Self;
 
    // Instance methods, only signatures
    fn name(&self) -> &'static str;
    fn noise(&self) -> &'static str;
 
    // A trait can provide default method definitions
    fn talk(&self) {
        // These definitions can access other methods declared in the same
        // trait
        println!("{} says {}", self.name(), self.noise());
    }
}
 
struct Dog { name: &'static str }
 
impl Dog {
    fn wag_tail(&self) {
        println!("{} wags tail", self.name);
    }
}
 
// Implement the `Animal` trait for `Dog`
impl Animal for Dog {
    // Replace `Self` with the implementor type: `Dog`
    fn new(name: &'static str) -> Dog {
        Dog { name: name }
    }
 
    fn name(&self) -> &'static str {
        self.name
    }
 
    fn noise(&self) -> &'static str {
        "woof!"
    }
 
    // Default trait methods can be overridden
    fn talk(&self) {
        // Traits methods can access the implementor methods
        self.wag_tail();
 
        println!("{} says {}", self.name, self.noise());
    }
}
 
struct Sheep { naked: bool, name: &'static str }
 
impl Sheep {
    fn is_naked(&self) -> bool {
        self.naked
    }
 
    fn shear(&mut self) {
        if self.is_naked() {
            // Implementor methods can use the implementor's trait methods
            println!("{} is already naked!", self.name());
        } else {
            println!("{} gets a haircut", self.name);
 
            self.talk();
            self.naked = true;
        }
    }
}
 
impl Animal for Sheep {
    fn new(name: &'static str) -> Sheep {
        Sheep { name: name, naked: false }
    }
 
    fn name(&self) -> &'static str {
        self.name
    }
 
    fn noise(&self) -> &'static str {
        if self.is_naked() {
            "baaah"
        } else {
            "baaaaaaaaaaaah"
        }
    }
}
 
fn main() {
    // Type annotation is necessary in this case
    let mut dolly: Sheep = Animal::new("Dolly");
    let spike: Dog = Animal::new("Spike");
    // TODO ^ Try removing the type annotations
 
    dolly.shear();
 
    spike.talk();
    dolly.talk();
}

Animal := Object clone do(
 name ::= ""
 talk := method((name .. " says " .. noise) println)
)
 
Dog := Animal clone do(noise := "woof")
Sheep := Animal clone do(
 naked ::= false
 shear := method(
  if(naked, (name .. " is already naked") println, (name .. " gets a haircut") println)
 )
 noise := method(
  if(naked, "baaah", "baaaaaaaaaaah")
 )
)
 
spike := Dog clone setName("Spike")
dolly := Sheep clone setName("Dolly")
 
spike talk
dolly talk
dolly shear

Но это примитивный случай. А настоящий смех начнется, когда дело коснется рантайма.

А можно вопрос? А так ли необходимо это выражать? Какую проблему это решает?

Я тыкнул в рандомное место, так что пример действительно не лучший. Однако перед bool operator<(Rc<T> a, Rc<T> b); есть солидное преимущество: оно ложится в строгую систему типов, которая пока (до введения и широкого применения концептов) в крестах отсутствует. Т.е. это именно Ord, а не просто абстрактный ad hoc полиморфизм (перегрузка). Поэтому я и говорю:

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

А то так можно и с js сравнивать начать.

Не понял. Как ты this параметризируешь? Принимаемый аргумент — да, но речь-то об ограничениях на this.

есть солидное преимущество: оно ложится в строгую систему типов,

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

А настоящий смех начнется, когда дело коснется рантайма.

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

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