Особливості Rust: сфера застосування, відмінності від інших мов, вакансії

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Привіт! Я цікавлюся створенням апаратного та програмного забезпечення для вбудованих систем від 1987 р. Останні 10 років — це участь в проектах в аутсорсингових компаніях в ролі розробника.

У цій статті хочу поговорити про Rust.

Сфера застосування

Я би не вставив вибір мови програмування як наріжний камінь. Для «вільного муляра» з свободою вибору проблема стоїть скоріше в тому, який інструмент на даний момент ліпше використати: кайло чи лопата чи сокира, за умови що вона є і, що хоть якось вмієш нею користуватися. Для командної роботи — тут ще більше змінних, які впливають на вибір інструменту. З іншого боку, на мою думку, поява Rust — об’єктивна необхідність, і рано чи пізно щось би придумали подібне, тим паче, в нетрях якось корпорації.

Екосистема

Якщо мається на увазі ІDE, то в силу специфіки (написання мікросервісів), мало коли нею користуюся, і розробку веду в звичайному текстовому редакторі. Rust має чудовий пакетний менеджер, який впевнено вирішує залежність від сторонніх бібліотек та модулів. Підтримує достатньо велику кількість платформ, операційних систем та апаратних архітектур.

Приклад кроскомпіляції під Raspberry PI.

Особливості

Як на мене, основна особливість це володіння об’єктом, і пов’язані з цим дії щодо управління пам’яттю. Як наслідок, писати використовуючи Rust в стилі іншої мови програмування скоріш за все не дозволить компілятор, і на початках Вам прийдеться ламати свої звички та підлаштовуватися під нього.

Відмінності від інших популярних мов

Серед тих мов програмування, якими хоч трохи користувався (C, C++, Java, Python, Go) найближчою мені видається Golang.

Відмітив би тільки такі особливості:

  • підвищене безпечність;
  • кращий пакетний менеджер (не тре окремо виконувати go get щоб отримати модуль);
  • нема збирача сміття;
  • мінімум ручного управління пам’яттю;
  • виключне володіння об’єктами;
  • менший час виконання;
  • основна робота на стеці, як наслідок, мінімум глобальних об’єктів.

У решті дуже подібний. Ще одна спільність з Golang, що підтримується корпорацією, тільки не Google а Mozilla.

Супутні скіли, які потрібні для розробника цієї мови

Особливих вимог не потрібно, крім бажання, терпіння, та комп’ютерної грамотності. Якщо людина навчилася писати на одній із мов програмування, то зможе на іншій.

Приклади з власного досвіду

Це, мабуть саме цікавіше, так як решту інформації досить легко знайти та прочитати. Знайомство з Rust відбулося, тому що клієнт забажав змінити оновити апаратне забезпечення, і заодно архітектуру і програмне забезпечення, оскільки технічний борг досяг критичної маси.

Оцінюючи інші альтернативи щодо написання, однією із переваг була наявність готового модуля для обробки специфічного формату даних, якого не було у інших варіантах, і його прийшлось би писати з нуля.

Зі сторони підрядника лише мені видалася така опція цікавою, решті програмістів RUST був не до смаку: «я спробував і мені не сподобалося».

Що отримав у результаті:

  • швидке написання невеликих програм та модулів для підтвердження концепції (PoC — proof of concept) та мінімально цінного продукту (MVP — minimal viable product);
  • досвід програмування в іншій парадигмі, яку сповідує RUST.

Не обійшлося і без ложки дьогтю.

Оскільки Rust передбачає виключне володіння об’єктами, чітку синхронізацію його використання в різних нитках,то не вийшло написати програму для асинхронної роботи із послідовним портом, тобто працювати в окремих нитках програми на прийом і передачу.

Оцінюючи інші альтернативи, такі як C, C++, Java, Python зрозумів, що подібний нескладний сервіс швидко не вийде, тому вирішив спробувати на Golang. Спроба видалася вдалою, так як потрібні пакети роботи із послідовним портом та іншими модулями існували, а працювати асинхронно з глобальним об’єктом (TTY або COM порт), який доступний в різних нитках було так само легко, як в звичайному С.

Вакансії

З цим наразі не густо, в основному блокчейн, але приходять іноді цікаві запити, наприклад, від НАСА.

Резюме

З моєї точки зору, якщо Вас все влаштовує в тій ніші, у який ви працюєте, то знайомство з Rust, скоріш за все не принесе задоволення.

Але, якщо клієнт рекомендує Rust, і готовий оплачувати час на перехід на нього, то тре використовувати таку можливість.

Якщо Ви фрілансер, і Вам важливо зробити ефективно, швидко і надійно, то Rust, це ще один додатковий інструмент у вашому арсеналі: крім «кирки та лопати» у Вас з’явиться ще «сокира».

Так як Rust досить своєрідна мова, яка поєднує багато корисних рис із таких популярних мов як C, C++, Java, Python, Golang, то в багатьох застосуваннях (веб, бекенд, вбудовані системи, блокчейн, ІоТ і т.п.) є достойним конкурентом.

Іноді, завдяки підвищеній безпечності, безальтернативним варіантом.

За нею стоїть потужна корпорація. Не забуваємо також, що вона кілька років визнана як «найулюбленіша мова розробників».

На мою думку, поступово, тихою сапою вона пробиватиме шлях на гору в рейтингах використання. Так за п’ять років Rust із 50 місця добрався до 20-го в індексі tiobe. За десь років, від моменту офіційного представлення мови у 2010, в червні попав в топ 20.

В іншому рейтингу (який побудований на кількості запитів google щодо використання мови) 18.

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному7
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

АНБ США рекомендує відмовитися від С/С++
youtu.be/_JDQJr4QNTk?t=148
і використовувати замість них, напр: C#, Go, Java, Ruby, Rust i Swift
тут про Rust
youtu.be/_JDQJr4QNTk?t=196

Ну вот и сделали. A first look at Rust in the 6.1 kernel

lwn.net/...​/910762/0ebbdbf4b6f481d3

Вот когда сделают поддержку Rust в ядре Линукса, тогда и поговорим
====================== вы находитесь здесь =======================

git.kernel.org/...​7c8eede18cab11e1115e2062b

Со временем Rust станет полностью интегрированным вторым языком в ядро Linux. Но хлопцы совсем не обязательно, что все 30+ миллионов строк ядра будут переписаны на Rust. Rust делает любую программу, на которой он написан, более безопасной, чем ее аналоги на C. Первую пробу пера на Rust, можно увидеть в ядрах Linux следующего поколения, это уже будет реализовано на LKML.
lkml.org/...​ion&utm_campaign=platform

Через пару років буде питання звучати так:
А чи потрібне С в ядрі Лінукса?

Раст можно опустить на уровень ассемблера, при этом он остается по прежнему высокоуровневым языком, средства которого активно юзают там, где раньше доминировал старичок Си. Даже без стандартной библиотеки у Раста остаётся система типов, которая позволяет минимизировать количество ошибок, возникающих из-за человеческого фактора. И это одна из главных причин, по которой Раст включили в ядро Линукса. Кроме этого также не стоит забывать, что язык Си позволяет полностью отказаться от возможностей стандартной библиотеки. Кроме Си, таким свойством, как абсолютной независимостью от библиотечного кода, также иногда называемым zero runtime => обладают на сегодняшний день только языки ассемблеров; ни один из современных языко высокого уровня к моему глубокому сожалению не предоставляет такой возможности.

навіщо ти тягнеш цитати з хабра, при цьому ще й спотворюєш їх зміст?

Нам преподаватель это на 122-ой рассказывал, а с хабра он брал или с других мест я не знаю хлопцы, это вопросы к нему уже. Описал как мог, я не на филологическом учусь, сорян. Про zero runtime я прочитал тут, такого понятия я не встречал ранее поэтому вот ссылочка, там еще много чего интересного есть, а именно в www.stolyarov.info/...​ks/pdf/progintro_vol2.pdf Хлопцы если вас задевают, что мы студики вас подпираем, ну так это такое....

Этому преподавателю вполне квалифицированно ответили... о том, что он много где не прав, точнее почти нигде.

Rust должен умереть, МГУ сделал замеры
habr.com/ru/post/598219

МГУ сделал замеры

тільки там про школоло з МГУ

Rust должен умереть

Хіба після Лінукса (не Торвальдса) і краха долара США
www.phoronix.com/...​or-Linux-6.1-Pull-Request

Возможно вы имели в виду Rust Zero cost? Например, у нас есть трейт (interface) и функция, которая использует этот трейт в качестве входных данных, но разница в том, что когда rust компилируется, вызов метода трейта становится статическим. Диспетчеризация с использованием метода, называемого «мономорфизация», что в основном означает, что для каждого блока имплементации трейтов компилятор rust будет генерировать отдельную версию функции, которая получает тип в качестве параметра, если у нас есть другие реализации, он также будет генерировать другие функции. Затем компилятор Rust заменяет все вызовы трейт-методов вызовами этих сгенерированных функций, и таким образом трейты используют меньше памяти, становясь такими же по использованию памяти, как и функции. Абстракции с «нулевым» использованием памяти являются основной ценностью языка Rust, и знание того, что они из себя представляют и как они работают, очень помогает в разработке на этом языке.

Zero cost тоже есть.
Я имел ввиду, что Раст в теории можно запустить на голом железе без операционной системы, и без стандартной библиотеки.

Опыт использования Rust в компании Volvo Cars

medium.com/...​-in-your-car-4320bd639e09

Можно считать это очередным “признанием” ??
Rust Features that I Want in C++ — David Sankel — CppNow 2022
www.youtube.com/...​tch?v=cWSh4ZxAr7E&t=2461s

Linus Torvalds: Rust may make it into the next Linux kernel after all

At Open Source Summit Europe, Linus Torvalds announced that he would push to get Rust into the forthcoming 6.1 Linux kernel that same day.

The Rust programming language has already become Linux’s de facto second Linux language. It has several advantages over C, Linux’s root language. The biggest of these is it’s much better at memory security than C is. Managing C memory problems is a never-ending task for developers.

Torvalds also told me in our interview that another reason he wants to see Rust in the kernel is to encourage new developers to start working on the kernel. “Rust is one of those things that I think might bring in new faces,” he said, and, “We’re getting old and gray.”

Rust eraser, це якби «убивця раста».

Еще может быть в смысле Rust, Eraser, в смысле «Раст, чистильщик» — зачищает c++ другие неугодные языки.

Minecraft сервер, написаный на Rust, работает в 10000 раз 🚀 быстрее 🚀 , чем vanilla Minecraft сервер

Pinecone переписали с C/C++ на Rust и получили десятикратное увеличение быстродействия 🚀

Ну, трохи не так,

Pinecone переписали с C/C++ на Rust

а так

Pinecone was built with a mix of C/C++ and Python.

Думаю приріст 10х за рахунок «вичавлювання удава»

я завжди казав що го це головних конкурент пхп ( і це не наїзд)

Ну так вайрінг же, в кожній школі світу у STEM лабораторії, є хоча б одна плата ардуіно, на якій блимають за допомогою вайрінгу.

www.reddit.com/...​_being_amazing_yet_again

I rewrote a program in Python to Rust, because I couldn’t reasonably deploy it on Windows, and the Rust version ended up 60x faster and just worked on any OS despite quite a few dependencies.

Blazingly fast 🚀

JIT компилятор Ruby переписывают с C99 на Rust

Value proposition:

* Rust type systems will catch more bugs early, help prevent new bugs
* Easier to manage growing complexity of YJIT
* Easier to maintain codebase, fewer „footguns”
* Easier for newcomers because the compiler catches more bugs
* Better performance because we can implement more sophisticated optimizations
* Easier to add support for new platforms (which adds complexity)
* Rust has mature and easy-to-install tools such as source code formatter and editor plugins
* Rust as a programming language community has a great deal of enthusiasm behind it. This could translate to more enthusiasm for YJIT and for Ruby as well.

чудова новина, бо складається враження, що Rust тільки крипта

Rust — «отличный» язык программирования для мазохистов — www.rustmustdie.com . Поэтому рекомендую всем адекватным людям учить язык будущего — Go — dou.ua/forums/topic/16012

Я тебе так скажу, адекватные люди не тянут говно с рашкопомоек на ДОУ :)

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

Там, где компилятор не должен генерировать никакого кода вообще (так как функции тривиальны и должны быть оптимизированы до noop), он нашел целых 4300 инструкций на Rust и 20 на C.

rust.godbolt.org/z/KKWYqebMd
godbolt.org/z/ssT3W9fsj

Это намекает на то, что автор статьи не знаком с такими понятиями как сборка debug/release и дальше обсуждать нечего.

Автор неумелой статьи просто студент... под руководством профессора. Развожу руки...
Из его примера, где он «не сумел» в конце статьи, rust.godbolt.org/z/Pxv7Man5h

"Явное определение типа в Rust принято использовать, только если автоматическое так или иначе не справляется — как следствие, необходимо знать, понимать и помнить правила вывода типа, которые невероятно сложны, в силу чего задача определения, может ли тип быть выведен и какой тип будет выведен, также сложна."©

Если это правда, то это зашквар. Прелесть низкоуровневого Си что ты можешь играться и контролировать типы как хочешь. Вплоть до битов. А также кастить блоки памяти в любые нужные тебе типы, что является очень полезным низкоуровневым трюком

кастить блоки памяти в любые нужные тебе типы, что является очень

UB

Нема никакого UB. Типичный паттерн — нужен пулл мелких объектов в промышленных количествах. Например рендер движок, браузер, контейнер объектов произвольной длины и тд. Ты пишешь буквально 500 строк инкапсулированого кода, покрываешь его вдоль и поперек тестами и вуаля, багов ноль целых ноль десятых.

Если это правда

Ты думаешь, что чувак, который учится на программиста в МГУ будет врать?

, то это зашквар.

Это не зашквар, это стандартная фича, которая есть во всех нормальных современных языках программирвоания.

* docs.microsoft.com/...​ge-reference/keywords/var
* docs.oracle.com/...​iable-type-inference.html
* docs.microsoft.com/...​pp/auto-cpp?view=msvc-170
* go.dev/tour/basics/14

Прелесть низкоуровневого Си что ты можешь играться и контролировать типы как хочешь.

Прикинь, в Rust ты точно так же можешь контролировать типы. Кроме того, в Rust запилены нормальные обертки, которые позволяют делать это безопасно без ущерба перформансу типа docs.rs/...​te/latest/safe_transmute или github.com/...​ng/project-safe-transmute без необходимости писать unsafe.

А также кастить блоки памяти в любые нужные тебе типы, что является очень полезным низкоуровневым трюком

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

Ты думаешь, что чувак, который учится на программиста в МГУ будет врать?

Такие статьи и должен писать человек с незамыленным взглядом. Если кто-то в это дерьмецо окунулся и успел поварится лет пять, то там уже будет скорей стокгольмский синдром, а не обьективный взгляд.
Статья мне вполне понравилась, многие мысли интересны.

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

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

Ок, вот тебе самый простой пример. Отправитель отправляет буфер данных по сети. Получатель принимает буфер данных по сети. Отправитель отправлял обьект по сети, получатель принимает объект по сети. Типичное сетевое взаимодействие пакетами данных. В Си ты просто приводишь буфер к нужному объекту и вуаля. Ты сериализировал и десериалиазировал объект моментально.
Как это предлагается делать адептам раста ? Парсить джисон ?
Подозреваю есть лазейка делать через unsafe. Потому что это очень ходовой сценарий для низкоуровневого языка.

В Си ты просто приводишь буфер к нужному объекту и вуаля. Ты сериализировал и десериалиазировал объект моментально.

UB на невыровненном доступе + buffer overrun vulnerability на большинстве сетевых протоколов + баги из-за того, что кто-то не знает, что бывают такие вещи как BigEndian/LittleEndian.

Как это предлагается делать адептам раста ? Парсить джисон ?

Можешь для примера посмотреть github.com/...​b/master/src/wire/ipv4.rs

UB на невыровненном доступе + buffer overrun vulnerability

Проверить размер буфера перед тем как читать. Это не сложно.

что бывают такие вещи как BigEndian/LittleEndian.

Низкоуровневое программирование подразумевает написание кода с привязкой к архитектуре. Чтобы педалить под все в мире кофеварки есть джава.

Можешь для примера посмотреть github.com/...​b/master/src/wire/ipv4.rs

Посмотрел, почему это должно работать быстрее чем на Си не увидел.
Аргумент с UB это вообще не аргумент. Такой код микролибы отлаживается на Си на раз два.

Низкоуровневое программирование подразумевает написание кода с привязкой к архитектуре.

=>

как только ты выходишь за пределы единственной программы запускаемой единственно на твоём компе где она же ж и компилировалась отлаживалась писалась так сразу всё )) это не «сценарий низкоуровневого языка» это скорее «сценарий узкой архитектуры» и обойти его нельзя на столько что в общем смысле даже существуют раздельные порядки байтов сетевой и локально платформенный и это ещё и на низкоуровневом сетевом уровне чистого айпи и ethernet протокола ниже уже только физика ничего личного
Низкоуровневое программирование подразумевает написание кода с привязкой к архитектуре.

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

Ты, судя по всему не осилил писать кросс-платформенный код, но это не значит, что другие тоже не осилили.

Аргумент с UB это вообще не аргумент. Такой код микролибы отлаживается на Си на раз два.

Можешь объяснить своими словами что такое неопределенное поведение?

Ты, судя по всему не осилил писать кросс-платформенный код, но это не значит, что другие тоже не осилили.

Ну ты смешон. Сегодня я буду отлаживать код, который позволяет однажды написанное приложение под вин формы запустить как веб приложение, без модификаций. А однажды написаное приложение на вебформах, запустить как винформы. Линукс-Виндовс — не имеет никакого значения.
А майндсет растовода под кросплатформенным кодом подразумевают учитывание BigEndian/LittleEndian ? Чтобы путем обрушения перформанца и раздутия своего кода в два раза поддержать вот тот дедушкин альтаир ? Ну удачи.

Можешь объяснить своими словами что такое неопределенное поведение?

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

когда например вышли за диапазоны массивов

нет конечно просто потому что «в низкоуровневом коде» ни каких «диапазонов массивов» то и нет и соотв. и «выходить» не куда

другое дело скажем массив это фактически указатель и часто формально тоже но дальше начинается интересное когда можно взять 2 элемента массива и между собой сравнить кто раньше кто позже чисто адресная арифметика и даже можно сравнить что они равны как 2 указателя и соотв. это один и тот же ж элемент массива но вот если взять специально значение «нулевой указатель» то тут всё не так однозначно потому что с ним получается можно сравнить только на равенство «больше меньше» уже нельзя и результат такого сравнения будет формально не определённым

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

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

ЗЫ: другое дело когда ты взялся писать в эту память в одну и ту же ж с 2+ потоков сразу вот тут да вот тут результат операции не определён

«неопределенное» — это Undefined а не Unexpected. Unexpected — это «неожиданное» и ничего неожиданного в UB нет, разве что для неосиляторов, которые не прочитали спецификацию языка, на котором пишут.

В Си ты просто приводишь буфер к нужному объекту и вуаля.

та мы уже поняли, что на твоем 32битном пентиуме локально все работает))

Я все ещё подозреваю что 95% низкоуровневого кода написано на Си/Си++ и других языках с трюками по памяти. Сколько написано сетевых протоколов на Раст у меня нет информации. Поэтому это вопрос риторический у кого что локально работает

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

В Си ты просто приводишь буфер к нужному объекту и вуаля. Ты сериализировал и десериалиазировал объект моментально.

нет конечно эта фича с «бинарно сериализированными объектами» таки реально используется среди прочих игровой механикой в т.ч. в виде хранимом на диске но отсюда же ж известна её строгая не совместимость ни с чем кроме себя самого скажем писишная виндовая игра умеет играть по сети только сама с собой ну селяви

а ну и да даже мультимедийный контент самой игры поставляемый вместе с игрой при таком раскладе «платформенно уникальный» ))

ЗЫ: и ещё это то самое больное место за которое сейчас то ли дерутся то ли плачутся то ли вообще минимум половина «плюсовиков» которое проходит под секретным кодом abi breaking

Потому что это очень ходовой сценарий для низкоуровневого языка.

как только ты выходишь за пределы единственной программы запускаемой единственно на твоём компе где она же ж и компилировалась отлаживалась писалась так сразу всё )) это не «сценарий низкоуровневого языка» это скорее «сценарий узкой архитектуры» и обойти его нельзя на столько что в общем смысле даже существуют раздельные порядки байтов сетевой и локально платформенный и это ещё и на низкоуровневом сетевом уровне чистого айпи и ethernet протокола ниже уже только физика ничего личного

В си нет объектов

Есть, разумеется. Инстанcы структур.

Это не объекты. Инкапсуляция? Наследование (ну это с натяжкой можно сделать). Полиморфизм? — разве что через эмуляцию VMT руками

Наследование/полиморфизм — это не фича, а баг. Инкапсуляция во многих ООП-языках не поддерживается (например, пайтон).

Объекты, как некая сущность с релевантными данными/полями — это инстанс си-структуры и есть.

Ну тогда что угодно это объект

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

Это структура, а не объект. Объект- данные + поведение.

Объект- данные + поведение.

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

Понятно, что в низкоуровневом языке (си) можно эмулировать так или иначе все фичи высокоуровневых: объекты или классы через ручную таблицу виртуальных методов или цепочку прототипов, замыкания через структуры и указатели на функции, функции высшего порядка через замыкания, сборку мусора и другое.

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

Так вот примерно то же самое и с объектами

Понятно, что в низкоуровневом языке (си) можно эмулировать так или иначе все фичи высокоуровневых

О том и речь. Собственно, так и писались крупные сложные вещи (к примеру, ядро Линукса или винда).
И это вполне себе объектноориентированная декомпозиция системы — и соответственно, ОО-код.

В расте тоже можно, в ансейф коде

Понимаю, что занимаюсь некропостингом, но добавлю пару мыслей.

— Писал на расте юай (кроссплатформа десктоп), клиент для одного АПИ, причем юай с многопоточностью и асинхронностью. Использовал iced-rs. Было сложно разбираться с асинхронностью и многопоточностью, борроу чекер относительно безболезненно освоил. Конечно, бесконечные полотна Arc<Mutex<Option<...>>> выглядят не очень, пару раз словил дедлок, но вроде разобрался.

— Замыкания, особенно в связи с асинхронностью и многопоточностью, намного сложнее заимствования. Подход современного С++ намного нагляднее (где нужно указывать, как именно захватывается каждая переменная).

— Собрал аппликуху для мака и винды вообще с полпинка, для линукса пришлось поставить кучу библиотек. Но в итоге все собралось и заработало. Экосистема Раста очень удобная и современная.

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

— Борясь с предупреждениями компилятора, осознал, что Раст не дает совершать целый класс ошибок, особенно с многопоточностью. Понимаю, что куча многопоточного кода, написанного мной на сишарпе, было с ошибками.

— Хочу попробовать написать апишку на расте, и попробовать использовать его вместо .нет на беке. Вроде бы базовые вещи для этого есть (веб-сервер, ОРМ, логгеры, драйвера баз и редиса). Вообще, думаю, Раст взлетит в вебе (WASM) и, возможно, как быстрая альтернатива C# в энтерпрайзе (это, конечно, осложняется большей сложностью языка). В Go для этого слишком слабая система типов.

— Достаточно удобные юнит тесты, прямо в кодовой базе, встроенными средствами языка

бесконечные полотна Arc<Mutex<Option<...>>>

Arc<Mutex<Option<....>>>> — это практически писать на Java, но с синтаксисом Rust.

В самом iced-rs Mutex не используется ни разу (в т.ч. в примерах). Без него никак нельзя было обойтись?

В юай части мьютексов нет.
Приложение в фоне взаимодействует с сетью и файловой системой, это все крутится в потоках, и там все или на мьютексах, или на каналах.

бесконечные полотна Arc<Mutex<Option<...>>>

Коли дивився якийся туторіал, також це вишибало.
Відповідно, питання до більш досвідчених товаришів — а ці штуки не можна якось загорнути у typedef?
Ці типи і так параметризовані однаково у всій програмі, най живуть десь окремо, а ти собі тільки пишеш record_ptr і все

Та можно конечно
type ArcOption<T> = Arc<Mutex<Option<T>>>; 

Тут больше неудобство это клонировать и лочить.

Завернуть можно, но если у тебя столько этихArc<Mutex<Option<...>>> в коде, что хочется их куда-то заворачивать, может быть смысл потратить время на изучение более идиоматических подходов к проектированию приложения в расте и попытаться найти подходы, которые не требуют заворачивания всего в мьютексы.

Обычно приходят к Arc<Mutex<Option<...>>> после нескольких неудачных попыток использовать классические подходы (которые работали, скажем, в Java или C#), где все — ссылочный тип, который можно передать куда угодно в любоых количествах.

1)
— Как передать ссылку на объект куда-то?
— Ну вот используй reference (&MyType)
— О, збс... подожди, что-то оно мне тут про лайфтаймы начинает говорить. Как пофиксить?
— Давай я тебе про лайфтаймы расскажу
— Да я сам тебе могу тоже рассказать, ты лучше скажи как пофиксить?
— Короче закидывай все в RcArc, будет збс.
— О, збс.

2)
— Подожди, какого фига я не могу ничего в Arc изменять?
— Ну Arc дает тебе только shared reference, его нельзя менять
— Шо за нах? Может через unsafe получится?
— Нет, не получится. Блин если хочешь менять тебе прийдется еще и в RefCellMutex засунуть.
— Шо? Нафига мне мьютекс?
— Ты попробуй
— О, збс

3)
— Слушай я не пойму, он мне что-то жалуется что данные внутри мьютекса не инициализированы
— Ага, в Rust нельзя обращаться к неинициализированным данным
— И что мне делать?
— Ну вообще сделай так, чтоб когда мьютекс создавался, данные тоже инициализирвались
— Не могу, мьютекс создается в один момент, данные инициавлизируются в другой момент
— Ну тогда закинь туда еще Option, он по дефолту None.
— Ок, збс. Почти как в Java, теперь можно нормально писать.

Ответа на вопрос «что использовать вместо этой хрени» у меня нет, потому что если ты забрел в ситуацию, где тебе нужен Arc<Mutex<Option<...>>>, то кроме него ничего скорее всего не заработает, тебе нужно будет идти много шагов назад и переделывать архитектуру так, чтоб она нормально ложилась на идиоматические конструкции Rust.

Ну хорошо хоть в однопоточных приложениях это не нужно.

Вообще помимо мьютекса я знаю еще
— RwLock — то же самое, но не блокирует чтение из нескольких потоков
— atomic — атомарные конструкции для простых типов данных
— каналы — ну это другое, и под них действительно нужно переделывать архитектуру
— Unsafe Send or Sync — ну это убирает гарантии отсутствия data race, нафиг надо

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

Команда хромиум-а из гугл думает как избавиться от 70% багов по памяти из-за указателей. Есть три варианта.

1. Сделать с++ безопаснее в compile time, который не подходит, т.к. ЯП для этого не был спроектирован и не разработан изначально.
2. Сделать работу с ссылками безопаснее в run-time, что не покроет все баги и даст определённое ухудшение производительности.
3. Подключить раст и сделать между ними (с++ и раст-ом) взаимодействие/interop.

Остановились пока на вариантах 2) и 3).

Last year, we showed that more than 70% of our severe security bugs are memory safety problems. That is, mistakes with pointers in the C or C++ languages which cause memory to be misinterpreted.....

...That’s why we’re pursuing both strategies in parallel. Watch this space for updates on our adventures in 2. making C++ safer, and 3. efforts to experiment with a new language in Chrome.

security.googleblog.com/...​ory-safety-in-chrome.html

по улице шёл 21-й год 21-го века смартпоинтеры raii подсчёт ссылок и вообще вот это всё ещё не изобрели мыши продолжали мучиться кривыми руками совая в дырку кактус

Тупой Гугл, ну что я могу сделать ??

Что меня поражает в С++. Судя по рекламным брошуркам, там в любой момент есть все необходимое для написание безопасного кода и нет никаких проблем (ну разве что кроме стопицот edge case где есть проблемы), но раз в 2 итерации в новый стандарт добавляют очередной смарт поинтер, который уже вот кровь с носу опять решает все проблемы once and for all, но почему-то его никто не использует.

(ну разве что кроме стопицот edge case где есть проблемы)

я начал сильно обращать внимание как «плюсовый комюнити» сильно аццки просто зациклен на этих UB и corner cases и если начать присматриваться то видна какая-то кучка задротов простите с прямо отрицательной пользой дающей выхлоп в трубу вроде "что произойдёт если сделать

int x, y;

auto f = [&x, &y] { return x + y; };

auto[x1, y1] = f;

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

www.linkedin.com/...​-6809383833146839040-fszr

а сишечка с плюсами толкутся где-то в очень странном месте где

understanding template type deduction
но почему-то его никто не использует.

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

dou.ua/forums/topic/32515

Как раз таки в Хром(иум)е изобрели и смартпоинтеры, и треды, и много чего еще... только заново :) То есть всё это кастомное, а не из стандарта C++

Циклические зависимости, адовый 20-летний легаси, и наверняка никто уже не знает почему он так работает, и откуда повыпадают костыли если вот тут вот что-то изменить.
При этом у меня на рабочем лептопе хромик живет уже несколько месяцев без перезапуска.

Послушал доклад основного мейнтейнера по добавлению Rust в Linux kernel, которого нанял гугл за зарплату.

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

TLDR;
Осталось убедить основных Си мейнтейнеров, что все готово и можно начинать, заносить это все в основную ветку.
Как он это собирается делать, он не сказал, наверное просто ждёт «консенсуса и одобрямса».

С начале он рассказывает, что такое UB, почему safe rust — это хорошо (отсутствие ub). Там же показывает небольшую диаграмму взаимодействия Rust кода с си ядром/либами (без деталей), про то какие самые необходимые крейты были запилены. Что другую часть взаимодействия планируется делать через механизмы bindgen/ffi.

youtu.be/VlSkZYBeK8Q

он рассказывает, что такое UB, почему safe rust — это хорошо (отсутствие ub).

#totalfacepalm

examples of ub
int f(int a, int b) {
    return a / b;
}

f (INT_MIN, -1);

не знаю правда зачем так загадочно достаточно сделать

int i = INT_MIN / -1;

но зачем так делать? и при чём тут си?

ЗЫ: он потом ещё рассказывает что деление на 0 тоже UB

ділення на нуль має в результаті видавати число гуггл,
причому, якщо позитивне число, на плюс нуль або негативне на мінус нуль, то позитивний гугль,
інакше негативний гугль,
а от ділення 0 на 0, незалежно від знаковості і є UB

интересно что по этому поводу думает IEEE 754 и при чём тут собственно UB C

ЗЫ: а стоп это даже не Floating-Point Arithmetic это целочисленная арифметика в процессоре т.е. претензия к сишечке что она не имеет собственного калькулятора и кидает всё напрямую на CPU ALU а ну ок

Division by zero: an operation on finite operands gives an exact infinite result, e.g., 1/0 or log(0). By default, returns ±infinity.

про 0/0 ніц

it’s supposed to be infinity++

:)
по ідеї, мало би повертати множину чисел ( в залежності від типу операції, напр. чилочисленне знакове/безнакове ділення, тоді множина натуральних/цілих )

Если брать Linux Kernel, то... Rust видится мне достаточно высокоуровневым и заставляющим мыслить высокоуровневыми абстракциями (std::collections). Если брать Си, то там никаких коллекций нету, и в ядре достаточно распространены двунаправленные циклические списки и буфера. И тут вопрос, как эти списки представить в Rust? Основная то концепция, что на изменяемый объект указывает один указатель. А тут на каждый объект указывает два указателя, один из следующего, другой из предыдущего :) И это только беглый взгляд.

Моя чуйка, что надо писать операционную систему на Rust. С прицелом использовать части Linux на уровне ABI или как-то ещё. Это будет дешевле, чем впихать невпихуемое.

Если брать Linux Kernel, то... Rust видится мне достаточно высокоуровневым и заставляющим мыслить высокоуровневыми абстракциями (std::collections).

В Rust есть стандартные коллекции, но использовать их вы не обязаны.

И тут вопрос, как эти списки представить в Rust?

rust-unofficial.github.io/too-many-lists

Моя чуйка, что надо писать операционную систему на Rust.

www.redox-os.org

Это будет дешевле, чем впихать невпихуемое.

Подмножество Rust (nostd) вполне себе впихуемое.

В Rust есть стандартные коллекции, но использовать их вы не обязаны.

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

rust-unofficial.github.io/too-many-lists

Ну... там во многом теряются все преимущества, много оверхида, unsafe. Небольшая иллюстрация, переходи по ссылке из твоей ссылки на
github.com/...​ollections/linked_list.rs
как-то многовато кода..

#[inline]
unsafe fn unlink_node(&mut self, mut node: NonNull<Node<T>>) 
если у тебя двусвязный циклический список, то зачем нам тут self? Чтобы удалиться из него надо просто сделать два присваивания:
struct dlist
{
    struct dlist *next;
    struct dlist *prev;
};

static inline void dlist_remove(struct dlist *item)
{
    item->prev->next = item->next;
    item->next->prev = item->prev;
}

Так что выглядит больше как реализация чего-то отдалённо напоминающего и монстроидального.

www.redox-os.org

Я ж на это и намекаю...

Подмножество Rust (nostd) вполне себе впихуемое.

Для интеграции с Си... Не уверен.

Но если у тебя есть молоток, ты везде видишь гвозди.

Зависит от уровня профессионализма.

Ну... там во многом теряются все преимущества, много оверхида, unsafe.

Структура может содержать unsafe код внутри и предоставлять safe API наружу. Что, кстати, и сделано по сслыке, которую вы привели. Большинство внутренних контейнеров Rust содержат внутри небезопасный код, так как иначе их не реализовать.

если у тебя двусвязный циклический список, то зачем нам тут self?

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

Я книгу не читал, но могу дать одно банальное объяснение — для того чтоб семантически показать пользователю, что этот метод модифицирует содержимое связного списка, поэтому нужно владеть иметь экслюзивной ссылкой на него (&mut self), даже если эта ссылка не используется внутри метода.

Более того, эта функция приватная и не торчит наружу. Вам нужно смотреть где она используется и откуда берется ссылка на self, тогда может быть понятнее почему реализация такая.

если у тебя двусвязный циклический список... Чтобы удалиться из него надо просто сделать два присваивания:

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

Так что выглядит больше как реализация чего-то отдалённо напоминающего и монстроидального.

imgur.com/a/XFyWbHG

Для интеграции с Си... Не уверен.

В чем именно вы не уверены? В Rust zero cost интеграция с C, интеграция с внешний кодом (не обязательно С) это один из основных юз кейсов Rust.

Я книгу не читал, но могу дать одно банальное объяснение — для того чтоб семантически показать пользователю, что этот метод модифицирует содержимое связного списка, поэтому нужно владеть иметь экслюзивной ссылкой на него (&mut self),

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

навіщо писати щось так, що погано лягає на парадигму Rust?
може міняти концепцію роботи з буферами?

Во-первых, этот код уже написан, если мы говорим о Linux kernel. И с которым надо как-то работать, Linux Kernel таки монолит, и ABI часто размыто.

Во-вторых, возникает вопрос сравнения производительности двух решений. Можно писать в стиле Rust, но тогда вопрос о том, сколько это будет стоить?

Поэтому я больше сторонник того, чтобы развивать redox-os, писать на Rust и в его парадигме от и до.

коштувати буде 0 перформансу і +100500 в рості сайфті
мікромоноліт, так що модулі, що підключаються можна і на Rust
і не забуваєм про 100500 SoC, яких буде ще на порядки більше з часом

коштувати буде 0 перформансу і +100500 в рості сайфті

Ну... допустим код использует такую либу:

struct dlist
{
    struct dlist *next;
    struct dlist *prev;
};

static inline void dlist_init(struct dlist *me)
{
    me->next = me;
    me->prev = me;
}

static inline void dlist_insert_after(struct dlist *prev, struct dlist *infant)
{
    struct dlist * next = prev->next;
    infant->next = next;
    infant->prev = prev;
    next->prev = infant;
    prev->next = infant;
};

static inline void dlist_insert_before(struct dlist *next, struct dlist *infant)
{
    dlist_insert_after(next->prev, infant);
}

static inline void dlist_remove(struct dlist *item)
{
    item->prev->next = item->next;
    item->next->prev = item->prev;
}

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

прийдеться передизайнити, так як двозв"язаний список із вказівниками, думаю, що це не той концепт що бачить Rust

тобто шаблон мислення С/С++ такий — а давай натягнем сову на глобус (будем робити unsafe Rust ніби в С/С++. Хочете відстрілювати ноги, то навіщо вам Rust, який тільки заважатиме стріляти по ногам).

прийдеться передизайнити

Мені не зрозуміло,чому ти тоді впевнений, що після редизайну не буде мінус перформанс.

якщо перформанс на першому місці, то питань нема,
тоді патчити і супортити...

Какой будет эквивалент на Rust?

так написано же ж весь грязный код заметут под капот под плинтус unsafe с понтом пишет на руст а на самом деле там чисто сишечка а внутре у ней неонка и думатель (к) (тм)

майже так, але тільки для «непортабельних конструкцій»

Ну... допустим код использует такую либу:

В чем смысл этой либы? Есть какая-то документация на нее и примеры использования? По беглому взгляду выглядит как связный список ради связного списка.

Какой будет эквивалент на Rust?

На Rust можно написать эквивалентный код, который будет иметь такой же layout в памяти и работать точно так же, буквально даже с точно такими же инструкциями. В Rust есть нативные поинтеры.

Поэтому я больше сторонник того, чтобы развивать redox-os, писать на Rust и в его парадигме от и до.

www.youtube.com/watch?v=WCIKxVe4_Xw

надибав таку книгу:
„Hands-On Microservices with Rust”,
може кому пригодиться
books.google.com.ua/books?id=cGSGDwAAQBAJ

статєйка з медіума:
medium.com/...​ble-language-2248b839bee3

Recently, Rust’s decision to enter the Linux kernel has officially been put on the table. Last week, its kernel developer Miguel Ojeda submitted an RFC to add Rust support to the Linux kernel, which caused heated discussion.
Regarding this matter, many people naturally want to know the views of Linus Torvalds, the father of Linux. After all, this is the first time that Linux has added a second programming language other than C to its kernel in so many years. Therefore, the foreign media IT Wire interviewed Linus on this issue.
At first, he was more „reserved”, but rather officially responded that the Linux kernel’s support for Rust is still in the early stage, and the relevant patches may not be merged until the 5.14 version.
But after knowing that some developers thought that „C++ should be used instead of Rust”, Linus’s „temper” finally couldn’t hide.
He laughed and sarcastically said: „C++ is such a bad language!”

Дык, вроде попробовали уже. Раст, в силу особенностей реализации (exit(), в случае проблем) — вызывал кернeл-паник. Линус на основании этого раст, разумеется, забанил — до тех пор, пока проблемы не будут решены. Хипстеры-растеры не смогли дать никаких прогнозов по времени, сколько им нужно будте на решение.

В общем, эпик-фейл.

не «епік-фейл», а «пєрвий блін комом»
претензія тільки була до exit() а не до мови в цілому, як у випадку ЦеПеПе

а не до мови в цілому, як у випадку ЦеПеПе

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

не плюси, бо там без надії, а в Rust все ж світло в тунелі

Почему стоит изучать язык программирования rust, где используется, кем поддерживается, какие перспективы и сложности обучения...
Приятного просмотра 👉 youtu.be/2F1eMHtWkmk
Rust — это космос !😄

Apple ищет Rust разраба. С чего бы им такой фигней страдать ?? Си-плюсали, Swift-или бы дальше....

Найдено через LinkedIn
www.linkedin.com/...​ivity:6833485885263233024
Ссылка на вакансию.
jobs.apple.com/...​-information-intelligence

якщо бути точним, то AI/ML- Software Engineer (щоб хоча би міг уживати АІ так, щоб відрізняв той людей від макак)

Итак... 6-й год подряд, Rust назван наиболее любимым языком на SO.
insights.stackoverflow.com/...​-loved-dreaded-and-wanted

Дисней ищет на Rust в подразделение Disney Streaming Services.
jobs.disneycareers.com/...​ngineer-rust/391/19608511

вже знайли, мабуть
We’re sorry, this job is no longer available.

Команда Fuchsia расширяется.
Rust on Fuchsia is hiring! We’re looking for folks who want to help other developers succeed as we use Rust to build a modern OS.
В комментах — кого ищут.

twitter.com/...​tatus/1420791631041552387

Они то расширяются от сужаются, выцепить открытую вакансию тем более на Rust было нереально.

Ищем Rust разроботчиков jobs.dou.ua/...​/qdrant/vacancies/173375
Странно, что до сих пор нет категории Rust в каталоге поиска работы на Doa, приходится использовать C++ 🤦

Почему такой большой разброс по зарплате...3000$-8000$ ?

И на самоме деле вилка услвная. Главное что бы человек был хороший;)

We are looking for a senior rust developer

Це скільки, легендарних 10000 год.?

Ваша правда, будем исправлять. Имеется в виду Senior Developer with Rust knowldegde. No commercial experience required.

Отличная вакансия, интересный продукт! В поиске с заголовком rust она прекрасно видна. Удачи в поиске, все получится.

Спасибо. На самом деле отклики есть уже. Ищем кого-то с опытом, кто поможет натянуть проект на Raft.

Ищем Rust разроботчиков jobs.dou.ua/...​/qdrant/vacancies/173375

«Поисковый енджин» на расте, вместо C или накрайняк C++?

Вижу в этом лишь желание освоить новый ЯП, на оплаченном чужими (инвестора) деньгами проекте. Других преимуществ от использования раста не вижу, а недостатков полно.

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

от звідси можна поподробніше, друг цікавиться

от звідси можна поподробніше, друг цікавиться

Быстродействие — ниже.
Специалистов — меньше и с меньшим опытом (в основном, неопытные хипстеры с «горящими глазами»).
Наружу летят системные эксэспшены (из-за которых забракован Линусом).
Интеграция с другими ЯП — проблематичнее.

А в чём плюсы? 1) Хайповый язык с 2) «сэйфети», которая в энджине/АПИ реализуется без проблем и без растов.

«Поисковый енджин» на расте, вместо C или накрайняк C++?

поняв, сефеті в С найкраняк С++ лутшє

«memory safety» в энджинах/апи — реализуется с полпинка.

1. Это т.н. «новость будущего времени». Не самая лучшая вещь, для ориентации при принятии решения.

Известна и похожая «новость прошлого времени» — драйвер, уже написанный для линуксового кернела хипстерами на расте и забракованный Линусом. При этом, без обещаний даже приблизительных сроков — когда мешающие проблемы раста будут пофиксены.

2. Лично мои впечатления от статьи — «когда коту нечем заняться, он...» занимается более полезным делом.
Чем переписывание модуля, беспроблемно работающего уже лет 15 — с использованием какой-то новой хипстерщины.

3. В статье куча безмозглых хайп-утверждений. Включая даже легко-проверяемые фактические ошибки. Например:
«Аpache HTTP web server is today’s top web server technology, used today by 34.9% of all the websites whose web server technology is known» — притом, что даже по приведенной ссылке ясно видно, что 1) на первом месте Nginx (с долей 34%) 2) Апачи лишь на втором месте, с долей не 34.9%, а 32.2%"

В общем, не — не убедило.

www.zdnet.com/...​in-almost-every-category
OpenSSL такий опен, швидкий, сейфті, не те що Rust

И где она используется? Статья 19-го года — а с тех пор о об этой библиотеке ни слуху, ни духу.
Пукнули в лужу, и пропали.

У «стартапера» выше — статья от 2021-го года, где о ТЛС модуле на расте говорится так: «The ISRG says it plans to develop a new module called mod_tls that will do the same thing but using the Rust programming language rather than C.»

Ну если радуют UB, неизведанные крэши и вообще хочется хардкора за чужие деньги, то C++ — безусловно идеальный выбор для нового проекта.
Если хочется быстродействия уровня C/C++, современной экосистемы, async/await, то Rust.

Странно, что до сих пор нет категории Rust

Добавили:
jobs.dou.ua/vacancies/?category=Rust

Вот это я понимаю customer driven product development, причем на выходных. Моё уважение. 🙏

Тепер, коли Rust визнали на DOU, вакансій має стати більше, буду слідкувати за трендами Rust

так, і як завжди, шукатимуть сейнорів, із продвинутим Rust, та мінімум, 2 роки досіду, «так щоби потягнув проекти», і всього-навсього на $5K і щоб мав також кілька років досвіду у вебі/ембедед/АІ/ML (не потрібне закреслим)

Щось на кшталт:
"Для серйозних стосунків шукаю молодого чоловіка до 35 років, красивого, розумного, не лисого, без пивного пуза, без шкідливиз звичок, фінансово забезпеченого, з власним житлом, вище середнього зросту, спортивної зовнішості, не обтяженого сімейними узами ні тепер ні в минулому, щоб міг потягнути нову сім"ю.

Коротко про себе: 30 років, розведена, маю двох дітей, бодіпозитивна, тимчасово не працюю"

тренд такий, що крипта здулася, так що криптошизіків що носяться з Rust має поменшати.

Чего сдулась, у нас два новых проекта зашло, людей тоже ищут, там ещё хотят опыт разработки solidity...

до чого тут це відео?
яке відношення криптографії до Solodity і яким боком Rust до Solodity

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

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

Откуда такие фантазии? Блокчейн вполне может быть централизованным — если блоки генерирует один эмитент (которому и принадлежит блокчейн).

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

змішалися в кучу коні, люди... раст, солідіті, блокчейн, уаутентифікація

просто додай блокчейн (к) (тм)

www.youtube.com/...​mxu1Q&ab_channel=oleganza

Особенно в этих бреднях — понравилась страница «Почему Раст?» и один из ответов «стандарты качества от веб-разработчиков».

Стандарты качества от «веб-макак», не смогших в нормальную высокооплачиваемую разработку — это, конечно, сила. :)

P.S. А что там в традиционной криптографии «ансэйф» — что понадобился раст?

Зачем платить выше рынка — если можно переписать всё на жабоскрипте у индусов за 10 баксов/день? :)

Да, чё-то дофига, как за жабоскрипт...

Я ещё могу понять преимущество раста перед жабой — быстродействие и меньшее ресурсопотребление (кому это нужно).

Но преимущества раста перед "си"/"плюсами" в крипте (где нет особых проблем с «сэйфети»)? Не вижу таких.

P.S. А что там в традиционной криптографии «ансэйф» — что понадобился раст?

heartbleed.com

Тепер, коли Rust визнали на DOU, вакансій має стати більше

переписувати з Rust кому-сь буде треба

С цешки постоянно на руст переписываем. Правда это эмбедед...

Ответственностъ за то, что за ассемблер нагенерирует сишный компилятор для конкретного процессора — несёт производитель процессора (и сишниго компилятроа к нему). А кто несёт ответственость за нагенерированное растом?

«сишный» код, обычно нет проблем отлаживать (включая просмотр стэка, мемори, регистров, итп). И это даёт достаточно полезную/полную информацию о состоянии/проблеме.
А что с этим у раста?

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

А если код с динамическим выделением — прикольно будет посмотреть на эмбед, где при проблемах с выделением памяти растом, случится «экзит».
(на самом деле, не очень прикольно)

В общем, хипстеры — такие хипстеры. :) Хорошо, что вас с растом — ни до чего серьёзного (пока что) не подпускают.

Почему уже давно подпустили, в 2018 Mozilla выпустила Quantum CSS для Firefox, который стал кульминацией восьми лет разработки Rust — безопасного для памяти языка системного программирования. Rust — это не просто очередной системный язык программирования по мотивам Си, а системный язык, обогащенный рядом высокоуровневых концепций, можно посмотреть и с другой стороны: как на прикладной язык, снабженный низкоуровневым инструментарием. Полезны ли эти низкоуровневые инструменты в прикладной раработке, например эмбедед? Я думаю, что да. Они позволяют создавать новые эффективные высокоуровневые абстракции, расширяя арсенал разработчика. Дополнительно, наличие средств, которые позволяют изолировать и связывать между собой разные уровни, делают Rust по-настоящему универсальным языком программирования, для моих задач.

Это какой-то странный набор слов. Где тут примеры серьёзного, куда допустили хипстеров с растом?
Mozilla Firefox? Серьёзное, да... :)

Rust стек орієнтований, але як і з С, можна працювати з кучею.

«сишный» код, обычно нет проблем отлаживать

ага, деадлоки і рейскондішени.

чесно кажучи, поки що не бачив причини, щоб через gdb чи jtag дебажити Руст код, питання — напоркуа дебажити?

питання — напоркуа дебажити

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

Якщо ти написав, і код скомпілювався, то 99.99% що дебажити його не прийдеться. Це не С, де можна ловити глюки.

Мені цікаво, ти на Русті писав, скільки часу?
Чи ти так, аби поговорить.

Якщо ти написав, і код скомпілювався, то 99.99% що дебажити його не прийдеться.

Если речь идёт о программке, размером в 200 строк — вполне возможно.

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

П.С. Ты написал на расте, без потребности в отладке? Ок.
О коде какого размера идёт речь? Хотя бы 50к строк там есть?

ще раз, ти писав на Расті, щоб розказувати який він поганий у порівнянні з С?
Давай приклад, от робив таку річ на Русті, проблема виникла така. Прийшлось дебажити.

З свого боку, можу сказати, що один раз не вдалося осилити на Русті проблему як шарити TTY щоб одночасно\асинхронно з двох потоків приймати і передавати RX TX

В С це робиться просто.

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

мокнув так мокнув сінйора, маладєц

Еслин речь идёт о программке, размером в 200 строк — вполне возможно.

200 строк на Rust замінять 2000 на С,
менше кода — менше помилок.
Л — логіка

ще раз, ти писав на Расті, щоб розказувати який він поганий у порівнянні з С?

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

Раст в это число «мэйнстримовых» не входит. Как не входит и куча прочих «языков-однодневок» типа кложи (которая лет 5 назад, на хайпе, была популярна — но сейчас о ней никто не вспомнит).
Есть более полезные дела, чем осваивать такие языки.

тебе хтось змушує?

Ты допытываешься, писал или не писал...
Я тебе отвечаю, что не писал. И почему именно.

тоді це розмова про смак устриць з тим хто їх не пробував

тоді це розмова про смак устриць з тим хто їх не пробував

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

— Слышал «Битлз», не понравилось. Картавят, фальшивят, что только в них находят?
— А где ты их слушал?
— Мне Мойша напел.

В Rust реализована одна из лучших с моей точки зрения, система сборки и управления зависимостями. Если вы программировали на С или С++, или других языках и вопрос безболезненного использования внешних библиотек стоял для вас достаточно остро...Про Cargo слышали?

вопрос безболезненного использования внешних библиотек стоял для вас достаточно остро

В «си» такого вопроса вообще нет. В отличии (подозреваю) от раста (где, собственно, и библиотек-то нет).

Так да... «слышал я ваш Битлз».
crates.io
64,801 Crates in stock

В Rust реализована одна из лучших с моей точки зрения, система сборки и управления зависимостями. Если вы программировали на С или С++, или других языках и вопрос безболезненного использования внешних библиотек стоял для вас достаточно остро...Про Cargo слышали?

Гдето я уже слышал подобное. А! Ruby и npm! Начиналось все хорошо, а закончилось как обычно )) неподдерживаемые библиотеки, конфликты версий (B -> A.v1, B -> C -> A.v2, ...)

в плюсах Смаке, нінджа, може ще що.... і так вдобно, шо аж п**ц, не те що ваш тупий карго для хіпстерів

Гдето я уже слышал подобное. А! Ruby и npm! Начиналось все хорошо, а закончилось как обычно )) неподдерживаемые библиотеки, конфликты версий (B -> A.v1, B -> C -> A.v2, ...)

Понимаю источник боли, но такие зависимости cargo разруливаются без каких либо проблем, это стандартный кейс.

мокнув так мокнув сінйора, маладєц

Синьор, это не ответ на простые вопросы: «О коде какого размера идёт речь? Хотя бы 50к строк там есть?»

В принципе, код даже на 100к строк — это довольно-таки примитивная поделка.
(на освоение такого "сишного"/"плюсового"/"шарпового" кода в новом проекте, для дальнейшего развития/рефакторинга — мне нужно 1-2 дня).

Реальные решения — на 1-2 и более порядков крупнее.

200 строк на Rust замінять 2000 на С

Да ладно, фантазировать-то.

Под раст и библиотек-то толком нет — в отличии от «си».

Скорее наоборот. Tо, что при помощи библиотечных функций на «си» будет написано за 200 строк — хипстер на расте, будет реализовывать долгие месяцы, налабав 20к строк и более.

Tо, что при помощи библиотечных функций на «си» будет написано за 200 строк — хипстер на расте, будет реализовывать долгие месяцы, налабав 20к строк и более.

Если под С написана какая-то годная библиотека, то она подтягивается в Rust с zero cost через FFI

doc.rust-lang.org/nomicon/ffi.html

Плюс для большинства годных С библиотек уже запилены канонические враперы на Rust — даже FFI юзать не нужно, подключаешь нужный package и вперед. Например, crates.io/crates/pcap

З свого боку, можу сказати, що один раз не вдалося осилити на Русті проблему як шарити TTY щоб одночасно\асинхронно з двох потоків приймати і передавати RX TX

Если он потокобезопасный, то можно реализовать пустой трейт Sync через unsafe

простіше було переписати на Го і не паритися,
не тре бути рабом одного інструменту.
Коли в руках молоток, то здається, що кругом цвяхи ©

П.С. Ты написал на расте, без потребности в отладке? Ок.
О коде какого размера идёт речь? Хотя бы 50к строк там есть?

Я пишу на расте и потребности в отладке отладчиком с пошаговым выполнением реально не возникло ни разу.

Иногда приходится ловить баги с помощью более узко-направленных юнит тестов. В клинических случаях — обычными println. Такого п****ца чтоб приходилось заводить дебагер и с микроскопом рассматривать что там не работает у меня в коде нет.

Когда я переключился на другой проект, уже было больше 200 тысяч строк кода на расте. Код идет в фундаментальный компонент инфраструктуры публичного облака.

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

На расте пишется дофига юнит тестов (тем более инфраструктура языка делает это элементарным), плюс язык достаточно строгий, что хуиту написать очень сложно в отличие от C/C++, поэтому дебажить таки практически не приходится. Но если надо, то GDB в руки, он отлично работает, как и остальные инструменты.

зачєм?
працює, ну і фіг з ним.

Чи неосілятори С переписують на Руст?

пропонують переписувати проект з С++ на Rust.

Сколько платят за час?

40$/hour

Это ещё, куда ни шло. Думал, будет меньше...

на Расті менше?
гагага

Почему нет? Хипстеры, без опыта реальной разработки (часто, из академических инфантилов), с горящими глазами...

Я бы таких привлекал за еду.

Я не займаюсь Джинном, але ідеї можна подавати тут:
t.me/...​joinchat/rMBwgh5PJZMwN2My

та досить Go: 16 розробників і 100+ вакансій

SAP в новой Зеландии ищет разраба с опытом, адаптация Rust начинается.

— Minimum of 6-8 years of relevant, modern C++/Rust/Java development experience
jobs.sap.com/...​Developer-1010/669056501

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

Тут даже не з Руст екзотика, а з НЗ.
Писали мені колись, з якогось стартапа як в них чудово.
А як дійшло до мови, що було би добре 4К+ USD після податків, то щось тіпа «ми люді бєдниє..»

using C++, Rust and Java as the main development languages.

Возможно, что-то успели написать на rust, и теперь нужно переписать на java

в мене клієнт навпаки, хотів тормоза з Джави переписати на шустрий Руст

SAP не останавливается... вот по всей видимости недавно купленная контора, т.к. она уже «под брендом» SAP.
Backend Engineer — Rust (m/f/d) at Signavio Germany
Signavio is looking for an Intermediate Backend Engineer — Rust to help us build the future of our Business Transformation Suite.
www.signavio.com/jobs/?gh_jid=4398893003

дату смотрел? — 3 июня 11:40
Ты бы еще через год пришел. :)))

Вот новая ссыль — www.signavio.com/jobs/?gh_jid=4625546003

Если есть 2 часа линшего времени, лучше найти и почитать/послушать какой-то более серьезный и достоверный источник информации по Rust. Чуваки не совсем понимают о чем говорят. Я ради интереса начал слушать про «массивы и вектора» и там чувак несет ересь и сильно плавает в теории.

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

из комментариев:
Вот он! Вот он мечта HRa которая сможет выполнить все требования на должность Джуна (Возможно). На свои 18 лет он имеет 10 лет опыта программирования. Вместо игрушек у него перфокарты, первой его игрой на ЭВМ это была игра, написаная им же, а перед сном ему мама читает не сказки, а документацию на инглише.

Facebook Open Source is excited to announce our support of Rust Foundation at its highest member tier. Alongside the other fellow foundation members, Facebook is committed to sustaining and growing the Rust open source ecosystem and community....
developers.facebook.com/...​ok-joins-rust-foundation

Продолжение...
A brief history of Rust at Facebook
From 2017 through 2019, the Source Control team doubled as the unofficial Rust support team within Facebook. But by 2019, the number of Rust developers at Facebook had grown exponentially, to over 100.

At the end of 2020, we re-upped our commitment by launching a Rust team in our Programming Languages organization, the same org responsible for Facebook’s C++ standards work and toolchains.

engineering.fb.com/...​/29/developer-tools/rust

Instead of crawling your logdir in a mixture of Python and C++ code with
a lot of locking, cross-language marshalling, and slow data manipulation
in Python, we read the data in a dedicated subprocess. This program is
written in Rust and is optimized for concurrent reading and serving.

Так не считаєццо, там Пайтон на равликах замінили на Руст з стероїдами.

краще менше, але краще
але там не про цей випадок

www.quora.com/...​ome-a-mainstream-language

if you are talking about systems programming, the field shrinks dramatically. There you need precise control over what your code does with memory, and you do not want garbage collection. C and C++ have had a stranglehold on that space for almost forever in the history of this industry. D, Swift, and Go are closer to the metal than languages like Java and Python, but they do still effectively rely on a garbage collector. Rust does not. Rust is a true competitor to C and C++ for such work, requiring essentially no runtime, and compiling to just the machine code representing your code.

D, Swift, and Go are closer to the metal than languages like Java and Python, but they do still effectively rely on a garbage collector.

к сожалению у swift нет a garbage collector а только старый добрый ARC и с этого места статья закрывается и пролетает дальше над парижем селяви ))

Не осиляторам предлагает Microsoft.

docs.microsoft.com/...​n/paths/rust-first-steps

Что-то не слышно воплей про «агрессивную рекламу» от МС... :))

Там є аналогічна стаття про Го. Це вони VS Code рекламують.

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

Да, раст молодой язык,

First appeared: July 7, 2010; 10 years ago

Rust появился в 2010 году, и он сразу занял третью строчку в списке любимых языков разработчиков на StackOverflow. Год спустя Rust возглавил этот список и держался там несколько лет.

В 2010 году это был совсем не тот язык, что сейчас. Вести отсчёт имеет смысл с 1.0, а это 2015 год, что не так-то и давно.

Так о том и речь, что таким «молодым и зеленым» языкам в linux kernel делать нечего.

Поживём увидим. Я бы поставил на то, что раст в ядро всё-таки протащат.

Я бы поставил на то, что раст в ядро всё-таки протащат.

Когда-нибудь, туда протащат даже пайтон. Другое дело, когда это «прекрасное далёко» наступит (и что к тому времени, будет из себя представлять Линукс). :)

Linux сейчас доминирует среди OS в том числе и потому, что за 30 лет, python туда так и не проташили.

А толку ждать — момент уже упущен.
Дальше расту нужно будет конкурировать не только с архаическими С/C++ но и с модно-молодежными zig/odin/etc

Также, возможно, подтянутся (и станут доступнее) языки с theorem prover, вроде ATS/F*/Idris/etc и про rust можно будет забыть.

А толку ждать — момент уже упущен.

Ага, ведь zig, odin, ATS и прочие уже в ядре, да?.. Попасть в ядро — это вопрос не только технический, но и политический. Ну а если мы не в контексте ядра говорим, то раст может ещё и не взлетел прям полноценно, но позиции укрепляет: работу найти можно, крупные компании подключаются и т.д. Ничего этого у zig нет.

Дальше расту нужно будет конкурировать не только с архаическими С/C++ но и с модно-молодежными zig/odin/etc

Не вижу никаких предпосылок. Разве что какой-нибудь гугл поспособствует. Иначе без шансов.

Также, возможно, подтянутся (и станут доступнее) языки с theorem prover,

Было бы замечательно. Я как раз надеюсь, что языки с более мощными типами будут набирать популярность. Вот только в массе народ и хаскеля пугается, куда уж там Idris. Не говоря уже о том, что это языки со сборкой мусора (и из «мощных» языков таких большинство) — это не ниша раста. Во взлёт ATS не верю, но может действительно появится что-то более новое и модное/удобное.

Ага, ведь zig, odin, ATS и прочие уже в ядре, да?

если бы тут было «да», то было бы очень смешно)

Ну тут не в ржавом проблема, а в том что генерирует компилятор. Конечно out memory который ведёт к kernel panic это полное безобразие, будет Windows 98 помирающий с синим экраном каждый час работы. По этой же причине все ядра которые пишут на C++, когда компилируют исключения отключают ибо существует ровно аналогичная проблема bad_alock исключения, соответственно на серверах и т.д. происходит тоже самое.

Еще планирую создать на Руст простейшей однотабличной базы данных с таким функционалом:
Запись и загрузку файла базы данных (бинарный файл).
Добавление новых записей, удаление и редактирование старых.
Сортировать записи по любому из полей базы данных в любом направлении.
Фильтровать записи по значению любого поля.
Осуществлять поиск записей по значению любого поля.
Выполнять дополнительную обработку (с сохранением результата в текстовый файл).
Обработку данных производить в динамическом списке связанного хранения.

Дополнительные сведения:
Выделение и освобождение динамической памяти осуществляется поэлементно. Чтение и запись данных в файл базы данных производится поэлементно. Программа должна обладать дружественным и интуитивно понятным интерфейсом и проводить проверку на корректность вводимых данных.
База данных содержит информацию об измерениях: наименование устройства (строка 15 символов), модель ( приблизительно строка 10 символов), показатели датчика1 (целые шестизначные числа), показатели датчика2 (целое трехзначное число), суммарный показатель (целые числа). Дополнительно реализовать сервис по поиску показатели датчиков: пользователь диапазон значений, программа выводит список возможных показателей. Если кто сталкивался с реализацией подобной задачей, может я чего не учел. Возможно будет еще индексация , но это не точно еще.

ще планирую создать на Руст простейшей однотабличной базы данных

Зачем?

У нас Иот проект, мне нужна ооочень простая БД,и математики еще много...Стандартные не подходят, а массив слишком просто, там много не покрутишь...

Не очень понимаю пить. Ты хочешь сам движок NoSQL типа BigTable написать. Просто зачем это делать когда уже есть Casandra и HBase, проще портировать одну из них или нечто подобное но по проще и посмотреть что из этого получится. Изобретать свой движок баз данных не просто в принципе тут язык реализации не так уже и важен.

Думаю, там найпримітивніша БД длі крудів, але не ясно, чи для смал ембедед, чи кастомізована для трейдінга чи інший домейн специфік солюшн.

Хлопцы, шё бы вы не спорили шё раст лучше цешки, где очень сильно огорачает ситуация с системными селекторами в Си. Каждый делает свои обёртки, когда в Rust есть де-факто стандарт docs.rs/mio/0.6.21/mio

Евгений, если хочешь набрасывать, плиз, выучи Go и иди набрасывай в ветку про Go.

где очень сильно огорачает ситуация с системными селекторами в Си.

WTF системные селекторы в Си?

А чем MIO отличается от классических select/poll/epoll? Есть подозрение что где-то в глубине он их и дергает.
*ничего не знаю о Rust, вопрос не ради наброса.

вопрос не ради наброса

wink, wink

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

раст лучше цешки, где очень сильно огорачает ситуация с системными селекторами в Си. Каждый делает свои обёртки, когда в Rust есть де-факто стандарт

Это как жаловаться что каждый на расте пишет свой обработчик событий, который отрабатывает по возврату из poll.

я би порівнював скоріше із обгортками із Qt

а те що дає система під Лінукс для С (підозрюю і під С++ теж):
select, poll, epool, libevent

я би порівнював скоріше із обгортками із Qt

Да, похоже это ближе.

підозрюю і під С++ теж

Угу. The same.

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

Мы юзаем веб сервер на расте. Вообще великолепная штука! Очень мне он нравится как язык программирования... В крайнем случае лучше, чем цешка плюсовая...

В крайнем случае лучше, чем цешка плюсовая...

расскажите про свой крайний случай

Вот код, сами смотрите:use hello::ThreadPool;
use std::fs;
use std::io::prelude::*;
use std::net::TcpListener;
use std::net::TcpStream;
use std::thread;
use std::time::Duration;

fn main() {
let listener = TcpListener::bind("127.0.0.1:8181").unwrap();
let pool = ThreadPool::new(4);

for stream in listener.incoming() {
let stream = stream.unwrap();

pool.execute(|| {
handle_connection(stream);
});
}

println!("Внимание!Выявлена неисправность сервера!.");
}

fn handle_connection(mut stream: TcpStream) {
let mut buffer = [0; 1024];
stream.read(&mut buffer).unwrap();

let get = b"GET / HTTP/1.1\r\n";
let sleep = b"GET /sleep HTTP/1.1\r\n«;

let (status_line, filename) = if buffer.starts_with(get) {
(«HTTP/1.1 200 OK», «hello.html»)
} else if buffer.starts_with(sleep) {
thread::sleep(Duration::from_secs(5));
(«HTTP/1.1 200 OK», «hello.html»)
} else {
(«HTTP/1.1 404 NOT FOUND», «404.html»)
};

let contents = fs::read_to_string(filename).unwrap();

let response = format!(
«{}\r\nContent-Length: {}\r\n\r\n{}»,
status_line,
contents.len(),
contents
);

stream.write(response.as_bytes()).unwrap();
stream.flush().unwrap();
}

Вуаля и многопоточный сервак в действии!!!
Rust компилятор со встроенным менеджером и сборщиком пакетов, системой тестов и генератором документации.
Безопасная работа с памятью, не допускающая ошибок сегментации.
Возможность применять абстракции, облегчающие ручную работу с памятью.
Для многих ошибок во время компиляции приводятся варианты исправления, ошибки в шаблонах
Указатели можно использовать только в небезопасном коде, в безопасном коде применяются исключительно ссылки на гарантированно существующие объекты.
Отсутсвие классов!
Единственный минус это очень строгий компилятор кода, который очень жестко контролирует обращение к памяти!
поддерживает .wasm

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

Например,

    stream.read(&mut buffer).unwrap();

doc.rust-lang.org/...​t.Read.html#tymethod.read

fn read(&mut self, buf: &mut [u8]) -> Result<usize>

Pull some bytes from this source into the specified buffer, <strong>returning how many bytes were read.</strong>

Вы читаете данные в буфер, вам говорится сколько байт было прочитано (там может быть даже один байт), вы забиваете не проверку того сколько байт было прочитано сразу лезете в этот буфер искать ваш «GET / HTTP/1.1\r\n».

Вуаля и многопоточный сервак в действии!!!

На ноде такой сервак будет выглядеть еще меньше и при этом будет нормально поддерживать большую часть стандарта HTTP 1.1 и иметь обработку ошибок:

var fs = require('fs'),
    http = require('http');

http.createServer(function (req, res) {
  fs.readFile(__dirname + req.url, function (err,data) {
    if (err) {
      res.writeHead(404);
      res.end(JSON.stringify(err));
      return;
    }
    res.writeHead(200);
    res.end(data);
  });
}).listen(8080);

Спасибо, что высказали своё мнение, но нода как раз и использует руст для увелечения производительности www.youtube.com/...​vao&ab_channel=CodingTech

Интересно, можете указать, где именно находятся .rs файлы в этом репозитории? github.com/nodejs/node

В качестве Event loop в Deno используется Tokio, написанный на Rust.

Ок, т.е. Rust не используется в ноде для повышенеия производительности и ваш код «веб-сервера» до сих пор багнутый. Вы именно этот код в продакшене крутите?

в ноде нет, но в переспективе планируем, например так habr.com/ru/post/323106

Вуаля и многопоточный сервак в действии!!!

code.qt.io/...​ttpserver/simple/main.cpp
с раутами, блэкджеком и шлюхами

Руст используем для низкоуравневых прог, например сейчас на него данные с датчиков прилетают...Будет ещё шё то нужно, то дапишу... Есть желание попробовать все вместе нода+руст +вебассамбл. developer.mozilla.org/...​/WebAssembly/Rust_to_wasm

а Qt на чем написан?

на питони жы ж

питоном по клавиатуре

Зе тоже умеет питоном по пианине!

угу. только у него то руст, то еще какой жабоскрипт получается все время

Если бы у Зели получался хотя бы джаваскрипт или руст... так то у него YoptaScript получается постоянно)

В 2010 году разработчики языка сменили используемый до этого компилятор OCaml на компилятор, написанный на Rust. В 2011 году Грэйдон опубликовал сообщение о том, что компилятор сумел успешно «собрать» сам себя, а в 2012 команда Rust объявила о релизе альфа-версии компилятора — его документация была не полной, а скорость создания билда оказалась далека от идеальной, однако он уже поддерживал большинство функций языка и кросс-компиляцию.

Большая тулсета Rust сейчас написана на Rust. Бекенд компилятора (LLVM) — написан на C++

На OCaml были написаны одни из первых версий, но это интересно только для любителей истории или любителей забутстрапить Rust с нуля на новой платформе.

Большая тулсета Rust

большая тулсета, однако...

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

Плюсам уже все, их по скорости даже жаба вроде обгоняла.

Поясни як це могло статися хоча б в теорії?

При соблюдении определенных условий Java программа или, скорее, части java программ могут выполняться быстрее, чем «same» код в C++ (или другой предварительно скомпилированный код) из-за JIT оптимизаций. Это связано с тем, что компилятор может определять область действия некоторых переменных, избегать некоторых условных выражений и выполнять подобные трюки во время выполнения.
Нативно написанный код Java превосходит нативно написанный код C++ в таких ситуациях как:

Много маленькой памяти allocations/deallocations. основные JVMs имеют чрезвычайно эффективные подсистемы памяти, и сбор мусора может быть более эффективным, чем требование явного освобождения (плюс он может сдвигать адреса памяти и тому подобное, если действительно захочет).

Эффективный доступ через глубокие иерархии вызовов методов. JVM очень хорошо справляется с устранением всего, что не является необходимым, обычно лучше, по моему опыту, чем большинство компиляторов C++ (включая gcc и icc). Отчасти это происходит потому, что он может выполнять динамический анализ во время выполнения (то есть он может чрезмерно оптимизировать и только деоптимизировать, если обнаруживает проблему).

Инкапсуляция функциональности в небольшие недолговечные объекты.

В каждом конкретном исключительном случае, C++ может сделать лучше (между свободными списками и памятью block-allocated/deallocated, C++ может превзойти систему памяти JVM почти в каждом конкретном случае; с дополнительным кодом, шаблонами и умным macros можно очень эффективно свернуть стеки вызовов; и тогда могут появиться небольшие частично инициализированные объекты, выделенные стеком в C++, которые могут превзойти короткоживущую объектную модель JVM). Можно еще расписать, но этого думаю будет достаточно...

Зрозумів, дякую за пояснення.

Я подібні аргументи чув ще в 2010-му році про C# та .NET — оскільки у нас більше інформації про код то можна його оптимізувати прямо по ходу виконання, можему відкласти звільнення пам’яті, а виділення робити з одного великого блоку і таке інше. І в теорії виходило швидше ніж на С++. А на практиці — ніяк. Тому поки що скепсис та сумніви.

Ось ці наівно написані програми/функції десь можна подивитися щоб побачити який саме код на Java буде швидшим за такий же код на C++?

Здесь к сожалению код нельзя выкладывать,когда я выложил, людям это не понравилось...

Ось цікаве знайшов — python.plainenglish.io/...​-1000x-times-c9e7d5be2f40. Хоча стаття про Python, але є згадка про Java код який виконується швидше за такий самий на С++.

Бонусні поінти тим хто в С++ коді побачить де можна внести прості зміни для підвищення швидкості в рази.

Там взагалі-то код на C
Не знаю, чи прискорить в рази, але проситься замінити доступи до масиву на «ітератор» і, можливо, множення на приведення типів
це

for(int i = 0; i<length; i++){
    output_array[i] = 1.0/(rand_array[i]*1.0);
}
на це
int *src_itr = rand_array, *src_end = rand_array + length;
float *dst_itr = output_array;
for(; src_itr < src_end; ++src_itr, ++dst_itr){
    *dst_itr = 1.0f / ((float) *src_itr);
}

Там достатньо множення прибрати щоб навіть без оптимізації компілятором обігнати Java:

for(int i = 0; i<length; i++){
    output_array[i] = 1.0/float(rand_array[i]);
}
на це

А также добавить опцию компилятору -O3 -march=native -msse4.1

Компиляция в лоб gcc a.c:
took 10107 us

Компиляция gcc -O3 -march=native
took 4919 us

Убрал дебильный каст во флоат через дабл:

output_array[i] = 1.0f/((float)rand_array[i]);
took 2200 us

Добавил инициализацию output_array[] (кто знает современные ОС, тот поймёт зачем):

    for(int i = 0; i<length; i++){
        rand_array[i] = rand();
        output_array[i]=0.0f;
    }
took 1029 us

Добавил -ffast-math
took 683 us

Итого приблизительно в 15 раз за 3 минуты.

Добавил инициализацию output_array[] (кто знает современные ОС, тот поймёт зачем):

Чтоб бороться с влиянием оверкомита на перформанс?

Это называется lazy memory allocation. Overcommit — это следствие.

Майк, поясни плз чим це буде відрізнятися якщо я зроблю memset для того ж масиву?

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

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

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

лично меня это поражает «благородный дон поражён в пятку» (к) (тм)

вы это имели ввиду? ring-buffer?:

#ifndef FIFO__H
#define FIFO__H
 
//размер должен быть степенью двойки: 4,8,16,32...128
#define FIFO( size )\
  struct {\
    unsigned short buf[size];\
    unsigned short tail;\
    unsigned short head;\
  } 
 
//количество элементов в очереди
#define FIFO_COUNT(fifo)     (fifo.head-fifo.tail)
 
//размер fifo
#define FIFO_SIZE(fifo)      ( sizeof(fifo.buf)/sizeof(fifo.buf[0]) )
 
//fifo заполнено?
#define FIFO_IS_FULL(fifo)   (FIFO_COUNT(fifo)==FIFO_SIZE(fifo))
 
//fifo пусто?
#define FIFO_IS_EMPTY(fifo)  (fifo.tail==fifo.head)
 
//количество свободного места в fifo
#define FIFO_SPACE(fifo)     (FIFO_SIZE(fifo)-FIFO_COUNT(fifo))
 
//поместить элемент в fifo
#define FIFO_PUSH(fifo, byte) \
  {\
    fifo.buf[fifo.head & (FIFO_SIZE(fifo)-1)]=byte;\
    fifo.head++;\
  }
 
//взять первый элемент из fifo
#define FIFO_FRONT(fifo) (fifo.buf[fifo.tail & (FIFO_SIZE(fifo)-1)])
 
//уменьшить количество элементов в очереди
#define FIFO_POP(fifo)   \
  {\
      fifo.tail++; \
  }
 
//очистить fifo
#define FIFO_FLUSH(fifo)   \
  {\
    fifo.tail=0;\
    fifo.head=0;\
  } 
 
#endif //FIFO__H
Реализация на русте stackoverflow.com/...​cpclient-with-ring-buffer

Это не реализация, а рак, который никому не стоило показывать.

    //FIXME use <T> and a sanitize method.
    pub fn write_data(&mut self, incoming_data: &[u8]) {
        if self.write_cursor == self.length {
            self.write_cursor = 0;
        }

        self.cells[self.write_cursor] = Some(incoming_data.to_owned());
        self.write_cursor += 1;
    }
У вас нет никаких замечаний к этому куску кода по вашей ссылке?

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

Ссылка на код не рабочая. Комментарий удален наверное.

Лол, ты эту ссылку утром запостил, уже забыл? Все рабочее:

stackoverflow.com/...​cpclient-with-ring-buffer

Так вроде хлопцы уже написали, использовать дженерики...

Дженерики это единственное, что вас смущает в коде, на который вы дали ссылку сами? Других проблем не замечаете? Конкретно в куске кода, который я процитировал в своем сообщении.

Там нет уже этого кода, который был раньше. Можно еще заменить u8 взять T, поставить на этом T условие для имплементации трейта в котором есть метод to_owned () +что бы был Sized. Произвести замену в структуре(которая self), чтобы получить дженерик (и поле cells) ...

Можно еще заменить u8 взять T, поставить на этом T условие для имплементации трейта в котором есть метод to_owned () +что бы был Sized. Произвести замену в структуре(которая self), чтобы получить дженерик (и поле cells) ...

А проверку на предмет того, есть ли в буфере свободное место, или буфер уже полный, нужно делать перед добавлением или не нужно?

Мопед не мой Я в русте не шарю от слова «совсем», но я правильно понимаю, что в нем не принято проверять заполненность буфера и можно наваливать новые данные поверх невычитаных старых? И руст магическим образом разрулит это. По чтению пустого буфера те же вопросы.

Бинго

Разумеется, нужно делать проверку на заполненность массива, иначе не просто будешь затирать данные (в данной реализации это по крайней мере не ведет к небезопасному или неопределенному поведению), а повредишь инварианты, касающиеся указателей head и tail, на основе которых строится алгоритм ring buffer.

магия руста — программист не должен думать, руст все сделает сам

Годный говнокод. Где ты его находишь?

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

Две саечки за испуг.

Бонусні поінти тим хто в С++ коді побачить де можна внести прості зміни для підвищення швидкості в рази.

— заменить [] на указатели
— заменить *1.0 на static_cast
— держать рядом в памяти элементы массивов, а не сами массивы (возможно ускорится чтение за счёт кеш лайна)

Больше не могу придумать

C# та .NET

Ничего не скажу так как выполнял только учебные примеры на этих языках...

бггг....
аргументація нагадала колишні спори на форумах (років 15 тому), що Forth іноді виконується швидше, ніж код на асемблері, бо він вміє виконуватись на голому залізі «обходячи» CPU :)

Особливо коли форт на форт-процесорі. Oh, wait...

Плюсам уже все, их по скорости даже жаба вроде обгоняла.

не перестаю радоваться посетителям доу

там автор бредит

В целом перспектива у цешки в будущем не очень — С++ постепенно вытесняется более простыми и надежными языками, плюс к тому же в последнее время есть существенный уклон в сторону web и мобильных приложений, где главенствуют другие языки. Но с другой стороны вам же никто не мешает юзать цешку если оооочень хочется...

это не имеет никакого отношения к тому, что там автор набредил на хабре

С++ постепенно вытесняется более простыми и надежными языками

Так, але ці нові мови також поступово витісняють одна одну. І виходить так що є монолітні (в сенсі незворушності) С/С++ та зоопарк витісняторів з яких не про кожен згадають через 5 років.

виходить, що С++ переходить до роздяду незворушних, як гівно мамонта, Коболів зі Фортранами :)

Как знать. Руст еще очень молодой язык, и он себя еще покажет, вот увидите!

аргумент 1
тяжко вивчити Rust (щелепа не така)
аргумент 2
в Тулі нема ні розробників ні вакансій на Rust

аргумент 1

Вы ж программист...
аргумент 2
Любой изначально цешный проект можно писать на русте, обычно возражений не возникает

Любой изначально цешный проект

не любий, напр. під TinyAvr ніяк

Вроде можно, но сам не пробовал. Есть такой проект:github.com/avr-rust

Вы наверное имели в виду ATTiny 85? Тогда зачем ? ATmega 8 стоят как ATTiny 85, но при этом возможностей поболее.

а ленин такой молодой!
моложе пока не нашлось ©

Як на мене ключова відмінність тут така, що на плюсах активно і багато пишуть зараз, а не лише підтримують 30-річної давнини легасі.

Писати, то може і пишуть багато, але якщо стартують нові проекти, то що я бачу, що на Golang\Rust готові брати з 1р. досвіду і платити більше (або навіть, готові брати з умовою, що швидко навчишся, а на С++ тобі затрахуватиму міски на співбесідах, і офер виходитиме гірший все одно.), чим С++ з 5 р. досвіду.

Якщо порівняти з python, Golang, Rust, то
плюси впираються в:
— повільність розробки,
— високий вхідний бар"єр.

Тобто, на С++ проекти дописують, доробляють, доношують.

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

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

в країні рожевих поні

якщо стартують нові проекти, то що я бачу, що на Golang\Rust готові брати з 1р. досвіду і платити більше

Оскільки я завжди собі шукаю роботу де було б хоч трохи (а краще багато) С++ то мій особистий досвід не співпадає з цим.

плюси впираються в:
— повільність розробки,

Повільність через що — інструментарій, складність чи кількість коду? Якщо говорити про цикл який включає багаторазові компіляції то так, якийсь пітон виходить швидше. Але на мене різниця не така суттєва та і сам підхід «компіляємо після кожного виправленого символу» в С++ не надто використовують.

— високий вхідний бар"єр.

Це ж добре, хіба ні?

Тобто, на С++ проекти дописують, доробляють, доношують.

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

багато С++

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

если ты еще и секьюрити любишь

На двох попередніх роботах довелося спочатку трошки, а потім і глибше розібратися з основами. І виявилося, що це доволі цікаво. Тобто я ніякий не експерт і не кріптограф, але чисто алгоритмічно та процедурно це ІМО цікавий домен.

у нас есть много интерестного для тебя

Та я тільки роботу поміняв :) Може через кілька років.

плюси впираються в:
— повільність розробки,

если не знать языка, то да

Я думав про раст 5 років тому, але і зараз напевне вибрав би С++.

Може років через 10... Вийде якась MISRA Rust, багаті протопчуться по граблях і понаписують бібліотек, стабілізуються ABI і API, понавчаються програмісти...

Щодо власного довсіду, вибирати чи не вибирати, я би радив спробувати хоча б, так як дає інший погляд на С++ його кострукції і парадигми, та й загалом розширює кругозір, а не закуклюватися на С++ і його нішах: геймдев, автомотів, HFT

Після ІРО або в тюрмі, як буде час, так зразу і спробую. Десь році в 2012-му дивився на Haskell і ранній Rust.

какая жесть, а как же хттп 2.0?

GET / HTTP/1.1

а если клиент HTTP/1.0 поддерживает?

www.quora.com/...​w-is-Rust-faster-than-C

Rust builds everything into one static binary and uses LTO by default.

Rust has very strong types and pointer/reference guarantees and aggressively uses strict aliasing rules because Rust can guarantee that two pointers never point to the same thing.

Rust makes it easy and safe to write parallel code. C++ is almost as easy but is so much easier to screw up. I’ve seen, debugged, and written myself C++ thread bugs. Accidental lambda reference captures being used in threads without locking. Shared variables used without locking. Functions called by the wrong thread. Etc.

I have also seen SO MANY cases of incompetent (in my opinion) C++ developers who cannot build their software with high optimization levels. It breaks and they do not know why. In most cases it is NOT a compiler bug. It’s because they used undefined behavior.

And these two complaints are slightly related: In Rust it can be slower because it will needlessly zero-initialize large arrays like vectors. In C++ I have seen developers who seem to think it is somehow OK to call vector reserve and then use vec[20] (for example) without resizing the vector. Sure, genius. Keep doing that. It will all explode dramatically later

How is Rust faster than C++?

и 1м же ответом идет

It isn’t, rather there are components of the Rust standard library that are better tuned for some edge cases where the equivalent C++ standard library features are tuned differently.

в бенчмарках rust показывает весьма средние результаты, часто проигрывая не только С но и D (Nim, Kotlin, Java...).
Бенчмарки явно не самая сильная сторна Rust.

Rust builds everything into one static binary and uses LTO by default.

gcc -flto

Rust can guarantee that two pointers never point to the same thing.

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

на С++ можно не провєрять, авось не покрешиться на проді

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

Не задумываются, так как основной фокус идет на написание безопасного кода, в котором нельзя словить UB на двух строчках кода.

Если на бенчмарках находится проблема, то точечно делаются фиксы после профилирования. Например, практически все операции, которые делают рантайм проверку, имеют unsafe аналог, который эту проверку не делают, например. Если выясняется, что большую часть времени приложение тратит на рантайм проверках границ вектора (нет), то можно аккуратно там добавить небезопасного кода без проверок.

если у тебя получается

UB на двух строчках кода.

то у меня для тебя плохие новости

Так может раньше у него было UB на одной строчке

Rust can guarantee that two pointers never point to the same thing.

std::unique_ptr с запретом на передачу по ссылке (code review и/или sca) и по .get()

std::unique_ptr с запретом на передачу по ссылке (code review и/или sca)

це все міняє ... ©

В качестве бонуса — поддержка null reference (значит или пилить рантайм проверки, или ловить ub и сегфолты), плюс отсутствие нормальной поддержки памяти на стеке.

Можно запретить создавать нулевые юники в конструкторе. Память на стеке не знаю как делать. Нюансы везде есть.

Можно запретить создавать нулевые юники в конструкторе.

1) Как запретить?
2) Там еще оператор присваивания «обнуляет» указатель, который был с правой стороны. Даже если ты явно не создавал unique_ptr с null reference, он может быть создан как побочный продукт каких-то операций, связанных с этим unique_ptr.

1) Как запретить?

Run time проверка на ненулевой указатель или создание только через фабрику make unique

2) Там еще оператор присваивания «обнуляет» указатель, который был с правой стороны. Даже если ты явно не создавал unique_ptr с null reference, он может быть создан как побочный продукт каких-то операций, связанных с этим unique_ptr.

Об этом я не подумал (

Интеренсый тренд, который наблюдается при общении практически с любой командой/компанией, которая нанимает людей писать на С++

— Окай, и на чем вы пишете?
— Ну, на С...
— И...?
— Ну и еще на С++
— -_-
— Но это не тот отстойный С++. Мы взяли только хорошие вещи С++. Очень немного С++, практически нет С++, можно сказать, что максимум пол строчки кода на С++

Але на співсбесідах чомусь ганяють по ніштяках нової парадигми С++11 і вище,

Автосар Адаптів взагалі написав так, що С ацтой (ми не можем захєрячити свій автосар месидж брокер на ньому зокрема, і адаптивну платформу вцілому), і тому ми взяли С++14, а так як він нам не підходить то ще запиляли нові фічі і маєм Автосар С++14. Во як!!!

Кстати, на TIOBE index фортран обошёл раст по спросу и популярности!

Все самые годные вещи в IT были созданы до 70-х годов

Android Open Source Project (AOSP) now supports the Rust programming language for developing the OS itself.
security.googleblog.com/...​-in-android-platform.html

І знову про Rust

www.quora.com/...​n-something-more-relevant

I would not go so far as to call C++ obsolete, but it’s certainly outdated. Yes, yes, it is being updated — out of necessity, not want, and updated outdated language is still mostly outdated. Certainly Mozilla foundation thought so when they embarked on developing Rust, otherwise they’d just have used C++. I have the impression that C++ is not selected frequently for new projects. This is because the specific niche of C++ is again constricted by those five factors.

там есть и другие ответы

С++ як Ленін, вічно живий, чекаєм на С++23 (тіпа ще більше Джави\С# синтетичного цукру)
але С++ живий, тому, бо тонни гімна мамонта на ньому (легасі коду), а не тому, що він такий чудовий, модний і сучасний

він такий чудовий, модний і сучасний

да, он такой

якщо він такий "

чудовий, модний і сучасний

"
чому С++ників тягне на ржавий?

чому С++ників тягне на ржавий?

шо, серьезно?

шо, серьезно?

видимо тянет тех кто не дочитал книжку «С++ за 21 день»

наверное потому, что раст еще более

чудовий, модний і сучасний

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

Я вот буду рад, если Раст будет прилично проще С и С++ и даст такую же скорость выполнения прог.

дає, а в бонус ще набаго вища надійність і безпечність коду (думаю і економія на підтримці коду теж буде)

Несколько лет назад точно как ты писали гоуманы, но что-то последнее время про убивцу С и С++ затихли

Вони тихо рублять бабло, а то понабіжать цепепешнкики і спортять всю малину.

Але поки що, ті їдять С++ кактус, аж за вухами лящить.

А если асенизатор на говновозке работать, то больше програмера зарабатывать будешь

Це у вас в Білорусі.

Я вот буду рад, если Раст будет прилично проще С и С++ и даст такую же скорость выполнения прог. Но пока не выходит у растоманов каменный цветок.

Rust на бенчмарках идет рядом с С/С++. С моей точки зрения, Rust намного проще в освоении чем C++ (использую оба на работе).

Несколько лет назад точно как ты писали гоуманы

Что возьмешь с больных людей?

Rust намного проще в освоении чем C++

Субъективо — возможно, объективно — имеем массу холиваров.
Rust гораздо лучше спроектирован как язык, это его основной +.
Но «простота» не была среди целей.

За простотою в го ту Го, а в Руст за безпечним сєкасом

Я вот буду рад, если Раст будет прилично проще С и С++ и даст такую же скорость выполнения прог.

Для этого есть Zig

IMO подобные рассуждения лишены смысла.
Например «хорошо летящий» python появился в 1991, но кто его тогда использовал?
А за Rexx стоит IBM, но кто о нем вообще слышал?

А за Rexx стоит IBM, но кто о нем вообще слышал?

все, кто так или иначе сталкивались с продуктами ИБМ

Go уже давно победил C и C++, не говоря уже о каком-то Rust. Достаточно сравнить количество популярных проектов на GitHub, написанных на этих языках — github.com/search?q=stars:>1000

Go уже давно победил C и C++, не говоря уже о каком-то Rust.

в Го інша цільова аудиторія

Мнению анонимусов с кворы-реддита однозначно можно доверять :)

Ищу контакты айтишников на языке RUST в Украине, несколько человек

Ищу контакты айтишников на языке RUST

попробуйте поискать на английском

С какой целью? Почему именно в Украине? Удаленно рассматриваете? Куда обращаться?

думаю, шукають криптошизиків, щоб їх смарт контракти не просрали всі полімери

блокчейн і смартконтракти не пропонувати

HR, позволь тебе ответить
С высот айтишника седин:
Ты знаешь, прогеры — не дети,
Мы не последний хрен едим.

Вы прокачались, спору нет
И сыплете словами ловко,
Наверное, за много лет
Развили в терминах сноровку.

Вот так всегда: эйчар на встрече,
Явив павлинии хвосты,
Задавит мысли красноречием,
А как устроишься — в кусты.

Что программисту интересно?
Хороший офис, доля в деле?
А я сейчас отвечу честно:
Нам интересно много денег.

Садись сюда, меня послушай,
Я расскажу тебе без бэ:
Мы любим спать, гулять и кушать,
И радость приносить семье.

Нам наплевать на опенспейсы,
Аджайл, скрам и кипиай,
Нам важно быть всегда в процессе
И чтоб работы через край.

Наш ум — уже почти компьютер
И с IDE он заодно.
И если честно, нам до пупа,
Идёт ли босс на IPO.

Мы быстро merge your best solution
Deploy на сервер и commit.
Бывает, сон у нас нарушен
И голова с утра болит.

Я покажусь тебе токсичным,
Быть честным в наше время — токс.
Но набираете обычно
Вы не жемчужины — навоз.

Тех, кто пройдёт все сто этапов
И пишет на листочках код,
Кто смирно сложит обе лапы
И в офис посидеть придёт.

Он будет очень честно кодить,
И тихо ctrl-с github,
Потом всё крашится на проде,
Но это тестер виноват.

Хороший разработчик, зая,
Не будет мокрою рукой
Писать, что сортировку знает,
Он просто код покажет свой.

Не нужно пыли алгоритмов,
Они все гуглятся, ты знай.
А нужно множество коммитов
И чистый код, и codestyle.

Умелый нужен рефакторинг,
Возможность legacy убрать,
Хороший нужен мониторинг,
Чтоб ноды вечно не ронять.

И продакт адекватный нужен,
Который не проформы ради
ТЗ созданием загружен
И знает, что клиенты — б**ди.

Нам нужен диалог с начальством —
И адекватный диалог!
Чтоб без понтов и без бахвальства
Наш босс задачи ставить мог.

Нам нужен новый, ценный опыт,
Разнообразие задач,
Ты не услышишь грустный ропот
В момент айтишных неудач.

Нам всё равно на ваш agile,
Он нам давно не по душе.
Мы бажный код дебагом жарим,
И задолбались мы уже.

Гамак нам в офисе не нужен,
Митап засунь себе в mindcart.
Работа наша — hard и fusion,
Ну то есть синтез и прям hard.

Нам code review бы адекватный
И адекватный интерфейс,
И монитор чтоб был приятный —
Он светит сутками нам в face.

Нам наплевать на корпораты,
И на ассесмент наплевать.
Важны коллеги и зарплата,
И важно цену себе знать.

Ты хочешь слышать мой английский?
На нем читаю и молчу.
С провинциальной я пропиской
И удаленку я хочу.

А в целом нам немного нужно:
Бэклог продуманных задач,
Чтоб не тянуть из всех натужно,
Чего им надо — it’s too much.

Доверие и благодарность —
Ведь программист же человек.
А эту вашу элитарность
Оставьте тем, кто платит чек.

Мы жизнь переливаем в цифру
И правим алгоритмом мир.
Мы баги превращаем в фичи
Ты give me task and hold my beer.

Тебе же в поисках — удачи,
Айтишный мир is superior.
Ты смелая, а это значит,
Найдёт тебя твой best senior.

В ветку ядра Linux-next добавлен код для разработки драйверов на языке Rust
www.opennet.ru/...​nnews/art.shtml?num=54792

Да, только пока без компилера, APIшки ядра для него не переведены, демка работает только для char device driver, и коммит не заапрувлен Линухом. А в остальном — все хорошо.

ага, и весь код будет ансейф

інтернет колись теж був через дайл-ап із швидкістю до кількох десятків кілобод.

там ще кручє камєнти є:

С++ в ядро не пустили, а Раст уже в ядре, сейчас у цпп-макак от обидки начнется истерика

У них в каждом посте о Rust истерика

Да этот раст уже задрал, из каждого чайника ржавые уши торчат

Клетка. В ней 5 растаманов. На столе лежит книга «Си/Си++». Когда один растаман тянется открыть почитать книгу, другие растаманы поливают его холодной водой, приговаривая: «Нибизапасно!». .

В клетке 5 С++ в костюмах с галстуками. На столе лежит книга «Rust». Они по очереди открывают книжку, пытаются читать, но их хватает только на две страницы. В конце концов, все они, потерпев неудачу, набрасываются на книгу, рвут её на части, подтирают листами задницы, кидают их по всей клетке и громко кричат.

у цпп-макак

вот это тебя вштырило

мопэд не мой, я перепостив объяву

Перепишут на rust реализацию linked list в ядре linux? rust-unofficial.github.io/too-many-lists

А як там Redox OS — убивця Linux і QNX?

Хтось пробував?

Пока на реальном железе не удалось завести, только в qemu)

Я колись давно підписався через RSS на Opennet і за звичкою звідти читаю інформацію про Open Source новини.

medium.com/...​-java-python-9a0d505f85f7

Conclusion:
... before starting to write a new service in C or C++, it’s worth considering Rust. Because it’s as performant as C/C++, and on top of that:
Memory-safe
Data race-free
Easy to write expressive code.
In many ways it’s as accessible and flexible as Python.
It forces engineers to develop an up-front design and understanding of data ownership before launching it in production.

It forces engineers to develop an up-front design and understanding of data ownership before launching it in production.

Труъ стори:

Надумал решить пару задачек на литкоде на Rust.

1. Открыл самую популярную задачку (LRU Cache
2. Прочитал условие.
3. Понял, что задача легко решается с помощью двойного связного списка!
4. Понял, что мне сейчас прийдется запилить двойной связаный список на Rust
5. А нах эти задачки на литкоде, лучше пойти в Skyrim поиграть.

Без Rust я бы сейчас сидел и пилил этот LRU Cache. Но с Rust «up-front design and understanding of data ownership» я быстро избавился от необходимости вообще пилить какой-то LRU Cache.

Надумал решить пару задачек на литкоде на Rust.

для чого? закортіло в FAANG?

Но с Rust „up-front design and understanding of data ownership” я быстро избавился от необходимости вообще пилить какой-то LRU Cache.

docs.rs/lru/0.6.5/lru
docs.rs/...​ru-cache/0.1.2/lru_cache

3. Понял, что задача легко решается с помощью двойного связного списка!

github.com/...​-Cache/blob/master/lruc.c
bhrigu.me/...​plus-plus-implementation
github.com/...​/uluru/blob/master/lib.rs

і на Java
www.geeksforgeeks.org/...​lru-cache-implementation

На литкоде нет доступа к crates.io

На интервью вряд ли кто-то оценит «для LRU List есть какой-то crate на crates.io, инфа соточка, будем закругляться?»

На интервью вряд ли кто-то оценит "для LRU List есть какой-то crate

хз, не розумію теми надрочування літкода

до речі, С++ дає доступ до std
перевірив тільки що на myAtoi з допомогою std::strtoll()
так не чесно

п.с.
0 ms
100.00% faster then other C++ submissions!
#ялутшевсех

до речі, С++ дає доступ до std
так не чесно

бгггггг. бу-гагага
меня порвало

Ще раз повторю, замість того, щоб робити закат ручками, викликав для задачі «string to integer atoi» std::strtoll() і отримав кращий результат чим 100.00% інших

А ти жалуєшся, що в Rust тільки закат ручками (linked list).
Так втяніть boost в станадарт Rust і напишеться LRU на раз-два.

з.і.
часом нема в С++23 std::lru ?

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

Ще раз, ти хочеш вирішити задачу з літкода влоб, як би це робив в С++, використовуючи його встроєні можливості і бібліотеки, які стали частиною С++

В Русті, на жаль, а може, і на щастя, інший підхід, і не тре битися лобом об стіну (писати зв"язаний список).

І третє, привів приклад задачі з літкода для атоі(),
яка вирішується не влоб, а простим знанням бібліотеки стандартних шаблонів, і отримується результат ліпше чим у решти 100.00%.

В Русті, на жаль, а може, і на щастя, інший підхід, і не тре битися лобом об стіну (писати зв"язаний список).

а где надо?

І третє, привів приклад задачі з літкода для атоі(),
яка вирішується не влоб, а простим знанням бібліотеки стандартних шаблонів, і отримується результат ліпше чим у решти 100.00%.

Никакого результата не получаешь. Суть литкода не в том, что пройти тесты (за это никто не заплатит, внезапно), а в том, чтоб подготовиться к интервью. Если ты на интервью скажешь «легко, давай заюзаем std::XXX, которая 100% решает задачу», тебе скажут что нет, надо запилить самому, так хотят проверить твою способность решать алгоритмические задачи, а не знание std. И тогда вспомнишь как сидел вечером и вместо того, чтоб разобраться как сделать парсинг и обработать edge cases, подумал, что ты самый умный и прошел тесты стандартной функцией.

до речі, С++ дає доступ до std

Rust тоже дает доступ к std, и там даже есть LinkedList, причем конкретно двойной связный список, но он настолько куцый насколько это возможно в Rust и для нормальных проблем не годится.

перевірив тільки що на myAtoi з допомогою std::strtoll()

Если я правильно понимаю, это для парсинга строки в число? В Rust это тоже из коробки будет работать.

5. А нах эти задачки на литкоде, лучше пойти в Skyrim поиграть.

А как же карьерная цель принципала? )

смотри више про myAtoi.
я уже принципал?

уже просверлив на лацкані отвір під личку

4. Понял, что мне сейчас прийдется запилить двойной связаный список на Rust

Learning Rust by writing a linked list is like learning Python by writing a CPython extension...nobody actually writes linked lists in Rust

news.ycombinator.com/item?id=22390662

Влада приховує, але насправді індекс можна використовувати як вказівник. У тій його lib.rs так і роблять.

То, что запилено по ссылке — малая часть нужного функционала (нет O(1) операций). Да, можно пилить LinkedList с индексами, если хочется, чтоб было медленно, но будет куча плясок с бубном. Я не уверен, что, например, Rc + Cell будет чем-то хуже.

Таке на паскалі писалося на олімпіадах

Easy to write expressive code.

бгг

Частину б краще не писали ні на чому — сивіти менше треба було б

— Вот когда AWS перейдет на Rust, тогда и поговорим
— Ок, давай поговорим

по Rust уже пропонують 6КУЕ з 1-2 роки досвіду

Думаю, мало в кого більше досвіду з Растом.
Оно в Лінкедіні шукають 3 роки досвіду з клабхаусом.

мало в кого більше досвіду

хіба? он ФФ переписують 10й рік

І скільки цих переписувачів в Україні?

та вже скажи, чо уж там...

Так давай забацаєм МЛМ.
Я тебе зарефералю, а ти мене, потім.
Може ще і Дениса.
Але руст тре вивчити вперед.

Руст -> Крипта -> Цифрове золото

Пилітє гірі (учітє руст), Шура (Вітя).

Я руст бы выучил только за то, что им разговаривает крипта.

Без досвіду на 2-3 інших мовах на навантажених проектах?

x to doubt

порівняй з С++ при рівних інших умовах

Тобто умовний
Senior Highload
C++ vs Rust
?

при всіх інших рівних умовах (надіюсь, ти розумієш значення даної фрази)

Давайте ви повністю напишете, умови під цифру, що ви вказали, що б не грати в гру — вгадай вакансію по цифрі?

Зроби профілі з Rust на Лінкедін та Джині і взнаєш

Неочікуване закінчення треду про

по Rust уже пропонують 6КУЕ з 1-2 роки досвіду

вибач, я не хайрю і не хідхантю

C++ вже 10К djinni.co/...​6-media-server-developer
Але хочуть кодеки та стрімінг. Як раз для дяді Віті.

там якись стартап, думаю затрахають так, що потім погодишся і за 3К в бодішопі тупо таски в джирі пересувати

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

котиков стримить?

Рекламу

Так вже є рішення для і для реклами, і для вбудови її в відеопотік
І якщо логічно підійти, то це не основний функціонал продукту, тому його можна аутсорснути

котики будуть ловити мишей (кіберзагрози)

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

саундс лайк э план

Что-то чем дальше, тем хуже работает Файрфокс.
В прошлом году он временами не подгружал вкладки, если на старте несколько штук быстро пощелкать.
В последний месяц меню по правой кнопке часто открывается в левом месте экрана.
Сейчас еще и всю оперативу выжирает на ноуте за несколько дней работы. И на официальном сайте рекомендуют перезапускать))) Firefox may use more system resources if it’s left open for long periods of time. A workaround for this is to periodically restart Firefox.
support.mozilla.org/...​h-memory-or-cpu-resources

В результате флагманский проект Раста течет по памяти, и глючит.

Нужно было писать на Go

На докер посмотри. Под виндой особенно проблемы аналогичные. Очевидно что это закономерность — как эффективно писать код на C++ многие уже хорошо знают. Есть куча книг от Александреску, Маерса, Саттера и т.д. Типичные проблемы D, Go, Rust анти паттерны и бест практики ещё предстоит выявить. Хотя ИМХО FireFox стал в разы лучше после создания нового движка, но это связанно не с языком программирования — а с тем что его написали заново и выкинули все деприкейшены. Gecko написанный на C++ представлял из себя свалку кода миллиардом макросов. Вот где текла память по настоящему, особенно через плагин API.

Если вы пишете код С++ по книгам Александреску, то мне жаль тех, кто будет поддерживать этот код в будущем (среди этих несчастных можете оказаться и вы :) ).

С++ по книгам Александреску

це як збірник псалмів віруючих в хрести

В результате флагманский проект Раста течет по памяти

doc.rust-lang.org/...​con/what-unsafe-does.html

Rust is otherwise quite permissive with respect to other dubious operations. Rust considers it „safe” to:
...
* Leak memory

Ну ты же литкод решал даже в ресторанных туалетах на свиданиях, должен знать что есть memory leak, а есть orphaned memory, которые не лики, но и не освобождаются. Таков дизайн! ©

FF ще й не вміє Skype в браузері робити. В Edge, Chrome, IE web.skype.com працює, а от в FF ні.

Не думаю — у файрфоксі й інші відеоконференції погано працюють — затримка, розсинхронізація відео та аудіо.

Що мене наводить на думку, що жс і брузер не те місце, де треба робити такі речі

Але я мабуть занадто старий, бо пам’ятаю, коли скайп був нормальним софтом і міг працювати на 5кбпс

Браузер — то не жс, а С++. Відео має йти напряму в нативні плагіни.

має

*повинно
Але інколи не виходить

Зробили собі проблему на рівному місці, бо в руках є крива стамеска, а зробити треба осцилоскоп

жс не може обробляти відео, бо він:
1) інтерпретується
2) не є реал-тайм
3) має збирач сміття
Тому будь-яке відео, що Ви бачите, іде з нативного коду.

жс не може обробляти відео, бо

www.google.com/...​ editing on js in browser
Unfortunately it can

І навіть попри ті перепони, що ви вказали, люди будуть його використовувати для того, що він призназначений робити

А можна в сорцах десь побачити цю обробку відео?
Бо люди часто кажуть те, що не розуміють.

Це той випадок

Я мав на увазі WASM

Я мав на увазі WASM

This? en.wikipedia.org/...​iki/Open_Watcom_Assembler

Уже давно пора пацифиздить веб-школоту, которая даже не знает, что имя уже занято...

Ще бракувало загадати TASM...

Давно так не смеялся))

FASM ахуєнний

Ніколи на ньому не писав, але так, згадав, що коли він з’явився то про нього схвально відгукувалися. Але це було вже значно після MASM/TASM/WASM.

Я про нього з книжок/статей Кріса Касперські дізнався. Ну і ще демосценери багато про нього писали (хтось пам’ятає hugi.de?). В старі добрі часи він мені чомусь набагато більше за MASM зайшов.

цитата из readme:

Android’s H.264 decoder compiled with Emscripten to JavaScript, then further optimized with Google’s JavaScript closure compiler and further optimized by hand to use WebGL

Как я понимаю, то, на что вы дали ссылку — это исходники Android’s H.264 decoder.

mbebenita.github.io/Broadway/foxDemo.html

Достаём кишки из

mbebenita.github.io/Broadway/mp4.js

      /* Decode Pictures */
      var pic = 0;
      setTimeout(function foo() {
        var avc = this.avc;
        video.getSampleNALUnits(pic).forEach(function (nal) {
          avc.decode(nal);
        });
        pic ++;
        if (pic < 3000) {
          setTimeout(foo.bind(this), 1);
        };

avc.decode(nal); — точка интереса.

это они на первых 3000 фреймах рекурсией разгоняются? а потом — вжуххх

Трошки раніше

Я помітив, що щось не так, коли замість оновлення старого додатку на делфях і з вбудованими asm оптимізаціями, вони викатили на win нову широку фігню з рекламою
І тоді ж почались проблеми з апі на старому клієнті

Склалось таке враження, що вони втратили ключових розробників, що могли вносити правки в старий клієнт
Ну а далі пакращєння пішли з прискоренням

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

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

А у нас местная инфраструктура сделала всё, чтобы задавить файрфокс, хорошая треть сайтов только делают вид, что работают на файрфоксе. То клиент банка пишут, что трудности с логином под файрфоксом, мы решаем проблему ... уже 3 месяца (они решили, но все уже ушли с FF), то сервис электронной доставки документов под файрфоксом просто перестаёт работать, и т.д. Например, онлайн телевидение — только хром, немного FF — только половина функциональности доступна, и вообще без edge.

гугель доплачивает

Достатньо 2 дні поперемикатись між лінкедіном, двома поштами, слаком та доу, час від часу схлопуючи ноут в сон, щоб працювать стало дууже важко.

их хваленый гпу рендерер у меня не работает — рисует какойто прямойгольник сверху

В результате флагманский проект Раста течет по памяти, и глючит.

А чому вм його не назвали флагманським проектом плюсів. чи жс, чи XUL?

Не знаю, не сидел на нем так долго. Но там С++, и он течь не должен. А у Файрфокса половина на расте, поэтому течет.

Мені здаєтьтся насправді тече JS лайно на сторінках що дивишся і це не те щоб проблема браузерів.

У меня браузеры пухнут в основном по двум причинам:
1. Youtube и видео, которые не закрываю, чтобы по правой колонке открыть сразу несколько других. Кнопки «забыть сам ролик» там нет, поэтому такая страница может держать пару сотен мег влёгкую.
2. Facebook. Я не знаю, что он делает, что набирает в себя, но промотал сотню постингов в ленте — всё, гига 2-4 сожрало влёгкую. На лапте с 8GB это просто страшно.

2. Facebook. Я не знаю, что он делает, что набирает в себя, но промотал сотню постингов в ленте — всё, гига 2-4 сожрало влёгкую. На лапте с 8GB это просто страшно.

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

Я у жены на ноуте запускаю FF в memory caging режиме через вот это:
github.com/...​eldesign/process-governor

Отдаю 2.5-3Gb, память течёт потом доходит до предела, она вся освобождается и опять течёт. Правда иногда таки FF приходит полный писец в клетке. Но в любом случае это гораздо лучше, когда выжирается 8 гиг ОЗУ и свопа в два раза больше.

Отличный тул. Спасибо за наводку.

Earlyoom + Chrome працює нормально

момент освобождения не продуман от слова совсем

В жс з цим все ну дуже непросто і криворукість жсерів тут додає гємору розробникам браузерів

На лінуксах, до речі, з цим менше проблем ну і наведений функціонал обмеження на ram є з коробки
При чому хроміум жере набагато більше рам на умовних 20 відкритих вкладках

Фиг — рефрешу вкладку с линкедином — память все так же выжрана, и тормоза все те же.
Браузер течет.

Стрелочкой рефрешил в панели.
Браузер уже закрывал, так что — сегодня не узнаем.

Ніколи нею не користуюсь, бо прибираю з інтерфейсу.
Краще побачити 2 символи в упл

Не знаю з чим воно пов’язано і чому так, але якщо перейти в адресну строку (alt+d) і натиснути ентер, то проблемна сторінка перестає бути проблемною

Ну ФФ еще и глючит. Вот опять на старте вкладку не подгрузил. И фиг с ней потом что-то сделашь — рефреш тоже не работает. Движок думает, что вкладка пустая, а в списке — иконка от слака, который там в оригинале должен быть. Если перезагрузить ФФ — то он ее откроет.

Итого: Раст никак не гарантирует корректность работы приложения.

До чого тут Rust до всього FF, якщо читаю

Mozilla used Rust to build Stylo, the CSS engine in Firefox (replacing approximately 160,000 lines of C++ with 85,000 lines of Rust).

blog.mozilla.org/...​omes-the-rust-foundation

і ще, многабукафф
manishearth.github.io/...​d-c-plus-plus-in-firefox

27.7% С++, 26,3% JS, 11,6% HTML, 9.6% Rust, але Rust тормозить і тече, а С++ збс. :) :)

Ну тоді що є серйозне, написане на Расті?
І чому усе інше на ньому не переписали в браузері?

Итого: Раст никак не гарантирует корректность работы приложения.

Отказываюсь в это верить!

Итого: Раст никак не гарантирует корректность работы приложения.

Ламборжині не гарантує дотримання водієм ПДР.

Ну а толку?
Надо саммонить Камышана.

саммонить Камышана

нічого не зрозумів, перефразуй

Він весь час каже, що Раст допомагає (най гарантує) коректність написаної програми.

Якщо порівнювати з С++, то побочок та UB набагато менше

За моїм досвідом 80% багів в логіці. А може — й 90%.
Тому саме цей момент взагалі нічого не вирішує.

так от Rust провіряє коректність логіки, якщо не логічно з його точки зору, то лаконічно матюкнеться, і навіть з підказкою, а не викине простиню на 20 сторінок як С++ компілєр

так от Rust провіряє коректність логіки

Ти ж щойно писав, що не перевіряє:

Ламборжині не гарантує дотримання водієм ПДР.
так от Rust провіряє коректність логіки

Корявые требования (реквайременты) тоже он проверяет?

для валідації вимог є інші інструменти

такі як для валідації вимог С++ проектів

Я жодного не знаю.
Котрими Ви користуєтесь для С++?

Питання до хлопа що писав

Корявые требования (реквайременты) тоже он проверяет?
Питання до хлопа що писав

А плохую реализацию требований (с ошибками) Раст тоже проверит? Понятие «логика программы» — очень широкое.

Решает. Если ты знаешь, что у тебя в языке нет доступа к raw pointers, есть автоматическое управление памятью, нет UB, автор кода (и код ревьюверы) могут фокусироваться на логике, а не на том, чтоб искать лажу в коде, которая выглядит как конфетка, а на самом деле триггерит UB.

И толку — файрфокс все равно глючит?

Увы, в ход идут bad faith аргументы, мне на это нечего ответить.

В большистве языков

нет доступа к raw pointers, есть автоматическое управление памятью, нет UB

при этом софт кривой. Не помогает.

По моему опыту — вполне помогает

То есть, софт на С++ более глючный, чем на других языках?

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

Перекидываться пассивно-агрессивными общими фразами, не относящимися к Rust большого желания нет, надеюсь, понимаете.

название топика посмотри еще раз

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

Устройте видео-стрим сессию Q&A. Я пришлю свои вопросы и присоединюсь к просмотру. Можно и донат открыть будет для желающих )

Устройте видео-стрим сессию Q&A. Я пришлю свои вопросы и присоединюсь к просмотру. Можно и донат открыть будет для желающих )

Подумаю. Никогда не делал стримов такого формата. Есть что-то для примера посмотреть?

Подумаю. Никогда не делал стримов такого формата. Есть что-то для примера посмотреть?

Лично не делал. Видел только на ютубе стримы с донатами. Вот пример «урбанисты собирают деньги на адвокатов задержанным в Мск» www.youtube.com/watch?v=qgYHxeW2sqY
В принципе достаточно начать стрим на ютубчике, плиткой расставить спикеров (что бы всех было видно) и прилепить ссылочку типа donation alerts www.donationalerts.com Не знаю только как счетчик поставить на видео поток, но наверное это несложно делается, раз счетчики доната есть уже у всех геймеров ) Возможно этим занимается стриминговая софтинка.

Мне на донаты пофиг, главное что было полезно людям. У вас нет случайно примера на технический стрим такого формата, который бы был вам интересен? Сбор денег на ремонт провала — не совсем моя тематика :)

У вас нет случайно примера на технический стрим такого формата, который бы был вам интересен?

Есть по C++: www.youtube.com/watch?v=3tKg2fiiaD0 В таком стриме есть live-chat всегда, где можно общаться. Так же, разумно будет собрать вопросы предварительно на форуме, это даст пищу на первые час-полтора, и еще полчасика оставить на Q&A.

Это кому-то нравится? Я посмотрел минут 10, сильно скучно и уныло.

Это кому-то нравится? Я посмотрел минут 10, сильно скучно и уныло.

Людей мало, поэтому уныло. Перед аудиторией презентация/диалог намного динамичнее развивается.

Дивись, виходячи з умов написання нового коду (не розгрібання, підтримка легасі), та накладених обмежень (CPU, OS, memory, швидкість виконання та розробки і т.д.) я би йшов від простішого до складнішого таким шляхом:
Вирішується на С (так: берем С)?
Ні -> вирішуєтся на Rust (так: берем Rust )
Hі -> вирішуєтся на Go (так: берем Go)
Hі -> вирішуєтся на Python(так: берем Python)
Hі -> вирішуєтся на Qt (так: берем Qt )
далі Java, PHP, D ....
C++ як ласт ресорт, коли всі інші варіанти відпали

Я мав на увазі, що якщо управління пам’яттю та UB то така проблема, що не дає можливості якісно ревьювить код, то на мовах, де цих проблем нема, рев’ю коду буде більш якісним:

Решает. Если ты знаешь, что у тебя в языке нет доступа к raw pointers, есть автоматическое управление памятью, нет UB, автор кода (и код ревьюверы) могут фокусироваться на логике, а не на том, чтоб искать лажу в коде, которая выглядит как конфетка, а на самом деле триггерит UB.

Відповідно, сам продукт має бути більш якісним. Якщо якість продукту не залежить від мови програмування — то посилка, що керування пам’яттю чи UB заважає рев’ювить код — неістинна.

Hі -> вирішуєтся на Qt (так: берем Qt )
C++ як ласт ресорт, коли всі інші варіанти відпали

рукалицо

Я бачу три і один сумнівний

KEKW

склади свій ряд,
критиканствувати легко

C++? По-типу все остальное это явно дело рук человеческих, а С++ дело рук рептилоидов.

а тепер дивимся бойлерплейт для С++ і офігіваєм:
aws.amazon.com/...​ing-the-c-lambda-runtime

CGI повертається!

bleeding edge technology:

So serverless is essentially a return to the PHP/CGI execution model... What’s changed to turn a bad idea into a good idea again?
news.ycombinator.com/item?id=16407290

You’ve just invented the next big thing: Serverful Architectures!
news.ycombinator.com/item?id=23368536

а що там на виході після всіх цих компіляцій? просто джаваскрипт? я чого цікавлюся: пишу іноді для своїх студентів демки (наприклад fbeilstein.github.io/simplest_smo_ever ), але при цьому не знаю джаваскрипта від слова зовсім (гуглю як цикли писати, ну і за дикий говнокод соромно, хоч я його нікому й не показую), то може мені було б зручніше транслювати туди з чогось іншого, може там граблів менше. правда, мені ще важливо, щоб той результат збирався в один самостійний файл (і без ніякої серверної частини) — так треба, щоб мені було потім простіше вмонтовувати це все в GoogleColab (я там зберігаю відразу теорію з формулами, код на Python для прикладів і отакі живі демо для інтуїції).

що там на виході після всіх цих компіляцій

веб асемблер

Пітон на стероїдах — це nim.
Rust все таки складніше і в освоєнні, і в написанні так, щоби боров чекер був щасливий.

Завершён процесс создания организации Rust Foundation
www.opennet.ru/...​nnews/art.shtml?num=54555

Для http-сервера Apache будет подготовлен TLS-модуль, написанный на языке Rust
www.opennet.ru/...​nnews/art.shtml?num=54519

Таке ще пишуть:

In November 2020, Amazon Web Services announced its commitment to Rust’s continuation by hiring some people who had a close relationship with the Rust language development. AWS claimed to be expanding the use of Rust in the development of its own products.

aws.amazon.com/...​and-how-wed-like-to-help

en.wikipedia.org/...​ffs_and_a_Rust_foundation

Потрібна думка Валялькіна. Що вчити: Раст чи Го?

Electron.js же -> dou.ua/forums/topic/32657 :-) Хотя боюсь Валялкин со мной не согласится)))

Позитивная новость, теперь сломать Апаче через библиотеку, реализующию TLS, будет намного сложнее :)

безпечність має бути безпечною

Не стоиn парится по этому поводу. Просто модный язык как до недавнего времени был Goland. Дальше точно так же займет свою узкую нишу — системные утилиты и иже с ними.

Там явный «гений бенчмарков» писал.

Посмотрел первый попавшийся тест: benchmarksgame-team.pages.debian.net/...​rksgame/fastest/rust.html

«reverse-complement»:
— в коде рaста чел пользует mm_shuffle_epi8(), _mm_and_si128() и тому подобные быстрые штуки
— в коде C чел гоняет циклы с посимвольными сравнениями

«Ч» — честность.

В общем, каждое нубо хочет понаписать бенчмарков. Удивительно, что у него жаба с C лишь ~ на равных — а не быстрее.

Если при компиляции С или С++ выставить правильные ключики и не писать код, как 7 летний ребенок, то компилятор сам вставит где нужно эти SSE и AVX.

Когда у чела в коде такое: «while(*front_Pos==’\n’ && front_Pos<=back_Pos) front_Pos++;» — компилятор уже ничего никуда не вставит.

П.С. Больше склоняюсь к дурачку. :)

while(*front_Pos==’\n’ && front_Pos<=back_Pos) front_Pos++;

чисто із цікавості — а що з цим кодом не так?
Єдине, до чого можу докопатись, це те, що умови треба переставити, а не то вилізе за межі back_Pos

while(front_Pos <= back_Pos && *front_Pos == ’\n’) ++front_Pos;

ну або так, якщо компілятор зможе це якось краще оптимізувати

for( ; front_Pos <= back_Pos && *front_Pos == ’\n’; ++front_Pos);
чисто із цікавості — а що з цим кодом не так?

Как минимум:
— двойные условия плохо хаваются «бренч-предикторами»
— «<=» часто работает медленнее, чем «>» (в зависимости от компилятора и оптимизации)
— желательно совместить пост-инкремент с одной из проверок
+ ещё всякие методы ускорения (типа, разворачивания цикла, итп), в которые я не буду вдаваться

Это, если пытаться оптимизировать этот код.
Но проблема в том, что сам концепт посимвольного пробегания массива с проверками в цикле — ущербен (и в раст-тесте такого нет, из-за чего он существенно быстрее).

от цікаво, Rust гарантує, що не буде вильоту за межі масиву (секюрність), а СРР не повинен?

Хоча, перформанс не завджди є вимогою, а там де є, то Rust наступає плюсам на п"ятки (HFT, blockchain)

Плюси ще вільно пасуться в геймдеві , і аутомотів (та й там де купа легаці коду).

Я би на нові проекти розглядав або Go або Rust, в залежності які вимоги до проекту та коду.

Плюси ще вільно пасуться в геймдеві , і аутомотів (та й там де купа легаці коду).

Ниша «плюсов» — крупные (как правило, десктоп) проекты, где требуется скорость, ООП и портабельность.

Ниша «си» — быстрый/производительный небольшой и портабельный код. В таком, обычно, у разработчика нет проблем с индексами за пределами массива, прочим мемори-менеджментом.

А вот где ниша для «растa» — для меня пока неясно. Да и синтаксис выглядит крайне мутно, (а-ля, лишь для фриков). В общем, не взлетит...

Ниша «плюсов» — крупные (как правило, десктоп) проекты,

десктоп пішов у минуле, рулить веб і хмара,
про хмару Rust vs C++ тільки що написав вище
dou.ua/...​rums/topic/30864/#2060633

десктоп пішов у минуле, рулить веб і хмара,

Лишь в мире хипстеров и аутсорса всякого формошлёпского хлама в страны африки. :)

Ничего реально серьёзного/критичного (и денежного) — «облакам» всё ещё не доверяют. А для веба — делают лишь примитивное «рид-онли» отображение.

десктоп пішов у минуле

омг. ванга

В GCC 7 оптимізатор розвалили, досі не поправили. Сидимо на 6.5, бо є важливіші проблеми, ніж розбиратися і пеерписувати.

Более интересные новости по теме статьи.

Компания Bluefruit software 20 лет разрабатывает софт для встраиваемых систем. В ней работает автор блог поста статьи „про степень пригодности Rust для встраиваемых систем”

There are three main types of bugs that Rust avoids:
— Memory bugs
— Concurrency bugs—specifically „data races”
— Consequences of Undefined Behaviour

What’s not great about Rust?
— Target support
— Compile time
— Learning and training
— What about real-time and Rust?

...It’s worth noting that in embedded, it’s important to fail early. Rust forces software to be correct at compile time. In other languages, issues may not be identified until a prototype is in the field or when the product has shipped. The discipline needed for development in Rust has the potential to reduce the cost of testing prototypes and the need for fixes after deployment....

Is Rust ready for embedded software?
Posted 5th September 2019 by Emily
www.bluefruit.co.uk/...​dy-for-embedded-software

Так и не понял, из-за чего тут возник «дружный срач» на костях предполагаемого трупа (не убитого медведя), не понятно из-за чего. Если кто пропустил новость, то вот она вам.

Основываясь на этой работе, Mozilla и Rust Core Team рады сообщить о создании фонда Rust. Наша цель — к концу года завершить первую итерацию создания фонда.
Первой задачей фонда будет то, в чём Rust уже хорош: получении владения (ownership). Но на этот раз — реальный ресурс, а не что-то в программе. Различные торговые марки и доменные имена, ассоциированные с Rust, Cargo и crates.io перейдут фонду, который также возьмёт на себя финансовые расходы на их поддержку. Мы рассматриваем эту итерацию только как начало. Существует множество точек роста роли фонда и мы будем рады изучить их в будущем.

habr.com/ru/post/515712

Ну чьо пацани, не очкуєм:

Post-Mozilla Rust: The Future of the Rust Language

With Mozilla shrinking in total employees, what is going to happen with Rust?
Image for post

Recently Mozilla announced and enacted a sizeable number of layoffs, citing the COVID-19 pandemic. Many within the Rust community at large began to worry about the future of the beloved Rust programming language.
There are over 5000 open issues on GitHub, the Rust-based Servo team is no more, and some of the internal Mozilla contributors to Rust have lost their jobs!
As with any major news, things that can affect a programmer’s happiness are always going to cause a stir online. But guess what?

Rust is going to be okay!

Microsoft Loves Rust ...
Amazon Loves Rust ...
Google Loves Rust ...
npm Loves Rust ...
Many More Companies Love Rust ...
Developers Love Rust ...

medium.com/...​ust-language-61a5cfb1f615

Як в мультику „Весь мир за” www.youtube.com/watch?v=iYgUPQ8jMAA

Я помню также успокаивали когда накрывался медным тазом передовой XUL, говорили, что скоро Qt умрёт и везде будет один XUL. www.webopedia.com/TERM/X/XUL.html . Прошло 15 лет, уже никто не помнит что такое XUL %) В 2030 — что такое rust? Это то что у тебя на порогах в машине.

ти схожий на брюжащєго старікашку

Ну слава боху не на happy idiot. Это называется реалист.

Просто нейронку хорошо натренировал :)

це мало впливає та теоретичну межу передбачування,
до пророцтва це не має відношення.

Microsoft Loves Rust ...
Amazon Loves Rust ...
Google Loves Rust ...
npm Loves Rust ...
Many More Companies Love Rust ...
Developers Love Rust ...

напомнило онекдот: «А Руст вас всех ненавидиииит»

фальшива проекція власного его

что ты все про себя да про себя

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

This is a short ad of a Rust programming language targeting experienced C++ developers...
1.
....Rust compiler tracks aliasing status of every piece of data and forbids mutations of potentially aliased data...Rust doesn’t allow doing stupid things.....

2.
The counter variable lives on the stack, and a pointer to these stack data is shared with other threads....Rust allows doing dangerous, clever, and fast things without fear of introducing undefined behavior....

matklad.github.io/...​o-beautiful-programs.html

2.
The counter variable lives on the stack, and a pointer to these stack data is shared with other threads....Rust allows doing dangerous, clever, and fast things without fear of introducing undefined behavior....

О! Это просто образец мегатупости, когда в руки дали управление потоками и не объяснили что это такое и как не стоит делать. Это ж надо родить такой выражденный кейс, который в здравом уме никто использовать не будет и этим гордится. На С эта же программа будет не намного больше и такой же безопасной ... и бестолковой.

На С эта же программа будет не намного больше и такой же безопасной

Можно привести пример кода?

Я искренне пытался сделать её длинее и умнее чем на расте, но не смог, получился супер-короткий эффективный код %)

#include <stdio.h>

int main()
{
    int total = 0;

    #pragma omp parallel shared(total) num_threads(10)
    {
        #pragma omp atomic
        total++;
    }

    fprintf(stdout, "total=%d\n", total);

    return total;
}

Компилировать:

gcc -fopenmp crulez.c -o rustsuxx
[email protected]:~# ./threads
total=10

Если растаманы не могут без мьютекса, там где его можно прилепить, как пятую ногу слону и создать на стеке pthread_mutex_init()/pthread_mutex_lock()/pthread_mutex_unlock()

Сенкс, не знал про openmp, выглядит интересно.

       #pragma omp atomic
        total++;

Как я понимаю, omp atomic это то, что делает эту операцию безопасной в многопоточной среде.

Я покажу пример где проявляется небезопасность С.

Добавим итераций, чтоб повысить шанс гонки (итерации были в исходном примере на раст):

int main()
{
    int total = 0;

    #pragma omp parallel shared(total) num_threads(10)
    {
        int i;
        for (i = 0; i < 1000000; i++) {
          #pragma omp atomic
          total++;
        }
    }

    fprintf(stdout, "total=%d\n", total);

    return total;
}

Запускаем, выдает

total=10000000

Предположим, кто-то забыл напиать

pragma omp atomic
. Попробуем его удалить и снова запустить
% gcc -fopenmp crulez.c -o rustsuxx

% ./rustsuxx                       
total=1793787

Компилятор довольно схавал и программа выдала неверный результат. Вся безопасность программы полагалась на good intention разработчика, который может проебаться, недосмотреть, или вообще быть не в курсе, что такая вещь как race condition существует.

Раст просто не позволит совершить такую ошибку. Доступ к общей переменной из разных потоков будет возможен либо через мьютекс (что показано на примере), либо через безопасные атомарные операции (например, через doc.rust-lang.org/...​mic/struct.AtomicU64.html).

Вся безопасность программы полагалась на good intention разработчика, который может проебаться, недосмотреть, или вообще быть не в курсе, что такая вещь как race condition существует.

Зато С разработчик может быть в курсе того, что на многих платформах арифметические операции с памятью атомарные и может заставить компилятор их использовать, например, через встроенные bultins: __atomic_add() и не использовать мьютексы, которые как удар кувалды по яйцам, так и стандартные атомики, которые везде используют implicit barriers and fences, которые уже лучше, но всё равно, как удар сокирой по яйцам.

rust — это как детские штанишки, некоторые из них вырастают, а некоторые растягивают до взрослого размера. В расте тесно, как клаустрафобам в лифте.

Зато С разработчик может быть в курсе того, что на многих платформах арифметические операции с памятью атомарные и может заставить компилятор их использовать, например, через встроенные bultins: __atomic_add()

Если б только в Rust была возможность использовать эти самые атомарные операции и контролировать как memory barrier и fence расставлены вокруг них... А надо же, вот же она: doc.rust-lang.org/...​td/sync/atomic/index.html

All atomic types in this module are guaranteed to be lock-free if they’re available. This means they don’t internally acquire a global mutex.

и не использовать мьютексы

Прикинь, есть операции, которые не могут быть атомарно выполнены процесором и требуют синхронизации мьютексом. Пример по ссылке демонстрирует, как его использовать.

Данный кейс может быть запилен атомиками:

use crossbeam::scope;
use std::sync::atomic::{AtomicU64, Ordering};

fn main() {
  let mut counter = AtomicU64::new(0);

  scope(|s| {
    for _ in 0..10 {
      s.spawn(|_| {
        for _ in 0..1000000 {
          counter.fetch_add(1, Ordering::Relaxed);
        }
      });
    }
  }).unwrap();

  let total = counter.get_mut();
  println!("total = {}", total)
}

Запустить: play.rust-lang.org/...​f10531d6ec67abc714968fe15

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

use crossbeam::scope;

fn main() {
  let mut counter = 0;

  scope(|s| {
    for _ in 0..10 {
      s.spawn(|_| {
        for _ in 0..1000000 {
          counter+=1;
        }
      });
    }
  }).unwrap();

  let total = counter;
  println!("total = {}", total)
}

error[E0499]: cannot borrow `counter` as mutable more than once at a time
  --> src/main.rs:8:15
   |
6  |     scope(|s| {
   |            - has type `&crossbeam_utils::thread::Scope<'1>`
7  |       for _ in 0..10 {
8  |         s.spawn(|_| {
   |         -       ^^^ mutable borrow starts here in previous iteration of loop
   |  _______|
   | |
9  | |         for _ in 0..1000000 {
10 | |           counter+=1;
   | |           ------- borrows occur due to use of `counter` in closure
11 | |         }
12 | |       });
   | |________- argument requires that `counter` is borrowed for `'1`
Раст обидился и не дал скомпилить.

play.rust-lang.org/...​4320268d25c027fc5ca100b88

Если б только в Rust была возможность использовать эти самые атомарные операции и контролировать как memory barrier и fence расставлены вокруг них... А надо же, вот же она: doc.rust-lang.org/...​td/sync/atomic/index.html

Они не то называют fences, ну да бох с ними. Проблема в том, что их atomic не может не вызывать команду lock на x86, чтобы остановить все остальные процессоры и ядра, а это болезненная операция. Но при соблюдении ряда условий, довольно простых, как выравнивание памяти на размер типа и прочее может lock не вызывать, но раст в это не умеет и перестраховывается.

Как и с ARM’ами, например ARMv8 (AARCH64) поддерживает два типа атомических операций (старый тёплый ламповый медленный LLSC en.wikipedia.org/...​ad-link/store-conditional — встречайте его в расте) и новый ультрабыстрый Large System Extensions (LSE) как в x86, которого раст боится, т.к. нет универсальности.

P.S. Когда все уже забыли годами про это, раст таки что-то попытался сделать два месяца назад: github.com/...​rust-lang/rust/pull/72324 , но в x86 не сделали.

Они не то называют fences, ну да бох с ними. Проблема в том, что их atomic не может не вызывать команду lock на x86, чтобы остановить все остальные процессоры и ядра, а это болезненная операция. Но при соблюдении ряда условий, довольно простых, как выравнивание памяти на размер типа и прочее может lock не вызывать, но раст в это не умеет и перестраховывается.

Спасибо, где можно про это детально почитать? Есть пример на С, которые это демонстрирует?

На C можешь поискать „gcc atomic builtins”, „__attribute__(aligned(x))”.

Почитать про синхронизации тредов (8.4 THREAD SYNCHRONIZATION), атомики (12.7.2.2 C++11 atomic support):
www.intel.com/...​s-optimization-manual.pdf

Атомики очень подробно:
software.intel.com/...​2d-3a-3b-3c-3d-and-4.html
CHAPTER 8 MULTIPLE-PROCESSOR MANAGEMENT

Есть поверье, что если ты прочтешь три раза документ в последней ссылке, все 5000 страниц, то тебе будут поклоняться как божеству %) Я пока только на втором цикле на 2653 странице.

Этот пример компилируется с lock:

godbolt.org/z/c55afa

        lock            xadd    qword ptr [rsp], rax

Как я сказал, он не может этого не делать, rust не поддерживает модель программирования, когда ты можешь знать что делаешь.

GCC зі всіма варіантами атоміків і моделей пам’яті генерує LOCK ADD [total], 1

total вирівняний по межі сторінки (з запасом).

Якщо в асемблерному лістингу забрати LOCK і перекомпілювати, результат очікувано некоректний.

Як в цьому прикладі позбутися LOCK?

fence команда + inc.

Щось в мене ця магія не працює.

А можна при нагоді кусок робочого асемблера в студію? Бо або я гальмую, або там не все так просто.

GCC з -O1 генерує щось таке:

main._omp_fn.0:
.LFB374:
        .cfi_startproc
        movl    $100000, %eax
.L2:
        movq    (%rdi), %rdx
        lock addl       $1, (%rdx)
        subl    $1, %eax
        jne     .L2
        rep ret
        .cfi_endproc

Викидання LOCK і різноманітні танці з бубнами з MFENCE і ADD/INC ні до чого доброго не приводять. Дописався до самопального спінлока, в результаті час виконання став в 10 разів повільнішим, і я вирішив, що досить на вечір п’ятниці.

Ось версія з MFENCE + INC (яка не працює):

main._omp_fn.0:
.LFB374:
        .cfi_startproc
        movl    $100000, %ebx
        movq    (%rdi), %rdx
.L2:

        mfence
        incl    (%rdx)

        subl    $1, %ebx
        jne     .L2
        rep ret
        .cfi_endproc

Ну і версія зі спінлоком, яка працює, інкремент без префікса LOCK, але в результаті все повільне.

main._omp_fn.0:
.LFB374:
        .cfi_startproc
        movl    $100000, %ebx
        movq    (%rdi), %rdx
.L2:
        movl    $1, %eax
        xchgl   %eax, 8(%rdi)
        testl   %eax, %eax
        jnz     .L2

        incl    (%rdx)

        movl    $0, %eax
        xchgl   %eax, 8(%rdi)

        subl    $1, %ebx
        jne     .L2
        rep ret
        .cfi_endproc

Коротше, здаюся на сьогодні.

Приношу извинения, запутал в начальном посте и сам запутался :)

В современных процессорах lock захватывает только cacheline и не выставляет сигнал lock на шине. Поэтому можно считать, что на архитектурах до SkyLake это быстро, а на архитектурах выше — это очень быстро, т.к. у них есть ещё и сериализатор для lock.

Тот способ что я предложил для strong ordered memory, например, write-combine. Если написать префикс lock для такой памяти, то процессор будет лочить всю шину. Для кешируемой не подойдёт, что впрочем твои тесты наглядно показали.

Ещё раз сорри за заблуждение.

Что если несколько виртуальных адресов ссылаются на один и тот же физический адрес памяти (типа shared memory между двумя разными процессами)?

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

Процессор работает только с физическими адресами, все виртуальные транслируются через TLB, а та в свою очередь наполняется из таблиц и директорий памяти: en.wikipedia.org/...​nslation_lookaside_buffer

Мало того, одну и ту же память можно замапить много раз, сколько хватить виртуального адресного пространства процесса. Хоть одну страницу на всё виртуальное пространство. Например в драйверах GPU может быть 3 маппинга одной и той же памяти, как кешируемая, как некешируемая и как, например write-combine форма некешируемой памяти. Для разных видов работы.

Прикинь, есть операции, которые не могут быть атомарно выполнены процесором и требуют синхронизации мьютексом. Пример по ссылке демонстрирует, как его использовать.

А прикинь, кроме мьютекса есть ещё другие объекты синхронизации. Мьютекс, например, в линуксе — это убийство производительности, в QNX используется lock contention механизм, только если мьютекс залочен, то происходит трип в ядро для ожидания, но даже с этим механизмом например для задачи с одной переменной — это оверкилл. А оказывается, что есть ещё такая вещь, как spinlock, которая не делает трипы в ядра, а используя встроенные атомарные свойства процессора просто жрёт процессор в ожидании и это оправдано когда защищать нужно парочку операций, а не тяжелую логику, для которых пригодень мьютекс.

Но ты не поверишь, на собеседовании не знают разницы, а также гибридных моделей синхронизаций 99 из 100 человек. Так что в жопу тот литкод, люди не знают базовых вещей, которые существуют уже больше полувека. А раст позволяет этим людям держаться на плаву.

А оказывается, что есть ещё такая вещь, как spinlock, которая не делает трипы в ядра, а используя встроенные атомарные свойства процессора просто жрёт процессор в ожидании и это оправдано когда защищать нужно парочку операций, а не тяжелую логику, для которых пригодень мьютекс.

Ты ж сам понимаешь, что все это добро на любой вкус давно запилено в Раст в стандатной библиотеке или в внешних. Бери используй что надо.

Но ты не поверишь, на собеседовании не знают разницы, а также гибридных моделей синхронизаций 99 из 100 человек. Так что в жопу тот литкод, люди не знают базовых вещей, которые существуют уже больше полувека. А раст позволяет этим людям держаться на плаву.

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

которую можно будет потом оптимизировать, если надо

Как занимающийся оптимизациями, скажу, что потом не наступает никогда. А если наступает, то это стоит очень и очень дорого.

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

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

Это можно запилить

use crossbeam::scope;

fn main() {
  let mut counts: Vec<u64> = vec![0; 10];
  
  scope(|s| {
    for c in counts.iter_mut() {
      s.spawn(move |_| {
        for _ in 0..1000000 {
          *c+=1;
        }
      });
        
    }
  }).unwrap();

  let total: u64 = counts.iter().sum();
  println!("total = {}", total);
}

play.rust-lang.org/...​2d9444d2aa2dd2cd7a890641e

Т.е. раст защищает отдельные элементы, но не весь массив в целом? Просто как пример, на x86/x86-64 ты можешь использовать невыравненный доступ к памяти, например создать массив U64 по адресу, заканчивающийся с 1,2,3,4,5,6,7 цифрами. Всё будет работать, будет работать медленно, но будет до тех пор пока не используется многопоточный доступ, который будет писать и читать значения на границах cacheline по невыравненным адресам два раза, вначале кусочек по одному выравненному и кусочек по другому. Таким образом сделать race condition с соседними элементами.

Т.е. раст защищает отдельные элементы, но не весь массив в целом?

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

Просто как пример, на x86/x86-64 ты можешь использовать невыравненный доступ к памяти, например создать массив U64 по адресу, заканчивающийся с 1,2,3,4,5,6,7 цифрами. Всё будет работать, будет работать медленно, но будет до тех пор пока не используется многопоточный доступ, который будет писать и читать значения на границах cacheline по невыравненным адресам два раза, вначале кусочек по одному выравненному и кусочек по другому. Таким образом сделать race condition с соседними элементами.

Не знаю как это воспроизвести. Vec в раст не дает контроля за выравниванием. Можно запилить с помощью unsafe rust, но гарантии безопасности на этот код, ясное дело, распространяться не будут.

так и стандартные атомики, которые везде используют implicit barriers and fences, которые уже лучше, но всё равно, как удар сокирой по яйцам.

Мнэээ...
atomic_fetch_add_explicit(&x, v, memory_order_relaxed);

или в твою среду ни C11, ни C++11 не завезли?

Или ты о чём-то совсем другом?

Also

[email protected]

завязывай с этим, least privilege principle епта :)

У меня индульгенция на рута. Мне можно.

Да, милости просим твой мега-безопасный код на Си, на порку.

Подбросим «дровишек».
TLDR; В Linux ядре будет поддержка драйверов написанных на Rust.

Линус Торвальдс подключился к обсуждению возможности добавления в ядро Linux средств для разработки на языке Rust. Джош Триплет (Josh Triplett) из компании Intel, работаюдий над проектом до доведение языка Rust до паритета с языком Си в области системного программирования, предложил на начальном этапе добавить в Kconfig опцию для поддержки Rust, которая не приводила бы к включению в число зависимостей компилятора Rust при выполнении сборки в режимах «make allnoconfig» и «make allyesconfig» и позволяла бы более свободно экспериментировать с кодом Rust. Аналогичный трюк был реализован при добавлении в ядро экспериментальной поддержки сборки в Clang в режиме оптимизаций на этапе связывания (LTO, Link Time Optimization), после которой планируется добавить и поддержку сборки с защитой потока выполнения команд (CFI, Control-Flow Integrity).

www.reddit.com/...​rnel_intree_rust_support

драйверов написанных на Rust.

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

Ох и не говори — это наглая и агрессивная реклама раст-а от Товальдса, просто форменное безобразие!

Линус Торвальдс подключился к обсуждению возможности добавления в ядро Linux средств для разработки на языке Rust.

«подключился»:
рустаманы в ядре: ща мы тут как подключим руст в ядро!
лт: воу-воу! полегче! сделайте опции правильные и примеры читабельные, шоб о5 херни не напороли как всегда

а так да, подключился

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

так пойди ним в переписку,

зачем?

use std::os::linux::kernel::driver::{read, write, open, close,ioctl};

Если раньше ядро линукса можно было собрать из исходников за пару минут, то теперь нужно будет ждать пару дней, пока компилятор Rust проведет все свои borrow check’и. В итоге развитие ядра линукс затормозится, т.к. только у самых упоротых растеров хватит терпения дождаться окончания компиляции исходников.

Даже и не говорите.... вот я например, да и вы, наверное, почти каждый день собираем ядро линукса. Ну ладно, раз в неделю уж точно...
Серьезная проблема однако !

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

Не поверите. Иногда приходится раз 5-7 за день пересобрать

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

Я запускаю джаву или что-то на джаве раз в квартал. Джава не нужна?

собрать из исходников за пару минут

Я собираю проект по несколько раз в день, в среднем 7-8 минут сборка.
Значит джавой нельзя пользоваться?

Это 100% означает, что джавой нельзя пользоваться. Я собираю свой проект на Go с нуля (не инкрементальная сборка) за 5 секунд. Инкрементальная сборка занимает полсекунды. Если бы сборка занимала 7-8 минут, то я бы давно забросил вносить изменения в такой проект, не дождавшись завершения компиляции. Теперь понятно, почему программы на Java развиваются черепашьей скоростью по сравнению с программами на Go.

А проект большой? Сколько файлов и сотен тысяч строк?

Проект очень даже солидный. Почитал немного библиотеки, очень хорошо поработал в плане увеличения производительности. Может пока что там не увидел, есть ещё одна тема как ускорить сервер, работающий с большими файлами — memory mapping. Она актуальна для работы с файлами, размеры которых коррелируют с объёмами оперативной памяти. Юзается в играх следующим образом: все файлы данных сшиваются в один большой цельный пак, и дальше когда нужен доступ к какому-то файлу, находящемуся в паке, лочится соответствующий кусок файла, и дальше доступ как к []byte. С чтением всё просто, если нужна запись, то лучше юзать буферизацию. Стандартный mmap слишком примитивный, вот тут github.com/edsrzf/mmap-go для примера более проработанный.

Там уже используется чтение из файлов через mmap — см. github.com/...​46281/lib/fs/reader_at.go

$ git clone https://github.com/VictoriaMetrics/VictoriaMetrics
$ cd VictoriaMetrics
$ find . -name *.go | wc
   1597    1597   83172
$ find . -name *.go | xargs cat | wc
 594935 2409381 19458477

1597 файлов с 594935 строками