Rust 1.91.0

Этим славится только си. Современный C++ позволяет писать безопасный код, если ты не шиз вроде Столярова, который до сих пор пишет на си с классами.

Rust тоже позволяет. И в нем куда меньше UB. Зачем страдать с C++, если можно страдать с Rust, но меньше?

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

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

Только если в любых языках тебе надо осматривать на предмет порчи памяти вообще весь код, то в rust тебе надо смотреть только в unsafe части. Минусы-то где?

Код ревью проводится не для всей кодовый базы. А для отдельных MR. Тебе так и так код отсматривать.

Зачем страдать с C++, если можно страдать с Rust, но меньше?

Или больше :)

Код ревью проводится не для всей кодовый базы. А для отдельных MR. Тебе так и так код отсматривать.

И ты пропустил что нарушил инвариант, и это повлияло на код, который в MR вообще не светится. Ну мы сейчас серьезно будем обсуждать что code review не панацея, если инварианты живут только в голове у программиста?

Или больше :)

Или больше. А что получится покажет только практика.

вот что в защиту ржавого дерьма скажу:

fn f() -> *const u8 {

объявление функции в С++ это реально боль для парсера которая досталась от С. Как отличить объявление функции int x(int y) от int x(30); например? нетривиальная задача между прочим потому что можно ведь так написать:

struct somestruct {
};
int z = 5; 
int x(somestruct); //функция
int y(z); //переменная

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

fn const u8* f() {
}

Код на Си: pthread_mutex_lock, работа с данными, pthread_mutex_unlock.

Код на Rust: lock на Mutex возвращает ссылку на данные, иными способами недоступную (без unsafe и т п). Дроп ссылки освобождает Mutex.

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

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

fn i32 (i64, i64) get_function(i64) {}

Какой инвариант? Что нельзя доставать сырой указатель из smart_ptr? Так его достать можно только в новом коде и только в месте где есть этот самый smart_ptr.

Какой инвариант? Что нельзя доставать сырой указатель из smart_ptr? Так его достать можно только в новом коде и только в месте где есть этот самый smart_ptr.

Или достать можно в старом коде, а сломать в новом.

Доставать не нужно. Нужно везде таскать smart_ptr. Это очень просто.

Доставать не нужно. Нужно везде таскать smart_ptr. Это очень просто.

А человек выше говорит что нужно.

Погрози ему пальчиком.

Погрози ему пальчиком.

Один C++-программист – проект, два C++-программиста – проект с предаталем. В общем, пока вы там догориваетесь, как таскать надо, боров уже все проверил и выдал ошибку.

Ну да. Из плюсовиков не выписывают с проклятиями, если он что-то не то сказал или перепутал местоимение собеседника. Вам, из тоталитарных сект, это не понять )

Ну да. Из плюсовиков не выписывают с проклятиями, если он что-то не то сказал или перепутал местоимение собеседника. Вам, из тоталитарных сект, это не понять )

Нет, спасибо, этих срачей мне и соцсетях хватает. Тошно уже.

Ага, особенно когда указатель летит в Си-api :)

Ты кстати пробовал что-нибудь писать на rust’е с гуем? Я ради эксперимента попробовал. На gtk. Пока писал проклял все :)

Ты кстати пробовал что-нибудь писать на rust’е с гуем? Я ради эксперимента попробовал. На gtk. Пока писал проклял все :)

Я делал маленькие развлекательны программы на iced, мне, в целом, понравилось.

Ты кстати пробовал что-нибудь писать на rust’е с гуем? Я ради эксперимента попробовал. На gtk. Пока писал проклял все :)

А из прям готового софта, кажется Papers в гном уже на Rust. И их Matrix чат. Я мельком смотрел код, тоже неплохо.

Разница между управлением памятью в современных плюсах и в расте в том, что:

• в плюсах безопасное управление памятью (shared_ptr и т.д.) - «opt-in» фичи, т.е. можно пользоваться по желанию, но не обязательно, и осуществляется в рантайме;

• в расте это «opt-out», т.е. обязательно по умолчанию, но можно отключить по желанию, проверяется во время компиляции.

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

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

gtk - это да, так что лучше получается tauri + что то там (yew мне тут понравился, такой реакт), но приходится еще и html css и возможно ts/js знать

typedef же есть. А во вторых,

fn (fn* u8(..)) f() {
}

Например вот так. По идее как я делаю парсер там скобки вокруг указателя на функцию не нужны. Там после function может быть имя типа или сразу имя функции. Как в js. Но для красоты я явно запретил такую некрасоту

Писал аккуратно на С и продолжу, пожалуй. Никакой rust мозги не заменит.

В плюсах боров заменяется ПРОЕКТИРОВАНИЕМ и умными указателями. Всегда когда код течет это от того что кто то на с++ рукоблудит, не использует контейнеры и методы с проверкой индексов, и самое главное - не продумал устройства программы.

Vala удобнее. Тот же сэ но ска насколько же с ним проще

В плюсах боров заменяется ПРОЕКТИРОВАНИЕМ и умными указателями. Всегда когда код течет это от того что кто то на с++ рукоблудит, не использует контейнеры и методы с проверкой индексов, и самое главное - не продумал устройства программы.

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

Не запрещает а лишь частично ограничивает твою свободу ошибаться. Это эмулируется в c++ надстройкой над умными указателями. Тривиальной кстати.

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

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

Писал аккуратно на С и продолжу, пожалуй. Никакой rust мозги не заменит.

Переходи на ассемблер. Никакой C мозги не заменит.

Неправильные по его мнению.

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

А зачем язык вокруг этого городить?

страдать с C++

лучше не страдать же

страдать с Rust

Я слышал©, что борьба с borrow checker это секс на уровне Генту.

В rust есть egui так-то.

Вот вот. Как обойтись без ручного управления памятью все было сказано еще в трудах Саттера и Александреску еще в конце 90х начале 200х, но ниасиляторы никак не могут осилить, аж язык для этого специальный написали :)

Разница есть только на малом числе быстрых современных ядер.

/tmp ❯❯❯ rustc atomic.r -C target-cpu=native -C opt-level=2
/tmp ❯❯❯ gcc -O2 -march=native atomic.c -o atomic-c
/tmp ❯❯❯ taskset -c 31 hyperfine --warmup 20 --runs 50 ./atomic-c ./atomic
Benchmark 1: ./atomic-c
  Time (mean ± σ):      18.5 ms ±   0.0 ms    [User: 18.2 ms, System: 0.4 ms]
  Range (min … max):    18.5 ms …  18.6 ms    50 runs
 
Benchmark 2: ./atomic
  Time (mean ± σ):      18.7 ms ±   0.0 ms    [User: 18.3 ms, System: 0.5 ms]
  Range (min … max):    18.7 ms …  18.8 ms    50 runs
 
Summary
  ./atomic-c ran
    1.01 ± 0.00 times faster than ./atomic
/tmp ❯❯❯ taskset -c 28,29,30,31 hyperfine --warmup 20 --runs 100 ./atomic-c ./atomic
Benchmark 1: ./atomic-c
  Time (mean ± σ):      38.4 ms ±   3.1 ms    [User: 152.9 ms, System: 0.3 ms]
  Range (min … max):    32.5 ms …  42.4 ms    100 runs
 
Benchmark 2: ./atomic
  Time (mean ± σ):      38.5 ms ±   3.2 ms    [User: 152.5 ms, System: 0.6 ms]
  Range (min … max):    32.7 ms …  42.8 ms    100 runs
 
Summary
  ./atomic-c ran
    1.00 ± 0.12 times faster than ./atomic
/tmp ❯❯❯ taskset -c 2,3 hyperfine --warmup 20 --runs 100 ./atomic-c ./atomic
Benchmark 1: ./atomic-c
  Time (mean ± σ):      15.4 ms ±   0.3 ms    [User: 29.5 ms, System: 0.3 ms]
  Range (min … max):    14.9 ms …  16.1 ms    100 runs
 
Benchmark 2: ./atomic
  Time (mean ± σ):      18.8 ms ±   0.2 ms    [User: 36.1 ms, System: 0.4 ms]
  Range (min … max):    18.3 ms …  19.3 ms    100 runs
 
Summary
  ./atomic-c ran
    1.22 ± 0.03 times faster than ./atomic
/tmp ❯❯❯ taskset -c 2,3,4,5 hyperfine --warmup 20 --runs 100 ./atomic-c ./atomic
Benchmark 1: ./atomic-c
  Time (mean ± σ):      36.3 ms ±   5.8 ms    [User: 142.7 ms, System: 0.2 ms]
  Range (min … max):    27.9 ms …  47.9 ms    100 runs
 
Benchmark 2: ./atomic
  Time (mean ± σ):      39.0 ms ±   6.3 ms    [User: 152.3 ms, System: 0.3 ms]
  Range (min … max):    26.8 ms …  49.4 ms    100 runs
 
Summary
  ./atomic-c ran
    1.07 ± 0.25 times faster than ./atomic
/tmp ❯❯❯ taskset -c 2,3,4,5,6,7,8,9,10,11 hyperfine --warmup 20 --runs 100 ./atomic-c ./atomic
Benchmark 1: ./atomic-c
  Time (mean ± σ):      29.9 ms ±   3.2 ms    [User: 112.1 ms, System: 0.3 ms]
  Range (min … max):    24.8 ms …  35.7 ms    100 runs
 
Benchmark 2: ./atomic
  Time (mean ± σ):      31.2 ms ±   2.9 ms    [User: 118.4 ms, System: 0.3 ms]
  Range (min … max):    25.1 ms …  35.7 ms    100 runs
 
Summary
  ./atomic-c ran
    1.04 ± 0.15 times faster than ./atomic
/tmp ❯❯❯ cat atomic.r atomic.c 
use std::sync::atomic::{AtomicU32, Ordering};
use std::thread;

const N: usize = 4;
const ITERS: usize = 1000_000;

static COUNTER: AtomicU32 = AtomicU32::new(0);

fn main() {
    let mut handles = Vec::with_capacity(N);

    for _ in 0..N {
        handles.push(thread::spawn(move || {
            for _ in 0..ITERS {
                COUNTER.fetch_add(1, Ordering::Relaxed);
            }
        }));
    }

    for h in handles {
        h.join().unwrap();
    }

    println!("counter = {}", COUNTER.load(Ordering::Relaxed));
}
#include <pthread.h>
#include <stdio.h>
#include <stdatomic.h>

#define N 4
#define ITERS 1000000

atomic_int counter = 0;

void* worker(void* _) {
    for (int i = 0; i < ITERS; i++) {
                atomic_fetch_add(&counter, 1);
    }
    return NULL;
}

int main(void) {
    pthread_t t[N];
    for (int i = 0; i < N; i++) pthread_create(&t[i], NULL, worker, NULL);
    for (int i = 0; i < N; i++) pthread_join(t[i], NULL);
    printf("counter = %d (expected %d)\n", counter, N * ITERS);
    return 0;
}

Какая-то ложная дилемма. Вы либо «трахаетесь с памятью», либо у вас GC(костыли), либо костыли, либо костыли. А у нас костыли в языке, поэтому вы лохи, а мы политизируем разработку и поляризуем разработчиков.

Ох уж эти ваши новомодные навороты. Пробивал перфокарты и продолжу. Никакой си мозги не заменит.

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

Умные дядьки говорят, что даже smart_ptr не нужно.

Например тут строка это просто

struct String8
{
  U8 *str;
  U64 size;
};

Да, видел. И раньше всё было плохо, но каждый новый стандарт делает ещё хуже. Причём плохо не только с т.з. реализации или интерфейса, но и со сложностью, что очень важно. Теперь добавят рефлексию, и станет ещё хуже, по всем фронтам) Я ненавижу Си++, конечно, но очень люблю в некотором смысле, потому что там можно делать деньги — компании готовы платить тем, кто может хоть как-то в этом разобраться. :D

Так то egui хорош внешне и прост…на этом преимущества заканчиваются и всплывают подводные камни. У егуи покадровая прорисовка (immediate mode). В итоге обычный менеджер аддонов на раст занимает 6мб озу и 60% цпу. То же приложение на электрон метров 200 озу и 0% процессора.

Если ОЗУ у меня много, то засирать процессор я считаю недальновидным. Ну его нахрен. Проще прикрутить к расту Qt сбоку или писать гуи на чем то другом вообще.

Хотя изначально egui мне даже нравился…

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

Зачем страдать с C++, если можно страдать с Rust

Обратное верно, да. :)

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

Это было жестоко!.. ;P ;)) :)))

Я запустил amdgpu_top, но данной проблемы не вижу. При интерактивной отрисовке нагрузка 0.6 - 3.0%.

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

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

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

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

Каждый update() - полный пересчёт UI - CPU-нагрузка.

У Qt событийная модель (retained mode) - гораздо проще сделать модуль с логикой на раст и подклчить куда надо к Qt интерфейсу, чем возиться с egui. Или к тому же электрону. Да куда угодно проще, чем возня с egui в итоге.

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

Tauri это опять гытыка.

Вот чем мне нравится электрон - гибкостью рисовки интерфейсов. Это же тупо браузер, а там можешь рисовать что хочешь с любыми анимациями как тебе надо. Объектов накидал, стили определил как надо - все. Любые изменения - вот тебе файлик стилей.

А вот гтк, Qt, egui и прочие прочие дают всетаки некоторые ограничения.