Rust 1.91.0

Что значит не популярный? Честное 10-е место. Там ему и место пока что.

Точно, на целый пукт опережает АДУ! Которая рвется вверх.

P.S. Думаю нужно бы еще в инете пошарить, вдруг он в каком то рейтинге аж на 9 месте будет !

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

Ариан-5 не взлетела потому что код для нее перетянули с Ариан-4 без учета специфики.

Думаю нужно бы еще в инете пошарить, вдруг он в каком то рейтинге аж на 9 месте будет !

Год назад раст был на 15-м месте. Даже так, назвать его непопулярным это сильно. Тогда куча любимых в энтерпрайзе языков тоже непопулярны, typescript, kotlin, lua и т.д.

Ну, например, я пишу однопоток, на утечки память насрать, потому что это десктопная утилита командной строки, и всё что явно течёт я уже валгриндом увидел и поправил. Зато у меня прямая линковка (ну почти) с сишным кодом. Это я про C++.

typescript, kotlin, lua и т.д.

Да но на них не переписывают существующий софт и не вопят про это на каждом углу.

Да но на них не переписывают существующий софт и не вопят про это на каждом углу.

Да ладно. И переписывают, и вопят. И какое это имеет отношение к популярности?

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

И какое это имеет отношение к популярности?

Я про это и пишу, не я же тыкаю в котлин.

Это те самые знаменитые растовские понятные сообщения об ошибках, которые сами подсказывают тебе как исправить код?

У него просто пример неудачный. std::thread::spawn требует чтобы замыкание было с временем жизни 'static.

pub fn spawn<F, T>(f: F) -> JoinHandle<T>
where
    F: FnOnce() -> T + Send + 'static,
    T: Send + 'static,

О чём компилятор явно и говорит:

argument requires that `counter` is borrowed for `'static`

Если взять std::thread::scope, который не требует 'static, то ошибка будет более наглядной.

use std::thread;

const N: usize = 4;

fn main() {
    let mut counter = 0;
    thread::scope(|s| {
        for _ in 0..N {
            s.spawn(|| counter += 1);
        }
    });
}

error[E0499]: cannot borrow `counter` as mutable more than once at a time
 --> src/main.rs:9:21
  |
7 |     thread::scope(|s| {
  |                    - has type `&'1 Scope<'1, '_>`
8 |         for _ in 0..N {
9 |             s.spawn(|| counter += 1);
  |             --------^^--------------
  |             |       |  |
  |             |       |  borrows occur due to use of `counter` in closure
  |             |       `counter` was mutably borrowed here in the previous iteration of the loop
  |             argument requires that `counter` is borrowed for `'1`

Если пользователь попробует использовать Cell или RefCell чтобы попытаться это обойти:

use std::{cell::Cell, thread};

const N: usize = 4;

fn main() {
    let counter = Cell::new(0);
    thread::scope(|s| {
        for _ in 0..N {
            s.spawn(|| counter.update(|i| i + 1));
        }
    });
}

То компилятор подскажет использовать атомики или блокирующие примитивы:

error[E0277]: `Cell<i32>` cannot be shared between threads safely
   --> src/main.rs:9:21
    |
  9 |             s.spawn(|| counter.update(|i| i + 1));
    |               ----- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `Cell<i32>` cannot be shared between threads safely
    |               |
    |               required by a bound introduced by this call
    |
    = help: the trait `Sync` is not implemented for `Cell<i32>`
    = note: if you want to do aliasing and mutation between multiple threads, use `std::sync::RwLock` or `std::sync::atomic::AtomicI32` instead
    = note: required for `&Cell<i32>` to implement `Send`

Видимо он ещё только изучает Rust и под впечатлением. Я бы не прислушивался к его мнению. :)

Это те самые знаменитые растовские понятные сообщения об ошибках, которые сами подсказывают тебе как исправить код?

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

Была философия «код работает корректно, пока не доказано обратное». Даже того, что сейчас считается стандартной практикой (тестирование на граничные значения переменных), не проводилось.

Наоборот, теперь фанатики что нибудь ещё поломают

Любопытно почитать критику классиков (Вирт, Дийкстра, Хоар) языка Ада. Что-то есть в русскоязычной Википедии. И действительно, язык оказался достаточно сложный, чтобы разрабы НАСА облажались с ним. Но, впрочем, такая же критика у них была бы в отношение Раста, мол столько всяких механизмов, что будет много багов в компиляторе.

А что учитывается в этих рейтингах? Подозреваю, что от части количество проектов на Расте? А ято если в это количество входят все эти сириады растопакетов, на каждый чих, как у Питона? Есть где-то статистика по проектам использующим Раст для конечного продукта, а не для написания растосодуля для растомодуля?

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

https://fil-c.org
https://github.com/pizlonator/fil-c:

Fil-C: completely compatible memory safety for C and C++

Fil-C is a fanatically compatible memory-safe implementation of C and C++. Lots of software compiles and runs with Fil-C with zero or minimal changes. All memory safety errors are caught as Fil-C panics. Fil-C achieves this using a combination of concurrent garbage collection and invisible capabilities (each pointer in memory has a corresponding capability, not visible to the C address space). Every fundamental C operation (as seen in LLVM IR) is checked against the capability. Fil-C has no unsafe statement and only limited FFI to unsafe code.

Fil-C is special because:

• Fil-C achieves full safety with no escape hatches. There is no unsafe keyword in Fil-C that could be used to turn off protections. Linking to unsafe code is severely restricted.
• Fil-C’s capability-based approach achieves a similar level of safety to hardware capabilities like CHERI, except that it runs on stock hardware (X86_64, currently).
• Fil-C is engineered to prevent memory safety bugs from being used for exploitation rather than just simply flagging them often enough to find bugs. This makes Fil-C different from AddressSanitizer, HWAsan, or MTE, which can all be bypassed by attackers. The key difference that makes this possible is that Fil-C is capability based (so each pointer knows what range of memory it may access, and how it may access it) rather than tag based (where pointer accesses are allowed if they hit valid memory).
• From a language user standpoint, Fil-C is just C and C++ with GCC/clang extensions. It’s more likely than not that your favorite C or C++ program or library compiles in Fil-C with zero changes. The Fil-C compiler is based on clang 20.1.8, so it supports C17 and C++20.

А что учитывается в этих рейтингах?

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

Fil-C achieves this using a combination of concurrent garbage collection

Да никто в здравом уме не будет использовать велосипед, в котором непонятно, какого качества эти GC и проч. И что толку с этих паник? Это всего лишь упростит в какой-то степени отладку.

Да никто в здравом уме не будет использовать велосипед

Кто-нибудь из них будет:

1.7k stars

Думаю, что скачивают на посмотреть, протыкать палкой и выкинуть.

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

Осилили. Можешь взять тут.

Предлагаю немного абстрагироваться от ЯП и прочитать еще раз

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

Под A и B можно попробовать поставить разные языки. Во-первых, в каждом ЯП есть свои идеоматичные подходы, которые где-то пересекаются, а где-то расходятся. Во-вторых, а вам точно нужно воспроизводить неправильное поведение сишной программы? Просто если надо добиться правильного решения, то и в C и в Rust появятся примитивы синхронизации.

А кидаться субстанциями, с криками: «У вас не так как в С(++)!!!1!» – гораздо лучше, да?

Тут аксиома Эскобара, где с одной стороны сишники и плюсовики, а с другой стороны РАСТовчане – оба «хороши» в чем то своем.

Не смог взять. Говорит, сишный компилятор нужен. :(

error: linker `cc` not found
  |
  = note: No such file or directory (os error 2)

Не сишный компилятор, а линкер.

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

Я доустановил то, что ему хотелось и дальше он таки скачал llvm и начал что-то там компилять.

-- Build files have been written to: /root/rust/build/x86_64-unknown-linux-gnu/llvm/build
running: cd "/root/rust/build/x86_64-unknown-linux-gnu/llvm/build" && DESTDIR="" LC_ALL="C" "cmake" "--build" "/root/rust/build/x86_64-unknown-linux-gnu/llvm/build" "--target" "install" "--config" "Release" "--" "-j" "16"

Я думаю для рейтинга взлетающих языков это важно. В смысле, для понимания истинного положения дел. Вот взять буст какойнить - там куча всего. Один проект. И возьмём питонолибу-однострочник, как они любят это делать. С точки зрения статистики они равнозначны. Понимаешь о чём я? Стопиццот либочек питона делают меньше, чем один буст, но на статистику очень хорошо влияют. Но на Питоне и реальных проектов выше крыши. Также и с растом, только реальных проектов на нём ПОКА не так много. Я бы скептически смотрел на статистику.

У вас debug для ржавого включен. И у меня на атомиках ржавой быстрее на 20%:

use std::sync::{
    Arc,
    atomic::{AtomicUsize, Ordering},
};
use std::thread;

fn main() {
    let counter = Arc::new(AtomicUsize::new(0));
    let mut handles = Vec::new();

    for _ in 0..4 {
        let c = Arc::clone(&counter);
        handles.push(thread::spawn(move || {
            for _ in 0..1_000_000 {
                c.fetch_add(1, Ordering::Relaxed);
            }
        }));
    }

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

    println!("counter = {}", counter.load(Ordering::Relaxed));
}

[profile.release]
opt-level = "z"
lto = true
codegen-units = 1
panic = "abort"


[package]
name = "atomics-rust"
version = "0.1.0"
edition = "2021"

[dependencies]

40 ms против 50 ms.

А ещё размер таким образом нечестно сравнивать. У него свой std.

намерено получится поведение как в примере на сях

Тогда тебе придётся воспользоваться unsafe

Прочитал https://fil-c.org/invisicaps_by_example

Первые несколько десятков примеров - супер.

А потом столкнулся с местом, где они кажется очень сильно перебдели, вроде хранить уазатель в uintptr_t «хоть вечно» вполне нормальная практика:

But this only works if the cast from int-to-ptr and ptr-to-int casts are local to one another and the compiler can unambiguously pick the original pointer’s capability. For example, this doesn’t work:

#include <stdio.h>
#include <inttypes.h>

uintptr_t x;

int main()
{
    const char* str = "hello";
    x = (uintptr_t)str;
    asm volatile("" : : : "memory");
    printf("%s\n", (const char*)x);
    return 0;
}

Here, we’ve made sure that the compiler cannot see the int-to-ptr cast as having any relationship to the ptr-to-int cast, since x is a global variable (so anyone could muck with it) and we have prevented any kind of load elimination (thanks to the compiler fence). So, this gets:

filc safety error: cannot read pointer with null object.
    pointer: 0x60ac4d7f1cf0,<null>
    expected 1 bytes.
semantic origin:
    src/string/strlen.c:8:9: strlen
check scheduled at:
    src/string/strlen.c:8:9: strlen
    src/stdio/fputs.c:6:13: fputs
    src/stdio/puts.c:7:8: puts
    test28.c:11:5: main
    src/env/__libc_start_main.c:79:7: __libc_start_main
    <runtime>: start_program
[722598] filc panic: thwarted a futile attempt to violate memory safety.
Trace/breakpoint trap (core dumped)

это просто инерция бизнеса

А, вон оно чО!.. ;D;P ;))

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

И у меня на атомиках ржавой быстрее на 20%

Разные атомики, в atomic_fetch_add по умолчанию полный барьер.

Не в этом дело, у него толстое приложения из-за debug сборки получилось, плюс сишка жестко залинкована на glibc, а ржавой использует только необходимые для linux функции из неё, поэтому времени на запуск тратит больше. Честно сравнивать это static vs static.

За реакцию «нинужно» отдельное спасибо! Буквы тратить не надо.

Возможно, но разница измеряемая:

$ hyperfine --warmup 20 --runs 50 /tmp/relaxed /tmp/seqcst
Benchmark 1: /tmp/relaxed
  Time (mean ± σ):     118.1 ms ±  13.6 ms    [User: 430.7 ms, System: 2.1 ms]
  Range (min … max):    96.2 ms … 137.5 ms    50 runs
 
Benchmark 2: /tmp/seqcst
  Time (mean ± σ):     123.6 ms ±  10.5 ms    [User: 452.4 ms, System: 2.5 ms]
  Range (min … max):    97.3 ms … 141.9 ms    50 runs
 
Summary
  /tmp/relaxed ran
    1.05 ± 0.15 times faster than /tmp/seqcst

Хотя и в пределах погрещности конечно. Но оно в принципе все такое. Надо сишную версию с musl слинковать и сравнить.

Не понял, а чего срч такой вялый? Даже в этом лор деградировал…

Дык стремно об униженного и оскорбленно Раста еще и ноги вытирать, пусть хоть на скриптиках он существует, аля баш)))))))

Сборка чужого кода из под рута? Да ты экстремал! Может, ты ещё любишь curl https://totaly-not-malwa.re/install | bash делать?

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

А разве rust при переполнении не кинет panic, навернув всю систему? В alvr при конвертации float в int именно так было в какой-то версии, какой-то несчастный невлезший в диапозон float ронял весь процесс

есть огромный минус подсчёта ссылок: каждое обращение к объекту - потенциальный бранч в деструктор. Если деструктор сложный - будет забивать кэш ненужным мусором.
GC существует не просто так
А ещё бывают циклические ссылки...

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

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

«Как трудно жить!»... © :))))

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

Все языки с пакетными менеджерами превращаются в неконтроллируемую блоатварь.
npm, cargo, pip - везде одна и та же проблема.
У питона вообще в стандартой библиотеке столько всего, что он просто не имеет права иметь пакетный менеджер

ведь раньше без rust как-то жили

Да я и сейчас живу... :))

Вот пообщался тут, почитал тут и «там», и решил, что для своих МК таки C выберу, а не новомодные Rust и Zig...

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

бегут из разработки, рассказывая как боров крутил им руки

https://youtu.be/lUFtrZ2xd_8

Вам кто-то запрещает использовать makefile + rustc?

Как минимум, все существуюие проекты кроме разве что ядерного кода используют cargo. Впрочем, никто не запрещает использовать cargo, но зависимости им не тянуть, только вот так тоже не делают.
А вообще, у rustc стабильный командный интерфейс?