Машинное обучение с использованием Python. Сборник рецептов

Автор: Крис Элбон

Год издания: 2019

Скачать книгу

#python #machine_learning #русский

Не очень понятно зачем всё это, но можно как-то так:

use once_cell::sync::Lazy;
pub static USERNAME: Lazy<String> = Lazy::new(|| env::var("USER").unwrap_or_else(id_un))

https://godbolt.org/z/nXZR97

Почему раст добавляет дополнительные

push    rax // in the beginning of example::bar
// and
pop rcx // in the end of example::bar

По сравнению с C++?

TF 2.0 за 7 часов

https://youtu.be/tPYj3fFJGjk

Потому что еrrare humanum est, а компьютер железный.

это объяснение ведь можно (справедливо) понять так, что в языке без хкт лучше просто фп не страдать и все

в дотнете без hkt в принципе контейнерную библиотеку нормально не сделать

вернее нормально с точки зрения более позднего фп подхода.

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

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

т.е. досвидания статика, привет динамический глюкодром

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

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

@ozkriff тлдр про сжв, выгонение контрибуторов и прочее: вот ишью, и этот meh который там отвечает говорит прям так, как я бы сам ответил

Трудно сказать, что лучше учить раньше. Имхо, раст. Ибо раст это как бы правильный С++, каким был бы С++ если Страуструп забил на совместимость с уродским С, а комитет по-настоящему развивал язык, а не добавлял новые фичи на кривой фундамент.

С++ это помойка парадигм, старых и новых подходов. Там у всех свои стандартные библиотеки, математические библиотеки, уйма кривых решений. Например, есть автовывод типов, но EpicGames предлагают его не юзать, т.к. в С++ неявные приведения типов по всюду и разделив 10.0 на 20 ты можешь внезапно получить 0(из-за интов и флотов). Или там нельзя вернуть из функции несколько вариантов значения(алгебраический тип данных, enum в расте), или несколько занчений(кортеж), поэтому там везде кривые и опасные методы реализации этого. А ещё там копи-семантика, в отличие от move-семантики раста, поэтому он там копирует всё без конца и без конца вызывает деструкторы. Да и вообще там можно спокойно создать класс с неинициализованными полями, или обратиться к несуществующему элементу массива, а компилятор скажет "всё ок". Ещё там заюзаешь тип char, и надо будет открыть файла с русскоязычным именем.. и в рантайме он будет говорить, что такого файла нет, потому что чар поддерживает ANSI, но не юникод, и вообще там типы уродские вроде unsigned short int, длина которых разная на разных платформах. В общем, там полный бардак. И блуждая в этом бардаке, не научишься правильно программировать. Там везде нулевые указатели и указатели, а EpicGames вообще GarbageCollector прямо во внутрь классов встроили. Вообще не все понимают, зачем нужны ссылки, ведь от них особого профита нет, или скучно писать без конца const, (это подобно let mut в расте, но в расте по дефолту перменные иммутабельны, а в крестах мутабельны и для иммутабельности нужен конст). В С++ нет нормальных модулей, там приходится делать дубликаты сигнатур функций в .cpp файле, и там нужно так называемо предъобъявление, потому что компилятор долбанутый. Да что там, там даже вложенных многострочных комментариев делать нельзя, и приходится удалять комментарии-документацию или иначе мучиться:

/*

некий код

/** Из документации: эта функция делает то-то *//
void MyFunction(..) {}

*/

А enum в крестах такой, что он толком как константа, ты его объявляешь:

enum State {
A,
B
}

а потом везде в коде можешь юзать напрямую A, а не State::A. И вообще там нет системы модулей, там нет use math::{PI, abs, sqrt}; Там тупо икнлюдил файл и получай уйму функций, которые имеют те же имена, как другие функции, например, твои.. Поэтому там везде префиксы и суффиксы вроде fabs. Правда поверх этого есть система namespace, но она тоже кривовата и все ею пренебрегают, например, Epic Games. Ты инклюдил хедер двига, и получаешь все типы двига, а не ue4::network::Packet. Правда появились более нормальные енумы — enum class.

Модели памяти у них общие, ниша одна.

Сейчас переходный момент и нужны оба языка. Причем часто фирмы тупо переучивают набивших шишки ++ков на раст. Сейчас как бы хотим раста — поддерживаем древний код на крестах, или иначе: думаем на расте, но пишем древний код на крестах.

С++ ничему хорошему не научит. Там и вообще не ясно, как писать то надо, там есть сотни рекомендаций, и все они друг-другу противоречат. А библиотеки.. будь добр качать как zip с какого-то сайта — никаких там пакетных менеджеров нет, а если и есть, то их тысяча и не все библиотеки доступны. И библиотеки все кривые.

Думаю, лучше научиться программировать на расте. А вот ООП(классы) придётся изучить из ++ -ов. А затем будет тошнить от этих старперов, которые пишут криво и твердят(придумали какой-то там раст зачем-то), от всяких уродский Code-стайлов, вида всё CamelCase как у Microsoft и Epic, от всего этого бардака и повседневных кривых решений, потому что никто не знает, что такое алгебраические типы данных.

Блин, каждый день теперь ловлю лулзы с заказов на freelance.habr'e.

Вот, например, полностью корректная и нормальная программа на C11, которая ни разу не валидный C++.
https://gist.github.com/GoldsteinE/0ac1bb70dd59635b5de9452ca3fcd638