Комментарии 24
Глядя на такое огромное количество заброшенных крейтов на crates.io, мне даже становится жалко экосистему раста. Порядка 1300 крейтов с ключевым словом matrix. Самый популярный обновлялся в 2018 году.
Уже давно поговаривают о том, что крейты постигнет судьба npm-помойки.
Извините, если вас задел.
Там есть каталоги типа awesome Rust, по которым можно найти хорошие крейты, да и поиск тоже неплохо справляется. А что будет тонна мусора, это неизбежно в свободной экосистеме.
Мне нравится подход phpшного packagist, где у каждого пакета не только свое название, но и неймспейс, соответствующий юзернейму. Ну или как у докер-хаба сделано, где только проверенные образы не имеют префикса. Никакой помойки нет, и пакеты одного автора в одной куче лежат.
Мне казалось, что Раст пойдет по тому же пути. Но он пошел дорогой npm.
В расте обсуждались неймспейсы, стандартное возражение: чем помойка (и сквоттинг) неймспейсов лучше помойки названий?..
Плюс я не очень представляю долговременное развитие с неймспейсами. Скажем, появился условный vasya/serde, поначалу как эксперимент. У Васи ещё с десяток библиотек опубликовано, но они никому не нужны и заброшены. А вот новая библиотека оказалась удачной, привлекла контрибьюторов и завоевала популярность. И появляются petya/serde_json, anton/toml и т.д. Стало ли лучше от неймспейса?.. Или надо создавать пользователя/организацию serde и уговаривать авторов отдельных библиотек перенести их туда? Причём удалять старые нельзя — так можно кому-то билд поломать.
Опять же, если я ищу библиотеку (по тегам или названию), то поиск должен быть глобальным: то есть все библиотеки во всех неймспейсах. В общем, мне кажется, что эти пространства имён ничего особо не добавляют.
Насколько мне известно, сначала Вася тащит библиотеку под собой. Потом создаёт организацию и публикует под новым неймспейсом, а старый помечает как депрекейтед. Всяческие экстеншены либо остаются под своими именами, что тоже неплохо как по мне, либо создаётся форк в организации на тот случай, если автор оригинальной библиотеки забросит ее..
В общем, не вижу никакой проблемы. Зато если мне были интересны библиотеки одной организации (например Symfony), то в поиске было явно видно, кто владелец. Да и, если быть откровенным, npm и его пользователи движутся в том же направлении со своими @namespace/name
Могу ошибаться. Просто мнение. Все таки мейнтейнеры раста раньше очень ответственно проходили к подобным решениям (про сейчас не знаю, учитывая всю шумиху). Но всякие подобные ребята, как из статьи, ради экспериментов просто забивают хорошие имена, оставляя их просто висеть в качестве бесполезного мусора. Единственный плюс: авторы начинают придумывать достаточно креативные названия для библиотек
В общем, не вижу никакой проблемы.
(Значительных) действительно нет, но я не уверен, что все это дополнительные телодвижения того стоят. Опять же, в вырожденном случае, у нас будут организации под одну библиотеку. Плюс сразу возникает ряд вопросов начиная с того насколько "свободным" должна быть регистрация организаций. И как быть, если на момент существования (но до набора критической популярности) vasya/serde я создаю организацию serde.
Ещё можно рассмотреть ситуацию когда организация была создана, но автор библиотеку забросил, а права никому не передал. И у нас появляется форк в "левом" неймспейсе.
Зато если мне были интересны библиотеки одной организации (например Symfony), то в поиске было явно видно, кто владелец.
А зачем? Спрашиваю без подвоха. Сам вот как раз подумал, что если большие организации вроде гугла или майкрософта серьёзно возьмутся за раст, то через некоторое время в соответствующем неймспейсе будет миллион библиотек. Причём как актуальных, так и заброшенных, экспериментальных и т.д.
Кстати, посмотреть все крейты автора можно уже сейчас. И при желании под это можно использовать отдельных специальный аккаунт. В больших организациях, скорее всего, так и будет. Например: https://lib.rs/~aws-sdk-rust-ci
Да и, если быть откровенным, npm и его пользователи движутся в том же направлении со своими namespace/name
Хороший опыт надо перенимать, но я пока не убеждён, что этот подход действительно даёт какие-то заметные преимущества. Сейчас в расте используют префикс к имени крейта вместо неймспейса. Как по мне, особой разницы нет.
Все таки мейнтейнеры раста раньше очень ответственно проходили к подобным решениям
Было и есть несколько обсуждений, например вот: https://github.com/rust-lang/rfcs/pull/3243
Можно почитать аргументы. Думаю, что тщательно взвесить все за и против, а не спешить внедрять фичи — это и есть ответственный подход.
Но всякие подобные ребята, как из статьи, ради экспериментов просто забивают хорошие имена, оставляя их просто висеть в качестве бесполезного мусора
Скажу больше: есть люди/боты которые сквоттингом занимаются. Нет формального критерия по которому можно во всех случаях отличить хорошие намерения от плохих. Нейспейсы сделают ситуацию проще только для "солидных людей".
Если я ничего не путаю, то мусорныe крейты иногда удаляли. Так что если есть серьёзные намерения, но прям очень нужное имя занято (мусором), то варианты есть.
Ну гитхаб же как-то живёт с организациями и юзерами. Ровно как и докер. Да и библиотеку может автор забросить, и наличие или отсутствие неймспейса тут никак не решает. И тогда форк вообще будет иметь отдельное имя.
В общем, мое мнение -- это мое мнение. Субъективное, без достаточного исследования и мозгового штурма. Я варюсь в таком котле, где используются все три подхода (докер как гибридный). И подход Раста и Ноды мне нравится меньше всего.
Хотя не, есть подход ещё хуже: Гошный. Там вообще репозиторий целиком прописывается.
В целом, мне больше нечего сказать. Я -- разработчик со своим мнением. И, к сожалению, я не смог проникнуться минималистичным подходом с одним именем пакета, как и понять его преимущества. Разве что гуглить гораздо проще, имея на руках уникальный слаг. За ссылку спасибо. Попробую повкуривать в аргументы и может пойму что к чему
PS Спасибо тем, кто не минусует комменты и не сливает карму. Мне очень приятно, когда я могу просто пообщаться в комментах без риска быть захабренным
Если что, я не пытался агрессивно спорить и минусы не ставил. Более того: когда впервые услышал, про неймспейсы для библиотек, то идея мне понравилась (потому что "красивее и аккуратнее"), но над преимуществами задумался только когда почитал аргументы против. И пришёл к выводу, что заметных не вижу. Спор начался с того, что мол сейчас глобальная помойка. Пусть так, но скажем иметь 100 крейтов rand (или подобных очевидных имён) в разных неймспейсах вряд ли прям лучше. Да, сортировка по популярности спасёт, но всё равно. Но это мы уже повторяемся.
Аргумент "мне так нравится" имеет место быть и спорить с ним невозможно. Но хотелось бы поговорить об объективных преимуществах. Может я отказываюсь принимать аргументы, но пока увидел только одно: легко понять какой организации принадлежит крейты.
Закончу тем, что мне это вообще не кажется сильно важным. Если завтра в раст завезут неймспейсы для крейтов, то мне лично будет более-менее пофиг. Слегка расстроюсь только если их сделают "потому что в докере тоже есть", а не потому что они решают какие-то проблемы.
Но всякие подобные ребята, как из статьи, ради экспериментов просто забивают хорошие имена, оставляя их просто висеть в качестве бесполезного мусора
я изначально писал библиотеку, чтобы она могла кому-то понадобиться, а не потому, что я хотел поэкспериментировать).
Был не очень тактичен, извиняюсь. Я очень рад, что ты подошёл к этому более ответственно, чем большинство.
Я помню, когда изучал Ноду, был урок по публикации пакета. Видео посмотрело около 10к человек. Если даже учесть, что только десятая часть решила пойти по уроку, то в нпм появилось 1к hello world пакетов.
Сейчас Раст не на том уровне, где 1к учеников будет постить бесполезные крейты, но это только вопрос времени, если популярность языка будет расти.
Я без понятия, какую мораль из этого извлечь. Но подход докера мне нравится куда больше, где только определенные образы не имеют префикса. Тем не менее, кто я такой, чтобы указывать профессионалам, что делать)
Относительно недавно появился ещё cargo-release позволяющий в том числе и публикацию на crates.io. Интеграция с CI включена.
Набор советов:
Используй
cargo-msrvдля определения поддерживаемой версии RustЕсли пишешь типы матриц/тензоров, пожалуйста сделай общение по индексации (C-order, Fortran-order, Morton-order).
не совсем понял Ваш комментарий про общение по индексации, пользователь итак может получить элемент матрицы по индексу, или я чего-то не понял)
extern crate mematrica;
use mematrica::*;
fn main() {
let mut matrix_2x2 = Matrix2::new(1, 2, 3, 4);
assert_eq!(1, matrix_2x2[(0, 0)]);
// change element
matrix[(0, 0)] = 2;
assert_eq!(2, matrix_2x2[(0, 0)]);
}
Имелось в виду что-то вроде вот этого: Row- and column-major order. Однако причём тут "общение" я тоже не понял.
так у меня вроде бы также реализовано)
Опечатка. Подразумевалось слово обобщение.
У тебя не совсем так. Ты решил полагаться на подход через вектор векторов, который за простоту расплачивается низкой производительностью. У тебя данные могут хранится только в non-contiguous подобии Raw-major order.
У меня данные могут храниться?.. Вы что-то путаете. И я всё ещё не понимаю как Raw-major order становится обобщением по индексации.
А крейт и правда некузявый выше привели. Хранить матрицу 2х2 через три вектора ещё же додуматься надо было...
pub fn new(m11: T, m12: T, m21: T, m22: T) -> Matrix2<T> {
let e = vec![vec![m11, m12], vec![m21, m22]];
Matrix2 {
rows: 2,
columns: 2,
elems: e,
}
}// Трейт для типов индексации.
trait Idxn<const N: usize> {
fn flat_idx(indices: [usize;N], sizes: &[usize; N]) -> usize;
fn mult_idx(fidx: usize, sizes: &[usize; N]) -> [usize; N];
}
struct Matrix2<T, I>
where
T: /* ... */,
I: Idxn<2>,
{
dims: [usize; 2]
buf: Vec<T>,
}
// impls: ...У вас тоже ерунда.
Матрица 2x2 (не произвольного размера, и именно фиксированного!) может быть определена либо так:
struct Matrix2<T>
{
a: T,
b: T,
c: T,
d: T,
}Либо вот так:
struct Matrix2<T>
{
a: [T; 4],
}Тот, кто пишет хоть один Vec в подобном определении — профнепригоден заигрался с неуместной универсальностью.
"У вас тоже ерунда."
Это убеждение строится на предположениях о моих намерениях. Как вы отметили, мы реализуем разные концепты. У вас матрица 2x2, у автора (и у меня) динамически-размерная матрица NxM. И даже это не так важно так как единственной целью представленного кода была демонстрация того, что я подразумевал под обобщением по индексации. Я написал наименьший и самый простой код демонстрирующий именно эту идею.
Тот, кто пишет хоть один Vec в подобном определении —
профнепригодензаигрался с неуместной универсальностью.
Для цели демонстрации идеи, это более чем разумный выбор.
В идеале ещё обобщать по знанию размерности на этапе компиляции, аналогично тому как это делает ndarray из экосистемы Rust. Хотя я согласен, что это уже может становиться сложно.
Вопрос замусоренности cargo.io - это компромис.
С другой стороны, зачем вообще туда тестовые крейты публиковать, если практически все можно потестировать и даже нормально использовать через git-платформу какую-нибудь, а далее "адресовать" версии и тд через параметризацию зависимостей в toml: rev, branch, tag.
[dependencies]
the-MA = { git = "https://github.com/someguys/thelib", rev = "9f35b8e" }
the-Tri = { git = "https://github.com/someguys/thelib", branch = "dev" }
the-X = { git = "https://github.com/someguys/thelib", tag = "v1.2.3-alpha" }
Создание своей библиотеки на Rust: от cargo init до cargo publish