×

Особливості 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

И теперь ЯП доступен в пресертифицированной RTOS системе.

Rust now available for Real-Time Operating System and Hypervisor PikeOS
The security-focused programming language Rust is now available for the real-time operating system and hypervisor PikeOS. For the use of applications on Rust basis no guest operating system and/or no interface is necessary such as POSIX: Applications can run directly on a native PikeOS instance......PikeOS is also pre-certified against many industry software safety standards such as DO-178C for avionics, EN 50128 and EN 50657 for rail, ISO 26262 for automotive, EN 61508 for industrial and IEC 62304 for medical.....
www.sysgo.com/...​tem-and-hypervisor-pikeos

люди пишуть (думаю що на кворі читав), що С++ стає мовою легасі, і скоро із розробниками буде зовсім біда як з Коболом.
Але С++ не помре

40x Faster! We rewrote our project with Rust!

* Fewer bugs due to Rust’s powerful compilation check and error handling.
* 66% improvement in language end-to-end compilation and execution performance.
* The performance of the language front-end parser has been improved by 20 times.
* The performance of the language semantic analyzer has been improved by 40 times.
* The average memory usage of the language compiler during compilation is half of the original Python version.

Ну с Питона очевидно. А вот по сравнению с C++ это уже интереснее...

Scala, Go і Rust залишаються мовами з найвищими медіанними зарплатами як у початківців, так і в досвідчених спеціалістів
dou.ua/...​y-report-devs-winter-2023

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

Наверное, АНБ встроили бэкдор в Rust, а в C не удалось встроить

В С встроить удалось, но оказалось, что в самом бекдоре закралась уязвимость buffer overrun.

«21-й век будет посвящьон вопросам безопасности и защите от взломов»
угу, а це хто фіксати буде?
en.wikipedia.org/wiki/Year_2038_problem

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

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

This function prints out the numbers that were stored in the Vec at initialization time (thus confirming that the data survived in meantime) and returns; after that, the module will be removed and its memory freed. There does not appear to be a way for module removal to fail — which occasionally needs to happen in real-world modules.

That is, to a first approximation, the extent of what can be done with Rust kernel modules in 6.1. Torvalds asked for something that could do “hello world” and that is what we got. It is something that can be played with, but it cannot be used for any sort of real kernel programming at this point.

Ошеломительные успехи Rust в ядре Linux! Ждем, когда у Линуса кончится терпение и он выпилит все растоподелки из ядра

кста, буфєр овєррун нєнаблюдаєццо

не зовсім,
www.phoronix.com/news/Linux-6.1-Released
So here we are, a week late, but last week was nice and slow, and I’m much happier about the state of 6.1 than I was a couple of weeks ago when things didn’t seem to be slowing down.

Of course, that means that now we have the merge window from hell, just before the holidays, with me having some pre-holiday travel coming up too. So while delaying things for a week was the right thing to do, it does make the timing for the 6.2 merge window awkward.

Ну вот так «хреново выпилил».

Вот когда сделают поддержку 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 нову широку фігню з рекламою
І тоді ж почались проблеми з апі на старому клієнті

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

І був на Delphi написаний :) тобто не у мові програмування справа.

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

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

А у нас местная инфраструктура сделала всё, чтобы задавить файрфокс, хорошая треть сайтов только делают вид, что работают на файрфоксе. То клиент банка пишут, что трудности с логином под файрфоксом, мы решаем проблему ... уже 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
root@mikenfs:~# ./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

root@mikenfs

завязывай с этим, 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 строками

И какая часть приходится на столь любимые вами «велосипеды»? Я там увидел, например, кастомную реализацию decimal))

Почти весь код состоит из «велосипедов» и «копипаст», т.к. лучше скопировать небольшой кусок кода из стороннего пакета либо написать свой велосипед, оптимизированный под конкретную задачу, чем пытаться приклеить скотчем с костылями стомегабайтную зависимость. См. medium.com/...​docker-image-983fb5912b0d

А как потом этот гуанокод саппортить? Когда используешь сторонние пакеты, то у них выходят новые версии с фиксами багов. При таком подходе эти баги придется фиксить руками. Впрочем гоферы видимо прутся от того, что делают кучу бессмысленной хрени))

зато бинарь маленький)

А как потом этот гуанокод саппортить?

Прикол в том, что на Go невозможно написать говнокод, в отличие от Rust, C++, Scala и Java.

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

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

При таком подходе эти баги придется фиксить руками.

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

Впрочем гоферы видимо прутся от того, что делают кучу бессмысленной хрени))

Куча бессмысленной херни — это 99% кода из всяких абстракций на Rust, C++, Scala и Java. Что касается Go, то там 99% кода имеет ясное практическое назначение.

...на Go невозможно написать говнокод, в отличие от Rust, C++, Scala и Java.

Ржу....
Да вы батенька фантазер!! Можете даже не верить моему 20 летнему опыту.... :))
Цитату повешу в рамочку. Хахахаха...

Можете даже не верить моему 20 летнему опыту....

У вас 20-летний опыт работы с Go или Rust?

20 лет backend-а, R&D в разных startup и legacy enterprise проектах различной сложности и объемов. Вполне знаю, про что говорю, поэтому посмеялся цитате.

Прикол в том, что на Go невозможно написать говнокод, в отличие от Rust, C++, Scala и Java.

Зато его можно успешно скопипастить.

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

Прикинь, делаешь зависимость на сторонний пакет и указываешь мажорную и минорную версию, которую надо.
Или Го не умеет в версии зависимостей?

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

А еще можно пойти и самому пофиксить баг в зависимости и заапстримить его. Гоферы не умеют в опенсорс?

Зато его можно успешно скопипастить.

Не понял — зачем копипастить говнокод из Rust, C++, Scala и Java в программу, написанную на Go?

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

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

Или Го не умеет в версии зависимостей?

Умеет — см. github.com/...​etrics/blob/master/go.mod

А еще можно пойти и самому пофиксить баг в зависимости и заапстримить его. Гоферы не умеют в опенсорс?

Чукча не читатель — чукча писатель? Может, еще раз прочитаете и осмыслите скопированную цитату, под которой оставили комментарий?

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

А еще можно пойти и самому пофиксить баг в зависимости и заапстримить его. Гоферы не умеют в опенсорс?

пробовали и знаем опенсорс, баг горит на проде, время рассмотрения пулл реквеста от дней до бесконечности, ждали и полгода пока PR примут. Могут просто закрыть PR и останетесь сами с собой и авторским багом. Держать еще тонну форков и сливать их потом с мастером немыслимо. Так что опенсорс не всегда приветлив к сторонним фиксам

Прикол в том, что на Go невозможно написать говнокод

Ты или наивен, или, что более вероятно, выдаешь желаемое за действительное))
пример из той же репы
github.com/...​ter/app/vmstorage/main.go
функция длиной в 360 строк — что это как не классический гуанокод?)
там же море select-ов по литералам вместо констант
например: case «/api/v1/write»: встречается в коде 7 (СЕМЬ) раз в
и такой срани там полно. И это то что бросается в глаза за 5 минут ковыряний)))
Вобщем как-то так: youtu.be/iFBU828ZzHE?t=18

функция длиной в 360 строк — что это как не классический гуанокод?)

Предложите лучший способ реализовать эту функцию.

там же море select-ов по литералам вместо констант

Объясните, чем селекты по константам лучше селектов по строковым литералам?

Предложите лучший способ реализовать эту функцию.

Легко — вынести данные и лямбды во внешний массив/список. И вместо этой простыни будет короткий цикл.

Объясните, чем селекты по константам лучше селектов по строковым литералам?

Мне казалось, что это очевидно даже для студента, ан нет...
1) если нужно изменить — то меняешь _один_ раз, а не _семь_
2) исключает тупые баги, типа поменял в 6 местах, а в одном забыл
3) намного проще смотреть pull-реквесты. Например, когда кто-то поменял, скажем в 3 местах, а остальные 4 провтыкал. И чтобы понять, что тут провтык, надо искать все вхождения...
4) в большинстве IDE легко получаешь список _ссылок_ на эту константу, что гораздо удобнее полнотекстового поиска, в котором будут и комментарии, и документация

Легко — вынести данные и лямбды во внешний массив/список. И вместо этой простыни будет короткий цикл.

Спасибо за интересный вариант. Несколько вопросов:

1) Сколько строк удалится и добавится в коммите, меняющем первый вариант на второй?
2) Как изменится сложность понимания получившегося кода?
3) Как изменится сложность внесения изменений в получившийся код?

Мне казалось, что это очевидно даже для студента, ан нет...
1) если нужно изменить — то меняешь _один_ раз, а не _семь_
2) исключает тупые баги, типа поменял в 6 местах, а в одном забыл
3) намного проще смотреть pull-реквесты. Например, когда кто-то поменял, скажем в 3 местах, а остальные 4 провтыкал. И чтобы понять, что тут провтык, надо искать все вхождения...
4) в большинстве IDE легко получаешь список _ссылок_ на эту константу, что гораздо удобнее полнотекстового поиска, в котором будут и комментарии, и документация

Спасибо за пояснения. Есть несколько вопросов по ним:

1) Как изменится сложность понимания кода, где вместо строковых литералов используются именованные константы, во время его изучения на github, gitlab или подобных инструментах? Например, что легче понять:

case "/api/v1/write": ...

Или

case constants.PrometheusWriteApiPath: ...

2) Вспомните последний раз, когда вам приходилось менять значение строковых литералов, спрятанных за именованными константами. Как часто приходилось это делать?
3) Как узнать, что в pull request’е используется корректная именованная константа, которая давно определена где-то в другом месте, которое не было затронуто данным pull request’ом?
4) Как определить, что pull request не создает новую именованную константу для уже существующего строкового литерала?
5) Насколько сложно вам было отыскать все вхождения строкового литерала «/api/v1/write» через поиск на github? Насколько изменилась бы сложность поиска по имени константы?

1) Сколько строк удалится и добавится в коммите, меняющем первый вариант на второй?

+/- одинаковое количество

2) Как изменится сложность понимания получившегося кода?

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

3) Как изменится сложность внесения изменений в получившийся код?

Не изменится — какая разница, добавить строку в массив, или скопипастить три строки кода?

1) Как изменится сложность понимания кода, где вместо строковых литералов используются именованные константы, во время его изучения на github, gitlab или подобных инструментах?

учитывая, что github умеет в переход по клику, то упростится
а в gitlab есть webide, умеющее много

2) Вспомните последний раз, когда вам приходилось менять значение строковых литералов, спрятанных за именованными константами. Как часто приходилось это делать?

у меня много интеграции со внешними сервисами, и там api имеет свойство меняться, так что случается относительно часто

3) Как узнать, что в pull request’е используется корректная именованная константа, которая давно определена где-то в другом месте, которое не было затронуто данным pull request’ом?

Точно так же как узнать, правильный ли endpoint указан в строковом литерале

4) Как определить, что pull request не создает новую именованную константу для уже существующего строкового литерала?

Если константы правильно сгруппированы (например по контроллерам — Endpoints.Auth.SignIn), а не свалены в кучу, то вероятность добавления дубликата становится исчезающе малой
ну и для 100% проверки достаточно будет просмотреть коротенький файлик

5) Насколько сложно вам было отыскать все вхождения строкового литерала «/api/v1/write» через поиск на github? Насколько изменилась бы сложность поиска по имени константы?

в моем комментарии я писал:

в большинстве IDE легко получаешь список _ссылок_ на эту константу,

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

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

stackoverflow.com/...​tring-efficiency/29566955

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

Прикол в том, что Go на невозможно написать говнокод, в отличие от Rust, C++, Scala и Java.

Прикол в том, что Rust на невозможно написать говнокод, в отличие от Go , C++, Scala и Java...

Что касается Go, то там 99% кода имеет ясное практическое назначение.

Куча бессмысленной копипасти — это 99% кода .

Все равно , еще оптимизировать и оптимизировать по размеру)) Шутка. Но факт отстутсвия зависимостей от левого булшита налицо, видно, что над оптимизацией все-таки старались)
Обычно если какой-то гошный бинарь прогнать анализатором, то там тонна мертвого дерьма с гитхаба вшита

~/go/bin/goweight ./victoria-metrics | head -n 15
3.9 MB net/http
3.8 MB runtime
2.5 MB github.com/VictoriaMetrics/VictoriaMetrics/lib/storage
2.3 MB github.com/VictoriaMetrics/fasthttp
1.8 MB net
1.8 MB crypto/tls
1.6 MB github.com/VictoriaMetrics/VictoriaMetrics/app/vmselect/promql
1.5 MB golang.org/x/sys/unix
1.4 MB reflect
1.1 MB gopkg.in/yaml.v2
999 kB math/big
847 kB syscall
841 kB github.com/VictoriaMetrics/VictoriaMetrics/lib/mergeset
746 kB github.com/klauspost/compress/flate
742 kB crypto/x509
И какая часть приходится на столь любимые вами «велосипеды»? Я там увидел, например, кастомную реализацию decimal))

Ничего удивительного. На моей прошлой работе, увы, завелся немного упоротый гофер. Решил на го написать хрень, которую никто не просил писать на го (особенно учитывая, что никто в команде го не знает). Когда я открыл code review, там было больше 40 страниц, из которых куча кода выглядело как библиотечный. Когда я спросил что за херня. Мне чувак объяснил, что все нормально, на Го все так делают. Ты вот тут код смотри, а тут не смотри. Пришлось послать его нах и этот код больше года висел ждал, кого-то кто захочет тыкать палочкой в Г.

Когда я открыл code review, там было больше 40 страниц, из которых куча кода выглядело как библиотечный

Может, это был код сторонних зависимостей из папки vendor? К сожалению, код сторонних зависимостей редко ревьювают :(

Для чого його рев’ювити якщо на Го все одно гівнокод не можна написати? Одразу в master і в продакшн!

А как правильно собирать? Development build собирает только малую часть:

nvi@qwe:~/VictoriaMetrics$ time PATH=$PATH:/home/nvi/Downloads/go/bin VERBOSE=1 make victoria-metrics
APP_NAME=victoria-metrics make app-local
make[1]: Entering directory ’/home/nvi/VictoriaMetrics’
CGO_ENABLED=1 GO111MODULE=on go build -mod=vendor -ldflags „-X ’github.com/VictoriaMetrics/VictoriaMetrics/lib/buildinfo.Version=victoria-metrics-20200717-072448-heads-master-0-gdfa156e6’” -o bin/victoria-metrics github.com/VictoriaMetrics/VictoriaMetrics/app/victoria-metrics
make[1]: Leaving directory ’/home/nvi/VictoriaMetrics’

real 0m5,335s
user 0m4,921s
sys 0m2,026s

А эта аппка 1200 строк. Очень хочу посмотреть на чистую сборку большого числа исходников.

С чего вы взяли, что там компилируется только 1200 строк? Попробуйте следующую команду:

go clean -cache && time go build -mod=vendor -v ./app/victoria-metrics/
Она сначала почистит закэшированные бинарники, а затем скомпилит проект с нуля из всех исходников. По пути она покажет компилируемые пакеты, в которых намного больше, чем 1200 строчек кода.

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

time go build -mod=vendor -v ./app/victoria-metrics/

Да, интересно. Го не знаю, неужели такой простой синтаксис у него, что он так быстро парсится.

Это одно из главных преимуществ Go — код на Go не только легко писать, но и легко читать, т.к. в нем пока нет всякого матана и zero-cost abstractions, как в Scala, C++ или Rust. К сожалению, это может измениться через пару лет, если в Go добавят дженерики — blog.golang.org/generics-next-step . Такое развитие событий меня не очень радует :(

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

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

Тогда придется перейти на С или сделать форк Go без дженериков )

Давай к нам на С, там нет дженериков и не будет.

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

это писалось еще 20 лет назад. Эти километровые макросы уже устаревший подход. Они что не дебажатся нормально что крайне сложны в поддержке и багу очень просто допустить
вот, например, аккуратные маленькие макросы github.com/...​ter/include/linux/kfifo.h
а в фрибсд то какой-то старый трэш, еще и в svn, только мазохисты еще сидят на svn

вот, например, аккуратные маленькие макросы

А чего это вы сравниваете RB-дерево с простым списком? Конечно, список проще будет.

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

Простому юзеру и не надо их менять, надо соблюсти 2-3 элементарных правила использования.

Правило 1: Не користуватись макросами
Правило 2: Див. Правило 1.

«Любая проблема имеет простое, понятное, неправильное решение» ™.

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

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

А вот макры Rust или Common LISP уже вполне пригодны и для полка макак — там есть возможность аккуратно укоротить все возможные побочные эффекты. Но вы явно про них никогда не слышали.

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

мова йшла про макроси в С, це раз,

Все одно — хто вміє, той вміє, і навчитись акуратному застосуванню тут не легко, а дуже легко.

Можна сказать, що помилки завжди є і макри вміють їх маскувати... але це проблема C в цілому. Я не бачу нічого принципово суттєвого в макрах порівняно з іншими фічами сього переносимого асемблера. А саме з макрами організації списків і дерев я жодного разу не бачив тих помилок, що типові саме для макр. Ті помилки, яких припускаються — були б точно так же зроблені з функціями чи пдітримкою мови.

по друге, Голанг має свою нішу,

Ось коли Валялкін віддасть мені програне віскі — я почну обговорювати це :)

по третє, приниження інших тебе кращим не робить.

Я ще не почав. Ось коли деякі місцеві... мнеее... дописувачі зайдуть у гості — тоді буде в повний зріст :)

Могу провести пару уроков по макросам :) Это руст так деформирует?

зважуючи за і проти, раціональне рішення в довгому горизонті

Здивував прямо.

Так на Русті теж перший раз поки закачає пакети, поки збере....
а потім вжух, тільки змінені пакети перезбирає.

Але для крітікал лайф апп прийнято кожен раз артефакти збирати з нуля.

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

Недавно запросили на співбесіду по підтримці сборки іміджа Лінукса. І що характерно, там тре видумувати і тести кейси, при яких їх девайс йде у відключку. І 20% парку пристроїв в таком стані експлуатації.

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

та мінімально цінного продукту (MVP — minimal valueble product)

Minimum Viable Product

живой тобиш, жизнеспособный :)

На вопрос о переработке ядра на таких языках как Go и Rust, так есть риск, что в 2030 годах Си-разработчики превратятся в нынешнее подобие разработчиков на COBOL, Линус ответил, что язык Си остаётся в десятке популярных языков, но для неосновных подсистем, таких как драйверы устройств, рассматривается возможность предоставления привязок для разработки на таких языках как Rust. В будущем ожидается предоставление разных моделей написания подобных вторичных компонентов, не ограничивающихся применением языка Си.

www.opennet.ru/...​nnews/art.shtml?num=53292

Статистика использования операционных систем посетителями ДОУ за последнюю неделю (без учета мобильных и планшетов):
Windows 67.30%
Macintosh 23.69%
Linux 8.78%

На серверах разве много

драйверов устройств

?

Ну обычно около 20 набирается, в составе, навскидку (под x86), распишу, пока просыпаюсь:

1a. Драйвер корня шины PCI (PCI-E, один чёрт) — управляет конфигурированием устройств (даже когда это задача просто прочитать, какие порты/адреса настроил BIOS). В простейшем варианте транслирует чтения-записи в PCI-E mapped control area (которую должен найти), хотя может и крутить что-то через порты.

1b. Драйверы мостов PCI. Обычно достаточно просты, типа «этот мост ретранслирует вот эти 2 диапазона памяти и 2 диапазона портов», но бывают противные тонкости с управлением электричеством.

2. Драйвер ACPI. Выглядит как толстенный переходник с искателем и декодером таблиц, интерпретатором команд оттуда (фактически там своя система машинных команд, которая в конечном итоге транслируется в действия типа «поместить 1 в R0 и записать из R0 в порт 0xA2»). Почти все основные управляющие действия, типа выключить питание, стартовать процессор и т.д. — сейчас замаплены туда, задача исполнителя — найти в таблицах, откуда читать код для виртуальной машины, и выполнить его. Внутрь без причины не лезть — водки потребуется не много, а очень много. Его следует считать драйвером материнки в целом, поэтому вписываем сюда же.

3. Драйверы таймеров. Их сейчас дофига (одновременно присутствуют RTC, i8254, ACPI-fast aka PIIX или ACPI-safe, APIC, HPET, не считая возможно универсального TSC в процессоре), и надо найти их, определить свойства (частоту и стабильность), определить оптимальный. Наружу выдают обычно две рукоятки clocksource (считалка) и clockevent (источник прерываний). Тут уже можно было бы посчитать пунктов за 8.

4a. Драйвер основного источника энтропии (важен для криптографии). Может просто звать RDRAND в процессоре, а может ходить в чипсет (если там такое есть) или ещё куда-то.

4b. Драйвер генератора недетерминированного ГПСЧ (а для особо критичных случаев — истинного ПСЧ), совместно с п.4a, может набирать данные ещё откуда-то (например, из драйвера сетевухи).

5. Драйвер видео (даже на сервере — надо же первично настроить, а потом посмотреть, что получилось? компорт не все любят).

6. Драйвер клавиатуры (туда же).

7. Драйвер компорта (если включён... часто делают и сейчас, особенно не на x86).

8a. Драйвер сетевухи (по одному на тип основной части, которая отправляет-принимает пакеты).

8b. Драйвер PHY сетевухи (начиная с 100Mbit/s выделен в отдельное устройство, доступ через сетевуху), управляет скоростью, дуплексностью и их согласованием.
У некоторых производителей могут быть разные PHY для одного исполнения центральной части адаптера... в общем, это отдельный вложенный зверь.

9. Драйверы USB хостов (даже серверу USB регулярно нужен — например, управлять UPSом или клавиатура для настройки), может быть вполне и 3 разных типа (при нынешнем бардаке — например, USB 2, 3.0 и 3.1).

10. Драйверы конкретных USB устройств (клавиатура, мышь, UPS, переходник на компорт...) — много их. Могут быть выполнены в userland, но не для всех устройств (системную клавиатуру так не организуешь).

11. Драйвер контроллера интерфейса диска (несколько типов: SATA, NVME...) — поддержка логики интерфейса (например, какие команды SATA и как организуется их очередь).

12. Драйвер переходника на контроллер интерфейса диска (SATA хост, M.2 или что там будет). Пункт 11 работает через его средства.

13. Драйвер диска — обычно типовой для вида интерфейса, требует подгруппу команд интерфейса (потому что на SATA бывают диски, бывают CD/DVD приводы, бывают контроллеры логики корзин... много их). Работает через п.11.

14. Сущности, которые удобно укладывать на логику понятия «драйвер» — например, ROM с BIOS, чтобы вписать его постоянные адреса в карту адресного пространства. Могут быть просто таблицами без кода, но так как ROM — устройство, имеет смысл включить его сюда.

15. Драйверы специальных функций процессора, таких, как хост гипервизора — для запуска подчинённой VM. Зависят от вендора (Intel и AMD имеют несовместимые реализации).

Google: “Over time we will continue to invest in Rust and see which [Android] system components are better off being written in Rust”.
Sudhi Herle, Head of Android Platform Security, says in yesterday’s Android Developer weekly video:
Over time we will continue to invest in Rust and see which system components are better off being written in Rust. We believe Rust will end up fundamentally making the platform safe for all of our users.
www.youtube.com/...​6E&feature=youtu.be&t=727

Microsoft Releases Emergency Windows 10 Patch for Malicious Image Attack
The bugs, known CVE-2020-1425 and CVE-2020-1457, are inside the Windows Codecs Library. This component contains the necessary software to decode and render many different image and video formats in Windows. By causing a buffer overflow with malformed image files, the attacker can “trick” the computer into leaking important data and running code hidden in the image files.........
www.extremetech.com/...​or-malicious-image-attack

By causing a buffer overflow with malformed image files

типа руст здесь чем то поможет

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

Бегу-бегу...
Расскажи как там ее не решают?

ясно-понятно. беги дальше

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

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

а тобі як більше подобається: болдом, капсом чи італіком?

Да ладно, на Андроиде щас куча телефонов, например.

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

Не могу ничем помочь тому, кто «чукча — не читатель, чукча — писатель».

сделано то только за счет нереальных тормозов

citation needed

В «их английском клубе» — принято верить на слово, «тут фишка мне и пошла...» (Петька из анекдота). Сказано «за счет нереальных тормозов», значит «так и есть». :))

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

man7.org/...​ages/man2/mprotect.2.html

x86 давно умеет что тут только читать, тут читать и писать, тут только выполнять

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

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

Ловили ми колись давно притирання пам’яті, в алокаторі виділяли трохи більше пам’яті, писали спереду і ззаду якусь сигнатуру, вели список об’єктів і періодично запускали пошук притертих сигнатур. За пів дня багу виловили.

Это реализовано в железе в MMU, что за фигню ты несешь? :)

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

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

Вы спорите с фактом существования API, которая позволяет пометить свою память как readonly?

Тупишь???

Цитату серьозного разработчика/компании про то, что :
Rust содает код (включающий проверки), который работает «с нереальными тормозами».

который работает «с нереальными тормозами».

Це ніасіляторів так називають?

Обращения к памяти или статически проверяются, что не было выхода за пределы размера буфера . Если статическая верификация ничего не дала (например, если просто берется рандомный индекс из массива), то будет явная проверка на выход за пределы буфера в рантайме. Избыточные проверки оптимизируются в LLVM по мере возможности.

Можете привести результаты бенчмарка, который их показывает?

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

судя по

benchmarksgame-team.pages.debian.net/...​ame/fastest/rust-gpp.html

с++ тормозит и без проверок.
и памяти больше ест
и вообще

Как было не однократно проверено в сравнении C++ vs Rust/etc...
бенчи — штука не простая, не совсем корректное использование языка в ту или другую сторону — и результаты идут «в разнос», НЕ ЗАВИСИМО от языка (С++ / Rust)

Но что совершенно определенно выходит из многочисленных бенчей сделаных ранее — это то, что Rust показывает производительность кода НЕ ХУЖЕ, чем С++ или на уровне С++. (иногда лучше, не смотря на доп.проверки рантайма)

ядро Лінукса не хоч на Русті, от прям шас?

Я OpenCV просил.

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

свои ровные ручки Интел приложил

смешно

вы смешиваете язык и экосистему, и делаете удобные вам выводы выводы
с тем же успехом можно спросить про условный хадуп/флинк на с++

Rust показывает производительность кода НЕ ХУЖЕ, чем С++ или на уровне С++

Рекомендую посмотреть youtu.be/E9-scyUdmeI?t=1154 всю главу, а самое важное по таймкоду youtu.be/E9-scyUdmeI?t=1596

На хабре кажется была ответка: habr.com/ru/post/492410

Баян.... при том давний.

Как было не однократно проверено в сравнении C++ vs Rust/etc... бенчи — штука не простая, не совсем корректное использование языка в ту или другую сторону — и результаты идут «в разнос», НЕ ЗАВИСИМО от языка (С++ / Rust)

habr.com/ru/post/492410
В 2019 (и в 2020) году я был на конференции C++ CoreHard, слушал доклад Антона antoshkka Полухина о незаменимом C++. По словам Антона, Rust еще молодой, не очень быстрый и вообще не такой безопасный.
Антон Полухин является представителем.......... Антон действительно крутой и авторитетный человек в вопросах по C++. Но доклад содержит несколько СЕРЬЕЗНЫХ фактических ОШИБОК в отношении Rust. Давайте их разберём.......

Но доклад содержит несколько СЕРЬЕЗНЫХ фактических ОШИБОК в отношении Rust.

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

слайды в стиле — «смотрите, rust использует лишнюю инструкцию процессора!».
но при этом скромно умалчивается, сколько человеко-часов(месяцев) потребуется, но отладку очередного UB, «съекономившего», эту самую инструкцию процессора.

но при этом скромно умалчивается, сколько человеко-часов(месяцев) потребуется, но отладку очередного UB, «съекономившего», эту самую инструкцию процессора.

Это утверждение неверно когда ваш код работает в датацентре состоящем из 1000 и более CPU, каждое из которых это 200 Вт под нагрузкой.

Если бы это было ВСЕГДА критически важным, но не было «ни питонов, ни ява, ни NodeJS и других вещей», все было бы на С++.
«Подсчитывать инструкции» важно, но далеко не всегда, если за них платят те самые 1000 заказчиков, пусть и в ДатаЦентрах на 1000 серверов.

Так предотвратить UB это проверка данных на входе. Далее в критически важных участках пишется код который позволяет сгенерировать UB, но не сгенерирует потому что данные уже проверены ранее. Все счастливы — UB нет, производительность высокая.

код работает в датацентре состоящем из 1000 и более CPU, каждое из которых это 200 Вт под нагрузкой

Сложно представить, кто кто-то будет заниматься оптимизацией одной инструкции в дата-центре из 1000 серверов. У вас есть ссылка на case study такого проекта?

Это утверждение неверно когда ваш код работает в датацентре состоящем из 1000 и более CPU

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

Такие микро-оптимизации могут иметь смысл где-то в ембедед, где пытаются выжать $10 из чипа, который стоит $1. Или где-то где латентность очень критична, например, в HFT.

для чого, будеш внуків лякати растом?

так уже прожив 10, далі буде ще прикольніше

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

а кресты умирают уже 18 лет

так это потому, что много легаси, которое не ак просто переписать из-за тех-же UB.
COBOL еще дольше умирает, но это вряд ли повод для гордости.

так это потому, что много легаси, которое не ак просто переписать из-за тех-же UB.

т.е. по твоему весь крестовый легаси софт построен на эксплуатации UB?

т.е. по твоему весь крестовый легаси софт построен на эксплуатации UB?

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

о госспаде, ну почему я спорю о плюсах с человеком с ником ява би?

Більша частина легасі на С++ доволі швидко допилюється до новіших версій компіляторів вже пару десятків років мінімум.

Поэтому мы наш новый проект с hard-realtime требованиями под ASIL-D — начали на С++14 с нуля с всем тулингом. Нам в этой жизни явно мало легаси.

так это потому, что много легаси, которое не ак просто переписать из-за тех-же UB.

Вот что-что, а легаси на плюсах практически нулевое. Всё, что я вижу — это всё одноразовое. Сейчас столкнулся с LLVM как бекенд для своего компилятора для кастомного языка — это просто писец, каждая мажорная версия переписывается практически с нуля, причём с использованием нового стандарта, это просто непременное правило.

Не бачу, чим у випадку

buffer overflow with malformed image files

Rust відрізняється від C чи C++. Звідки компілятор може знати, що в картинці криві розміри чи зміщення? Тут тільки параноїдальні перевірки.

Хіба дійсно Rust вміє сам при індексуванні масиву ці всі перевірки розумно робити коли потрібно і не кожен раз... Треба буде якось на пенсії побавитися і подивитися...

коли потрібно і не кожен раз...

я не верю в чудеса

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

Але чи робить це Rust, я не знаю.

У Rust находится LLVM на бекенде, который занимается всеми оптимизациями, включая и те, про которые вы сказали.

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

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

Коментар порушує правила спільноти і видалений модераторами.

На Rust дивлюся вже не менше року, але реального досвіду небагато. Робив задачки з літкода, по роботі виходило мінімум вдвічі довше ніж, скажімо, на JS. Зараз виникла реальна задача, яку наче можна реалізувати на Rust. Невеликий API для синхронізації даних існуючих бізнес-додатків. Не те щоб це було необхідно, мабуть, я на .net/.netcore написав би такий сервіс за день-два, але стало цікаво, чи готова екосистема для задач, до яких я звик. Специфіка ще в тому, що працювати це буде на Windows, і БД — MS SQL. Крейтів для Windows взагалі менше, а тут ще й мс... Спочатку пішло доволі бадьоро, warp працює без проблем, tiberius для mssql виявився робочим, diesel з mssql не працює, тому всі запити до бази вручну. Трохи мутно з обробкою помилок у warp, але гугл допоміг з рішенням, потім ще перегляну... Спробував запустити все як service, за допомогою windows-service — працює. Зараз поки що застряг на спробі реалізувати connection pool до бази (bb8) і є проблеми з поллінгом service events для корректного shutdown (просто не знаю, куди це вставити :). Всі ці дженеріки круті, але треба добре розібратись. Впевнений, що коли скомпілиться, запрацює, як годинник, як це й було досі. Бінарник 4mb в релізі, далі росте дуже повільно. Як закінчу, зможу зробити висновок, чи це для подібних задач good fit. Поки що плюс-мінус.
Яке майбутнє у раста з врахуванням складності освоєння, не впевнений. Я вже бачу, що він відсікає дуже великий шар розробників. Хто розбереться з дженеріками, асінками, result/error, модулями, вже зможе зробити щось реальне.

Мабуть не дуже вдало висловив щодо «крейтів для windows»... Маю на увазі, що є багато корисних крейтів, які не можна збілдити та/або використати в Windows, автори просто не планували підтримку або в них не вистачає ресурсів, щоб цим зайнятись. Звісно, вони часто не проти допомоги... Як наслідок, деякі додатки, розроблені на Rust, в Windows теж не працюють. Часто причина виключно в якомусь крейті, де забули про вінду.

JS vs Rust, мабуть захопливий баттл

:) Зараз перевірив, чесно кажучи, в мене нема реалізацій на обох мовах одної задачі... Тобто те, що я оцінив «вдвічі» — чисто відчуття. Rust vs JS/Python/C#. Причому в самому коді нічого складного начебто й нема, це більше говорить про те, що на раст треба витратити набагато більше часу, щоб навчитися кодити швидко.

тут холівари як про убійцу С/С++ (закат сонця ручками робити) та конкурента Го, але

JS/Python/C#

О_о

Навіщо тоді для Rust розробляються web-фреймворки, в т.ч. клієнтські, ORM-ки, UI-ліби? Все це — proof of concept, то чому б ні?

откуда я могу знать, якщо є wasm, значить комусь це треба

І доречі, мова йшла про літкод. Там можна і на C, C++, Rust, Python, JS і тд... Я робив задачі різними мовами, тому й порівнюю.

Літкод, для реальних проектів, ну не зна.

Флай, я теж не знаю, про що ти? :)

Якщо о рішати задачки на літкод, то яке це відношення до реальних проектів?
Як на мене літкод позадрачувати хіба для того щоб спробувати витягнути лотерейний квиток у ФААНГ

Гаразд, це було востаннє, вибач...

По своему опыту могу сказать что при основном яп js, rust воспринимается гораздо легче, чем тот же go. Задачи на литкодах не решал, но писал сервис, который решал задачу масштабирования других сервисов на основе мониторинга их ресурсов. Единственную сложность вызвало опрокидывание ошибок в некий общий хендлер. Скорее всего я делал что-то не правильно, но в конце концов оно работало, память не текла.

память не текла.

так це ж не С/С++ з ручним керуванням пам"яті, чого б її текти?

обожаю такое

Щось давно камєнтів не було.

„C is still one of the top 10 languages,” answered Torvalds. However, he said that for things „not very central to the kernel itself”, like drivers, the kernel team is looking at „having interfaces to do those, for example, in Rust... I’m convinced it’s going to happen. It might not be Rust. But it is going to happen that we will have different models for writing these kinds of things, and C won’t be the only one.”

Тут уже писали (Mike Gorchak и «припеватели») — никто никих серьезных систем на rust не делал, (и может делать не будет).
Товальдс — может будет раст, может не раст... какая разница?
Статья старая — 2016 года.
www.infoworld.com/...​-and-future-of-linux.html

news.finance.ua/...​150-tys-v-god-infografika

Swift. Apple создала этот язык программирования в 2014 году, и с тех пор он набирает популярность. С помощью Swift можно создавать приложения для iOS, Mac, Apple TV и Apple Watch. Разработчики со знанием этого языка получают около $125 тыс. в США и $58 тыс. в среднем в мире.
Uber, Airbnb, Square, приложение для медитации Calm и около 500 тыс. других приложений в App Store хотя бы частично написаны на Swift.

C. C, созданный Деннисом Ритчи в 1972 году, до сих пор остается одним из самых популярных языков. Разработчики, владеющие C, могут рассчитывать на зарплату размером в $125 тыс. в США и $50 тыс. в среднем в мире.
Rust. Rust — проект компании Mozilla, который по замыслу создателей должен был стать следующим этапом эволюции C и C++. Программисты, которые работают с Rust, получают в среднем $130 тыс. в США и $74 тыс. в других странах.

Этот язык программирования используют такие проекты, как Firefox, Dropbox, Amazon и Coursera. Кроме того, он возглавляет рейтинг самых любимых языков на сайте Stack Overflow 5 лет подряд.

Ruby. Разработчики, знающие Ruby, получают $130 тыс. в США и $71 тыс. в среднем в мире. Этот язык программирования с открытым исходящим кодом был создан японским ученым Юкихиро Мацумото в 1995 году и с тех пор стал одним из самых популярных.

Ruby использовали для создания Twitter, GitHub и Kickstarter.

Perl. Язык программирования Perl создал лингвист Ларри Уолл в 1987 году, когда работал в американской компании Unisys. В мире Perl является одним из наиболее высокооплачиваемых языков программирования, поскольку разработчики получают в среднем $76 тыс. В США за работу с этим языком готовы заплатить $130 тыс.

Kotlin. Kotlin, который создала петербургская компания JetBrains в 2010 году, помогает разработчикам писать программы для Android. Программисты, владеющие Kotlin, зарабатывают $130 тыс. в США и $54 тыс. в среднем в мире.
Сегодня этот язык используют компании Google, Square и Atlassian.

Objective-C. Objective-C является одним из основных языков, которые Apple использует для создания своих операционных систем OS X и iOS. Разработчики, использующие Objective-C, получают в среднем $135 тыс. в США и $64 тыс. в других странах.
Этот язык программирования также используют при разработке приложений для iOS. Язык программирования Objective-C появился в начале 1980-х годов и был главным языком, который использовали на платформе NeXT, до того как ее приобрела Apple.

Go. Язык программирования Go в 2007 году создали разработчики Google. По словам одного из создателей языка Роба Пайка, Go был придуман для решения реальных проблем, возникающих при разработке программного обеспечения в Google.
Программисты, владеющие Go, зарабатывают $140 тыс. в США и $74 тыс. в среднем в мире.

Scala. Scala или Scalable Language — язык, который был создан в начале 2000-х годов немецким ученым Мартином Одерским. Программисты, которые работают с этим языком, получают в среднем $150 тыс. в США и около $76 тыс. в других странах.
Он используется многими разработчиками старого и очень популярного языка программирования Java. Основные фреймворки языка — Play и Lift — часто используют новостные сайты, например The ​​New York Times, Guardian, The Huffington Post, а еще соцсети Foursquare и LinkedIn.

insights.stackoverflow.com/...​s-worldwide-united-states

п.с.
С++ нема в списку топ 10 по зепешкам

С++ нема в списку топ 10 по зепешкам

(ушел плакать)

Судя по го на втором месте — как обычно платят не за сложность языка, а за «потребность рынку»

ринку шото плюси не дуже востребовані

www.youtube.com/watch?v=OU55PWXm2rg
з 14:30 про С++ динозаврів

ринку шото плюси не дуже востребовані

продолжай над этим медитировать

добавлення двох плюсів піднімає илітарність та труъшність мови

это звучит так же тупо, как если бы я сказал, что добавление «ust»

піднімає илітарність та труъшність мови
продолжай над этим медитировать
как если бы я сказал, что добавление «ust»

Cust++ гггг

Ага, а ті, хто пишуть на ньому, по аналогії з Rust — Crustaceans!

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

Чесно кажучи від статті в розділі «технічні статті» я очікував більшого. Хоч би трішки коду, прикладів. Бо я так і не зрозумів з неї що таке Rust і чим він відрізняється від інших мов.

Хоч би трішки коду

«Жрица любви» приезжает в отпуск на море с целью спокойно отдохнуть, позагорать, там к ней то и дело начинает приставать мужчина. Ей это дело надоедает и она идёт с ним на следующий диалог:
— Парень, как тебя зовут?
— Василий.
— Вась, вот ты кем работаешь?
— Рабочим на заводе работаю, а что?
— Вот представь, Вася, приезжаешь ты на море отдохнуть, лежишь на пляже, загораешь, а вокруг станки, станки, станки!
ruanekdot.ru

трішки коду

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

— Как тебя звать?

— Петя

— Петя, вот ты кем работаешь?

— Программистом, а что?

— Вот представь, Петя, приезжаешь ты на море, лежишь на пляже, загораешь, а вокруг компьютеры, компьютеры , компьютеры !

— (Мечтательно) Да .. и одни пентиумы

Женщина легкого поведения приезжает....
ой...а у вас цикл отклеился

там два варіка, для рабацяги з заводу і ойтішнєга (overriding)

Между прочим, вполне себе нормальная тема. Был у меня как-то офис в 80 метрах от пляжа и ночных клубов, очень клёво там работать. Не работа, а одно удовольствие.

Раст хорош для любителей С++ и/или мазохизма (что, в принципе, одно и то же).
Если вам нравится бороться с borrow checker вместо того, чтобы продуктивно писать код на Го, то используйте Раст.
Если вам нравится сочинять запутанные конструкции на С++, чтобы потом в них никто не разобрался, в т.ч. и вы, то Раст вам подойдет.
Если вам нравится разбираться в многостраничных сообщениях об ошибках при использовании STL или boost, то Rust вам понравится.

Есди же вам нравится писать легкочитаемый код на Go, то Rust вам противопоказан (впрочем, как и C++).

о, любовний треугольнічек вирісовиваєццо

Я не упоминал Си. Это отличный язык программирования. Почти как Го :)

Что касается сиприплюснутых, то, если они не любят Раст, значит, есть разные виды мазохизма. Я в них не разбираюсь

Зауваження було одне, що б не гребти одним гребнем С і С++,
так як там різна парадигма мислення, С++ це зразу моноліт та ООП ООД та сильне зв’язування. У тих підгорає від всього.

А в С тоді що?

в С тупі неосілятори високих матерій, хто умний той на JS перейшов

Дивися, щоб не забанили, бо будеш анонімусом як дядя Вітя

гигиги,
а то шо, Базука потролить на італійському ресурсі, як Майка?

Я писал на PHP много лет, потом на Ruby больше, до PHP и после Ruby писал на чём придётся С, С++, JavaScript/TypeScript, немножко Python, немножко Java, игрался с Erlnag/Elixir, застрял на некоторое время со Scala и на одном проекте потрогал Go несколько месяцев.

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

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

После определённого периода адаптации Rust нравиться отсутствием необходимости настраивать и беспокоиться (на уровне метрик) о GC, аллокейшены всё же надо мониторить, но обычно одного 2-х графиков по алокатору достаточно, часто можно написать код, компильнуть поправить ошибки и отправить в прод в пятницу вечером и быть спокойным на выходных.

Система типов позволяет писать программы, которые в случае модификации исправляются следуя за ошибками компилятора! И это действительно работает! Они очень читаемые (по большей части). После исправления всех ошибок можно быть уверенным в работе программы на 99.9999%.

Вам не надо закрывать файлы, анлокать мьютексы, возвращать соединения в пул, всё это реализуется через Drop trait.

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

Стоит упомянуть про макросы! Это очень круто! Почти гибкость Ruby со статическими гарантиями и скоростью выполнения в рантайм в одном флаконе!

А ну и конечно никаких нулов (привет Go) и исключений! В Rust используется тип сумма Option/Result aka Either/Maybe.

Много чего хорошего можно ещё написать... Даже есть попытки реализации зависимых типов, хотя Idris/Haskel тут не досягаемы и я не думаю, что в Rust могут появиться их нормальная реализация. Язык уже стабилизировался и столь сильное изменение типов не хило встряхнёт экосистему.

Из не очень хорошего, чем больше нагружаешь систему типов, тем дольше компиляция, хотя IMO до Scala ещё далеко :). Язык ещё молод и каких-то специфичный вещей может просто ещё не реализовано, например, каких-то хитрых структур данных или деревьев, под специфичные задачи. Самому подобные штуки крайне сложно реализовывать, а в Rust ещё придётся хорошо ознакомиться с Rustonomicon.

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

Немного разочаровывает сильная разница между nightly и stable. На roadmap на 2020 обещали уделить стабилизации больше внимания, но уже полгода прошло, а сильных подвижек не видно.

Язык очень интенсивно развивается, особенно в плане эргономики, и сейчас уже многое исправлено, поэтому обращайте на это внимание, когда читаете статьи 2015-2018 годов.

И как подтверждает Stackoverflow, я funboy, ибо им сложно не стать после детального ознакомления с языком.

Вам не надо закрывать файлы, анлокать мьютексы, возвращать соединения в пул, всё это реализуется через Drop trait.

отркрой для себя удивительный мир scope & destructors

Drop trait — це ті ж самі деструктори, просто чуть по-іншому організовані

спасибо, я догадался

После исправления всех ошибок можно быть уверенным в работе программы на 99.9999%.

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

Только код будет работать не так, как нужно. Толку? Лучше напихать ассертов и чтобы прога валилась на каждый чих, чем чтобы она стабильно неправильно работала.
Ошибки в логике никто не отменял, и это — основной тип ошибок.

Ошибки в логике никто не отменял, и это — основной тип ошибок.

citation needed

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

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

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

college grad и чуваками с минимальным опытом работы,

Много они на Расте напилят?
Сравнивай одинаковый грейд.

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

Тогда смысл от умного компилера, если он нужен только

college grad
код будет работать не так, как нужно.

WAT?

Компилятор гарантирует правильность бизнес логики?

После исправления всех ошибок можно быть уверенным в работе программы на 99.9999%.
Только код будет работать не так, как нужно.

тобто, якщо виправити помилки, то компілятор змінить бізнес логіку?!
ггг

А що в С по нішому, чи С++, чи в якій іншій мові програмування.

Компілятор провіряє код щодо дотримання бізнес логіки згідно ТЗ?

От я не розумію, для чого починати дискусію, яка не стосується специфічно Руста.

п.с.
Якщо вже пішло про поведінку кода, то C та С++ UB на порядки більше того, що «компілятор змінить бізнес логіку»

Я про те, що оце

Система типов позволяет писать программы, которые в случае модификации исправляются следуя за ошибками компилятора! И это действительно работает! Они очень читаемые (по большей части). После исправления всех ошибок можно быть уверенным в работе программы на 99.9999%.

 не вирішує реальних проблем, бо реальні проблеми в бізнес логіці.

до чого тоді випад в сторону Руст?
ще раз

C та С++ UB на порядки більше того, що «компілятор змінить бізнес логіку»
до чого тоді випад в сторону Руст?

До того, що наступна теза некоректна:

После исправления всех ошибок можно быть уверенным в работе программы на 99.9999%.

 бо залишиться купа помилок в бізнес логіці.

Якщо вже пішло про поведінку кода, то C та С++ UB на порядки більше того, що «компілятор змінить бізнес логіку»

Не компілер змінить, а програміст неправильно напише, а компілер — не виправить.

Не компілер змінить, а програміст неправильно напише, а компілер — не виправить.

так С/С++ ще гірше,
компілер не тільки не виправить,
а ще добавить баги через UB

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

якщо покрити код аналізатором кода.

Навіть і без нього. Якщо нормально писати. Може залежить від області.
В нас валгрінд та cppcheck пару штук кожен познаходили колись. Лісу проблем не було.

Про що й мова: до С/С++ тре ще куча зовнішніх тулзів, щоб не відстрілювати собі ноги.

Про що й мова: до С/С++ тре ще куча зовнішніх тулзів, щоб не відстрілювати собі ноги.

Чувак, можеш не перекручувати?
Я тобі пишу, що в С та С++ майже не трапляється таких проблем, в нас на проекті всього кілька штук знайшлося.
Ти пишеш — що для С та С++ треба тулзи.
Ну реально — змінюєш сенс на прямо протилежний.
Ну навіщо таке робити? Щоб поважали?

Мы всё поняли — вы гораздо умнее МС, поэтому у вас ошибок на много порядков меньше, чем у них. Поэтому вам реально никакой Раст не нужен, вы и так справитесь со всеми ошибками, что логическими, что UB на обычном С++. Это просто МС — «слабаки», которым до вас «тянуться и расти».

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

В Rust тобі не дають совати пістолєт, навіть незаряжений куда надо і куда не надо, тільки в унсейф.

если

в унсейф

то можно и в штаны

в штани то для труъ ЦеПеПе,
в памперс для растаманів

в памперс для растаманів

а кто вам памперсы меняет?

ЦеПеПе

шники?

Боровер Чекер (не путати з
Чак Норісом)

Вот С и С++ и есть аналог этого пистолета

Аналог очень точного, плохо послушного пистолета. Ствол его дрожит в руке стрелка, сам пистолет стреляет едва прикоснулся к курку, и даже если направил его вперёд — иногда стрелок остаётся без затылка и следовательно мозгов. Но если стрелок опытный — это оружие не подведёт ))

Якобы HKT эквивалентно GADT. Которые в нём есть. Но я в этой теме не очень ориентируюсь

Якобы HKT эквивалентно GADT.

это разные понятия, характеризующие систему типов языка.

Но я в этой теме не очень ориентируюсь

что не помешало вам написать коментарий.

Rust — это полигон где испытывают новые фичи\идеи перед принятием их в стандарт С++

УмнО !!! ...но словно «пук в воду»... :(

...первый стандарт языка C++98 был окончательно утвержден только в 1998 году.
Работа над языком была начата Грэйдоном Хором в 2006 году, в 2009 году[18] к разработке подключилась Mozilla....Версия 1.0 выпущена в мае 2015 года....
УмнО !!! ...но словно «пук в воду»... :(

Так речь о новых фичах. Фьючерсы, контракты и так далее. В С++ с наскоку это слишком рискованно вводить, вот и проверяют на других языках сначала — что нужно людям и в каком виде.

Это для сишников, которые хотят новые фичи, но не хотят ждать 20 лет

В фейсбуке вполне себе тренд последних двух лет.

Юзаю раст на одном из проектов. В основном приятные впечатления, за исключением системы владения. Если он на что-то начинает жаловаться, и не получилось это исправить за минуту, то скорее всего прийдется засесть на пару часов в интернетах, разбираясь в богатом внутреннем мире borrow checker, и в итоге прийдя к выводу, что проблема в принципе не имеет решения, и есть какой-то ***утый workaround в виде запихивания значения в 

Arc<Mutex<Rc<Box<RwLock<....>

Разочаровала реализация интеграция с С библиотеками (например, нет поддержки макросов и даже static функций). Есть workaround, но они немного херят перформанс, что ставит крест на интеграции с С библиотеками, которые заточены на перформанс (например, DPDK).

Static-функций? Как вам нужно интегрироваться с сишными static-функциями?

Например, тупо вызвать static C функцию из Rust кода

Я розумію про що ви говорите з обгортками типів (правда, ваш конкретний приклад виглядає дуже нереалістично, можу пояснитись; якщо це справжній код, було б цікаво дізнатись деталі). В мене в подібних ситуаціях зазвичай виявлялось, що я не враховував якихось дрібниць, які потім могли б вилитись в складні баги, і borrow checker був правий, він просто змушував мене структурувати і типізувати дані правильно відразу. З часом в мене випрацювалась деяка інтуїція, і я став витрачати на це менше часу.

Я пригадую, в інтернетах натикався на випадки, де borrow checker, будучи недостатньо розумним, матюкався на повністю валідний з точки зору власності код, але це буває рідко. По-моєму, я це бачив ще до NLL borrow-checker’а, який ввімкнений за замовчуванням ще з Rust 1.31.

Про static функції я теж не зрозумів. Чому FFI повинен вміти викликати функції, явно позначені як приватні в межах свого файлу (юніту трансляції)?

Про static функції я теж не зрозумів. Чому FFI повинен вміти викликати функції, явно позначені як приватні в межах свого файлу (юніту трансляції)?

Куча библиотек предоставляют свои функции в *.h файле как static. Вопрос не философский и не праздный, это серьезный блокер, если что.

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

Чому Rust мусить «бачити», як вище написали, «приватну функцію»?

Куча библиотек предоставляют свои функции в *.h файле как static.

Може це проблема все ж не Rust? А мови С, та кодерів бібліотек?

Може це проблема все ж не Rust? А мови С, та кодерів бібліотек?

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

Не вижу смысл продолжать разговор в таком тоне. Если хочется посраться на уровне детского сада, пишите Виктору Чижденко.

Я описал проблему, с которой я лично сталкиваюсь, используя Раст, который пытается потеснить С, которая не существует в самом С.

Ти намагаєшся натянути безпечний Rust на небезпечний С.

І кажеш, що це тобі створює Rust пробеми.

А може навпаки, використання С створює проблеми?

В статті згадано неосіляторів Rust, які заявили: «спробував Rust і мені не сподобалося», що пішли шляхом натягування Rust на С.

Це та як би почати писати на Java з використання JNI та заявляти, що Java лайно, бо не такий як потрібно інтерфейс із С.

Може ще в cучасний ПК вставиш ІDE диски з 90х років та скажеш, що сучасний ПК хріновий, бо нема слоту для ІDE та тре ліпити китайські адаптори ІDE на SATA з алікеспреса? I UART нема, LPT порта теж, просто жах що зараз клепають замість старого доброго PC AT/XT. А дискету, куда пхати дискету, де дисковод FDD?

А може навпаки, використання С створює проблеми?

Когда будут Rust native реализации кошерных библиотек, можно будет говорить об этом. Но пока что библиотек в crates.io тьма, но многие из них по качеству недалеко ушли от говна, которое лежит в npm, а то, что годное, часто имеет ту самую С библиотеку под капотом.

Чувствую JS-ом пахнуть начало ... :D
Я не скажу про всех ДЖсников, но вот что-то особенное в ихнем комьюнити есть...

Може інлайн статік?

Куча библиотек предоставляют свои функции в *.h файле как static.

А можна якісь посилання на приклади?

Я можу щось упускати, але припускаю 2 причини так робити:

1. Якшо функції прямо в хедері і реалізовані (e.g. single-header бібліотека, static inline і т.д.) і по якимось причинам не хочеться, шоб ці функції експортувались за межі файлу, де вона інклудиться — ну так хедер ви ж все-рівно не перевикористовуєте в Rust, а описуєте всі деклараці в Rust-коді. Ну тобто, так, rustc не компілює С-шний код, але хіба це не резонно?

2. Якшо хедер хоче задати якийсь єдиний інтерфейс для функції, але кожен *.c файл, який його інклудить повинен реалізувати цю функцію самостійно — ну тоді це і не публічна функція бібліотеки, і не треба шоб FFI мав до неї доступ. І таке є сенс робити тільки в приватних хедерах.

А можна якісь посилання на приклади?

Например, DPDK, SPDK

Ок, відкрив рандомний публічний хедер (code.dpdk.org/...​_eal/include/rte_bitmap.h) — є багато static inline (те, про що писалось вище). Так, я не бачу способу обернути це в Rust. Але я залишаюсь на позиції, шо це резонне обмеження. rustc не компілює С код.

Гіпотетично, шоб це працювало автоматично, то треба, шоб умовно якись bindgen розпарсив хедер, видалив static, скомпілював хедер без static як *.с файл С компілятором, прописав прапори лінковки до скомпільованого obj (навіть не знаю куди, якось так шоб їх було зручно включити в build.rs напевно). І при цьому треба ще якось сек’юрно аугментувати імена цих функцій, бо тепер вони глобальні і можуть конфліктувати з іншими....

Думаю, набагато резонніше вимагати від програміста, який пише обгортку, шоб він переписував функції, реалізовані в хедерах, на Rust вручну. В Python і C# така ж позиція в цьому, наскільки я знаю. Цікаво, чи хоч якась мова, синтаксис якої не сумісний з С, вирішує це краще?)

Ок, відкрив рандомний публічний хедер (code.dpdk.org/...​_eal/include/rte_bitmap.h) — є багато static inline (те, про що писалось вище). Так, я не бачу способу обернути це в Rust.

К сожалению — это образец плохого дизайна кода на С и такими библиотеками лучше не пользоваться, если есть альтернативы. Используя статики в хэдерах, функциональность библиотеки размазывается между самой библиотекой и клиентом, что является источником многих ошибок, например:

static inline void
__rte_bitmap_index2_set(struct rte_bitmap *bmp)
{
	bmp->index2 = (((bmp->index1 << RTE_BITMAP_SLAB_BIT_SIZE_LOG2) + bmp->offset1) << RTE_BITMAP_CL_SLAB_SIZE_LOG2);
}

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

Зато быстро работает

__rte_bitmap_index2_set(struct rte_bitmap *bmp)

Конкретно эта функция не документирована, и, можно предположить, не является частью API.

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

В DPDK не предполагается совместимости API и ABI между мажорными версиями. Разные мажорные версии библиотек имеют даже разные названия.

Ну наконец-то нормальная статья про Rust! До этого только лозунги фанатиков попадались.

А чего вы все так на раст ополчились? Прикольный язык, я когда попробовал на нём писать начал ловить флешбеки начала 90х прошлого века, приятный, тёплый, ламповый язык. Как буд-то снова сижу за своей 386SX-33MHz, всё так медленно, спокойно, исполнение команд видно невооружённым взглядом. Спасибо расту за ностальгию!

исполнение команд видно невооружённым взглядом.

que?

це може ти cборку спостерігав?

Навіть скалу переплюнув за медитативністю?

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

Открыл клетку с черепахами, а они как ломанутся! ©

В Канаді конопля легалізована?

Ещё как!

Як трактор в Канаду, ще їде, чи як у Трампа?

Если честно, то даже не интересовался.

прийшов Майк, ще не вистачає Кожаєва

Наблюдение не однократно увиденное — ни раз, ни два и не три, в разных местах и в обсуждениях.

Самыми «ярыми противниками» Rust являются разработчики.... на С/С++. И чем они «махровее», тем «более противнЕе» они выступают (доводы — в нем нет и быть не может : ничего нового, полезного, удобного, безопасного, от гонок данных не защищает... и т.д.).

Их МОЖНО ПОНЯТЬ... т.к. они много усилий вложили в другой сложный ЯП и поэтому изучать что-то ДРУГОЕ для них «как бы не мыслимо». Это downgrade + еще не малые усилия. Это «нормальная психологическая защита», имхо.
Хотите «угробить» проект хорошо подходящий для Rust — возьмите «хорошего плюсовика», он отговорит. :)

Поэтому основные люди приходящие и вполне осваивающие Rust — из мира js, python, java, иногда Go, xxx#, ruby, редкая птица из С/С++ долетит до раст (хотя бывают).

Доказывать что либо, кому либо — не собираюсь, так «наблюдения из жизни».

....по большому счету этого достаточно. Больше на тебя можно не обращать внимания.

Странный... :)

Самыми «ярыми противниками» Rust являются разработчики.... на С/С++. И чем они «махровее», тем «более противнЕе» они выступают (доводы — в нем нет и быть не может : ничего нового, полезного, удобного, безопасного, от гонок данных не защищает... и т.д.).

міг би коротко написати: старпёри

Это ты про меня ?? :)))
Ну, ну... :-D

я замінив довге речення одним терміном (десятиповерхову С конструкцію одним рядком з Rust )

Таких называют «не осильщики» (не шмагла я, не шмагла). :)

Странно обсуждать то, что «вам не зачем».
Проходил мимо — решил «писнуть» ??

> Самыми «ярыми противниками» Rust являются разработчики.... на С/С++

«Спасибо» агресивным фанатам Rust за нападки в основном на сишников и плюсовиков. Антипатия к отдельным пропагандистам теперь переросла в антипатоию ко всем раст-разрабам, а то и к языку как таковому. Такова людская психология.

> т.к. они много усилий вложили в другой сложный ЯП

Это C вы назвали сложным? Я бы еще поспорил на счет С++, но проще С я ничего никогда не видел.

«Спасибо» агресивным фанатам Rust за нападки в основном на сишников и плюсовиков.

Вы не перепутали???

Нападки — это когда «фанаты Раст» приходят в статью про С++ и нападают на чужой ЯП (кого можете в этом обвинить здесь ???).

А когда происходит «наоборот», в статье про Rust, фанаты С++ приходят и «нападают на другой» ЯП — это как раз «вам спасибо». :)) (нападки ниже)

до речі, чому Гошніки не псіхують, а в С++ників істерика?

до речі, чому Гошніки не псіхують

У них другое название вызывает лютый баттхерт — на букву S начинается, на а заканчивается))

Осторожнее, так можно скастить в тему дух упоротого гофера
Они на название триггерятся)

тре ж відвідуваність теми покращувати...

Осторожнее, так можно скастить в тему дух упоротого гофера
Они на название триггерятся)

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

до речі, чому Гошніки не псіхують

Шо, раст, шо го — мёртвые языки, чего им психовать?

мертві після того як родилися та пожили,
чи вмарли як родилися,
чи родилися мертвими,
чи родилися недоношеними і померли,
чи померли від аборту,
чи померли до аборту?
х.з., може ще є варіанти

Аминь.

Бо гофери перекваліфікувалися з інших мов і для гоферів звично що колеги розробляли раніше на Python, PHP, Ruby або навіть Angular, хоча зустрічав нападки гоферів на PHP

чому Гошніки не псіхують

Вони з цього стану не виходять (дивимось на А.В-на).

> Нападки — это когда «фанаты Раст» приходят в статью про С++ и нападают на чужой ЯП (кого можете в этом обвинить здесь ???).

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

И кстати, мне совершенно непонятно, почему они называют Rust «Убийцей С», когда его ниша больше пересекается с плюсами?

P.S. если под «здесь» вы имели в виду ДОУ, то тут я ничего подобного не наблюдаю. Скорее всего потому, что это не технический форум.

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

И кстати, мне совершенно непонятно, почему они называют Rust «Убийцей С», когда его ниша больше пересекается с плюсами?

потому, что бенефитов руста по сравнению с плюсами практически нет

Давайте не будем тут разводить холиваров на тему «язык А во всем лучше языка Б». Вопрос был в том, сможет ли Rust вытеснить С оттуда, откуда его еще не вытеснил С++?

ядро лінукса переписувати ніхто не буде (в найближчі 5 років)
але якщо будуть братися за нові проекти, то цілком достатньо простору для Rust замість С та С++ для системного та низькорівневого програмування, та замість Го, Джави, РНР, Пайтона на бекенді.

5 лет — это как-то совсем оптимистично. Я полагаю, текущая структура Линукса умрет только вместе с самим Линуксом. Да и логично было бы после полного переписывания дать дродукту уже другое название. В общем, тут более вероятно перетягивание всех user-space надстроек на совершенно другое ядро. Да и совать много логики в модули ядра — это дурной тон.

замість Го, Джави, РНР, Пайтона на бекенді.

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

Вопрос был в том, сможет ли Rust вытеснить С оттуда, откуда его еще не вытеснил С++?

А вообще-то НЕ было такого вопроса. Чего врете то, взрослый вроде уже...???

Было мнение Макрософт, что: Rust является ’лучшим шансом’ в отрасли программирования безопасных систем

Статью вы НЕ ЧИТАЛИ, поэтому вам было НЕ ДОСУГ (барское ли это дело???) прочитать текст MS о том, что :
Хотя Microsoft оптимистично настроена на Rust, Левик признает, что разработчики ядра Microsoft не прекратят использовать C/C++ в ближайшее время.
«У нас в Microsoft много C++ и этот код никуда не денется» — сказал он. «Фактически, Microsoft продолжает писать на С++ и будет писать некоторое время».
Много инструментария построено на C/C ++. В частности, двоичные файлы Microsoft сейчас почти полностью собраны компилятором Microsoft Visual C++............

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

Кто кого должен вытеснить, вы это о каком ВЫТЕСНЕНИИ ??

разработчики ядра Microsoft не прекратят использовать C/C++ в ближайшее время

Ну естественно, переход под .Net не молниеносный.

А вообще-то НЕ было такого вопроса.

dou.ua/...​rums/topic/30864/#1882628
Абзац «И кстати, мне совершенно непонятно, почему они называют Rust „Убийцей С“, когда его ниша больше пересекается с плюсами?»

Похоже, вы не в тот тред откоментировались. Тут Microsoft не обсуждался. Тут про конфликс с сишниками/плюсовиками.

Сами задаете вопрос, сами на него отвечаете??
Ну... не буду вам мешать, «приятно поговорить с умным человеком». :)

Сам задаю вопрос, сам уточняю его.

А вашу агрессию я могу объяснить лишь тем, что вы узнали себя в моем первом коментарии этого треда. Про фанатов Rust, набегающих с холиварами на сишников и плюсовиков.

Я думаю, что скорее вы узнали себя как сишника и плюсовика набегающего с холиварами на других в статье про Раст.
Думаю, что вам следовало бы даже принести извинения за эти самые не обоснованные обвинения, которых как ВЫ САМИ признались здесь НЕ было, а они были «где то там».

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

Но увы... это интернет и в нем «в завтрашний день не все могут смотреть....»

вот видишь, с растаманами лучше не спорить

но проще С я ничего никогда не видел.

Конечно вы вряд ли видели БК-0010, с его простым и «ламповым» BASIC интерпретатором. Я его видел и тоже знаю «что проще чем Си».

Сложность языка заключается в том, что на нём сложно научиться писать рабочие программы. Сам язык простой, но он слишком простой и не предотвращает очень опасные ошибки. Тоже можно сказать и про JS! язык прост, но овладеть им настолько, что бы писать надёжные программы крайне сложно.

Я бы это списал на порог вхождения. Да, для С он довольно высокий. Однако, тот объем компьютерной грамотности, позволяющий без проблем писать на С, в сфере его оправданного применения, он совсем не специфичен для С, а точно так же полезен и при использовании любого другого языка для тех же самых задач.

Сравните это с тем же изучением JS или Java фреймвороков, которые в отрыве от соответствующего языка никак не применимы.

Только давай не припутывать сюда любителей теплого лампового С.

Проклятый Майкрософт, опустился до «унижения» Си... увы, «из их песни слов не выкинешь». Можете на них пожаловаться, я ничем помочь не могу. :(

Джаваскрипт тоже «безопасный и простой», тот же Пайтон... Но почему-то я не вижу, как эти языки вытесняют С из его «зоны обитания».

я вижу. вот например:
— GNOME2 был на C
— GNOME3 — на javascript (gnome shell)

И где сейчас этот гном?

в убунте, и производных дистрах, как дефолтный DE

производных дистрах

особенно в кубунте

в Fedora / RHEL еще
в кубунте тоже есть, но не дефолтный

но не дефолтный

так про любой дистрибутив можно сказать

в кубунте тоже есть, но не дефолтный

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

GNOME3

глючный тормоз

глючный тормоз

там еще остались куски на C

поэтому оно еще хоть как то шевелится

— GNOME3 — на javascript (gnome shell)

Спасибо, теперь я понимаю почему он так тормозит на 8 ядрах.

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

Спасибо, теперь я понимаю почему он так быстро отрицательно акселерирует на 8 ядрах!

минус положительно (или альтернативно положительно)

Спасибо, теперь я понимаю почему он так быстро отрицательно акселерирует на 8 ядрах!

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

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

Как для восьми ядер очень качественная и детализированная симуляция slow motion!

Спасибо, теперь я понимаю почему он так быстро отрицательно акселерирует на 8 ядрах!

так spider-monkey написан на C++, что еще ожидать?
приходится ждать, как перепишут на rust

ти уже попав на италійський сайт за вордінг

Та ну, там по-доброму, як про Люксофт.

В теме про канадскую неосиляторшу? Так то у жука проблемы с парсингом текста, не мои. Многие в 90% случаев сами что-то выдумывают, а потом с этим спорят, со стороны выглядит как спортивный анонизм.

та яка потім осіла в Іспанії

італійський сайт тобі ссилка

У Gnome2 и Gnome3 из общего только название. А так, продукты в совершенно разных идеологиях.

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

Я помічаю подібну тенденцію. Але на щастя виключень вистачає, щоб мова розвивалась в напрямку покриття ніши С++. Я теж прийшов в Rust з C++. ІМХО, вивчення Rust і розвиток інтуїції в ньому допомогли мені писати кращий С++ код: думати концепціями володіння і тривалості життя об’єктів дуже зручно і там.

Вакансії зʼявляться, коли буде ротації з legacy проектами, що навряд чи буде найближчим часом. Загалом, ніша С/С++ дуже консервативна і не завжди Rust має сенс для старих проектів, а нові закриваються спеціалістами, які самі вирішили його спробувати. Клієнтам переважно байдуже, що «під капотом».

Прорив буде лише після стабілізації екосистеми. Для web він ще молодий (не так давно додали async, фреймворки ще сирі), а WebAssembly дуже повільно стандартизується. Для мікроконтролерів писати щось ефективне без unsafe взагалі проблематично. Наразі екосистема ефективна лише для проектів, де важлива швидкодія і паралелізація: рушії (2D,3D,html, css тощо), системні засоби (як-от, ripgrep), парсери, криптотехнології тощо.

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

Нагуглюєтся Rust під STM32.

Також підтримка FreeRTOS.

Так що цілком можливо, що ми принагідно доберемося спробувати...

Лучше не надо пробовать. А то у вас будет некому это поддерживать — это же очевидно.

Собственно оригинал видео-конференции ’cloud developer advocate’ Райан Левик-а (Ryan Levick)

www.youtube.com/watch?v=NQBVUjdkLAA

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

«VSCode» + «rust-analyzer» показывают вполне «приятную связку». Легко ставятся под разные платформы, легко обновляются новыми версиями. Под эмбеддед не пробовал, но тоже думаю не большая проблема.
CLion (или IDEA IntelliJ) + Rust plugin — тоже вполне работают для комфортного использования (но оба «обычно платные»).

CLion (или IDEA IntelliJ)

платні, нє?

VSCode

Windows only, нє?

платні, нє?

Месяц бесплатно, не? ) Потом если зайдет 90$, и пользоваться этой версией можно всегда, следующие версии 70$ в год можно брать. Или разбить эту огромную сумму на ежемесячные платежи.

Честно говоря, не совсем понимаю, как можно с нашими ЗП зажлобить 8$ в месяц и работать в блокноте вместо нормальной IDE

платні, нє?

Є повноцінна версія Intellij IDEA Community під Apache License 2.0.

Windows only, нє?

Не — прекрасно на линукс работают.

VS Code працює і під лінуксом

платні, нє?

Intellij IDEA Community Edition как бы бесплатен)

Windows only, нє?

Неа) Это вы наверное VSCode с Visual Studio перепутали)

Ні мода, ні тренди, не задається ні РБ ні вна неньці, і навіть не в РФ.
з.і.
в твоїх предметій темі, скільки вакансій на б.СНГ?

Не соглашусь — есть мода и тренды, но не на «абстрактный ЯП в ваккуме», а на «безопасность, скорость» и другие «плюшки» Раст.

і що? може гіганти оутсорса задають тренди?

Мне кажется, это попытка объяснения — «довольно однобокая». Процесс более сложный, разрабы предлагают заказчику (на его усмотрение), заказчик ищет «бенефиты» от внедрения (экономия чего то — железа и т.д.). Тренды могут задавать «масс медия», но тут ситуация в том, что Раст выбирают разработчики и ПОКА процесс идеть больше «снизу».
Но это меня особо НЕ беспокоит... я не тороплюсь, я «просто знаю»...

Раст выбирают разработчики и ПОКА процесс идеть больше «снизу».

habr.com/ru/post/506598
Возможно, самая большая проблема, тем не менее, является культурной. «Есть некоторые люди, которые хотят выполнить свою работу на языке, который они уже знают», — признался Левик.

По факту — большая часть проектов начатых на Раст — скорее инициатива разработчиков, т.е. «идет снизу».
А вы сами — ТОЧНО ТОТ САМЫЙ ПРИМЕР... поэтому я вас не понял.

в моєму випадку то була рекомендація клієнта

забув про Китай, вже звідти починають оутсорсити б. СРСР

Нет, потому что это «типичная» ситуация «курица и/или яйцо». Что раньше, проекты и люди под них, или сначала достаточно людей и проекты.
Ничего страшного в этом нет.
«Кто хочет — ищет возможности, кто не хочет — ищет причины».

Мне Rust-а достаточно в «ламповых пет-проектах свободного от работы времени», а когда придет время «я, например, буду во все оружии». :) И это время «уже приходит»... Козак-и (вакансия ниже) не просто так к нему пришли, а потому что «оно того стоит», имхо.

Когда JS начинался (поищи в каком году), там не было ни прототипов, ничего сложного, потому что ниша его была вполне понятная и определенная. А позже он превратился в «тот самый ненормальный ЯП» (с ваших слов). Я ничего против него не имею, кроме того что он динамический — легко пишется, тяжело отлаживается и все в рант-тайм... Раст — строго типизирован, если скомпилировалось, то работает без ошибок (от логических ошибок разраба никто не застрахован)
Дальше нужно пояснять... или все и так понятно?

Удачи сомневающимся....

потому, что лапки (см. ветку про НТП)

Экспоненциальная кривая сложности, гораздо проще чем логарифмическая для новичков.

Нет, потому что это «типичная» ситуация «курица и/или яйцо».

с рустом типичная ситуация мейнтейненса — «кто и как будет потом это суппортить?»

А чем D хорош и почему он не пошел? Может, реально не настолько хорош?

Наверное, потому что «безопасность у D на уровне С/С++» — т.е. «никакая» ??

Сказал пользователь ОС, написанной на С

Это означает, что я должен использовать ОС написанную исключительно на Раст-е?? Увы, такой возможности сейчас нет, потому что ЯП — с 2015 года.
RedoxOS еще не готова, но... кто знает, что будет когда она будет готова.

А вы совневаетесь в выводах Майкрософт ?? :) Можете обосновать свое опровержение их выводов ??

А какие у них выводы?
Чем Вас не устраивает надежность современных операционных систем?

«Чукча не читатель, чукча — писатель»... хорошо, прочитаю вместо вас.

«Мы используем языки, которые не дают нам возможности защитить себя от подобных уязвимостей, потому, что они довольно стары и происходят из другой эпохи», — сказал он. «C++ не является безопасным для памяти языком и никто не притворялся бы, что это не так», — сказал он.
Фактически, Microsoft сочла C++ менее приемлемым или менее подходящим для написания критически важных программ. Отрасль крайне нуждается в переходе на производительный язык, безопасный в плане работы с памятью для низкоуровневой разработки систем. А лучший выбор на рынке сегодня — это Rust, сказал Левик.
.......
Но отрасль страдает от всех ошибок, связанных с памятью многие из которых представляют угрозу безопасности. Сейчас по словам Левика, 70% CVE (www.zdnet.com/...​are-memory-safety-issues) созданных в Microsoft, являются проблемами безопасности памяти. «Нет никакой реальной тенденции, это соотношение не растёт и не убывает, оно просто остается неизменным», — сказал он. «Несмотря на огромные усилия с нашей стороны, чтобы решить эту проблему, это все еще кажется обычным делом».
..........

Может, еще проанализируете за меня ситуацию с Линуксом? Там, кажется, лучше ситуация — после покупки Микрософт даже Скайп и Линкедин начали нестабильно работать.

Также можете изучить вопрос RTOS — они написаны на С и считаются достаточно стабильными для использования в life-critical systems.

Можете на RTOS запустить LibreOffice, чтобы я мог написать какой-то документ, раз уж она «достаточно стабильная» ?

А Вы не боитесь нестабильности

LibreOffice

?

Вы сами написали «RTOS достаточно стабильная»... я вам доверяю.
Хотел узнать — справитесь ли? Похоже нет... :( ну ладно.

Меня и Убунта устраивает)

На Убунте — я и сам ее запущу, спасибо.

Не страшно? Там же в ядре ужас-ужас, порча памяти и уязвимости. А в юзер спейсе — еще и С++ могут попасться.

Прям как «в воду глядел», типун тебе...
www.cvedetails.com/...​-Kernel.html?vendor_id=33

2016 год — 217 штук
2017 — 454
2018 — 177
2019 — 170
2020 — ???
Total — 2333

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

Денис же написал — «достаточно стабильная», но не указал где и для чего. :) Мне тоже для life-critical хочется.

Хочется — делай)

Вы сами написали «RTOS достаточно стабильная»

RTOS это не название ОС. Это обозначение класса ОС.
пример RTOS — QNX
QNX — более чем стабильная. области применения — можете сами нагуглить

Да, раньше у нас были билды libreoffice — потребителей 0, теперь только оставили Qt и Chromium.

Также можете изучить вопрос RTOS — они написаны на С и считаются достаточно стабильными для использования в life-critical systems.

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

Они делались сразу такими. И да, пару человеко-лет там могли быть вложены.

И да, пару человеко-лет там могли быть вложены.

у вас получается, что RTOS по сложности ~ среднему пет проекту
зачем вы тогда это как пример приводите?

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

Ну... если действительно брать HW, то, ИМХО, там проблем больше, чем Rust может решить. Моё видение, что Rust больше заточен под Usermod. Всё-таки моменты, связанные с IRQ, выгрузкой страниц из памяти и т. п. уже больше не являются прозрачными, и язык почти никак не поможет в их разруливании.

Основной пойнт не в том, что на C можно писать стабильный код. Это можно делать и на ассемблере, почему нет? Тут проблема в том, какие ресурсы могут быть потрачены на разработку.

какие ресурсы могут быть потрачены на разработку.

обратно пропорционально ресурсам, потраченным на обучение

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

работают в медицине и в космосе,
пару человеко-лет

ок

C++ не является безопасным для памяти языком и никто не притворялся бы, что это не так

Достаточно странно, что Microsoft ссылается на C++, а не на C#. Не говоря о том, что Microsoft это Windows, и там я не знаю аналогов valgrind и санитайзеров clang, которые позволяют отлавливать действительно много проблем с памятью. Возможно что-то поменялось за то время, когда я ушёл из мира Windows, но по ощущениям Microsoft всё-таки большую часть усилий направляли на C#, до недавнего времени там не поддерживаелся даже древний стандарт C99.

И очень непонятно, почему Левик не говорит ничего о многопоточности. Потому что именно доказательсва отсутствия race conditions (при условии, что unsafe код работает правильно) это достаточно весомая плюшка Rust. Не говоря о том, что Rust принуждает разрабатывать приложение грамотно с точки зрения возможных проблем с многопоточностью, без накапливания технического долга.

А вы совневаетесь в выводах Майкрософт ??

да, черт побери, да!

я читав, тому, що D потім вирішив бути «умним і красівим», і втратив фокус

Пришел Александреску и снова все испортил ?

там же гербедж коллектор из коробки ?

В продуктах можуть бути вакансії.

(Ми на С++ правда — але хтозна, може років за 10, якщо не здохнемо, потопчемо Rust’у. Особливо, якщо він буде помічний для всяких сертифікацій з безпеки...)

Достаточно хорош. Не пошёл, потому что никто не занимался его раскруткой. За Го стоит Гугл, за Растом — Мозилла. Д же делался отдельными энтузиастами, продвигать его в массы было некому из больших корпораций (такой мог бы оказаться Фейсбук, если бы Александреску оттуда не ушёл).

У D були проблеми з ліцензією компілятора — він належав Symantec. І тільки в 2017 вони відпустили його.
Ну а основна проблема — відсутність великих корпорацій за ним. Ну і garbage collector — не всім він підходить. Хоча зараз туди додають аналогічну до Rust систему з borrow-checker.

Никогда он не принадлежал Symantec.
И компиляторов 2 — dmd и gdc — второй вообще под GPL

DMD, the reference compiler for D, has been encumbered by legacy licensing, courtesy of Symantec.

www.infoworld.com/...​piler-is-open-source.html

поменяли лицензию на Boost License, исходники (open source) были доступны и до этого
сам компилятор симантику никогда не принадлежал
https://forum.dlang.org/thread/[email protected]

Не розумію, чому ви так кажете. Перший пост на форумі по вашому посиланню:

Yes, this is for real! Symantec has given their permission to relicense it. Thank you, Symantec!

D був альтернативою хрестам, а не пішов тому що велика частина стандартної біблотеки потребувала garbage collector. Як тільки хтось скаже програмісту на плюсах що системна мова вимагає GC, для нього вся дискусія на цьому закінчиться.
Зараз ситуація звичайно виправилась, алгоритми не потребують більше GC, сам GC став опціональним, мова стала набагато потужнішою і загалом є кращою аніж С++.
Якби D був в теперішньому стані років 8 назад, я думаю він би злетів. Але РАПТОВО з’являється RUST, який не тільки пропонує zero-cost абстракції і купу плюшок ФП, а ще й вирішує багато проблем з безпекою.
В результаті кілька років назад у С++ не було альтернативи для системного програмування, а ті задачі які вирішував D зі своїм GC так само успішно вирішував і Go. Тепер D став нормальним для системного програмування, але як альтернатива з`явився Rust який краще.

Ну... D всё-таки отличается больше синтаксическим сахаром и GC. Если брать GC то уже есть Java, C#. Кроме того, язык D появился уже после волны популярности C++, когда возникло много объектно-ориентированных библиотек. Поэтому в том время лишить себя всех наработок С++ и написание биндингов к C в обмен на синтаксический сахар скорее всего было минусово.

Думал, он совместим с С++ либами.

Сомневаюсь, что можно заюзать, например, boost. Моё ощущение, что в D просто уменьшили количество разных граблей.

помню была шутка что Д куда более совмистим с С, чем С++ совместим с С. хз правда или нет.

DMD (Digital Mars D) полностью совсестим с Digital Mars C++

Если брать GC то уже есть Java, C#

В D можна было и в гарбедж колектор, и в малок если нужно.
Кроме того он был компилируемый в нативник, в отличии от жабы с дотнетом.

Хорош тем, что «косяки» C++ исправили — сам язык более «цельный» и приятный, нет порнографии, в виде препроцессора, и есть вменяемые темплейты. часть кода может выполняться в compile time.

«Не пошел» именно по этой же причине — знатоки C++ ничего друго-го видеть не хоятят, а знатокам других языков, D ничего революционного не предлагает.
Он бы вполне мог взлететь, если бы за ним была какая-то корпорация, а так его целевую аудиторию забирают golang, swift, kotlin-native, и тот-же rust

Тезисы про достоинства мягко говоря не очень хорошо сформулированы.
Например менеджер пакетов лучший, вот мне интересно а чем он так лучше pip в Python?
Тезис про то что нет garbage collector и при этом выше безопасность, тут тоже надо говорить по сравнению с C++, но при этом надо говорить что оверхед меньше чем в языках с виртуальной машиной. Основная работа на стеке минимум глобальных объектов, ну я вот и в C++ программ с огромным количеством глобальных переменных не видел. Меньшее время испролнения по-сравнению с чем, что-то я не вижу массовой миграции на Rust разработчиков ресурсоемких приложений, так что пункт тоже сомнительный. Ну и про корпорации, я разговоры в духе приведенных тезисов слушал лет 6 назад, что с тех пор поменялось? Mozilla не стала успешнее, это не способствует развитию языка, так что этот аргумент тоже не ахти. Ну и про быстрое написание прототипов, как он с Python соотносится совершенно не ясно.

garbage collector и при этом выше безопасность, тут тоже надо говорить по сравнению с C++, но при этом надо говорить что оверхед меньше чем в языках с виртуальной машиной

Оверхед такой же как в С++, ни больше, ни меньше.

Меньшее время испролнения по-сравнению с чем, что-то я не вижу массовой миграции на Rust разработчиков...

И не будет, т.к. Rust для новых проектов... или не спешного переписывания очень важных либ (что в природе происходит, но редко)

слушал лет 6 назад, что с тех пор поменялось?

Майкрософт сделал выводы, другие корпорации вроде Амазон, тоже спокойно используют.

В остальном — ЯП развивается, все нормально...

Майкрософт сделал выводы,

і пиляє свою мову на основі Руста

Послушай видео самого Ревика. ЯП «Verona», который они выложили в ГитХаб — это эксперимент. Во что он выльется — никто не знает, ясных планов по нему НЕТ.
А вот дать шанс Раст-у — про это Ревик уже говорит (в том числе от лица Майкрософт). Статья и видео (целых ДВА) есть, желающие могут послушать и сами сделать выводы.

я вот и в C++ программ

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

Rust — универсальный язык, железо, микро-сервисы, системное ПО, web (yaw веб framework) он подходит для всего (при должном навыке). Порого вхождения в ЯП — высокий, да.

Коропорация Microsoft в лице ’cloud developer advocate’ Райан Левик (Ryan Levick) рассказала, что : «C++, по своей сути, не является безопасным языком», поэтому Microsoft постепенно переходит с C/C++ на Rust для создания своего инфраструктурного программного обеспечения. И вдохновляет других гигантов индустрии программного обеспечения задуматься о том же."

Детали в переводе :
habr.com/ru/post/506598

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

Согласен, микроскопом — тоже можно гвозди забивать, вы же похоже «как раз про это» ??

Да, да, и плац ломом подметать.

А як же «Лопата — друг солдата»?

Насчёт железа не уверен, да и решит по дизайну только часть проблем. И потребует очень большой обвязки unsafe, макросами и т. п.

нема збирача сміття;
мінімум ручного управління пам’яттю

Як воно організоване тоді?

„Conclusion

These ideas—smart pointers and references—form the basis of memory management in Rust. If you’re a C++ programmer, most of this will (hopefully!) simply have been an exercise in learning different syntax. For other programmers, these concepts are likely more foreign. But using these tools, you can write code with fine-grained control over memory, with improved safety over languages like C.”
смешно, да

на Rust, ти можеш під капот не лізти, і писати висопродуктивний безпечний код.
при чому більше компактний в строках, а менше коду — менше багів, ще один плюс Руста.

люди, которые подобное говорят, при этом сравнивая руст с плюсами, просто не видели последние изменения в плюсах
ц++20 будет не меньшим шагом, чем ц++11

і шо?
от ти думаєш, що тут фанат Руста прийшов тебе прінуждать к любві к Русту?

от ти думаєш, що тут фанат Руста прийшов тебе прінуждать к любві к Русту?

я думаю, что руст надо сравнивать с Ц, а не Ц++

З Ц треба порівнювати Го.

Яка фіча 20х плюсів вирішує проблеми memory-management?

А які в ньому проблеми?

Теоретично ніяких — у тебе є і RAII i smart pointers і все таке інше. На практиці не зважаючи на наявність цих інструментів в тебе може:
— Текти пам’ять.
— Робити use-after-free.
— Звертатись за межі масиву
— Дедлоки на мьютексах

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

З мого досвіду більшість багів — семантичні. Щось робиться не в тій послідовності. Десь не завершується сценарій з обміном меседжами. Десь система входить в стан, котрий не передбачався при розробці. З пам’яттю класикою ваажається, коли рельно об’єкт не використовується, але на нього є вказівники. І це — причина (на додаток до фрагментації), чому програми з часом починають їсти більше пам’яті. Ось стаття хороша ithare.com/...​t-punishment-for-failure

Перші три вирішує санітайзер. Багатопоточність так, трохи складніше. Але...

use std::sync::{Arc, Mutex};

fn main() {
    let data = Arc::new(Mutex::new(0));
    let d1 = data.lock();
    let d2 = data.lock();
}
The exact behavior on locking a mutex in the thread which already holds the lock is left unspecified.

Тобто компіятор не може гарантувати.

не ++20, а начиная с ++11: сматртпоинтеры и обвязка

Зробити циклічну залежність на смартпойнтерах в коді з купою взаємодій коли не дуже зрозуміла модель володіння дуже просто. І тоді хопа — а пам’ять потікла. І компілятор тобі нічого не скаже.

коли не дуже зрозуміла модель володіння

очень даже понятна — в библиотеке есть явные инструменты для этого

І компілятор тобі нічого не скаже.

смотря какой

очень даже понятна — в библиотеке есть явные инструменты для этого

Я маю на увазі коли в проекті багато взаємодій (напр колбеки) часто модель хто ким володіє не є очевидною.

смотря какой

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

Valgrind може сказати

Ну... большей частью синтаксический сахар. Главное в том, что компилятор C++ не в состоянии доказать, что в программе нет ошибок при работе с памятью и race conditins.

Да, возможно, при соблюдении двух правил: (1) разрешён только один указатель на область памяти, по которому разрешена запись. Или разрешено несколько указателей, которым разрешено чтение. (2) тип указателя содержит ещё точку, где указатель освобождается. Если указатели освобождаются в разных точках, они несовместимы.

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

Да, такой подход имеет смысл для нетребовательных к памяти и скорости приложений.

Но для таких уже есть языки с GC

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

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

obj->next = nullptr;
obj->prev = nullptr; // А тут компилятор должен перечитать значение obj, потому что  obj->next вполне мог изменить сам obj. В Rust мы можем использовать закэшированное в регистре значение 

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

Ну а то, что нельзя играться с указателями сразу накладывает много сложностей на обработку больших картинок (4K).

Играться можно, только по правилам Rust. Например, картинка по факту это массив. Мы его может разбить на два массива, оба доступны для записи, и поскольку они оба доступны для записи, то правила Rust не нарушены.

Не говоря о том, что можно просто писать unsafe. И сама логика Rust не в том, чтобы полностью исключить unsafe, а скорее в том, чтобы продумать, каким образом минимальным количеством unsafe удовлетворить наши потребности в оптимизации. И если будут возникать ошибки, то весь safe код будет вне подозрения.

В общем, Rust в этом плане достаточно продуман, и я не думаю, что имеет смысл вот так наезжать на него не ознакомившись с ним. Практически любой код можно переписать на Rust без потери производительности, с этой задачей разработчики, ИМХО, справились.

Ну и нафиг Раст в этом случае.

unsafe кода обычно на порядки меньше

Картинку на 4k дорого копировать даже на современных мощных интелах с быстрой памятью.

Картинка не будет копироваться, это скорее аналог slice.

Вот покажи, как на Расте выглядит код для ответа на вопросы выше?

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

fn quick_sort<T:PartialOrd+Send>(v: &mut [T]) {
   if v.len() > 1 {
       let mid = partition(v);
       let (lo, hi) = v.split_at_mut(mid);
       rayon::join(|| quick_sort(lo),
                   || quick_sort(hi));
   }
}

fn partition<T:PartialOrd+Send>(v: &mut [T]) -> usize {
    let pivot = v.len() - 1;
    let mut i = 0;
    for j in 0..pivot {
        if v[j] <= v[pivot] {
            v.swap(i, j);
            i += 1;
        }
    }
    v.swap(i, pivot);
    i
}
/ А тут компилятор должен перечитать значение obj, потому что obj->next вполне мог изменить сам obj. В Rust мы можем использовать закэшированное в регистре значение

o_O вот только компилятор об этом не знает %)

void set_tt(struct tt* t)
{
    t->next = NULL;
    t->prev = NULL;
}

<------>movq<-->$0, (%rdi)
<------>movq<-->$0, 8(%rdi)

хіба в С / С++ з багатопоточністю ліпше: мютекси-шмютекси, умовні змінні, переключання контексту...

компилятор C++ не в состоянии доказать, что в программе нет ошибок при работе с памятью

address sanitizers

race conditins

нет мютексов — нет проблем :)

нет мютексов — нет проблем :)

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

address sanitizers

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

С учётом твоей специфики (научный софт, расчёты), я вижу там больше проблемы в предметной области, нежели в программной реализации. А вот если реализовывать ту же ноду Ethereum, то там проблем будет несколько больше: очень много сущностей, очень много взаимодействий, требования по производительности, ...

“A couple of weeks ago, I tried out Rust. One of its concept, called ownership, made me excited”
std::move/std::forward
I’m excited!

Ще раз повторяю, напиши статтю для доу, що Руст авно, а в С++11 вже девно є мув сементика, а непорядні рустамани її стибзили.

п.с.
std::swap забув

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

ще одни Вітя з РБ,
ви близнюки?

нет аргументов, поэтому переходишь на личности?

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

от ти і Вітя вирішили, що їм тут насаджують Руст

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

Я утверждаю, что — безопаснее, а вы говорите «мягко говоря не правду».

Я утверждаю, что — безопаснее

на основании чего?

Вы просто докажите обратное.

Как? Надо что-то широкоиспользуемое на Расте. В Файрфоксе пока только четверть кода переписали.

Придумайте сами.

msrc-blog.microsoft.com/...​-security-daemon-in-rust

Before we shipped Azure IoT Edge for general availability, we ENGAGED AN EXTERNAL SECURITY VENDOR to perform penetration testing on the software. The fact that they discovered ZERO SECURITY ISSUES with the Rust part of the codebase was to us a vindication of our choice of Rust.

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

Таки переплюнул в том плане, что если в C++ можно ошибиться (а мой опыт подсказывает, что если я могу совершить где-нить ошибку, я её обязательно совершу), то в Rust такие ошибки исключаются компилятором. Например, допустим есть многопоточное приложение. В случае Rust если оно компилируется, значит там исключён race condition. А в случае C++?

А в случае С++ используются Actors или Pipes and Filters.
О многопоточности в логике: ithare.com/...​hreading-with-a-script/2

Нет, в rust типа исключён data race наличием ownership’а, но race condition вполне легален, грабли поданы, сэр! Как по мне rust исключает те кейсы, которые может только ньюби создать или миддл в пьяном угаре.

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

Вы скорее всего гораздо умнее всего Майкрософт, потому что их опыт не совпадает с вашим, и говорит о том, что даже „делая внутреннее обучение” и обучая „всех быть более сеньеорными и безопасными — это не помогает существенно исправить ситуацию с наличием и появлением новых CVE на С++”. (Именно поэтому они оценили Rust)

The race condition, but not a data race: it’s a little subtle, but they are different

В остальном, все верно, и про это написано и рассказано:
doc.rust-lang.org/nomicon/races.html
data race has Undefined Behavior, and is therefore impossible to perform in Safe Rust. Data races are mostly prevented through Rust’s ownership system: it’s impossible to alias a mutable reference, so it’s impossible to perform a data race. Interior mutability makes this more complicated, which is largely why we have the Send and Sync traits (see below).
However Rust does not prevent general race conditions.
.......So it’s perfectly „fine” for a Safe Rust program to get deadlocked or do something nonsensical with incorrect synchronization.
........Still, a race condition can’t violate memory safety in a Rust program on its own. Only in conjunction with some other unsafe code can a race condition actually violate memory safety. For instance:.........

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

A data race has Undefined Behavior

Это установка языка, а не платформы. На данной конкретной платформе они как правило имеют очень даже defined behavior. И язык, который не учитывает аппаратные особенности платформы, абстрагируя от неё ничем не отличается от той же Java.

Извините, читать ваши глупости — утомило и нет времени. :)

Как всё запущено. Если что-то не понимаешь, то объявляешь это глупостью. Очень удобно.

И язык, который не учитывает аппаратные особенности платформы,

Готовы доказать, что раст «не учитывает»?

навєрно шо «біблотєка Лінукс для С ніхрєна не гарантірує»

Ты сам вверху написал

A data race has Undefined Behavior

Причём даже не понял что имеется в виду под этим:

1) Результат чтения и записи непредсказуем, но он и не предсказуем даже в случае с атомиками — кто последний, тот и прав.
2) Процессор так или иначе сериализирует доступ к данным через внешний контроллер памяти или свои кеши, что даёт автоматически атомарные операции при работе с памятью при соблюдении определённых условий. На С/C++ ты можешь утилизировать все эти свойства не делая абсолютно ничего, на расте же ты не контролируешь доступ к памяти, только через прослойку абстрактной машины.
3) Все имплементации многопоточных высокоэффективных алгоритмов утилизируют свойство _контроллируемых_ data races.

The threading model в расте вообще оторвана как от ОС, так и от аппаратной платформы. В С++ лишь немногим лучше. Например, изменение приоритета потока возможно лишь в самом потоке только с использованием внешней библиотеки, которая является залипухой поверх posix threads, но при определённых условиях можно сделать так, что вновь созданный поток может вообще не получить управления для изменения приоритета. Потоки для домохозяек.

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

какой машины?

The threading model в расте вообще оторвана как от ОС,

ти про що, про треди чи про канали
mpsc ?
чи про «зелені нитки» Го?

So it’s perfectly „fine” for a Safe Rust program to get deadlocked or do something nonsensical with incorrect synchronization.

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

Так контролируешь или ВООБЩЕ НИКАК НЕ контролируешь? Похоже все-таки контролируешь с помощью классов, в ЧЕМ ПРОБЛЕМА? Работает „по другому” чем где-то там.... ну и ЧТО?

В С++ лишь немногим лучше. ........возможно лишь в самом потоке только с использованием внешней библиотеки, которая является залипухой поверх posix threads, но при определённых условиях можно .....

doc.rust-lang.org/std/thread
The threading model
An executing Rust program consists of a collection of native OS threads, each with their own stack and local state. Threads can be named, and provide some built-in support for low-level synchronization.

Communication between threads can be done through channels, Rust’s message-passing types, along with other forms of thread synchronization and shared-memory data structures. In particular, types that are guaranteed to be threadsafe are easily shared between threads using the atomically-reference-counted container, Arc....

В Rust контролировать race conditions нельзя или МОЖНО?

Так контролируешь или ВООБЩЕ НИКАК НЕ контролируешь?

Контроллирую процесс доступа, но не контроллирую результат.

Похоже все-таки контролируешь с помощью классов, в ЧЕМ ПРОБЛЕМА? Работает «по другому» чем где-то там.... ну и ЧТО?

Как можно контроллировать с помощью классов, не зная что под капотом в каждой конкретной версии. Базовый пример — спинлок.

and provide some built-in support for low-level synchronization.

И зачем ты мне это цитируешь? Ключевое слово SOME — то, что надо домохозяйкам и ничего лишнего, что взорвёт головы бедным программистам на расте.

В Rust контролировать race conditions нельзя или МОЖНО?

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

То, что на С является ван-лайнером на расте надо городить целый огород:

doc.rust-lang.org/...​ch16-03-shared-state.html

что на С является ван-лайнером на расте надо городить целый огород:

Так где доказательство того, что в раст нельзя контролировать race conditions даже с помощью (built-in support for low-level synchronization) примитивов ??

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

Контроль кодогенерации — тут я ничего толкового сказать не могу, врать не буду. То что есть:
doc.rust-lang.org/...​e/attributes/codegen.html

А если «хочется совсем упороться», то ASM вполне подойдет под нужную платформу, не пойму где доказательство??
doc.rust-lang.org/...​book/inline-assembly.html
если хочется «упороться» — то всегда пожалуйста.

Так где доказательство того, что в раст нельзя контролировать race conditions даже с помощью (built-in support for low-level synchronization) примитивов ??

Я ж тебе привёл пример — ты не можешь задать приоритет потока до его создания.

Не прыгайте с темы на тему. Давай сначала разберемся с :

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

Учитывает ?? — ДА, оказывается УЧИТЫВАЕТ аппаратные особенности платформы!

... ты не можешь задать приоритет потока до его создания...

Да, что вы говорите...?

Для UNIX
docs.rs/...​hread_priority/index.html

Для Windows
docs.rs/...​fn.SetThreadPriority.html

Что еще начнете фантазировать и свои фантазии выдавать за действительность???
«Да у него гранаты не той системы» (С «Белое солнце пустыни»)

Учитывает ?? — ДА, оказывается УЧИТЫВАЕТ аппаратные особенности платформы!

Не увидел, где учитывает?

Да, что вы говорите...?

Для UNIX
docs.rs/...​hread_priority/index.html

Там для текущего потока, разве не?

Не увидел, где учитывает?

The «target_feature» attribute may be applied to an unsafe function to enable code generation of that function for specific platform architecture features.

Там для текущего потока, разве не?

Да, для текущего.

Если «хочется совсем упороться», то ASM вполне подойдет под нужную платформу

Найдется очень много разрабов, которым без этого «ну никак нельзя» и обычными примитивами синхронизации ну никак не обойтись, от слова «совсем»?

The «target_feature» attribute may be applied to an unsafe function to enable code generation of that function for specific platform architecture features.

Ну и зачем такой язык, который по команде превращается в С?

Найдется очень много разрабов, которым без этого «ну никак нельзя» и обычными примитивами синхронизации ну никак не обойтись, от слова «совсем»?

Да, именно так. В любом mission/life critical применении это необходимо. Необходимо контроллировать кодогенерацию, нужно знать что на выходе.

Ну и зачем такой язык, который по команде превращается в С?

Это ж ***енно. Можно написать 99.9% кода на безопасном расте, на котором нельзя сделать ничего плохого, и 0.1% на небезопасном расте там, где это нужно (кошмар, даже с богомерзким inline asm).

Да, именно так. В любом mission/life critical применении это необходимо. Необходимо контроллировать кодогенерацию, нужно знать что на выходе.

т.е. языки программирвания вообще юзать нельзя, только ассемблер?

Это ж ***енно.

Нет, это пи@$ец. С и С++ стандартизирован и есть требования к кодогенерации.

т.е. языки программирвания вообще юзать нельзя, только ассемблер?

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

Нет, это пи@$ец.

В чем п****ц, конкретно?

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

Т.е. не «контролировать», а «кушать что дают».

В чем п****ц, конкретно?

В том что концепция как языка общего назначения была полностью провалена. Чтобы сделать что-то отличное от сдвига окошка на 1 пиксель нужно включать unsafe режим.

Т.е. не «контролировать», а «кушать что дают».

Можно подумать в расте не так.

Где-то я уже читал...

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

Это «позор, безобразие, непотребство» !!!

Можно «скомпилить в платформу», можно контролировать генерацию.

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

Это «позор, безобразие, непотребство» !!! концепция как языка... полностью провалена

«Вы уж либо крестик снимите, либо трусы наденьте» (анекдот)

Можно «скомпилить в платформу», можно контролировать генерацию.

И как ты будешь контроллировать в unsafe хотя бы out-of-order execution который привнесён самим компилятором? Барьеры?

Ты специально рандомные ссылки находил? %)
fy.blackhats.net.au/...​_orderings_explained.html

Рука предательски дрогнула, вторая ссылка была на не тот Ordering что нужно было. Вот правильная:

doc.rust-lang.org/...​atomic/enum.Ordering.html

Гы, С++20. Это для атомиков, но а оно у них работает? Потому что даже в С++20 и бусте очень много было пустых стабов. Т.е. ты пишешь код, а реально по-боку какой ордеринг для атомиков. Для платформы реализован один дефолтовый и всё.

Если это тработает в LLVM, то работает и в Rust

Интеграция с LLVM запилена тут

Потому что даже в С++20 и бусте очень много было пустых стабов.

Стабы в релизе, еще и с версии 1.0.0 ??
Да вы фантазер однако... знатный.

Мда. Открой код и читай.

Гы, С++20.

Оно тут не отличается по сути от 11. 20 упомянут только ради мелких правок, которые там внесли (список orderingʼов не менялся, но глубокие тонкости семантики — да).

fy.blackhats.net.au/...​_orderings_explained.html

В чем суть? Юзать мьютексы и все будет хорошо, но не очень быстро?

В чем суть? Юзать мьютексы и все будет хорошо, но не очень быстро?

Разве это не идеология Раста? Только в safe оно под капотом.

В том что концепция как языка общего назначения была полностью провалена. Чтобы сделать что-то отличное от сдвига окошка на 1 пиксель нужно включать unsafe режим.

Есть unsafe режим: «кококо, язык провален, в нем оставили возможность выстрелить себе в ногу»
Нет unsafe режима: «кококо, язык провален, в нем нет возможности выстрелить себе в ногу»

Я, например, пилю что-то сложнее чем сдвиг окошка на 1 пиксель, и пока из unsafe кода — несколько оберток над одной кошерной си-шной библиотекой . Все остальное — теплый ламповый rust. Unsafe код изолирован (в расте задается scope unsafe, например, можно указать, что только один блок в функции небезопасный, все остальное по дефолту будет безопасное). Не вижу, в чем проблема.

Можно подумать в расте не так.

Разумеется, так. Но никто не пытается продать Rust как язык, в котором есть какой-то офигенный контроль за тем, как будет происходить кодогенерация.

чекай, я не зрозумів, є С кодогенерація, для чого тоді С програмери?

Есть unsafe режим: «кококо, язык провален, в нем оставили возможность выстрелить себе в ногу»

С весь unsafe и в нём на самом деле очень много правил, чтобы unsafe не становился chaotic. У раста нет правил настолько, чтобы запускать в unsafe весь язык, например, а не пару строчек кода.

Поинт раста не в том, чтоб извратиться и написать всю программу как unsafe.

А в том чтобы написать ещё один браузер...

А в том чтобы написать ещё один браузер...

Конкуренция идет на пользу консьюмерам. Тебе нравилось, когда был один Internet Explorer 2.0?

Я застал время, когда был один Netscape Navigator, а Internet Explorer ещё даже в RCS не положили пустую функцию main().

WinMain(), дядьку. Это же IE...

Посыпаю голову пеплом! %)

unsafe тре включити, якщо ти хочеш через FFI викликати С код,
або хочеццо покоди в С стилі або ще щось такого труъ С-ного

або ще щось такого труъ С-ного

Если я захочу молока, я не буду пить соевое молоко %)

Соевое молоко это не молоко. Так как молоко добывают из (. )( .) Разве у сои есть (. )( .) ?

сначала ти создаш фабрику класов молока: яка тобі дальше создать нужний клас молока

Dad: What are you drinking, son?
Son: Soy milk.
Dad: Hola Milk, soy tu padre.

ми не з Техасу, в чому суть шуткі?

то була хвилинка гумору, не зважай

Обкуренный наркоман пришел домой, стучит в дверь. Из-за двери голос:
— Кто там?
— Мама, это я!
— Нет, сынок. Ты гонишь. Мама — это Я!

давай без оффтопов. правильно так:

Обкуренный рустаман пришел домой, стучит в дверь. Из-за двери голос:
— Кто там?
— Мама, это я!
— Нет, сынок. Ты гонишь. Мама — это Я!

Судя по issue, «почти никому» кроме вас это не нужно, иначе бы возможно уже сделали (кому ОЧЕНЬ надо, но за 7 лет таких не нашлось).
github.com/...​rust-lang/rfcs/issues/819

На самом деле на расте просто не писалось ни одного серьёзного приложения до сих пор. Только и всего.

язык, который по команде превращается в С?

Дает широчайшие возможности (при ОЧЕНЬ большой необходимости и такой же «осторожности + аккуратности»), разве не?

Конечно не писали, и скорее всего даже не будут писать, только и всего.
И мой мир рухнул и теперь не будет прежним, только и всего. :))

И врядли будет. До применении в mission/safety critical ему ещё очень далеко.

Такие планы есть, но меня они мало волнуют. Будет — хорошо, не будет — переживем. Хватит и обычного использования в бизнес системах. Для реализации „Sealed Rust” все упирается по большому счету в деньги и время...

Sealed Rust Update — Part 2 — The Plan
James | February 13, 2020
Sealed Rust is the effort led by Ferrous Systems GmbH to qualify the Rust Language and Compiler for use in the Safety Critical domain.
..........
Our goal is to improve the status-quo of software quality and correctness in safety critical domains by enabling the use of the Rust Programming Language for safety critical software development.
........
We propose preparing a normative specification for a subset of the Rust Language, that includes:
** A subset of the Language and its features
.......
In the next post, we’ll discuss more about the financial details and opportunities for partnerships in making Sealed Rust a possibility........

...we need to hear from companies that are interested in being a part of the Sealed Rust initiative! In particular, we are interested in hearing from parties such as:
** Companies interested in using Rust in safety critical domain and projects
.....

ferrous-systems.com/...​log/sealed-rust-the-plan

на расте просто не писалось ни одного серьёзного приложения

Так самый лучший код — не написанный код.
вроде серьезный человек, а таких азов не знаете.

«нуб», якому прийшлось відправляти глобальні дані в хіп, щоб мати можливість для асинхронного доступу з різних потоків:
dou.ua/...​rums/topic/30864/#1882741

А в случае C++?

есть lock-free подходы

А есть ли гарантия, что с использованием lock-free подхода ошибка исключена? Или ошибиться таки можно, но так лохануться может только джун?.

100% гарантию дает только страховой полис

я же утверждаю, что это, мягко говоря, неправда

вы врете
thenewstack.io/...​safe-systems-programming

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

Выбирайте кто вам больше подходит и спрашивайте у них. Кому надо тот ищет. :)

www.rust-lang.org/production/users

уже бегуууууу

ніхто тебе не убіждає, крім Бацьки

тому що тут набігло пару і почали тєму, що їх цепепешеку абидєлі, напісяли в їх няшну норку,
хоча я таку реакцію вже бачив і це було передбачувано,

До того в статі порівння з Go, так на мою думку Go ближче по духу до Rust, а не з С++, так що видихни разом з Владом та розслабся.

Є один цікавий клас помилок в С++, який роблять джуніори. Це взяти вказівник на елемент std::vector<>, а потім з цим вектором щось зробити. (Не знаю, чи є зараз лінтер, який це ловить).

Так от, Rust мав би від таких помилок оберігати.

кто мешает хранить вектор смартпоинтеров?

ну тогда они ССЗБ

Не, про то, что вектор ресайзится и при этом меняет память, в которой лежат элементы.

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

тоді Руст для тупих, бо не дозволяє вистрілити собі в ногу

Те кто юзают С и С++ знают зачем он им и для чего.

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

свідки сєкти нєасіляторов

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

на таке питання на співбесід інтерв«ювер тебе обично приймає за неадеквата,
напр., єсть специ які на позицію розробника під STM32 допитуються як працює в ядрі Лінукса динамічне виділення пам’яті, так щоб від зубів відскакувало, а ти «управлять підводною лодкою»

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

так не знаете же, применимы или нет.
чтобы делать экспертное утверждение — нужно знать.

Ну смотрите. Человек работает с датчиками для умного дома. Зачем ему Джава? Она по памяти не влезет — тут нужно экспертное утверждение?

работает с датчиками для умного дома. Зачем ему Джава? Она по памяти не влезет — тут нужно экспертное утверждение?

нужно экспертное утверждение, чтобы выбрать из
— Rust
— C / C++
— C--
— D (as better C)
— Nim
— Vala
— TinyGo
— Lua
— Squirrel
— Forth
— (список можно продолжить.)

я бы Foth выбрал, например.

Ада

..больше Ада!

Маза Фака

Заложите цену экспертного утверждения в бюджет и сроки проекта)
Либо напишите пилотник на каждом из этих языков и сравните)

напишите пилотник на каждом из этих языков и сравните)

зачем? «(Embedded C)/C++ Tech Lead» уже проестимировал, что java не подходит, поэтому годится только C/С++ :)

ну а если серьезно — то выбирать все равно будут из того, что знает команда.
Т.е. если присутствует только C/C++ экспертиза, то выбирать и не из чего.
Тут больше wiki.c2.com/?BlubParadox

Щас бесплатно запилю экспертное утверждние.
Vala — не прокатит ни для чего, язык сырой.
TiniGo — это непонятно что, на официальном сайте такого дистрибутива нет.
Lua — для встроенного скриптования. То есть должен присутствовать код на C/C++, куда эмбедится код виртуальной машины, или jit-компилятор.
Squirel — форк со старой версии Lua.
Forth — старое говно, код write-only. Хотя интерпретатор может похвастаться самыми маленькими размерами.

Lua з сішним хостом прекрасно ставиться на всякі мєлочі і там, де не треба страшний-страшний реал тайм, прекрасно себе чухає

Vala — не прокатит ни для чего, язык сырой.

Даже для GNOME не прокатит?)))

Lua — для встроенного скриптования. То есть должен присутствовать код на C/C++, куда эмбедится код виртуальной машины, или jit-компилятор.

luajit.org или github.com/moonjit/moonjit (форк)

TiniGo — это непонятно что, на официальном сайте такого дистрибутива нет.

tinygo.org

Щас бесплатно запилю экспертное утверждние.

«эксперт» — это тот, кто разбирается в предмете обсуждения

TiniGo — это непонятно что, на официальном сайте такого дистрибутива нет.

а вы, похоже, и гуглом пользоваться не умеете.

экспертиза уровня с++

эксперт

уже давно інфлювало,
як і сінйор

а вы, похоже, и гуглом пользоваться не умеете

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

Оскільки тема про Rust, то можна згадати Gluon — це щось подібне на Haskell.

Forth це більше як філософія... чи світогляд... щось середнє між грибами і буддизмом...

Forth це більше як філософія... чи світогляд... щось середнє між грибами і буддизмом...

А brainfuck тогда что? o_O

А brainfuck тогда что? o_O

Как что? Тяжеляк конечно...

Поки ми тут триндимо, китайці вже майже все зробили github.com/chengchangwu/rtforth

бізнес аналітік клієнта хоче убєдіцца, що дійсне не влізе, інашке ти балабол і лєнтяй

швидке написання невеликих програм та модулів для підтвердження концепції (PoC — proof of concept)

Як так вийшло? :)
Кодив на Rust деякий час, мова цікава і прогресивна, але здалась такою, що не підходить для прототипування.

здалась такою, що не підходить для прототипування.

в порівнянні із якою мовою?
для мене швидше чим на С/С++, хоча би тим, що не тре заморочуватися із залежностями, особливо при кроскомпіляції

В порівнянні з пітоно-матлабом.

Бо на С/С++ прототипи писати — ну не знаю, якщо чесно)

в Rusti ще поряд з швидким прототипуванням Пайтона/Го іде швидкодія на рівні С/С++.
Єдине, що крива навчання, не така полога, тому тре спочатку трохи «набити руку»

залежить від того, чи є готові бібліотеки, чи ні.

Numpy це чи не єдине, що виправдовує використання пітона, і дозволяє йому конкурувати з матлабом. Від фінтеха до робототехніки. Для прототипування.

Гугл забанили?? Я удивляюсь „писателям”, не „читателям”.

docs.rs/numpy/0.9.0/numpy

rust-numpy provides Rust interfaces for NumPy C APIs, especially for ndarray class.
It uses pyo3 for rust bindings to cpython, and uses ndarray for rust side matrix library....

Попытки сравнения.
www.reddit.com/...​python_numpy_performance

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

Go, как убивцу C и С++.

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

Ще раз, для чукчєй пісатєлєй, редакція ДОУ попросила статтю про Руст, от будь ласка.

Не подобається, напиши про Пайтон або Матлаб, як вони рвуть як Тузік грілку інші мови для ML

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

Так, наприклад, буде заважати необхідність обробки помилок, на які в прототипі хотілося б забити. Для прототипів — python, js, c#

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

.unwrap() в помощь

Дякую за статтю!

Щодо вакансій, їх дійсно небагато. Наприклад, ми в Cossack Labs працюємо з криптографією та захистом даних (не блокчейн), і використовуємо Раст (в майбутньому мріємо використовувати його ще більше замість C).

У нас зв’явилась вакансія на System-level developer, ми шукаємо розробників з знанням Расту.
www.cossacklabs.com/jobs/c-engineer.html

Знайшов приклади Rust-у у вашому відкритому проекті на GitHub-і: Themis

Якщо є ще проекти з Rust-ом то доповни будь-ласка

Привіт, дякую. Так, Themis це наша опенсорсна крипто бібліотека, що працює однаково та підтримує 14 мов, включаючи rust.

Нажаль, інші штуки, які ми робимо на rust, не є відкритими.

кращий пакетний менеджер (не тре окремо виконувати go get щоб отримати модуль)

В Golang вже гарний go mod який автоматично додає залежності які з’явилися в коді, тому про go get можна забути

Дякую, а з якої версії?
На raspberry був Golang v1.11, то там через go get.

Using Go Modules (19 March 2019):

Go 1.11 and 1.12 include preliminary support for modules
Starting in Go 1.13, module mode will be the default for all development

Я почав використовувати go mod з версії 1.13 для статей і подобається більше ніж dep (який теж використовував)

Дякую за статтю, ще й українською мовою

Можете ще подякувати редакції ДОУ, то їх ідея

Підписатись на коментарі