t1ha (Fast Positive Hash) реализован на Rust

И это хорошо.

И это плохо.

Очень рад за Фли Лю, но польза сомнительна.

И всё-таки синтаксис у rust адский. Беда.

Ну, хоть получше чем у питона...

Да синтаксис это вообще последнее дело в языке, ИМХО.

Толстяшка ,)

Да синтаксис это вообще последнее дело в языке, ИМХО.

Когда-то давно тоже так думал. И как раз пример rust-а меня разубедил. Всему есть предел.

У питона эстетичней, но с фигурными скобками практичней. С ними автоформатирование в IDE в разы проще

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

Кто-то сдал курсач ?

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

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

Раст - специализированный инструмент. К примеру он не удобен для реализации ООП подхода. Но это в принципе в какой-то мере хорошо, так как не везде ООП полезен, поскольку data-oriented design рулит. Так что можно повторять как мантру «если у меня что-то на расте не получается, значит я делаю что-то не то» и поиметь с этого профит. Впрочем отсутсвие эксепшенов в более менее серьезных проектах приводит к необходимости писать тонну хоть и полезного, но довольно нудного кода обработки. Так что хоть я и перехожу на раст, агитировать за него других не стану. Это язык для тех, кто знает чего хочет.

Откуда в Раст ООП?

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

Это ты про ?, лол? Ну да, длинно.

отсутсвие эксепшенов в более менее серьезных проектах

Есть же в расте всё. Просто выглядит оно, скажем так, своеобразно, но всё вполне полноценное.

Омномном

Разве криптографию не на ассемблере положено писать? Там же всякие атаки через напряжение процессора и прочее.

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

Есть же в расте всё

А как стэк раскручивать? Через longjmp чтоли?

В последний раз юзал map_err год назад, когда зачем-то писал на токио без async/await.

Хотя не, вру. И тогда не юзал, потому что Future::from_err().

Ну вот реализовывал я трейт Format. Там метод возвращает свой Result со своим Error. И внутри не работал вопрос, потому что нельзя привести чей-то там эррор к fmt::Error поскольку реализация трейта Convert для чужого еррора запрещена.

В такой ситуации и в другом языке пришлось бы писать try-except или аналог.

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

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

Вообще-то ему как раз разрешено по интерфейсу. Просто в нормальном языке я б написал бы както так try { println!(«{}», myObj); } catch (MyFormatException&) {...}, а в расте такое в принципе нереализуемо.

Эти хеш-функции не декларируются для криптографического применения.

трейт Format

сорри, он Display зовётся. Каша в голове, блин

А чё, неплохой хэш.

https://imgur.com/ilb29qX

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

Поэтому внутри можно подсмотреть как из C/C++ на Rust перекладываются связанные с производительностью трюки.

Где сравнение производительности с нормальным языком?

К тому же, никому не интересно как мартышка перепащивает С/С++ - всем интересно то, как она реализует его с нуля. Опять же, даже для перепасты нету бенчмарков, а это основная вещь, которая должна быть.

можно подсмотреть как из C/C++ на Rust перекладываются связанные с производительностью трюки

А как у него с объёмом скомпилированных бинарников по сравнению с C и C++?

Одинаково.

Кто-то обманывает…

$ cat hello.rs
// This is a comment, and will be ignored by the compiler
// You can test this code by clicking the "Run" button over there ->
// or if prefer to use your keyboard, you can use the "Ctrl + Enter" shortcut

// This code is editable, feel free to hack it!
// You can always return to the original code by clicking the "Reset" button ->

// This is the main function
fn main() {
    // The statements here will be executed when the compiled binary is called

    // Print text to the console
    println!("Hello World!");
}
$ rustc -C debuginfo=2 -C opt-level=0 hello.rs  # debug
$ du --apparent-size --bytes hello
269920	hello
$ rustc -C debuginfo=0 -C opt-level=3 hello.rs  # release
$ du --apparent-size --bytes hello
260376	hello
$ cat hello.c 
#include <stdio.h>

int main()
{
    puts("Hello, world!");
}
$ gcc -Og -g3 hello.c  # debug
$ du --apparent-size --bytes a.out
42264	a.out
$ gcc -O3 hello.c      # release
$ du --apparent-size --bytes a.out
16608	a.out
$ gcc -s -O3 hello.c   # release + strip
$ du --apparent-size --bytes a.out
14408	a.out

P.S.

rustc --version
rustc 1.32.0

P.P.S.

$ ldd ./a.out  # C
	linux-vdso.so.1 (0x00007fff1fc54000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f72b4205000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f72b43ed000)
$ ldd ./hello  # Rust
	linux-vdso.so.1 (0x00007ffd85406000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fda405b0000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fda405a6000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fda40585000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fda4056b000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fda403aa000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fda40608000)

Раст свою libstd статически линкует. Можно сделать динамически но не нужно.

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

Println не возвращает Result. Ну это другой подход в Расте, вместо того чтобы бросать исключения повсюду и надеятся что их поймают, всегда можно знать если в программе нету unwrap то все ошибки обработаны.

А чё, неплохой хэш.

Хеш выбирается под задачу. Рандомный хеш — это не всегда хорошо. Например, идеальных хеш, дающий наиболее равномерное распределение значений для unordered_map<int,int> — это почти всегда [](int i){return i;}

это почти всегда [](int i){return i;}

В любом случае FNV1a, как и все Мур-муры и прочие можно было считать устаревшими после появления Икс-икса (или популяризации, хз). А теперь Икс-иксу появилась альтернатива.

Ты только пытаешься изучать, а китайцы уже пишут на нём. Сверхчеловеки

А будут тесты производительности этого дела под С/С++ и на Русте ?

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

В чём он адский?
Трудно запомнить что 'a это лайфтайм?

Нет, просто ты ленивый.

man google

По ссылке пройди. Что за перл?

#[cfg(feature = "unaligned_access")]
pub fn t1ha0_32le(data: &[u8], seed: u64) -> u64 {
    unsafe { t1h0_body::<LittenEndianUnaligned<u32>>(data, seed) }
}