Rust, же не смотря на формальное отсутствие состояния гонки, все-таки более подходит не для написания приложений, но драйверов и операционных систем.
Не совсем понимаю, почему вы так считаете. Аргументируйте это пожалуйста. Потому что на мой взгляд это не так и вот почему:
1) Rust подходит для разработки во многих других областях, помимо написания драйверов и операционных систем. Для того, чтобы убедиться в этом, можно взглянуть, какие компании используют его: https://www.rust-lang.org/production/users. У него есть все необходимые инструменты для этого.
2) Хорошая статья с более подробной аргументацией: https://habr.com/en/post/434200/
Просто оставлю здесь цитату:
Концепции раста очень мощные, и отлично работают на уровне прикладных приложений, которые не задумываются о производительности, но скорее только о продуктивности разработчиков, скорости внедрения новых фич и простоты поддержки. Очень грустно наблюдать, что такой отличный во всех отношениях язык всё больше получает клеймо "странного и сложного языка для низкоуровневых гиковских задач". Надеюсь, я немного пошатнул этот вредный миф, и в мире станет на сколько-то более продуктивных и счастливых разработиков больше.
3) В нашей компании успешно используется Rust в продакшене, и это не разработка ОС и драйверов. И используется не в стиле "написали утилиту небольшую", это огромнейший кусок серверной части.
Напомню, что это перевод статьи 2015 года (мне серия статей показалась интересной). Ничего плохого в BIOS в 2018 году не вижу. Предполагаю, что после 2020 года (кстати почему он?) информация останется полезной. Касательно смены ассемблера на раст — я только всеми руками за, надо попробовать.
Рад за ваши успехи. А вы у себя в продакшене используете его (actix имею ввиду)? Если будет время подумайте над тем, чтобы написать статью про него. Будет интересно.
На счёт прекрасного языка я с вами полностью солидарен. В данном случае, хотелось продемонстрировать возможность того, что в Rust это можно сделать и это не особо трудно. Для автоматизации каких-либо уведомлений и повседневных задач пойдёт. Совсем уж бесполезными они не являются.
Всё верно, но данный факт не помешал написать работающее приложение используя форк библиотеки. Касательно переписывания, вся активность я так понимаю сосредоточена на ветке rewrite. Происходит полноценный перенос на Tokio для того, чтобы она работала в асинхронном режиме.
Честь и хвала. Я заметил, что Поляков Александр и influent.rs допилил немного под важи нужды для мониторинга всего этого дела. С его API есть некоторые проблемы (например, передавать можно только str вроде при создании Measurement и аналогичное, как у вас с передачей вектора). Расскажите пожалуйста, в каких местах были проблемы с производительностью у Rust, что пришлось прибегнуть к Assembler?
Термин promise был предложен в 1976 году Дэниэлом Фридманом и Дэвидом Вайзом, а Питер Хиббард назвал его eventual. Похожая концепция под названием future была предложена в 1977 году в статье Генри Бейкера и Карла Хьюитта.
Термины future, promise и delay довольно часто взаимозаменяемы, однако далее описана разница между future и promise. Под future обычно имеется в виду представление переменной, доступное только для чтения, а под promise — изменяемый контейнер с одиночным присваиванием, который передаёт значение future. Future может быть определён без указания того, из какого promise будет получено значение. Также с одним future может быть связано несколько promise, однако присвоить значение future сможет только один promise. В остальных случаях future и promise создаются вместе и привязываются друг к другу: future — это значение, а promise — это функция, которая присваивает значение. На практике future — возвращаемое значение асинхронной функции promise. Процесс присваивания значения future называют resolving, fulfilling или binding. В некоторых источниках на русском используются следующие переводы терминов: для future — будущие результаты, фьючерс, также может означать преднамеченность; для promise — обещание; для delay — задержка.
Если отталкиваться от этого — promise в futures-rs, это любая функция, которая возвращает структуру реализующую типаж Future.
Мы обсуждали перевод этого термина в канале на gitter российского сообщества Rust и пришли примерно к таким же выводам. Надеюсь текст не режет глаза из-за непереведённого термина. Рад, что наши мнения совпали. Аналогичная ситуация думаю может возникнуть с термином Promise(s).
ORM отсутствует, так как предназначение — работа с сетью. Но если вас интересует ORM имеет смысл посмотреть на Diesel. Вот ссылка на его сайт: http://diesel.rs/
Сравнение с NodeJS для V8 не совсем верное. NodeJS это всё таки программная платформа для запуска приложений написанных на javascript. А вот с Rails вы уже ближе, но он полноценный веб-фреймворк, использующий MVC в отличии от Iron. Вместе с расширениями возможно вы получите некое подобие "рельс", если захотите.
Не совсем понимаю, почему вы так считаете. Аргументируйте это пожалуйста. Потому что на мой взгляд это не так и вот почему:
1) Rust подходит для разработки во многих других областях, помимо написания драйверов и операционных систем. Для того, чтобы убедиться в этом, можно взглянуть, какие компании используют его: https://www.rust-lang.org/production/users. У него есть все необходимые инструменты для этого.
2) Хорошая статья с более подробной аргументацией: https://habr.com/en/post/434200/
Просто оставлю здесь цитату:
3) В нашей компании успешно используется Rust в продакшене, и это не разработка ОС и драйверов. И используется не в стиле "написали утилиту небольшую", это огромнейший кусок серверной части.
Напомню, что это перевод статьи 2015 года (мне серия статей показалась интересной). Ничего плохого в BIOS в 2018 году не вижу. Предполагаю, что после 2020 года (кстати почему он?) информация останется полезной. Касательно смены ассемблера на раст — я только всеми руками за, надо попробовать.
P.S Возможно, это не насилие, а любовь.
OSDev wiki уже видели? Если нет, то там есть разделы
EnvironmentиBooting and Setup.Рад за ваши успехи. А вы у себя в продакшене используете его (actix имею ввиду)? Если будет время подумайте над тем, чтобы написать статью про него. Будет интересно.
Да добавить можно. Уточню, что бот, который указан в данной статье — временный. Как пример для статьи, а не для постоянного использования.
Дело в проверке
starts_with("/rust "), не обрабатываются случаи когда там/rust\n, т.е всегда ожидает пробел после ключевого слова.На счёт прекрасного языка я с вами полностью солидарен. В данном случае, хотелось продемонстрировать возможность того, что в Rust это можно сделать и это не особо трудно. Для автоматизации каких-либо уведомлений и повседневных задач пойдёт. Совсем уж бесполезными они не являются.
Всё верно, но данный факт не помешал написать работающее приложение используя форк библиотеки. Касательно переписывания, вся активность я так понимаю сосредоточена на ветке rewrite. Происходит полноценный перенос на Tokio для того, чтобы она работала в асинхронном режиме.
Спасибо. Не за что. При написании своего бота — обращайтесь, если возникнут какие-либо вопросы.
Rust наше всё:
И отсутствие NPE. И всё прочее.
Честь и хвала. Я заметил, что Поляков Александр и
influent.rsдопилил немного под важи нужды для мониторинга всего этого дела. С его API есть некоторые проблемы (например, передавать можно только str вроде при создании Measurement и аналогичное, как у вас с передачей вектора). Расскажите пожалуйста, в каких местах были проблемы с производительностью у Rust, что пришлось прибегнуть к Assembler?Я хочу привести выдержку из статьи на википедии о futures и promises:
Если отталкиваться от этого — promise в futures-rs, это любая функция, которая возвращает структуру реализующую типаж
Future.Мы обсуждали перевод этого термина в канале на gitter российского сообщества Rust и пришли примерно к таким же выводам. Надеюсь текст не режет глаза из-за непереведённого термина. Рад, что наши мнения совпали. Аналогичная ситуация думаю может возникнуть с термином
Promise(s).ORM отсутствует, так как предназначение — работа с сетью. Но если вас интересует ORM имеет смысл посмотреть на Diesel. Вот ссылка на его сайт: http://diesel.rs/
Сравнение с NodeJS для V8 не совсем верное. NodeJS это всё таки программная платформа для запуска приложений написанных на javascript. А вот с Rails вы уже ближе, но он полноценный веб-фреймворк, использующий MVC в отличии от Iron. Вместе с расширениями возможно вы получите некое подобие "рельс", если захотите.
Вы правы, это типы, а не типажи. Спасибо за комментарий! Поправил.