Серьезная команда
ебаный КЛОУН
27.04.2020, 14:54
Я скорее охуел когда увидел PID контроллер, а потом вариацию с генетическим алгоритмом. Точнее в чем он написан, я пиздец ругался когда в код внедрял MQTT и прием сигналов с другой машины. Geany IDE в которой если у тебя 4 пробела, то может не заработать, а может не заработать когда табуляция. Т.е. я написал питоновский рабочий код и при порте 4 ПРОБЕЛА НЕ НРАВЯТСЯ, заменяю на табы ок. Чуть чуть под машину модифицирую код, то теперь табуляции не нравятся меняю на пробелы. Я хз как они в нем пишут.
Там своя ООПшность. Нету наследования, реализация и данные разделены в исходнике. Каждый интерфейс для структуры реализуется в отдельном блоке. Но там самый сок в Rust - владение. Владеть ссылкой на объект может в один момент лишь один контекст. И это всё на уровне компиляции. Что бы делать что-то крутое - нужно самому прописывать принадлежность переменных к контекстам времени жизни (только так придумал это объяснить). А ещё макросы - расширение компилятора, со всеми вытекающими типо доступпа к АСД во время компиляции макроса
ссылкой на объект для ИЗМЕНЕНИЯ. А читать могут сколько угодно
Трейты - не интерфейсы. Это ближе к typeclass из Haskell. По-идее, куда более крутая и мощная штука. Хотя, не скрою, есть моменты, которые обычным ООП* реализуются проще. Либо я еще не скурил.
* примечание.
Что же, блять, такое обычный ООП? Тут я имел в виду C#/C++/Java. Но, справедливости ради, это не труЪ ООП, которым его задумывали. Да и вообще, спроси любого разраба, он вам назовет свое понимание ООП.
* примечание.
Что же, блять, такое обычный ООП? Тут я имел в виду C#/C++/Java. Но, справедливости ради, это не труЪ ООП, которым его задумывали. Да и вообще, спроси любого разраба, он вам назовет свое понимание ООП.
Нет, не так. В Rust не ООП, а другая система типов, которая ближе даже к функциональным языкам. Там есть трейты (traits, в других языках эта штука может называться typeclass), алгебрарические типы данных и прочие прелести.
Трейт - это хм... требования к типу. Тип является "Comparable" (в Rust - трейт Eq), если он определяет какой-то набор методов. Но это не интерфейс, который необходимо указать при объявлении класса, трейт определяется отдельно от типа. Еще тип можно расширить. Это позволяет очень круто и гибко компоновать разные куски из разных библиотек. На самом деле, я бы сказал, что это даже круче ООП.
Про Rust в первую очередь известно про его безопасную модель памяти, основанную на заимствованиях. В двух словах, у объекта может быть только один владелец, только одна мутабельная ссылка, либо много иммутабельных. Все это проверяется статически, и за нарушение компилятор карает тебя анально. Move-сементика в масштабах всего языка.
Но я бы заметил, что система типов Rust не менее интересна, чем безопасная работа с памятью. Использование крутой строгой системы типов и безопасной работы с памятью позволяет перенести ряд ошибок в ошибки компиляции.
Конечно, не без недостатков. По первой borrow checker трахает мозг; некоторые особенности синтаксиса системы типов и управления владением приводят к необходимости иногда писать синтаксически ебанутые конструкции; структуры данных со множественным владением (граф, список) на модель раста ложатся плохо, привет, аналог старого доброго shared_ptr. Еще в раст не завезли типы высшего порядка и труЪ монады, поэтому его система типов все же не такая труЪ, как во всяких хаскелях, что приводят к костылям и велосипедам от разработчиков раста.
Трейт - это хм... требования к типу. Тип является "Comparable" (в Rust - трейт Eq), если он определяет какой-то набор методов. Но это не интерфейс, который необходимо указать при объявлении класса, трейт определяется отдельно от типа. Еще тип можно расширить. Это позволяет очень круто и гибко компоновать разные куски из разных библиотек. На самом деле, я бы сказал, что это даже круче ООП.
Про Rust в первую очередь известно про его безопасную модель памяти, основанную на заимствованиях. В двух словах, у объекта может быть только один владелец, только одна мутабельная ссылка, либо много иммутабельных. Все это проверяется статически, и за нарушение компилятор карает тебя анально. Move-сементика в масштабах всего языка.
Но я бы заметил, что система типов Rust не менее интересна, чем безопасная работа с памятью. Использование крутой строгой системы типов и безопасной работы с памятью позволяет перенести ряд ошибок в ошибки компиляции.
Конечно, не без недостатков. По первой borrow checker трахает мозг; некоторые особенности синтаксиса системы типов и управления владением приводят к необходимости иногда писать синтаксически ебанутые конструкции; структуры данных со множественным владением (граф, список) на модель раста ложатся плохо, привет, аналог старого доброго shared_ptr. Еще в раст не завезли типы высшего порядка и труЪ монады, поэтому его система типов все же не такая труЪ, как во всяких хаскелях, что приводят к костылям и велосипедам от разработчиков раста.
Сборщика нет (т.к. язык низкоуровневый), вместо него концепция владения, заимствования и времени жизни — фактически очень строгий встроенный синтаксический анализатор, который просто не даст скомпилировать потенциально ошибочный код, деструкторы автоматические, почти всегда — просто смещение регистра стека, т.к. почти всё живёт на стеке. Есть и куча других преимуществ (в т.ч. касающихся безопасности), но я их расписывать не буду, они уже не касаются области действия сборщика мусора.
Пишут на нём всё — сервера, графические (в т.ч. с прямым использованием GPU) и неграфические приложения под все платформы (включая wasm, android, ios и микроконтроллеры), синхронный, асинхронный, многопоточный код, учебные книги, возможно кто-то уже и драйвера успел написать, сборочные скрипты (вместо cmake, например, если в проекте уже есть раст).
Главное в расте, на мой взгляд, даже не сами фишки языка, а библиотеки, которые благодаря этим фишкам выросли, умопомрачительной функциональности которых я до сих пор не могу нарадоваться.
Пишут на нём всё — сервера, графические (в т.ч. с прямым использованием GPU) и неграфические приложения под все платформы (включая wasm, android, ios и микроконтроллеры), синхронный, асинхронный, многопоточный код, учебные книги, возможно кто-то уже и драйвера успел написать, сборочные скрипты (вместо cmake, например, если в проекте уже есть раст).
Главное в расте, на мой взгляд, даже не сами фишки языка, а библиотеки, которые благодаря этим фишкам выросли, умопомрачительной функциональности которых я до сих пор не могу нарадоваться.
отрадно видеть, что люди растом интересуются. ИМХО раст далеко пойдёт.
