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

👍НравитсяПонравилось0
В избранноеВ избранном5
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

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

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

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

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

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

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

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

Гы-гы-гы. Ты, надеюсь, его удовлетворил в поглощении его денег?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

First appeared: July 7, 2010; 10 years ago

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зачем?

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

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

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

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

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

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

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

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

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

wink, wink

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

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

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

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

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

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

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

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

Угу. The same.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

на питони жы ж

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Бинго

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

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

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

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

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

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

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

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

C# та .NET

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

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

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

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

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

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

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

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

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

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

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

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

аргумент 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

багато С++

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

How is Rust faster than C++?

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

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

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

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

gcc -flto

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

І знову про Rust

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

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

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

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

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

да, он такой

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

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

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

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

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

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

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

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

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

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

Не надоело еще?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пока выглядит интересно. Но взлетит-ли? За ним не стоит монстров, которые его продвигать будут.

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

И вот те, кто разобрался с питоном в 90-х и даже 2000- пролетели. А востребован он стал в 2010х.

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

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

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

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

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

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

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

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

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

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

Может познакомиться, выйти замуж за перспективного... Ну как когда-то в совке за военного, красивого и здоровенного.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

у цпп-макак

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

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

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

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

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

А що в нас є пісатєлі ОС?

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

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

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

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

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

Труъ стори:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

а где надо?

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

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

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

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

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

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

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

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

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

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

4. Понял, что мне сейчас прийдется запилить двойной связаный список на Rust

Learning Rust by writing a linked list is like learning Python by writing a CPython extension...nobody actually writes linked lists in Rust

news.ycombinator.com/item?id=22390662

Влада приховує, але насправді індекс можна використовувати як вказівник. У тій його lib.rs так і роблять.

То, что запилено по ссылке — малая часть нужного функционала (нет O(1) операций). Да, можно пилить LinkedList с индексами, если хочется, чтоб было медленно, но будет куча плясок с бубном. Я не уверен, что, например, Rc + Cell будет чем-то хуже.

Таке на паскалі писалося на олімпіадах

Easy to write expressive code.

бгг

Чому на Go написали купу всього корисного, а на Rust поки не бачив?

Частину б краще не писали ні на чому — сивіти менше треба було б

— Вот когда AWS перейдет на Rust, тогда и поговорим
— Ок, давай поговорим

по Rust уже пропонують 6КУЕ з 1-2 роки досвіду

Думаю, мало в кого більше досвіду з Растом.
Оно в Лінкедіні шукають 3 роки досвіду з клабхаусом.

мало в кого більше досвіду

хіба? он ФФ переписують 10й рік

І скільки цих переписувачів в Україні?

так тобі тут і признаються

та вже скажи, чо уж там...

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

Так давай забацаєм МЛМ.
Я тебе зарефералю, а ти мене, потім.
Може ще і Дениса.
Але руст тре вивчити вперед.

Я ж написал: «деньги вперед».

Таки перечитай золотое теля. Там про это есть.

Руст -> Крипта -> Цифрове золото

Пилітє гірі (учітє руст), Шура (Вітя).

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

Без досвіду на 2-3 інших мовах на навантажених проектах?

x to doubt

порівняй з С++ при рівних інших умовах

Тобто умовний
Senior Highload
C++ vs Rust
?

при всіх інших рівних умовах (надіюсь, ти розумієш значення даної фрази)

Давайте ви повністю напишете, умови під цифру, що ви вказали, що б не грати в гру — вгадай вакансію по цифрі?

Зроби профілі з Rust на Лінкедін та Джині і взнаєш

Неочікуване закінчення треду про

по Rust уже пропонують 6КУЕ з 1-2 роки досвіду

вибач, я не хайрю і не хідхантю

C++ вже 10К djinni.co/...​6-media-server-developer
Але хочуть кодеки та стрімінг. Як раз для дяді Віті.

там якись стартап, думаю затрахають так, що потім погодишся і за 3К в бодішопі тупо таски в джирі пересувати

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

котиков стримить?

Рекламу

Так вже є рішення для і для реклами, і для вбудови її в відеопотік
І якщо логічно підійти, то це не основний функціонал продукту, тому його можна аутсорснути

котики будуть ловити мишей (кіберзагрози)

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

Что-то чем дальше, тем хуже работает Файрфокс.
В прошлом году он временами не подгружал вкладки, если на старте несколько штук быстро пощелкать.
В последний месяц меню по правой кнопке часто открывается в левом месте экрана.
Сейчас еще и всю оперативу выжирает на ноуте за несколько дней работы. И на официальном сайте рекомендуют перезапускать))) Firefox may use more system resources if it’s left open for long periods of time. A workaround for this is to periodically restart Firefox.
support.mozilla.org/...​h-memory-or-cpu-resources

В результате флагманский проект Раста течет по памяти, и глючит.

Нужно было писать на Go

На докер посмотри. Под виндой особенно проблемы аналогичные. Очевидно что это закономерность — как эффективно писать код на C++ многие уже хорошо знают. Есть куча книг от Александреску, Маерса, Саттера и т.д. Типичные проблемы D, Go, Rust анти паттерны и бест практики ещё предстоит выявить. Хотя ИМХО FireFox стал в разы лучше после создания нового движка, но это связанно не с языком программирования — а с тем что его написали заново и выкинули все деприкейшены. Gecko написанный на C++ представлял из себя свалку кода миллиардом макросов. Вот где текла память по настоящему, особенно через плагин API.

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

С++ по книгам Александреску

це як збірник псалмів віруючих в хрести

В результате флагманский проект Раста течет по памяти

doc.rust-lang.org/...​con/what-unsafe-does.html

Rust is otherwise quite permissive with respect to other dubious operations. Rust considers it „safe” to:
...
* Leak memory

Ну ты же литкод решал даже в ресторанных туалетах на свиданиях, должен знать что есть memory leak, а есть orphaned memory, которые не лики, но и не освобождаются. Таков дизайн! ©

FF ще й не вміє Skype в браузері робити. В Edge, Chrome, IE web.skype.com працює, а от в FF ні.

Не думаю — у файрфоксі й інші відеоконференції погано працюють — затримка, розсинхронізація відео та аудіо.

Що мене наводить на думку, що жс і брузер не те місце, де треба робити такі речі

Але я мабуть занадто старий, бо пам’ятаю, коли скайп був нормальним софтом і міг працювати на 5кбпс

Браузер — то не жс, а С++. Відео має йти напряму в нативні плагіни.

має

*повинно
Але інколи не виходить

Зробили собі проблему на рівному місці, бо в руках є крива стамеска, а зробити треба осцилоскоп

жс не може обробляти відео, бо він:
1) інтерпретується
2) не є реал-тайм
3) має збирач сміття
Тому будь-яке відео, що Ви бачите, іде з нативного коду.

жс не може обробляти відео, бо

www.google.com/...​ editing on js in browser
Unfortunately it can

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

А можна в сорцах десь побачити цю обробку відео?
Бо люди часто кажуть те, що не розуміють.

Це той випадок

Я мав на увазі WASM

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

Ще бракувало загадати TASM...

Давно так не смеялся))

FASM ахуєнний

Ніколи на ньому не писав, але так, згадав, що коли він з’явився то про нього схвально відгукувалися. Але це було вже значно після MASM/TASM/WASM.

Я про нього з книжок/статей Кріса Касперські дізнався. Ну і ще демосценери багато про нього писали (хтось пам’ятає hugi.de?). В старі добрі часи він мені чомусь набагато більше за MASM зайшов.

цитата из readme:

Android’s H.264 decoder compiled with Emscripten to JavaScript, then further optimized with Google’s JavaScript closure compiler and further optimized by hand to use WebGL

Как я понимаю, то, на что вы дали ссылку — это исходники Android’s H.264 decoder.

mbebenita.github.io/Broadway/foxDemo.html

Достаём кишки из

mbebenita.github.io/Broadway/mp4.js

      /* Decode Pictures */
      var pic = 0;
      setTimeout(function foo() {
        var avc = this.avc;
        video.getSampleNALUnits(pic).forEach(function (nal) {
          avc.decode(nal);
        });
        pic ++;
        if (pic < 3000) {
          setTimeout(foo.bind(this), 1);
        };

avc.decode(nal); — точка интереса.

это они на первых 3000 фреймах рекурсией разгоняются? а потом — вжуххх

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

Трошки раніше

Я помітив, що щось не так, коли замість оновлення старого додатку на делфях і з вбудованими asm оптимізаціями, вони викатили на win нову широку фігню з рекламою
І тоді ж почались проблеми з апі на старому клієнті

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

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

Лично я пока на фурефоксе продолжу. Хром сколько не пробовал — сносил нафиг. Но ты пробуй, может понравится.

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

А у нас местная инфраструктура сделала всё, чтобы задавить файрфокс, хорошая треть сайтов только делают вид, что работают на файрфоксе. То клиент банка пишут, что трудности с логином под файрфоксом, мы решаем проблему ... уже 3 месяца (они решили, но все уже ушли с FF), то сервис электронной доставки документов под файрфоксом просто перестаёт работать, и т.д. Например, онлайн телевидение — только хром, немного FF — только половина функциональности доступна, и вообще без edge.

Насмешил. В РБ софт от налоговой как-то научился на win10 работать (причем для установки требует шаманства даже в биосе). До это хотел только win7 и ie. А года 3 назад хотел winXP и ie6.
Банки чуть посовременнее. Они уже год как умеют и под фурифоксом и под хромом свои странички, но только под виндой.

Достатньо 2 дні поперемикатись між лінкедіном, двома поштами, слаком та доу, час від часу схлопуючи ноут в сон, щоб працювать стало дууже важко.

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

В результате флагманский проект Раста течет по памяти, и глючит.

А чому вм його не назвали флагманським проектом плюсів. чи жс, чи XUL?

Не знаю, не сидел на нем так долго. Но там С++, и он течь не должен. А у Файрфокса половина на расте, поэтому течет.

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

У меня браузеры пухнут в основном по двум причинам:
1. Youtube и видео, которые не закрываю, чтобы по правой колонке открыть сразу несколько других. Кнопки «забыть сам ролик» там нет, поэтому такая страница может держать пару сотен мег влёгкую.
2. Facebook. Я не знаю, что он делает, что набирает в себя, но промотал сотню постингов в ленте — всё, гига 2-4 сожрало влёгкую. На лапте с 8GB это просто страшно.

2. Facebook. Я не знаю, что он делает, что набирает в себя, но промотал сотню постингов в ленте — всё, гига 2-4 сожрало влёгкую. На лапте с 8GB это просто страшно.

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

Я у жены на ноуте запускаю FF в memory caging режиме через вот это:
github.com/...​eldesign/process-governor

Отдаю 2.5-3Gb, память течёт потом доходит до предела, она вся освобождается и опять течёт. Правда иногда таки FF приходит полный писец в клетке. Но в любом случае это гораздо лучше, когда выжирается 8 гиг ОЗУ и свопа в два раза больше.

Отличный тул. Спасибо за наводку.

Earlyoom + Chrome працює нормально

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

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

На лінуксах, до речі, з цим менше проблем ну і наведений функціонал обмеження на ram є з коробки
При чому хроміум жере набагато більше рам на умовних 20 відкритих вкладках

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

Стрелочкой рефрешил в панели.
Браузер уже закрывал, так что — сегодня не узнаем.

Ніколи нею не користуюсь, бо прибираю з інтерфейсу.
Краще побачити 2 символи в упл

Не знаю з чим воно пов’язано і чому так, але якщо перейти в адресну строку (alt+d) і натиснути ентер, то проблемна сторінка перестає бути проблемною

Ну ФФ еще и глючит. Вот опять на старте вкладку не подгрузил. И фиг с ней потом что-то сделашь — рефреш тоже не работает. Движок думает, что вкладка пустая, а в списке — иконка от слака, который там в оригинале должен быть. Если перезагрузить ФФ — то он ее откроет.

Итого: Раст никак не гарантирует корректность работы приложения.

До чого тут Rust до всього FF, якщо читаю

Mozilla used Rust to build Stylo, the CSS engine in Firefox (replacing approximately 160,000 lines of C++ with 85,000 lines of Rust).

blog.mozilla.org/...​omes-the-rust-foundation

і ще, многабукафф
manishearth.github.io/...​d-c-plus-plus-in-firefox

27.7% С++, 26,3% JS, 11,6% HTML, 9.6% Rust, але Rust тормозить і тече, а С++ збс. :) :)

Ну тоді що є серйозне, написане на Расті?
І чому усе інше на ньому не переписали в браузері?

Итого: Раст никак не гарантирует корректность работы приложения.

Отказываюсь в это верить!

Итого: Раст никак не гарантирует корректность работы приложения.

Ламборжині не гарантує дотримання водієм ПДР.

Ну а толку?
Надо саммонить Камышана.

саммонить Камышана

нічого не зрозумів, перефразуй

Він весь час каже, що Раст допомагає (най гарантує) коректність написаної програми.

Якщо порівнювати з С++, то побочок та UB набагато менше

За моїм досвідом 80% багів в логіці. А може — й 90%.
Тому саме цей момент взагалі нічого не вирішує.

так от Rust провіряє коректність логіки, якщо не логічно з його точки зору, то лаконічно матюкнеться, і навіть з підказкою, а не викине простиню на 20 сторінок як С++ компілєр

так от Rust провіряє коректність логіки

Ти ж щойно писав, що не перевіряє:

Ламборжині не гарантує дотримання водієм ПДР.
так от Rust провіряє коректність логіки

Корявые требования (реквайременты) тоже он проверяет?

для валідації вимог є інші інструменти

такі як для валідації вимог С++ проектів

Я жодного не знаю.
Котрими Ви користуєтесь для С++?

Питання до хлопа що писав

Корявые требования (реквайременты) тоже он проверяет?
Питання до хлопа що писав

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

Решает. Если ты знаешь, что у тебя в языке нет доступа к raw pointers, есть автоматическое управление памятью, нет UB, автор кода (и код ревьюверы) могут фокусироваться на логике, а не на том, чтоб искать лажу в коде, которая выглядит как конфетка, а на самом деле триггерит UB.

И толку — файрфокс все равно глючит?

Увы, в ход идут bad faith аргументы, мне на это нечего ответить.

В большистве языков

нет доступа к raw pointers, есть автоматическое управление памятью, нет UB

при этом софт кривой. Не помогает.

По моему опыту — вполне помогает

То есть, софт на С++ более глючный, чем на других языках?

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

Перекидываться пассивно-агрессивными общими фразами, не относящимися к Rust большого желания нет, надеюсь, понимаете.

название топика посмотри еще раз

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

Устройте видео-стрим сессию Q&A. Я пришлю свои вопросы и присоединюсь к просмотру. Можно и донат открыть будет для желающих )

Устройте видео-стрим сессию Q&A. Я пришлю свои вопросы и присоединюсь к просмотру. Можно и донат открыть будет для желающих )

Подумаю. Никогда не делал стримов такого формата. Есть что-то для примера посмотреть?

Подумаю. Никогда не делал стримов такого формата. Есть что-то для примера посмотреть?

Лично не делал. Видел только на ютубе стримы с донатами. Вот пример «урбанисты собирают деньги на адвокатов задержанным в Мск» www.youtube.com/watch?v=qgYHxeW2sqY
В принципе достаточно начать стрим на ютубчике, плиткой расставить спикеров (что бы всех было видно) и прилепить ссылочку типа donation alerts www.donationalerts.com Не знаю только как счетчик поставить на видео поток, но наверное это несложно делается, раз счетчики доната есть уже у всех геймеров ) Возможно этим занимается стриминговая софтинка.

Мне на донаты пофиг, главное что было полезно людям. У вас нет случайно примера на технический стрим такого формата, который бы был вам интересен? Сбор денег на ремонт провала — не совсем моя тематика :)

У вас нет случайно примера на технический стрим такого формата, который бы был вам интересен?

Есть по C++: www.youtube.com/watch?v=3tKg2fiiaD0 В таком стриме есть live-chat всегда, где можно общаться. Так же, разумно будет собрать вопросы предварительно на форуме, это даст пищу на первые час-полтора, и еще полчасика оставить на Q&A.

Это кому-то нравится? Я посмотрел минут 10, сильно скучно и уныло.

Это кому-то нравится? Я посмотрел минут 10, сильно скучно и уныло.

Людей мало, поэтому уныло. Перед аудиторией презентация/диалог намного динамичнее развивается.

Дивись, виходячи з умов написання нового коду (не розгрібання, підтримка легасі), та накладених обмежень (CPU, OS, memory, швидкість виконання та розробки і т.д.) я би йшов від простішого до складнішого таким шляхом:
Вирішується на С (так: берем С)?
Ні -> вирішуєтся на Rust (так: берем Rust )
Hі -> вирішуєтся на Go (так: берем Go)
Hі -> вирішуєтся на Python(так: берем Python)
Hі -> вирішуєтся на Qt (так: берем Qt )
далі Java, PHP, D ....
C++ як ласт ресорт, коли всі інші варіанти відпали

Я мав на увазі, що якщо управління пам’яттю та UB то така проблема, що не дає можливості якісно ревьювить код, то на мовах, де цих проблем нема, рев’ю коду буде більш якісним:

Решает. Если ты знаешь, что у тебя в языке нет доступа к raw pointers, есть автоматическое управление памятью, нет UB, автор кода (и код ревьюверы) могут фокусироваться на логике, а не на том, чтоб искать лажу в коде, которая выглядит как конфетка, а на самом деле триггерит UB.

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

Hі -> вирішуєтся на Qt (так: берем Qt )
C++ як ласт ресорт, коли всі інші варіанти відпали

рукалицо

C, Rust, Go, Python, QT, Java, D, C++.
Если ты таки програмист, то ты сразу удалишь в этом ряду лишнее.

склади свій ряд,
критиканствувати легко

C++? По-типу все остальное это явно дело рук человеческих, а С++ дело рук рептилоидов.

до речі, Rust іде в хмару
aws.amazon.com/...​t-runtime-for-aws-lambda
jamesmcm.github.io/...​020/10/24/lambda-runtime

а тепер дивимся бойлерплейт для С++ і офігіваєм:
aws.amazon.com/...​ing-the-c-lambda-runtime

а тепер дивимся бойлерплейт для С++ і офігіваєм:
aws.amazon.com/...​ing-the-c-lambda-runtime

CGI повертається!

bleeding edge technology:

So serverless is essentially a return to the PHP/CGI execution model... What’s changed to turn a bad idea into a good idea again?
news.ycombinator.com/item?id=16407290

You’ve just invented the next big thing: Serverful Architectures!
news.ycombinator.com/item?id=23368536

Намекаешь, что растом можно заменять жабускрипт?

а що там на виході після всіх цих компіляцій? просто джаваскрипт? я чого цікавлюся: пишу іноді для своїх студентів демки (наприклад fbeilstein.github.io/simplest_smo_ever ), але при цьому не знаю джаваскрипта від слова зовсім (гуглю як цикли писати, ну і за дикий говнокод соромно, хоч я його нікому й не показую), то може мені було б зручніше транслювати туди з чогось іншого, може там граблів менше. правда, мені ще важливо, щоб той результат збирався в один самостійний файл (і без ніякої серверної частини) — так треба, щоб мені було потім простіше вмонтовувати це все в GoogleColab (я там зберігаю відразу теорію з формулами, код на Python для прикладів і отакі живі демо для інтуїції).

що там на виході після всіх цих компіляцій

веб асемблер

Пітон на стероїдах — це nim.
Rust все таки складніше і в освоєнні, і в написанні так, щоби боров чекер був щасливий.

Завершён процесс создания организации Rust Foundation
www.opennet.ru/...​nnews/art.shtml?num=54555

Для http-сервера Apache будет подготовлен TLS-модуль, написанный на языке Rust
www.opennet.ru/...​nnews/art.shtml?num=54519

Rust писаний фанатами жс із Мозіли. Чи я помиляюся?

Influenced by
Alef,[7] C#,[7] C++,[7] Cyclone,[7][8] Erlang,[7] Haskell,[7] Limbo,[7] Newsqueak,[7] OCaml,[7] Ruby,[7] Scheme,[7] Standard ML,[7] Swift[7][9]

А ні, все ок. С шарп в списку теж.

Таке ще пишуть:

In November 2020, Amazon Web Services announced its commitment to Rust’s continuation by hiring some people who had a close relationship with the Rust language development. AWS claimed to be expanding the use of Rust in the development of its own products.

aws.amazon.com/...​and-how-wed-like-to-help

en.wikipedia.org/...​ffs_and_a_Rust_foundation

Потрібна думка Валялькіна. Що вчити: Раст чи Го?

Ого, популярний опенсорс репо: github.com/valyala/fasthttp

Горжуся за укрів.

Потрібна думка Валялькіна. Що вчити: Раст чи Го?

Electron.js же -> dou.ua/forums/topic/32657 :-) Хотя боюсь Валялкин со мной не согласится)))

Позитивная новость, теперь сломать Апаче через библиотеку, реализующию TLS, будет намного сложнее :)

безпечність має бути безпечною

Не стоиn парится по этому поводу. Просто модный язык как до недавнего времени был Goland. Дальше точно так же займет свою узкую нишу — системные утилиты и иже с ними.

О. С слил C++. Какие безумные там картинки.

Там явный «гений бенчмарков» писал.

Посмотрел первый попавшийся тест: benchmarksgame-team.pages.debian.net/...​rksgame/fastest/rust.html

«reverse-complement»:
— в коде рaста чел пользует mm_shuffle_epi8(), _mm_and_si128() и тому подобные быстрые штуки
— в коде C чел гоняет циклы с посимвольными сравнениями

«Ч» — честность.

В общем, каждое нубо хочет понаписать бенчмарков. Удивительно, что у него жаба с C лишь ~ на равных — а не быстрее.

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

Если при компиляции С или С++ выставить правильные ключики и не писать код, как 7 летний ребенок, то компилятор сам вставит где нужно эти SSE и AVX.

Когда у чела в коде такое: «while(*front_Pos==’\n’ && front_Pos<=back_Pos) front_Pos++;» — компилятор уже ничего никуда не вставит.

П.С. Больше склоняюсь к дурачку. :)

Там же или дурачок или ребенок сравнение делал.
while(*front_Pos==’\n’ && front_Pos<=back_Pos) front_Pos++;

чисто із цікавості — а що з цим кодом не так?
Єдине, до чого можу докопатись, це те, що умови треба переставити, а не то вилізе за межі back_Pos

while(front_Pos <= back_Pos && *front_Pos == ’\n’) ++front_Pos;

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

for( ; front_Pos <= back_Pos && *front_Pos == ’\n’; ++front_Pos);
чисто із цікавості — а що з цим кодом не так?

Как минимум:
— двойные условия плохо хаваются «бренч-предикторами»
— «<=» часто работает медленнее, чем «>» (в зависимости от компилятора и оптимизации)
— желательно совместить пост-инкремент с одной из проверок
+ ещё всякие методы ускорения (типа, разворачивания цикла, итп), в которые я не буду вдаваться

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

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

Хоча, перформанс не завджди є вимогою, а там де є, то Rust наступає плюсам на п"ятки (HFT, blockchain)

Плюси ще вільно пасуться в геймдеві , і аутомотів (та й там де купа легаці коду).

Я би на нові проекти розглядав або Go або Rust, в залежності які вимоги до проекту та коду.

Плюси ще вільно пасуться в геймдеві , і аутомотів (та й там де купа легаці коду).

Ниша «плюсов» — крупные (как правило, десктоп) проекты, где требуется скорость, ООП и портабельность.

Ниша «си» — быстрый/производительный небольшой и портабельный код. В таком, обычно, у разработчика нет проблем с индексами за пределами массива, прочим мемори-менеджментом.

А вот где ниша для «растa» — для меня пока неясно. Да и синтаксис выглядит крайне мутно, (а-ля, лишь для фриков). В общем, не взлетит...

Ниша «плюсов» — крупные (как правило, десктоп) проекты,

десктоп пішов у минуле, рулить веб і хмара,
про хмару Rust vs C++ тільки що написав вище
dou.ua/...​rums/topic/30864/#2060633

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

Лишь в мире хипстеров и аутсорса всякого формошлёпского хлама в страны африки. :)

Ничего реально серьёзного/критичного (и денежного) — «облакам» всё ещё не доверяют. А для веба — делают лишь примитивное «рид-онли» отображение.

десктоп пішов у минуле

омг. ванга

В GCC 7 оптимізатор розвалили, досі не поправили. Сидимо на 6.5, бо є важливіші проблеми, ніж розбиратися і пеерписувати.

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

Компания Bluefruit software 20 лет разрабатывает софт для встраиваемых систем. В ней работает автор блог поста статьи „про степень пригодности Rust для встраиваемых систем”

There are three main types of bugs that Rust avoids:
— Memory bugs
— Concurrency bugs—specifically „data races”
— Consequences of Undefined Behaviour

What’s not great about Rust?
— Target support
— Compile time
— Learning and training
— What about real-time and Rust?

...It’s worth noting that in embedded, it’s important to fail early. Rust forces software to be correct at compile time. In other languages, issues may not be identified until a prototype is in the field or when the product has shipped. The discipline needed for development in Rust has the potential to reduce the cost of testing prototypes and the need for fixes after deployment....

Is Rust ready for embedded software?
Posted 5th September 2019 by Emily
www.bluefruit.co.uk/...​dy-for-embedded-software

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

Основываясь на этой работе, Mozilla и Rust Core Team рады сообщить о создании фонда Rust. Наша цель — к концу года завершить первую итерацию создания фонда.
Первой задачей фонда будет то, в чём Rust уже хорош: получении владения (ownership). Но на этот раз — реальный ресурс, а не что-то в программе. Различные торговые марки и доменные имена, ассоциированные с Rust, Cargo и crates.io перейдут фонду, который также возьмёт на себя финансовые расходы на их поддержку. Мы рассматриваем эту итерацию только как начало. Существует множество точек роста роли фонда и мы будем рады изучить их в будущем.

habr.com/ru/post/515712

Ну чьо пацани, не очкуєм:

Post-Mozilla Rust: The Future of the Rust Language

With Mozilla shrinking in total employees, what is going to happen with Rust?
Image for post

Recently Mozilla announced and enacted a sizeable number of layoffs, citing the COVID-19 pandemic. Many within the Rust community at large began to worry about the future of the beloved Rust programming language.
There are over 5000 open issues on GitHub, the Rust-based Servo team is no more, and some of the internal Mozilla contributors to Rust have lost their jobs!
As with any major news, things that can affect a programmer’s happiness are always going to cause a stir online. But guess what?

Rust is going to be okay!

Microsoft Loves Rust ...
Amazon Loves Rust ...
Google Loves Rust ...
npm Loves Rust ...
Many More Companies Love Rust ...
Developers Love Rust ...

medium.com/...​ust-language-61a5cfb1f615

Як в мультику „Весь мир за” www.youtube.com/watch?v=iYgUPQ8jMAA

Я помню также успокаивали когда накрывался медным тазом передовой XUL, говорили, что скоро Qt умрёт и везде будет один XUL. www.webopedia.com/TERM/X/XUL.html . Прошло 15 лет, уже никто не помнит что такое XUL %) В 2030 — что такое rust? Это то что у тебя на порогах в машине.

ти схожий на брюжащєго старікашку

Ну слава боху не на happy idiot. Это называется реалист.

Просто нейронку хорошо натренировал :)

це мало впливає та теоретичну межу передбачування,
до пророцтва це не має відношення.

Microsoft Loves Rust ...
Amazon Loves Rust ...
Google Loves Rust ...
npm Loves Rust ...
Many More Companies Love Rust ...
Developers Love Rust ...

напомнило онекдот: «А Руст вас всех ненавидиииит»

фальшива проекція власного его

что ты все про себя да про себя

Два примера замечательных свойств Rust компилятора.

This is a short ad of a Rust programming language targeting experienced C++ developers...
1.
....Rust compiler tracks aliasing status of every piece of data and forbids mutations of potentially aliased data...Rust doesn’t allow doing stupid things.....

2.
The counter variable lives on the stack, and a pointer to these stack data is shared with other threads....Rust allows doing dangerous, clever, and fast things without fear of introducing undefined behavior....

matklad.github.io/...​o-beautiful-programs.html

2.
The counter variable lives on the stack, and a pointer to these stack data is shared with other threads....Rust allows doing dangerous, clever, and fast things without fear of introducing undefined behavior....

О! Это просто образец мегатупости, когда в руки дали управление потоками и не объяснили что это такое и как не стоит делать. Это ж надо родить такой выражденный кейс, который в здравом уме никто использовать не будет и этим гордится. На С эта же программа будет не намного больше и такой же безопасной ... и бестолковой.

На С эта же программа будет не намного больше и такой же безопасной

Можно привести пример кода?

Я искренне пытался сделать её длинее и умнее чем на расте, но не смог, получился супер-короткий эффективный код %)

#include <stdio.h>

int main()
{
    int total = 0;

    #pragma omp parallel shared(total) num_threads(10)
    {
        #pragma omp atomic
        total++;
    }

    fprintf(stdout, "total=%d\n", total);

    return total;
}

Компилировать:

gcc -fopenmp crulez.c -o rustsuxx
root@mikenfs:~# ./threads
total=10

Если растаманы не могут без мьютекса, там где его можно прилепить, как пятую ногу слону и создать на стеке pthread_mutex_init()/pthread_mutex_lock()/pthread_mutex_unlock()

Сенкс, не знал про openmp, выглядит интересно.

       #pragma omp atomic
        total++;

Как я понимаю, omp atomic это то, что делает эту операцию безопасной в многопоточной среде.

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

Добавим итераций, чтоб повысить шанс гонки (итерации были в исходном примере на раст):

int main()
{
    int total = 0;

    #pragma omp parallel shared(total) num_threads(10)
    {
        int i;
        for (i = 0; i < 1000000; i++) {
          #pragma omp atomic
          total++;
        }
    }

    fprintf(stdout, "total=%d\n", total);

    return total;
}

Запускаем, выдает

total=10000000

Предположим, кто-то забыл напиать

pragma omp atomic
. Попробуем его удалить и снова запустить
% gcc -fopenmp crulez.c -o rustsuxx

% ./rustsuxx                       
total=1793787

Компилятор довольно схавал и программа выдала неверный результат. Вся безопасность программы полагалась на good intention разработчика, который может проебаться, недосмотреть, или вообще быть не в курсе, что такая вещь как race condition существует.

Раст просто не позволит совершить такую ошибку. Доступ к общей переменной из разных потоков будет возможен либо через мьютекс (что показано на примере), либо через безопасные атомарные операции (например, через doc.rust-lang.org/...​mic/struct.AtomicU64.html).

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

Зато С разработчик может быть в курсе того, что на многих платформах арифметические операции с памятью атомарные и может заставить компилятор их использовать, например, через встроенные bultins: __atomic_add() и не использовать мьютексы, которые как удар кувалды по яйцам, так и стандартные атомики, которые везде используют implicit barriers and fences, которые уже лучше, но всё равно, как удар сокирой по яйцам.

rust — это как детские штанишки, некоторые из них вырастают, а некоторые растягивают до взрослого размера. В расте тесно, как клаустрафобам в лифте.

Зато С разработчик может быть в курсе того, что на многих платформах арифметические операции с памятью атомарные и может заставить компилятор их использовать, например, через встроенные bultins: __atomic_add()

Если б только в Rust была возможность использовать эти самые атомарные операции и контролировать как memory barrier и fence расставлены вокруг них... А надо же, вот же она: doc.rust-lang.org/...​td/sync/atomic/index.html

All atomic types in this module are guaranteed to be lock-free if they’re available. This means they don’t internally acquire a global mutex.

и не использовать мьютексы

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

Данный кейс может быть запилен атомиками:

use crossbeam::scope;
use std::sync::atomic::{AtomicU64, Ordering};

fn main() {
  let mut counter = AtomicU64::new(0);

  scope(|s| {
    for _ in 0..10 {
      s.spawn(|_| {
        for _ in 0..1000000 {
          counter.fetch_add(1, Ordering::Relaxed);
        }
      });
    }
  }).unwrap();

  let total = counter.get_mut();
  println!("total = {}", total)
}

Запустить: play.rust-lang.org/...​f10531d6ec67abc714968fe15

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

use crossbeam::scope;

fn main() {
  let mut counter = 0;

  scope(|s| {
    for _ in 0..10 {
      s.spawn(|_| {
        for _ in 0..1000000 {
          counter+=1;
        }
      });
    }
  }).unwrap();

  let total = counter;
  println!("total = {}", total)
}

error[E0499]: cannot borrow `counter` as mutable more than once at a time
  --> src/main.rs:8:15
   |
6  |     scope(|s| {
   |            - has type `&crossbeam_utils::thread::Scope<'1>`
7  |       for _ in 0..10 {
8  |         s.spawn(|_| {
   |         -       ^^^ mutable borrow starts here in previous iteration of loop
   |  _______|
   | |
9  | |         for _ in 0..1000000 {
10 | |           counter+=1;
   | |           ------- borrows occur due to use of `counter` in closure
11 | |         }
12 | |       });
   | |________- argument requires that `counter` is borrowed for `'1`
Раст обидился и не дал скомпилить.

play.rust-lang.org/...​4320268d25c027fc5ca100b88

Если б только в Rust была возможность использовать эти самые атомарные операции и контролировать как memory barrier и fence расставлены вокруг них... А надо же, вот же она: doc.rust-lang.org/...​td/sync/atomic/index.html

Они не то называют fences, ну да бох с ними. Проблема в том, что их atomic не может не вызывать команду lock на x86, чтобы остановить все остальные процессоры и ядра, а это болезненная операция. Но при соблюдении ряда условий, довольно простых, как выравнивание памяти на размер типа и прочее может lock не вызывать, но раст в это не умеет и перестраховывается.

Как и с ARM’ами, например ARMv8 (AARCH64) поддерживает два типа атомических операций (старый тёплый ламповый медленный LLSC en.wikipedia.org/...​ad-link/store-conditional — встречайте его в расте) и новый ультрабыстрый Large System Extensions (LSE) как в x86, которого раст боится, т.к. нет универсальности.

P.S. Когда все уже забыли годами про это, раст таки что-то попытался сделать два месяца назад: github.com/...​rust-lang/rust/pull/72324 , но в x86 не сделали.

Они не то называют fences, ну да бох с ними. Проблема в том, что их atomic не может не вызывать команду lock на x86, чтобы остановить все остальные процессоры и ядра, а это болезненная операция. Но при соблюдении ряда условий, довольно простых, как выравнивание памяти на размер типа и прочее может lock не вызывать, но раст в это не умеет и перестраховывается.

Спасибо, где можно про это детально почитать? Есть пример на С, которые это демонстрирует?

На C можешь поискать „gcc atomic builtins”, „__attribute__(aligned(x))”.

Почитать про синхронизации тредов (8.4 THREAD SYNCHRONIZATION), атомики (12.7.2.2 C++11 atomic support):
www.intel.com/...​s-optimization-manual.pdf

Атомики очень подробно:
software.intel.com/...​2d-3a-3b-3c-3d-and-4.html
CHAPTER 8 MULTIPLE-PROCESSOR MANAGEMENT

Есть поверье, что если ты прочтешь три раза документ в последней ссылке, все 5000 страниц, то тебе будут поклоняться как божеству %) Я пока только на втором цикле на 2653 странице.

Этот пример компилируется с lock:

godbolt.org/z/c55afa

        lock            xadd    qword ptr [rsp], rax

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

GCC зі всіма варіантами атоміків і моделей пам’яті генерує LOCK ADD [total], 1

total вирівняний по межі сторінки (з запасом).

Якщо в асемблерному лістингу забрати LOCK і перекомпілювати, результат очікувано некоректний.

Як в цьому прикладі позбутися LOCK?

fence команда + inc.

Щось в мене ця магія не працює.

А можна при нагоді кусок робочого асемблера в студію? Бо або я гальмую, або там не все так просто.

GCC з -O1 генерує щось таке:

main._omp_fn.0:
.LFB374:
        .cfi_startproc
        movl    $100000, %eax
.L2:
        movq    (%rdi), %rdx
        lock addl       $1, (%rdx)
        subl    $1, %eax
        jne     .L2
        rep ret
        .cfi_endproc

Викидання LOCK і різноманітні танці з бубнами з MFENCE і ADD/INC ні до чого доброго не приводять. Дописався до самопального спінлока, в результаті час виконання став в 10 разів повільнішим, і я вирішив, що досить на вечір п’ятниці.

Ось версія з MFENCE + INC (яка не працює):

main._omp_fn.0:
.LFB374:
        .cfi_startproc
        movl    $100000, %ebx
        movq    (%rdi), %rdx
.L2:

        mfence
        incl    (%rdx)

        subl    $1, %ebx
        jne     .L2
        rep ret
        .cfi_endproc

Ну і версія зі спінлоком, яка працює, інкремент без префікса LOCK, але в результаті все повільне.

main._omp_fn.0:
.LFB374:
        .cfi_startproc
        movl    $100000, %ebx
        movq    (%rdi), %rdx
.L2:
        movl    $1, %eax
        xchgl   %eax, 8(%rdi)
        testl   %eax, %eax
        jnz     .L2

        incl    (%rdx)

        movl    $0, %eax
        xchgl   %eax, 8(%rdi)

        subl    $1, %ebx
        jne     .L2
        rep ret
        .cfi_endproc

Коротше, здаюся на сьогодні.

Приношу извинения, запутал в начальном посте и сам запутался :)

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

Тот способ что я предложил для strong ordered memory, например, write-combine. Если написать префикс lock для такой памяти, то процессор будет лочить всю шину. Для кешируемой не подойдёт, что впрочем твои тесты наглядно показали.

Ещё раз сорри за заблуждение.

Что если несколько виртуальных адресов ссылаются на один и тот же физический адрес памяти (типа shared memory между двумя разными процессами)?

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

Процессор работает только с физическими адресами, все виртуальные транслируются через TLB, а та в свою очередь наполняется из таблиц и директорий памяти: en.wikipedia.org/...​nslation_lookaside_buffer

Мало того, одну и ту же память можно замапить много раз, сколько хватить виртуального адресного пространства процесса. Хоть одну страницу на всё виртуальное пространство. Например в драйверах GPU может быть 3 маппинга одной и той же памяти, как кешируемая, как некешируемая и как, например write-combine форма некешируемой памяти. Для разных видов работы.

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

А прикинь, кроме мьютекса есть ещё другие объекты синхронизации. Мьютекс, например, в линуксе — это убийство производительности, в QNX используется lock contention механизм, только если мьютекс залочен, то происходит трип в ядро для ожидания, но даже с этим механизмом например для задачи с одной переменной — это оверкилл. А оказывается, что есть ещё такая вещь, как spinlock, которая не делает трипы в ядра, а используя встроенные атомарные свойства процессора просто жрёт процессор в ожидании и это оправдано когда защищать нужно парочку операций, а не тяжелую логику, для которых пригодень мьютекс.

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

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

Ты ж сам понимаешь, что все это добро на любой вкус давно запилено в Раст в стандатной библиотеке или в внешних. Бери используй что надо.

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

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

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

Как занимающийся оптимизациями, скажу, что потом не наступает никогда. А если наступает, то это стоит очень и очень дорого.

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

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

Это можно запилить

use crossbeam::scope;

fn main() {
  let mut counts: Vec<u64> = vec![0; 10];
  
  scope(|s| {
    for c in counts.iter_mut() {
      s.spawn(move |_| {
        for _ in 0..1000000 {
          *c+=1;
        }
      });
        
    }
  }).unwrap();

  let total: u64 = counts.iter().sum();
  println!("total = {}", total);
}

play.rust-lang.org/...​2d9444d2aa2dd2cd7a890641e

Т.е. раст защищает отдельные элементы, но не весь массив в целом? Просто как пример, на x86/x86-64 ты можешь использовать невыравненный доступ к памяти, например создать массив U64 по адресу, заканчивающийся с 1,2,3,4,5,6,7 цифрами. Всё будет работать, будет работать медленно, но будет до тех пор пока не используется многопоточный доступ, который будет писать и читать значения на границах cacheline по невыравненным адресам два раза, вначале кусочек по одному выравненному и кусочек по другому. Таким образом сделать race condition с соседними элементами.

Т.е. раст защищает отдельные элементы, но не весь массив в целом?

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

Просто как пример, на x86/x86-64 ты можешь использовать невыравненный доступ к памяти, например создать массив U64 по адресу, заканчивающийся с 1,2,3,4,5,6,7 цифрами. Всё будет работать, будет работать медленно, но будет до тех пор пока не используется многопоточный доступ, который будет писать и читать значения на границах cacheline по невыравненным адресам два раза, вначале кусочек по одному выравненному и кусочек по другому. Таким образом сделать race condition с соседними элементами.

Не знаю как это воспроизвести. Vec в раст не дает контроля за выравниванием. Можно запилить с помощью unsafe rust, но гарантии безопасности на этот код, ясное дело, распространяться не будут.

так и стандартные атомики, которые везде используют implicit barriers and fences, которые уже лучше, но всё равно, как удар сокирой по яйцам.

Мнэээ...
atomic_fetch_add_explicit(&x, v, memory_order_relaxed);

или в твою среду ни C11, ни C++11 не завезли?

Или ты о чём-то совсем другом?

Also

root@mikenfs

завязывай с этим, least privilege principle епта :)

У меня индульгенция на рута. Мне можно.

Да, милости просим твой мега-безопасный код на Си, на порку.

Подбросим «дровишек».
TLDR; В Linux ядре будет поддержка драйверов написанных на Rust.

Линус Торвальдс подключился к обсуждению возможности добавления в ядро Linux средств для разработки на языке Rust. Джош Триплет (Josh Triplett) из компании Intel, работаюдий над проектом до доведение языка Rust до паритета с языком Си в области системного программирования, предложил на начальном этапе добавить в Kconfig опцию для поддержки Rust, которая не приводила бы к включению в число зависимостей компилятора Rust при выполнении сборки в режимах «make allnoconfig» и «make allyesconfig» и позволяла бы более свободно экспериментировать с кодом Rust. Аналогичный трюк был реализован при добавлении в ядро экспериментальной поддержки сборки в Clang в режиме оптимизаций на этапе связывания (LTO, Link Time Optimization), после которой планируется добавить и поддержку сборки с защитой потока выполнения команд (CFI, Control-Flow Integrity).

www.reddit.com/...​rnel_intree_rust_support

драйверов написанных на Rust.

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

Ох и не говори — это наглая и агрессивная реклама раст-а от Товальдса, просто форменное безобразие!

Линус Торвальдс подключился к обсуждению возможности добавления в ядро Linux средств для разработки на языке Rust.

«подключился»:
рустаманы в ядре: ща мы тут как подключим руст в ядро!
лт: воу-воу! полегче! сделайте опции правильные и примеры читабельные, шоб о5 херни не напороли как всегда

а так да, подключился

Оу-Оу... так пойди ним в переписку, напишика, чтобы они херни там не напороли!! А то совсем безобразие устраивают, а с тобой даже не проконсультировались... беда.

так пойди ним в переписку,

зачем?

use std::os::linux::kernel::driver::{read, write, open, close,ioctl};

Если раньше ядро линукса можно было собрать из исходников за пару минут, то теперь нужно будет ждать пару дней, пока компилятор Rust проведет все свои borrow check’и. В итоге развитие ядра линукс затормозится, т.к. только у самых упоротых растеров хватит терпения дождаться окончания компиляции исходников.

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

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

Не поверите. Иногда приходится раз 5-7 за день пересобрать

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

Я запускаю джаву или что-то на джаве раз в квартал. Джава не нужна?

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

Я собираю проект по несколько раз в день, в среднем 7-8 минут сборка.
Значит джавой нельзя пользоваться?

Это 100% означает, что джавой нельзя пользоваться. Я собираю свой проект на Go с нуля (не инкрементальная сборка) за 5 секунд. Инкрементальная сборка занимает полсекунды. Если бы сборка занимала 7-8 минут, то я бы давно забросил вносить изменения в такой проект, не дождавшись завершения компиляции. Теперь понятно, почему программы на Java развиваются черепашьей скоростью по сравнению с программами на Go.

А проект большой? Сколько файлов и сотен тысяч строк?

Проект очень даже солидный. Почитал немного библиотеки, очень хорошо поработал в плане увеличения производительности. Может пока что там не увидел, есть ещё одна тема как ускорить сервер, работающий с большими файлами — memory mapping. Она актуальна для работы с файлами, размеры которых коррелируют с объёмами оперативной памяти. Юзается в играх следующим образом: все файлы данных сшиваются в один большой цельный пак, и дальше когда нужен доступ к какому-то файлу, находящемуся в паке, лочится соответствующий кусок файла, и дальше доступ как к []byte. С чтением всё просто, если нужна запись, то лучше юзать буферизацию. Стандартный mmap слишком примитивный, вот тут github.com/edsrzf/mmap-go для примера более проработанный.

Там уже используется чтение из файлов через mmap — см. github.com/...​46281/lib/fs/reader_at.go

$ git clone https://github.com/VictoriaMetrics/VictoriaMetrics
$ cd VictoriaMetrics
$ find . -name *.go | wc
   1597    1597   83172
$ find . -name *.go | xargs cat | wc
 594935 2409381 19458477

1597 файлов с 594935 строками

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Или

case constants.PrometheusWriteApiPath: ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Minimum Viable Product

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

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

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

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

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

Во. Пора линуху возвращаться к своим положенным 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

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

Как было не однократно проверено в сравнении 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] к разработк