От сижу кодю, нікого не чіпаю, і тут бац за місяць три контакта на djinni — і кожному тре Senior Rust не менше. Блокчейн.
А що embedded і далі буде сидіти законсервованим в своєму С або ще гірше в С++ з бустом?
P.S.
cliffle.com/blog/prefer-rust
P.P.S.
www.tiobe.com/tiobe-index
TIOBE Index for November 2019
November Headline: C getting close to Java, Swift enters top 10 and Rust scores all time high ... it might become a member of the top 20.
сесусіріті, сторінка 9
www.whitehouse.gov/...ONCD-Technical-Report.pdf
компанія добра звільняє, а компанія зла мастдай набирає:
mspoweruser.com/...nents-into-rust-from-c-c
Senior Microsoft exec says Windows 11 kernel will soon be booting with Rust inside
www.neowin.net/...booting-with-rust-inside
embebbed завжди був консервативний, ще досі є проекти із чистим С, або С++03, іноді С++11
Відбувся реліз розширення Rust для Godot 4
gamedev.dou.ua/...ust-extension-in-godot-4
Потому что никто не хочет разбираться в запутанном коде на rust и городить костыли против borrow checker. Зарплаты для программистов на Cobol и Scala тоже выше среднего по той же причине.
P.s. К сожалению, эта же участь постигнет и Go через пару лет после внедрения дженериков :(
зато С++/Java просто і незапутано та без костилів
Rust має трейти, а не женерікі, але Валялькін пише що проблема з боров-чекером. Мабуть, далекий від теми володіння над ресурсом
а ну да, “generic type parameters”
levelup.gitconnected.com/...bhu-eshwarla-303a6ff20720
And maybe we can actually look at replacing C++ with Rust, in the long run. That seems to be what the industry thinking is, and a lot of work is done
тобі для чого?
будеш соблазнять на малі шлюпки?
Не соблазнять не буду, это точно... Хотел просто узнать есть ли такие или нет?
думаю що ні, бо це не мейнстрім з тоннами легасі тіпа цепепе або жаби
Посмотрел раст — вроде хороший язык, интересный. Без кретинского синтаксиса, как некоторые хипстеры в своих языках любят извратиться по максимуму. Но вакансий 1 на страну, и то в какую-то сомнительную галеру. На фрилансе проектов тоже практически 0. И еще они выпилили «зеленые потоки» и сделали 1 новый поток = 1 новый системный тред. В общем смысла учить нет для профита, только для пет-проектов и саморазвития.
Не факт, що «нема змісту для профіта».
Мені за 3 останні місяці прийшло 4 пропозиції розглянути вакансію по Rust.
одна з них (сама остання) в Японію
и что вы завели трактор в японию? «пропозиції» и оффер это очень разные вещи, мне тоже кидали предложения с трактором из NL, NO, пока его не рассматриваю
справа в тому, що я по ембеддед, а пропонують крипту, так що не все так однозначно...
Помогите
самий простий варіант найти готову лібу/crate з потрібними методами, яка це робить, а не в С стилі «робити закат руками»
я останній раз я на ресурсі по задрочуванні алгоритмічних задач використовува для інтерв«ю в Амазон,
а просто так іпати міски на ньому нема бажання,
це все одно що задрочувати себе рішеннями дифурів при підготовці до вступу на фізмат в Баумана. От нашо воно мені, якщо я на фізмат і тим більше в Баумана не збирався ніколи
хоче чувак, хай робе.. чому за нього трахати собі моск?
його гемор, хай собі і лікує
не може на расті, хай спочатку зробит на жабі або пітоні, зрозуміє алгоритм і тоді перейде на раст варіант («треніруйся лучшє на кошках» www.youtube.com/watch?v=-j79mA_6BAQ )
ти сєрдобольний, помагай
ах да забув
Но, если будешь платить от 7000 в месяц, то могу и на расте тебе пописать
Володимир Корнійчук
Senior Software Engineer (C++)
в Infopulse, Part of Tietoevry Create
04.12.2019 09:39
Класична інститутська задачка на тему «Скінченний автомат». Прочитай що це, визначи стани, переходи між ними — і задача вирішується сама собою рядків в
транзакції — табличним методом, через колбеки, чи ifами/switchaми?
Володимир Корнійчук
Senior Software Engineer (C++)
в Infopulse, Part of Tietoevry Create
04.12.2019 11:09
Занадто багато честі на таку дрібницю колбеки городити. Таблиця та іфи будуть приблизно однакові що по швидкості, що по кількості коду.
вам нужна помощь с алгоритмом, или вы выбрали алгоритм решения и вам нужна помощь с его реализацией на rust?
Мне нужна помощь с реализацией на rust.
Пока такая ошибка. prntscr.com/q6ghcw
я не спец в rust, эксперты наверное помогут лучше.
проблема скорей всего вот здесь: stackoverflow.com/...to-index-a-string-in-rust
Може строку конветувати у вектор чарів?
І розверни повністю на скріншот, що пише компілер, там може бути підказка.
А да, ітератор, можливо не є індексом. Можливо тре ввести додаткову змінну для індекса.
Есть решение этой задачи:
Voicechat: Product в Deftechсереда о 19:30
flyman
Sergii Voloshyn
anonymous
Artyom Krivokrisenko
Aliaksandr Valialkin
Seven Berg
юнит тест
Valentyn K
code monkey
impl Solution {
pub fn is_match<S: AsRef<str>>(s: S, p: S) -> bool {
let (s, p) = (s.as_ref().as_bytes(), p.as_ref().as_bytes());
if s.is_empty() { return p.is_empty() || p.iter().all(|x| *x == b'*'); }
else if p.is_empty() { return false; }
let mut dp = vec![false; p.len()+1];
dp[0] = true;
for j in 1..dp.len() {
dp[j] = if p[j-1] == b'*' { dp[j-1] } else { break };
}
for i in 1..=s.len() {
let mut dp_i_1_j_1 = dp[0];
for j in 1..dp.len() {
let saved = dp[j];
dp[j] = if s[i-1] == p[j-1] || p[j-1] == b'?' { dp_i_1_j_1 }
else if p[j-1] == b'*' { dp[j] || dp[j-1] }
else { false };
dp_i_1_j_1 = saved;
}
if i == 1 { dp[0] = false; }
}
*dp.last().unwrap()
}
}
Я мимокрокодил, но вам не кажется что такой код попахивает?
так це задачка на літкод, а ти що СОМ об"єкти думав побачити?
Трохи нагадує сортувальну мережу з Седжвіка
Можно узнать мнение сообщества, подходит ли раст для разработки сетевых протоколов, может быть альтернативой языку це, а именно буст. В недалеком будущем возможны проекты подобного рода...
Подходит. И куда лучше чем ЦПП. Потому что нет UB, удобнее работать с поинтерами, практически нереально словить buffer overflow.
нереально словить buffer overflow
Таки реально, и не только buffer overflow:
libc треба ж, або інші ліби з яким потім лінкуєиться (dbus) чи ще що ти там захочеш приліпити собі
удав з мусоросборщиком, а ржавчина натівна як С
а С++ тре шаманити, щоб мали його ліби С інтерфейс
як ще пояснити, native = труъ_С
ще раз, для тих хто в танку, Rust натівний як труъ_С (а С++ ніт)
В чем это проявляется? Разница между С и С++?
ABI єдиного в С++ якого нема
alenacpp.blogspot.com/2007/03/c-abi.html
Який має стосунок ABI до нативності?
ти питав в чому різниця, я відповів що є в С++ ABI свій власний, і щоб робити ліби тре приводити до С АBI і тоді можна лінкуватися. В Rust такого нема, там в нього нативний С АВІ.
А як мова програмування, то що С що С++, що Rust нативні, тільки є одни ньюанс.
ще раз, для тих хто в танку, Rust натівний як труъ_С (а С++ ніт)
В чем это проявляется? Разница между С и С++?
ABI єдиного в С++ якого нема
Який має стосунок ABI до нативності?
ніякого, ти питав в чому різниця, я відповів
В Rust такого нема, там в нього нативний С АВІ.
Себто, Раст безпечний, доки в ньому не використовуються ліби з С, але він сам призначений для того, щоб використовувати ліби з С?
саме так безпечний, поки ти використовуєн безпечні штуки,
а секції які мітяться як unsafe Боров Чекер обходить, бо він думає, що ти знаєш що робиш і не заважає тобі.
То майже усюди використовуються небезпечні ліби від ядра ОС та libc до регекспів. Відповідно, більшість програм на Расті, більших за хелло ворлд (та й він, бо під ядром біжить) — небезпечні.
наприклад бекенд із Redis не вимагає С ліб
en.wikipedia.org/wiki/Redis
Written in ANSI C
Себто, ти вважаєш, що система з безпечним клієнтом до небезпечної бази є набагато ліпшою за систему з небезпечним клієнтом до небезпечної бази?
Головне — клієнт, а не база?
а хто сказав, що редіс небезпечна база?
маніпулюєш однако
Бо ж написана не на безпечній мові.
Й багато маніпулює пам’яттю.
тут або-або,
або пишеш на небезпечній мові і довго-нудно тестиш,
або на безпечній куяк-куяк і в продакшен .
95% багів пов’язані з логікою, а не з ресурсами. Відповідно, і результат будет такий як і процес розробки, якщо не тестувати.
не знаю в кого як, але в мене на Rust виходить розробка рази в 3 шивдше, а на дебаг крешів та сегфолтів та дивної повідінки — взагалі чи не зеро часу.
Крім того менеджмент пакетів та залежностей не такий примітивний як при зборці С/С++. І тут виграш в часі на розрішення проблем.
я не про тестування, я про дебаг, коли в тебе хз чого не зрозуміла поведінка, креші і сегфолти з коредампами
В мене 95% крешів — це асерти, котрі я сам і проставив, інші зазвичай теж стек показують і часто зрозуміло більш-менш, що там.
Проблеми як раз коли асерт не зловив баг і вчасно не скрешив прогу, і логіка вразнос пішла, якийсь асинхронний сценарій повис чи неправильно спрацював — в результаті чи то голоса нема, чи ще щось. От на днях були приколи:
1) Якщо 2 слухавки від радіотелефонів тримати в одній руці, і ці слухавки розмовляють одна з іншою, то коли приходить паралельний дзвінок (waiting call), його номер відображається лише на першій слухавці. Виявилось, що друга слухавка чує тони, котрі передають номер на першу слухавку, вони перетинаються з тонами, котрі передають номер на другу, і вона не може розібрати номер.
2) Якщо входить виклик, коли обидві слухавки покладені, і після першого гудка підняти слухавку, то замість того, щоб розмовляти з зовнішнім абонентом, розмовляєш сам з собою (loopback). Виявилось, що в сценарії завершення передачі номера була перевірка типу номера і типу дзвінка, тип номера обнулявся до перевірки, а тип дзвінка визначався з того, чи є голос на другій слухавці. В результаті в даному сценарії на платі вмикається cross-connect голосових пакетів (як для розмови між слухавками), але на шині байти розположені симетрично (бо насправді зовнішня розмова), і виходить loopback.
А креші — то фігня, за винятком двох наступних:
А) прога крешилась чи висла на роутері при виході в 5% випадків. Пів-року колюпали в лінивому режимі. Виявилось, що в musl libc нема перевірки, чи залочений мютекс, що знищується прогою, а SIP stack, котрий ми використовуємо (і не тільки ми, а ще й, наприклад, Астериск) сподівається, що йому ОС поверне помилку в цьому випадку. В результаті б’ється список мютексів в libc.
Б) хромік на андроїді валився коли повертаєшся з сторінки з великою картинкою. При цьому кол стек кожного разу був різний, і половину локальних змінних під дебагером не можна було подивитись. Ловив майже тиждень. Виявилось, що при виході табу робиться unmap(addr_, size_); addr_ = NULL; а при знищенні табу — ще раз unmap(addr_, size_), і хвостом отого unmap(0, size_) зачіпає область пам’яті під стек, в результаті чого змінюються права доступу до локальних змінних інших функцій на стеку, і прога вилітає в іншій функції при доступі до локальних змінних.
от Rust такі «залуплення» ще на етапі компіляції анігілює на 99%
Які саме з 4 вище наведених?
А я взагалі не бачу, як компілер може перевірити логіку роботи софта. Якби він міг — вже роботи писали б проги. Візьми і покажи для котрогось з цих випадків як Руст його покращив би. Інакше маємо підстави говорить, що серйозні баги потраплають в 1% того, з чим Руст не може впоратись.
тобі писали, там є такий чувак Боров Чекер, от він і перевіряє.
Тобто у об"єкта може бути лише один власник.
Якщо то зсилка, то лише один власник, який може модифікувати його.
Цикл життя об"єкта/зсилки під контролем теж.
І це все на етапі компіляції.
Тобто якщо ці правила порушуються програма не збереться, а якщо збереться, то 99% гарантії, що працюватиме коректно.
Крім того, код на Rust досить лаконічний, що веде до зменшення загальної кількості багів в програмі (код стає коротший), за умови, що в розробника що на С що на С++, що на Rust кількисть багів на 1000 строк більш менш величина стабільна.
1) Ти ж не чуєш. Почитай опис багів. До чого там власники об’єктів? В мене взагалі Actors, там нема проблем багатопоточності чи власників. Я кажу, що серйозні баги або в логіці, або десь на дуже низькому рівні, а ти — знов про власників вказівників.
2) Лаконічність коду (пихання усього в один рядок) призводить до збільшення кількості багів в програмі, бо це читать неможливо.
Лаконічність коду (пихання усього в один рядок) призводить до збільшення кількості багів в програмі, бо це читать неможливо
як все запущено
Ну... почему-то ты не удивляешься, когда компилятор C++ «проверяет», что переменной одного типа не присваивается значение другого (несовестимого).
Компилятор Rust гарантирует, что в системе может быть только один указатель, доступный для записи (чтобы предотврадить race conditions), или много указателей, доступных для чтения (отсутствие алиасинга). Кроме того компилятор Rust гарантирует, что каждый указатель будет когда-то освобождаться, что не будет обращения по нулевому указателю. Плюс можно дополнительно устанавливать гарантии, что указатели освобождаются в одном месте.
Минус в том, что вот так вот вольно обращаться с указателями в стиле C++ уже нельзя, просто взять адрес, куда-то передать — будут бить по рукам линейкой.
Да, это все те же рассуждения об указателях, а реальные проблемы у программ на С и С++ — с логикой, а не с указателями. RAII + ассерты порешали проблемы с указателями 25 лет назад минимум.
логіка в чому, як в рантаймі тебе іде гонка?
чи логіка в тому що не звільняються в правильному порядку ресурси?
Бачиш гонку чи звільнення вказівників в описі складних багів нижче?
1) Якщо 2 слухавки від радіотелефонів тримати в одній руці, і ці слухавки розмовляють одна з іншою, то коли приходить паралельний дзвінок (waiting call), його номер відображається лише на першій слухавці. Виявилось, що друга слухавка чує тони, котрі передають номер на першу слухавку, вони перетинаються з тонами, котрі передають номер на другу, і вона не може розібрати номер.
2) Якщо входить виклик, коли обидві слухавки покладені, і після першого гудка підняти слухавку, то замість того, щоб розмовляти з зовнішнім абонентом, розмовляєш сам з собою (loopback). Виявилось, що в сценарії завершення передачі номера була перевірка типу номера і типу дзвінка, тип номера обнулявся до перевірки, а тип дзвінка визначався з того, чи є голос на другій слухавці. В результаті в даному сценарії на платі вмикається cross-connect голосових пакетів (як для розмови між слухавками), але на шині байти розположені симетрично (бо насправді зовнішня розмова), і виходить loopback.А креші — то фігня, за винятком двох наступних:
А) прога крешилась чи висла на роутері при виході в 5% випадків. Пів-року колюпали в лінивому режимі. Виявилось, що в musl libc нема перевірки, чи залочений мютекс, що знищується прогою, а SIP stack, котрий ми використовуємо (і не тільки ми, а ще й, наприклад, Астериск) сподівається, що йому ОС поверне помилку в цьому випадку. В результаті б’ється список мютексів в libc.
Б) хромік на андроїді валився коли повертаєшся з сторінки з великою картинкою. При цьому кол стек кожного разу був різний, і половину локальних змінних під дебагером не можна було подивитись. Ловив майже тиждень. Виявилось, що при виході табу робиться unmap(addr_, size_); addr_ = NULL; а при знищенні табу — ще раз unmap(addr_, size_), і хвостом отого unmap(0, size_) зачіпає область пам’яті під стек, в результаті чого змінюються права доступу до локальних змінних інших функцій на стеку, і прога вилітає в іншій функції при доступі до локальних змінних.
1) проблема розшареного ресурсу в різних тредах, в Расті, скоріше за все тре було би зробити клони, і ніхто б нікому не заважав
2) знову є розшарений ресурс, і кілька тредів
Креші:
а) хз, якщо використовувати з Раста pjsip проблема могла би дальше бути, не можу сказати
б) думаю, що Раст би просто не скомпілив, так як явна пробламетчність із «власністю» на ресурс, але знову, це могло бути офрмлено як виклик із С ліби, і Расти би «не видів»
Резюме:
скоріше за все той дизайн, що під С++ не ліг би добре під Руст і прийшлосль би боротися із Боров Чекером і врешті решти побороти і його і проблеми, а заодно і підправити дезігн
1) проблема розшареного ресурсу в різних тредах, в Расті, скоріше за все тре було би зробити клони, і ніхто б нікому не заважав
Ніт, проблема розуміння того, як працює залізо в Панасоніка. Це — реальні пластикові радіотелефони чують один одного через динамік та мікрофон.
2) знову є розшарений ресурс, і кілька тредів
Нема розшареного ресурса, управління платою іде з актора, котрий живе в своєму власному потоці. Але 2 дії в коді були в неправильній послідовності, тому залізо вмикалось в неправильному режимі.
а) хз, якщо використовувати з Раста pjsip проблема могла би дальше бути, не можу сказати
Чиста несумісність бібліотеки та libc.
б) думаю, що Раст би просто не скомпілив, так як явна пробламетчність із «власністю» на ресурс, але знову, це могло бути офрмлено як виклик із С ліби, і Расти би «не видів»
Залежить, чи є в Расті нормальна обертка для mmap, бо та була трохи крива, але воно вилазило лише на смартфонах з мало пам’яті.
Сюда можно ещё добавить санитайзеры. Хотя всё равно, у меня когда что-то пишешь без санитайзинга, то определённые проблемы, которые могли бы потом вылезти, он находит.
Ну а логика и верификация кода... Это уже совершенно другой уровень. Я вот трогаю лапками Coq, правда не очень интенсивно.
ну чувак, хто тобі винний, що асерти не ставиш, і в тебе б’ються внутрішні дані проги настільки, що вона сегфолтить у випадкових місцях.
На С та С++ що не можеш сегфолти вивести.
мені простче переписать на руст, чим морочиться із С/С++ шо де там тече, крешиться чи впадає в гонки
Володимир Корнійчук
Senior Software Engineer (C++)
в Infopulse, Part of Tietoevry Create
04.12.2019 09:32
95% багів може і пов’язані з логікою, але от серед тих багів, які приводять до крешів і проблем з безпекою — десь 80% пов’язані з ресурсами та UB (є дослідження Мозілли та Майкрософт у щодо цього). Rust не напише за програміста правильний код, але в багатьох випадках дасть йому по рукам за небезпечний.
Rust дивлячись на поведінку твоїх об"єктів може підказати (тобто не компілити код), що проблеми з логікою.
Все ж при програмуванні на Rust тре дещо інші підходит як в С і тим більше в С++
бізнес логіку ще ніхто не парсить крім 1С
не бізнес логіку, а уникання негарних ситуацій типу дедока або гонок
Та усім пофіг на ці ситуації бо вони рідко виникають. Усунення 5% проблем компілером не призведе до прориву продуктивності програмістів, бо 95% глюків в бізнес логіці, і їх треба ручками ловить і ручками чинить.
я бачу, ти погано читав статтю,
там написано, що писати нове програмне забезпечення на Rust, а не переписувати існуюче (відтестоване і віддебажене)
Та не читав я статтю.
Але якщо ти вважаєш, що існуючі системи на С маєть хорошу надійність та якість, то головний твій аргумент за Раст інвалідується.
головний аргумент писати нове на новому
Нелогічно писати нове на новому, якщо старе написане на старому швидко й надійно працює.
Саме через це С досі живий і здоровий.
Залежно задач — прошивку для плати писав на С. Старий С++03 для більших задач давно перевірений та рекомендований, а в С++11+ не лізу, бо воно мені не потрібне в роботі.
як ти відстав від життя, мене на С++17 хантять
але ж ти не підеш?
хто спробував вкусного Rustа на галімі плюси вряд чи поведеться, хиба за велі пеньонзи
він не те що «призначений для того, щоб використовувати ліби С» , а він може їх використовувати з одного боку, і з іншого — можна його ліби використовувати як С ліби з інших мов, тобто тут фредлі в обидва боки.
Ти можеш написати обгортку в небезпечному С, і викликати безпечний Rust код, і навпаки.
І не тільки з С можеш, а із того теж, що розуміє С біндінги.
В Rust есть safe и unsafe. Идея Rust состоит в том, что компилятор может статически проверить правильность safe кода для многих типов ошибок (синхронизация потоков, race condition, bad memory access, ...) но при условии, что unsafe следует определённым установленным правилам.
Бонус в том, что если мы ловим какую-то такую ошибку, то весь safe код вне подозрения, и ошибка где-то в unsafe. B Rust не заставляет и не принуждает писать только safe код. Более того, не всё можно написать в safe. Но если соотношение safe/unsafe как 100:1, то уже жить проще.
Ох как помню натрахался, когда пытался подружить либу собранную борландом заюзать в апке собираемой мелкомягким.
у них вапще різні і несумісні формати об’єктних файлів
хіба є конвертери з одного в інший...
В зависимости от заказчика. Если он все стерпит — то да. Если не все — то лучше использовать более предсказуемые инструменты.
і кожному тре Senior Rust не менше. Блокчейн.
а разгадка проста — parity ethereum. Прикол в том что эта парити имеет такое ограниченное апи, что гораздо меньшие расходов дописать что — то в самой парити, нежели писать аппликуху вокруг самой парити. Например, пересадить его сторедж вместо rocksdb на google-bigtable или ещё что. возможно это даже были из одной конторы.
да не може буть... там спеціально підігнані тести.. тільки С++ тільки хадркор... хто не осилив С++ той олух...а в Rust вашому того, баги водяться... да і сирий він ... хіпстерщина ... для блокчейна... і пам"ять він бере з жопи... а перформанс... вопщем не может бить, патамушо не может бить.
Переписали приложение с учётом уже известных требований, причина больше в этом.
Microsoft потихоньку экспериментируют с языком:
www.infoq.com/...ft-exploring-rust-safety
скажите слыхал,что есть под Rust framework for Blockchain, вроде местного происхождения, может кто знает, киньте ссылочку пожалуйста...
Exomun, BFT consensus
github.com/exonum
Ещё Parity, клиент для Ethereum, реализован на Rust
github.com/...aritytech/parity-ethereum
И как он на проектах? Вы его на крипте юзали?
Я не юзал, только пробежал глазами документацию. Для себя же я привык создавать свои аллокаторы (склейка нескольких malloc в один с нужным мне выравниванием плюс свои пулы по принципу много выделений памяти — одно освобождение а-ля nginx). И моих знаний Rust недостаточно для того, чтобы писать в таком стиле, а детально разобраться не было времени.
Блокчейн
под раст сейчас нету killer app кроме крипты
хех, я тут писав pubsub так от для zeroMQ не доходя до 100000 повідомлень крешиться subsriber на C (out of memory), а на Rust рулить.
Але ця тема надійності готується для іншого топіка.
А розібрався, що там із пам’яттю на С? Може, фрагментація? То в браузерах це давно вирішили.
я думаю проблема на в С, а скоріше в С++, так як то zeroMQ приплюснута штука, і, скоріше завсе, отримується врешті-решт фрагментація пам"яті (щось таке пишуть що є така проблема, десь тут nanomsg.org/...documentation-zeromq.html або тут
nanomsg.github.io/nng/RATIONALE.html)
а С підписчик там тупий, як двері.
апдейт, на nanomsg такого креша не ловлю, може тому що там чистий С :)
В С++ є аллокатори, але їх ніхто не користує. Мабуть, хлопці не думали про 100000 повідомлень.
ZeroMQ взагалі річ дика. В
Написали своє за місяць, досі живе і цвіте, всі щасливі.
Так що ZeroMQ не показник.
А С++ в нас на дронах, політ нормальний.
вони ніколи не тестували більше ніж на2-х нодах, а в нас 20.Просто повідомлення не доходять деколи, ашотакоє?
pubsub? так воно не гарантоване майже всіх датаброкерах, крім MQTT з QoS > 0
Написали своє за місяць, досі живе і цвіте, всі щасливі.
що саме, месидж бас, чи що? чому писали, а не взяли готове: Redis або Mosquitto ?
а що робили raw sockets, чи HTTP, чи вебсокети, чи як? скільки людино-годин пішло?
Нормально, коли втрачається ІР-пакет — хоча в одному реку це хіба через переповнення буферів буває (цікаво, що там в Cisco з lossless Ethernet). А коли потік даних пропадає просто так, а діагностики ніякої — це викликає питання. Кластер з 5 нод просто не піднімався, а потрібно було 20.
Але проблема не в тому, а в ставленні сапорту до проблеми. Я вірю, що в них на Франкфуртській біржі воно якось працювало в контексті їхньої задачі, можливо навіть більше, ніж на одній ноді. А можливо і ні. Суть в тому, що воно навіть не піднімалося в контексті вимог нашої задачі.
Викинули, накостиляли, пережили демонстрацію, за півтора місяця написали по-людськи, досі живе і розвивається.
Переносимося на 5 років вперед.
Пабсаб, черги і історія зберігалися на диску в файловій системі. Зараз не знаю, що там. Бачив сьогодні автора на перекурі, забув спитатися.
На дроні пабсаб, писаний іншою людиною. Джерелом натхнення був брокер в стеку Pixhawk PX4, але реалізація з zero copy, далі доробили мережевий варіант, в минулий четвер виправили передостанній критичний баг. Людиногодини можна було б спробувати порахувати, але навіщо? Пішло достатньо.
Думаю, скоро позбудемося OpenCV — людям потрібен час, щоб повірити в свої сили. Розбиратися в чужому глючному коді без розуміння неможливо, а з розумінням можна написати свій. А можна творчо перекопіпастити чужий, з дотриманням умов ліцензійних угод.
Лінукса позбуватися не плануємо, але USB і (S)SD гальванічно і механічно відв’язані від всього, що пов’язане з реальним часом. Бо там забагато містики і магії.
Можна ще було написати про FINCAD, але це якщо комусь буде цікаво.
З іншого боку, прижилися і лишилися NumPy і Spyder.
Розбиратися в чужому глючному коді без розуміння неможливо, а з розумінням можна написати свій.
в цитатник
ну да, забув free поставити, тепер пофіксив, претензія знімається,
але в Rust я не думаю про те що тре десь робити ручне керування пам"яттю
viva la Rust
Бери С++ і використовуй RAII. І не думай про free, і код буде структурованіший.
Ну... тут есть свои грабли. Да, на C++ можно каждый член класса оборачивать smart указателем. Но, кроме того, что это оверхид, это напрягает. И на практике получается, что где-то берешь указатель, куда-то передаёшь. Потом этот указатель в результате рефакторинга переживает класс... Rust позволяет проделывать такие трюки не боясь ошибок, и получить по рукам при рефакторинге.
RAII != smart pointer. просто выделяешь в конструкторе и удаляешь в деструкторе. придумали задолго до смарт пойнтеров.
ну и да, шарить члены класса наружу по указателям, особенно в другой поток — это сложно и грустно и лучше не делать. кому надо — пускай попросит ссылку через вызов метода на классе. так он не сможет достать ресурс, если хозяина ресурса уже нет.
возможно, для части задач надо шарить — вот в хромиуме там адъ из этого, но я не знаю, это специфика области или исторически сложилось.
RAII не то
тобто ти так і не зрозумів концепцію «власності» яка у Rust, це більше до мув сементики, а не до RAII, але теж трохи ширше, бо разом з тим є ще мутабельність і смарт пойнтерність
А мені в 99% взагалі не треба мувать — зробив напівстатичний об’єкт і з ним працюєш. 1% — це читання чи запис з диска, там копіюється база. там можна зробить smart pointer щоб при виході з помилкою автоматом усе вичищалось.
Створюєш при старті програми в потрібний час. Знищуєш при завершенні, якщо потрібно викликати деструктор, інакше — нехай ОС розбирається.
Ну... задачи разные бывают. Rust хорошо себя проявил в P2P сетях, когда куча нод, которые конектяться друг к другу, передают информацию и т. д. Например, Ehtereum нода. Там RAII не хватает, много выделяется и освобождается в динамике, куча потоков, и там гарантии Rust помогают сохранить уверенность в бытии.
Те же авторы Exonum считают, что решение написать его на Rust было ключевым грамотным, и
Также отсутствие алиасинга позволяет проводить куда более агрессивную оптимизацию и за счёт этого потенциально обганять C/C++, а вот что на практике непонятно, потому что LLVM генератор кода не сильно это может юзать.
Опять же blockchain ещё и требует секьюрности и стабильности. Тут тоже заходит.
ніт, не так, це називається «закат солнца вручну»
знову не так, а так:
в мене є довірена особа, називається вона Боров Чекер, от вона мені дозволяє зосередитися на програмі, а не на ручному управлінню пам"яттю (але на відміну від мов із GC це є зеро кост щодо перформанса, тобто програма швидка ніби як написана на С без всяких тормозов)
upd.
от допустим в тебе є жінка, яка тобі готує їсти, підмітає хату, пере речі, слідкує за твоїм здоров"ям і настроєм (і все це за твої гарні очі, тобто задармо, а не п"є кров і не іпе міски), а ти не заморучуєшся цим всім і клепаєш бабло пишучи програми в доброму гуморі і здравії
Тут было о том, что если ты не течешь по памяти, а течешь по сокетам — лучше от этого ни твоим соседям, ни клиентам не станет. Вероятно, даже наоборот.
D пішов шляхом «бути умним і красівим» в результаті зайшов в тупик «ні Богу свічка, ні чорту кочерга»
наскільки я розумію Rust звільнєя те що випадає з його області видимості,
якщо ти якийсь ресурс хочеш передати, то це робиться або по зсилці, або передачею прав власності або клонуванням.
Чесно кажучи, я не пригадую, щоб були проблеми в мене в Rust із мемліками, чи сегфолтами, чи не залишеними сокетами (хоча не впевнений що вони звільняються автоматом)
А як ти гарантуєш, що ссилка на старий ресурс ніде не лишається? Ліки зазвичай як раз в логіці.
ithare.com/...t-punishment-for-failure
не я гарантую, а Rust з Боров Чекером & Co
що він гарантує? що ти не забудеш із списка відкритих сокетів прибрати ссилку на сокет, коли в тебе клієнт завершив сесію? все одно тобі руками треба цей сокет закрити та видалити.
Навіть ссилка має свій скоуп життя, як тільки цей скоуп пропадає зсилка прибивається.
Взагалі-то зсилка для того більше, щоб при передачі власності не робити клонів об"єкта.
Також є поняття мутабельності.
Якщо ти робиш кілька копій, але вони не міняються, то будь-ласка.
Якщо десь буде мінятися об"єкт, то він може бути переданий на мутабельність тільки один раз.
Якось так.
Щсоь подібне до сматр пойнтерів у С++, але мудріше.
Навіть ссилка має свій скоуп життя, як тільки цей скоуп пропадає зсилка прибивається.
Коли ти працюєш з клієнтами, котрі тримають сесію, то скоуп ссилки на сокет буде рівним скоупу сесії, котрий може дорівнювати лайфтайму твого сервіса. Відповідно, якщо коли клієнт прислав команду завершити сесію ти руками не вб’єш сесію разом з сокетом — то матимеш лік і пам’яті під сесію, і системних ресурсів на сокет. І жоден боров тобі не допоможе.
А ще може буть ситуація, коли ти маєш надістати клієнту підтвердження, що ти закрив сесію, тоді ти не можеш вбити сесію та сокет коли отримуєш команду на закриття сесії.
І чим тут тобі боров допоможе?
Я на Расті не пишу, і мені боров не потрібен. І тобі він не допоможе, коли відійдеш від функціональної парадигми.
так чого тролиш? набрид клятий ЦеПеПе? тоді спробуй раст
Скажем так, указатель в Rust, по сравнению с указателем в C, имеет ещё дополнительный атрибут — место где он освобождается. Кроме того, считается, что в системе может быть только один указатель, доступный для записи, и много для чтения. Так что scope в Rust свой особенный и потокобезопасный.
Если у меня есть сокет, и если у меня есть структура клиента, я могу потребовать чтобы они освобождались в одной точке. Соответственно, если компилятор не сможет доказать, что это справедливо, то ты получишь ошибку компиляции.
Опять же, если надо убить клиента и оставить сокет, то ты просто передаешь (borrow) из структуры клиента, например, в структуру закрытой сессии.
Я о том, что это все делается руками, и логические утечки ресурсов, когда забыл передать или удалить сессию, никуда не деваются.
Если они будут доступны в коде, то естественно никуда не денуться. Ты увидишь в памяти over 9000+ структур сессия.
Но в Rust есть дополнительный рычаг контроля— можно указать, что два указателя освобождаются в одном месте. И любая попытка нарушить это будет приравнена к побегу. Например
Гастрафет Аристархович
Yegor Chumakov
Not Sure
Иван Камышан
Alex L
Alex Koshterek
Dmytro Lapshyn
Dmitry Panfilov
Roman Pavlyuk
struct A {
s: &'static str
}
тут мы говорим, что поле s есть указатель на статическую строку. Соответственно, любая попытка присвоить туда указатель на любую другую будет пресечено.
Или
struct C;
struct B<'a> {
c: &'a C,
}
а тут мы говорим, что структура B содержит указатель на структуру C, и они должны освобождаться в одном месте.
Я пилил Rust wrapper для небезопасных буферов.
Решается проблема легко.
Небезопасный буфер оборачивается в безопасную Раст структуру. В этой структуре реализуется drop trait, и этот drop проверяет что лежит в указателе на безопасный буфер. Если там null, все хорошо. Если там не null, значит есть утечка и приложение крашится.
Далее добавляется метод, который позволяет вручную осовбодить буфер. Когда вызывается этот метод, небезопасный буфер освобождается и указатель на него убирается из структуры.
Получаем профит.
Можно еще пойти дальше и автоматически освобождать буфер когда проихсодит drop, в моем случае особождать надо по умному, и сама структура не имеет достаточно инфы чтоб буфер осовбодить, поэтому просто крашит приложение.
Если программист олень и решил эту структуру положить в какую-то глобальную переменную, то она не выйдет из области видимости и технически будет утечка, таки да.
вечер окуительных историй на доу.
руст — эдакий супермэн, достающий память из жо...
А в расте уже все buffer-overflow пофиксили?
in std::collections::vec_deque::VecDeque::reserve() function
це всі претензії?
C на тіобе готова стати нумбер 1
а ЦеПеПе угасає,
Rust ракетой вверх
Ну... embedded это обычно достаточно много легаси кода. Так что уйти от C крайне тяжело. Начиная от кода операционной системы.
наличие операционной системы для embedded-а нехарактерно
Та ты шо?
Роутеры уже перестали быть эмбедедом?
И даже в этом случае есть некоторый код инициализации от производителя, который никто не горит желанием переписывать, и который достался в наследство от предыдущей версии железа. Не говоря о специфических компиляторах для некоторых чипов, где C вроде как стандарт, а про Rust не слышали.
C вроде как стандарт, а про Rust не слышали.
є таке
А як же OpenFirmware?
Навіщо???
напр, з опису вакансії
Requirements: Understanding the limitation of low power/memory limited platforms.. Good knowledge of STL/Boostце що, буст в Ардуіну, чи як?
Чого, може там відеодомофон на батарейках. В нього буде дофіга флеша й хороший проц, але треба спати поки ІЧ датчик не ловить рух. Коли зловив рух — треба ввімкнути камеру й розібратись, що відбувається. Якщо щось цікаве — запакувати відео й відіслать на сервер. В такій системі (Ring, наприклад) 3 проца: основний потужний, DSP для упаковки відео, мережевий економний проц щоб слухать WiFi.
так де
memory limited
?
П.С.
а могли би все зробити на FPGA
а могли би все зробити на FPGA
Не вірю. Колись алгоритми розпізнавання намагались перенести на
ага, і Панда проц виявився з апаратним прискорювачем, тобто з FPGA
То й що? Це ж не писати свій FPGA.
Чи обрахунки на десктопі ти теж до FPGA віднесеш, бо там SSE?
Так идёт речь о блокчейне, или
low power/memory limited platforms
Или надо реализовать блокчейн на какой-то тостер?
Так чем плох c++ и буст? Неужели раст лучше и производительнее плюсов?
какой-то растофил случайно пролез в какую-то контору и влияет на хайринг, бывает
Напиши на Расті event-based stateful систему. Подивимось, що з тобою буде.
vent-based stateful
а шо це тіпа restfull?
Ні, це тіпа Астеріска, котрий керує залізом (голі регістри SLIC) якщо плату з телефонною лінією підключити + тримає зв’язок з телефонним сервером в інтернеті. Такий собі SIP<->FXS gateway.
Чи ядро операційної системи, в котрої дофіга типів ресурсів, користувачів, асинхронних задач, і за усім цим треба слідкувати, і воно одне з іншим взаємодіє якось.
тю, я забув в тебе ж попаболь із VoIP,
я ж мікросервіси люблю
VoIP як раз взяли готовий. В мене був DECT, зараз — SLIC
Чи ядро операційної системи, в котрої дофіга типів ресурсів, користувачів, асинхронних задач, і за усім цим треба слідкувати, і воно одне з іншим взаємодіє якось.
Firecracker Microvm написана на Rust
Firecracker implements a virtual machine monitor (VMM) that uses the Linux Kernel-based Virtual Machine (KVM) to create and manage microVMs.
Типа это супервизор над линуховыми сишными виртуалками. Не знаю, насколько много там логики)
stateful — це пряма протилежність REST: маємо систему з купою вхідних та вихідних каналів, котрі час від часу щось присилають, але ніде нема загальної кртини що відбувається — цю картину треба самому будувати, запам’ятовувати, підтримувати і, виходячи з неї, керувати системою.
Приклади: ядерна станція (бо вже навели), літак чи самокерований автомобіль, прошивка якоїсь мережевої карточки чи роутера чи Nokia 1100, операційна система.
Ідея в тому, що коли приходить інтерапт чи пакет — він нічого не вартий, якщо ти не маєш моделі, котра емулює твій пристрій. По інтерапту треба підкоригувати модель відповідно зміні, котру сигналізували, вирішити, чи маєш щось робити у відповідь, якщо так — відіслати потрібні команди (пакетами чи записом в регістри), можливо — понаставить таймерів на майбутнє, якщо запустився сценарій, а далі — чекати наступного інтерапта чи таймера.
так, там усе базується на них. вхідні дані — лише модифікатор.
приклад: малюєш віконну систему. приходить сигнал, що на миші натиснули кнопку. треба подивитись в себе десь поточні координати миші, потім подивитись в себе десь список вікон, відфільтрувати їх по координатам миші, знайти верхнє, передати йому сигнал, відповідний тому, чи це був одиночний клік, подвійний клік, чи початок перетягування, якщо не обробило — передати сигнал наступному вікну.
в Rust нема проблеми тримати глобальні дані, та шарити їх,
можна запихати в Box, або як залочену статичну змінну.
Проблеми може й нема. Та чи буде зручним і надійним Раст, коли КОЖНА функція працює з глобальними даними та половина функцій їх змінює. Це зводить нанівець усю ідею функціонального програмування.
rust не є функціонального програмування, так можна дійти до того що С++ з лямбдами став мовою функціонального програмування.
Наскільки я розумію, Rust оперує переважно на стеці (щось подібно до Lua) а для глобальних змінних я вказав дві техніки які знаю.
Тут питання, чи зручно гвозді забивати мікроскопом, чи для того молоток є.
як на мене, то для IoT/backend досить таки зручно
Ну в нього рантайм великий — не певен, що в IoT датчик влізе.
От зараз робив прошивку для USB-FXS перехідника — там 64KB Flash + 8KB RAM.
Для стейтлесс (REST) бекенда має буть супер. А от для ентерпрайз (склади чи супермаркети) бекенда — не думаю.
он зробили хелло ворд Rust бінарник майже як на С, на 32 байти довше
lifthrasiir.github.io/...ust-executable-large.html
Не всі хочуть вивчати камасутру в робочий час. Коли це все буде IDE робить автоматом — тоді, може, воно піде в маси. А поки є няшна сішечка.
Навіщо? Асемблер може знать хтось один на роботі, і всі до нього будуть бігать питать якщо треба. Воно трапляється раз на рік, що туди дивитись. А щоб на асемблері писать — взагалі не бачив такого.
что там его знать, открываешь instruction set manual, читаешь и уже знаешь )
вангую С++ скоро буде як COBOL, такою старперівською мовою «для тих кому за 50»
2×2.su/...-teh-komu-za-50-7932.html
8. Работа на дому. А вот это объявление меня заинтересовало больше всех: «Зарплата от 1000 рублей в день. Наличие ПК и интернета».
камасутру
ось тобі труъ камасутра:
www.muppetlabs.com/...software/tiny/teensy.html
Rust є той молоток, який замінить стару кувалду із С/С++
Ну от коли збереш в 20КБ прошивку з USB+DMA+I2S — тоді й замінить, може.
пля, fprint жере 2К на Атмезі (USB CDC теж займав 2К), так що не лякай старшними абревіатурами
то перепиши його на расті, щоб зайняв менше)
Як писав Вітя Ч. :
е:сли будешь платить от 7000 в месяц, то могу и на расте тебе пописать. Риски-то твои.
Як пише Вітя Ч.
если будешь платить от 7000 в месяц, то могу и на расте тебе пописать. Риски-то твои.
ну тут якесь ООП/ООД з вікнами та мишами, це більше ЦеПеПе стайл таки мабуть, але ж : «в любій мові можна писати як на Коболі»
Ну яка задача такий і стиль. Хочеш писати операційні системи чи прошивки для телефонів — вмій написати вікна та працювати з залізом. Х під лінукс, задється, на С писані. Вікна в ранніх Віндовс, імовірно, теж.
Qt — то новомодна хіпстерщина
Суть, скорее, в том, что WinAPI и X писались как R&D — без нормального предыдущего опыта, а Qt — более поздняя поделка, когда уже было понятно, как такое писать, и зоопарк граблей на всеобщем обозрении. Если самому писать какую-то странную штуку — будет похоже на WinAPI, а не на Qt.
The initial release of Qt software was on 20 May 1995.
Хіпстерщина, але працює, швидко, на вінді, лінуксі і андроїді (ну і під маки можна скомпілювати за потреба).
В некоторых случаях может быть производительнее:
1) более современные алгоритмы в либах
2) из-за жестких ограничений в коде больше возможностей оптимизации у компилера
Бенчмарки показывают, что на алгоритмических задачах Раст часто выигрывает.
А что должно быть?
Говорил каждый любитель крестов, до встречи с бороу чекером
Understanding the limitation of low power/memory limited platforms..
Good knowledge of STL/Boost
Какие-то взаимоисключающие параметры %) На работу требуется старый опытный дегустатор эвтаназий.
Vlad Stelmahovsky
Not Sure
Left Outer Join
Andrii Sevastianov
Left Outer Join
Bot Bot
Alexander Qel
Mike Gorchak
251 коментар
Додати коментар Підписатись на коментаріВідписатись від коментарів