Прийшов час осідлати справжнього Буцефала🏇🏻Приборкай норовливого коня разом з Newxel🏇🏻Умови на сайті
×Закрыть

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

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

Более интересные новости по теме статьи.

Компания 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%

Во. Пора линуху возвращаться к своим положенным 1-3%.
Но есть надежда, что большие и толстые конторы, что на серверах линух крутят по башке за лишние фантазии с драйверами Линусу настучат.

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

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

?

???
Да не, можешь быть уверен, что их там мало.

Ну обычно около 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?

Vlad Stelmahovsky Software Engineer
час назад

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

Цитата о чем тебе нужна? И от кого тебе нужна цитата?

Тупишь???

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

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

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

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

то будет явная проверка на выход за пределы буфера в рантайме

Это и есть тормоза.

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

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

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

судя по

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

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

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

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

Ладно убедили. Можно мне OpenCV на расте, без привычной ей проблемности с памятью, некоторой падучестью, дурных зависимостей от 100500 других либ на С и С++ и т.п.?
Там. кстати, даже С не осилили, она исключительно на С++.

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

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

Я OpenCV просил.

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

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

смешно

Зачем? Я всего-лишь попросил то, что сейчас используется всеми в этой области.

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

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

Можно мне OpenCV на расте, без привычной ей проблемности с памятью, некоторой падучестью, дурных зависимостей от 100500 других либ на С и С++ и т.п.?
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 лет это раст?

так уже прожив 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++).

dou.ua/...​ign=reply-comment#1882402
Вот сишников и приплюснутых сюда не приплетай. Ниже уже написали, что Раст не для них, а для других.

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

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

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

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

А в С тоді що?

в С тупі неосілятори високих матерій, хто умний той на 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 — из мира 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 фреймвороков, которые в отрыве от соответствующего языка никак не применимы.

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

Тут уже раз 20 написали, что он не безопасный и сложный, а Раст безопасный и простой.

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

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

я вижу. вот например:
— 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

Юзай community и ничего не плати.
Но как IDE Clion мне сильно не понравился.

зажрались прогери, ти що не знав?

платні, нє?

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

Windows only, нє?

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

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

платні, нє?

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

Windows only, нє?

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

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

Вот это самое важное. Каким бы правильным и хорошим не был раст, но вакансий нет на нем.
Каким бы кривым не был жабаскрипт, но вакансий на нем полно.
Был и есть такой язык D, получше С и С++, но вакансий на нем нет.

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

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

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

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

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

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 потім вирішив бути «умним і красівим», і втратив фокус

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

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

Он делался грамотными людьми с одной целью, убрать часть траблов С и С++ и не потерять возможностей этих языков. Ну и можешь почитать про его историю создания и развития.
А вот почему не пошел я не знаю, я не настолько понимаю все рекламные и маркетинговые фишки.
По мне основная причина, что его никто не раскручивал.
А язык программирования 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/oc8acc$1ei9$1@digitalmars.com

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

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, так что мы автоматом получаем, что некоторая область памяти не может быть изменена одновременно в двух потоках. И если мы что-то читаем, то мы уверены, что в это время никто другой не модифицирует.

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

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

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

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

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

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

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

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

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

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

Все эти проверки выполняются на этапе компиляции, поэтому накладные расходы во время выполнения равны нулю.

Причем тут это?
Читать из блока1 и писать в блок2 и параллельно читать из блока2 и писать в блок 3 возможно?
А читать из блока2 и писать в блок1?

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

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

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

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

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

Не говоря о том, что можно просто писать unsafe.

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

и я не думаю, что имеет смысл вот так наезжать на него не ознакомившись с ним

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

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

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

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

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++ — это операционная система.

Ніби це щось погане :)

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

address sanitizers

race conditins

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

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

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

address sanitizers

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

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

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

А ржал с одних кадров, которые 3 месяца пытались оптимизировать код на Питоне, который тормозил только по тому, что они много раз картинки по памяти туда сюда двигали.
А математику юзали, написанную в Америке грамотными программистами на С++ и CUDA ©. И она работала очень быстро.

С 10 рассказа им, где у них проблема, они таки решили это место посмотреть и начали фиксить.

А типичные проблемы у меня. Вот, например, есть openvino, отлично работает, но использует внутри MKL и еще пачку интеловских либ и тянет их с собой.
Есть матлаб — он тоже использует пачку тех же интеловских либ, но других версий и тянет их с собой.

Пытаюсь дернуть openvino из матлаба — логично падает на конфликте подгрузки динамических либ. Вот сейчас пишу простенький серверок, что с матлабом через шаред мемори общается. Мессаги шлю по сокету (с семафором не понравилось). Более простого способа я не придумал. На С++ достаточно быстро получается такое. На Раст подобное могу я быстро написать?
И ровна та же проблема с CUDA. Матлаб сам юзает CUDA. а движок нейронки сам и они в одном процессе конкретно конфликтуют.

“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...

Посыпаю голову пеплом! %)

Стареть начинаешь. Склероз. Но не пугайся, я тоже про WinMain забыл.

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, так на мою думку Go ближче по духу до Rust, а не з С++, так що видихни разом з Владом та розслабся.

Є один цікавий клас помилок в С++, який роблять джуніори. Це взяти вказівник на елемент std::vector<>, а потім з цим вектором щось зробити. (Не знаю, чи є зараз лінтер, який це ловить).

Так от, Rust мав би від таких помилок оберігати.

кто мешает хранить вектор смартпоинтеров?

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

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

Не, про то, что вектор ресайзится и при этом меняет память, в которой лежат элементы.

Да пофиг. Подобным и лопату в руки давать страшно — ноги себе поотрубают.

Главным образом тот факт, что Абрам берет указатель/итератор, то ты не думает, что вектор может где-то ресайщится. А когда Борис потом пошит терминальный элемент в конец массива, то не думает, что кто-то там брал указатель/итератор. Ну а массив смартпойнтеров всё-таки оверхед.

Ну блин, а еще можно free (фигня какая-то, не NULL). А еще можно запросто расстреливать память приложения в свое удовольствие.
Тут либо для таких всё нужно обвешивать красными флажками и делать менеджед язык, но тогда лучше взять C# и не дурить никому мозги своей неграмотностью.
Если у вас настолько безграмотные работают, то им в руки серьезные инструменты давать нельзя. Вот лопата — копай отсюда и до обеда. Хотя и лопатой некоторые умудряются себе ноги отрубать.

тоді Руст для тупих, бо не дозволяє вистрілити собі в ногу

Да ладно. Есть те, кто и лбы о пол в церкви себе разбивают.

Те кто юзают С и С++ знают зачем он им и для чего.

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

свідки сєкти нєасіляторов

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

на таке питання на співбесід інтерв«ювер тебе обично приймає за неадеквата,
напр., єсть специ які на позицію розробника під 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 ще поряд з швидким прототипуванням Пайтона/Го іде швидкодія на рівні С/С++.
Єдине, що крива навчання, не така полога, тому тре спочатку трохи «набити руку»

Доказательства приводи. Вот тебе задачка типичная для прототипирования: в магазине над кассами стоят камеры, нужно считать количество людей проходящих под ними (не считать одного дважды и не пропускать). Такая фигня прототипируется на питоне или матлабе потому, что легко быстро набрасывать разные алгоритмы и дергать разные либы, нейронки с математикой.
Дальше уже, когда прототип начал удовлетворять требованиям при необходимости портируетсяна С или С++ или не портируется.
За сколько времени ты подобный прототип напишешь на Расте?
На питоне, матлабе такой прототип пишется за 3 месяца максимум. Первый его вариант пишется за 2-3 недели.

Более того ты сам кривенький такой прототип слабаешь на питоне, просто слепив пачку туториалов и примеров из инета за 2-3 недели (причем толком не разбираясь в ML).

залежить від того, чи є готові бібліотеки, чи ні.

На С с биндингами для питона их море. Я же тебе написал, ты сам на питоне, не зная ML, такой прототип за 2-3 недели напишешь. Они почти готовые стадами в инете валяются, тебе только примеры и туториалы в кучку собрать на питоне нужно будет.
Более того многие раскрученые движки нейронок толком не имеют даже С интерфейса (он есть, но без какой-либо доки к нему) — но есть интерфейсы к питону.
Numpy предоставляет тензорную математику. Тебе даже не нужно разбираться, как там тензоры перемножаются, просто пишешь A*B.

Numpy це чи не єдине, що виправдовує використання пітона, і дозволяє йому конкурувати з матлабом. Від фінтеха до робототехніки. Для прототипування.

Ну вот я надеялся, что flyman сейчас покажет, как раст рвет питон или матлаб в протоколировании, например.
Про С или С++ для прода и не говорю даже, расту до С или С++ еще грести и грести, если мозила раньше на него не забьет.
Помню, как тут рекламировали Go, как убивцу C и С++. Но что-то последний год совсем затихли.

Гугл забанили?? Я удивляюсь „писателям”, не „читателям”.

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 ,
це як порівнювати юх з пальцем.

Вообще говоря может, но в ограниченом наборе задач.
Это же делается заменой аллокатора на С++ на свой, написанный под твою конкретную задачу.
Причем можешь это делать заменой new или аллокаторами для stl.

Ще раз, для чукчєй пісатєлєй, редакція ДОУ попросила статтю про Руст, от будь ласка.

Не подобається, напиши про Пайтон або Матлаб, як вони рвуть як Тузік грілку інші мови для ML

Зачем мне это надо? Я просто пытался выяснить чем же Раст лучше С или С++. Или питона с матлабом.

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

відповідно три гіт субмодулі

Ну так это нынче везде.
И в питоне такое-же и Расте и в Go, про жабаскрипт и не говорю.
Все давно забили на нормальное версионирование и обратную совместимость.
Юзай либы из репозиториев линуховых и все отлично всегда собирается. Там пока обратную совместимость поддерживают.

Так, наприклад, буде заважати необхідність обробки помилок, на які в прототипі хотілося б забити. Для прототипів — 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 (який теж використовував)