Комментарии 123
Добрый день, а на чем делали сам сайт? Самописный или какой-то движок готовый?
Айтинити, ядро Друпала + обвес, чтобы можно было нормально работать обычным людям и верстальщикам. Давнишняя история.
Спасибо, я уж грешным делом подумал что-то опенсорсное
Как по мне так ужасно не удобно справа листинг глав.
Просто он не сильно важен (внизу есть ссылки на следующую, предыдущую лекции), а если слева, то много на себя внимания берет. Если окно браузера сузить, то меню вообще сложится, чтобы никак не отвлекать от основного текста.
В том и дело, что как раз он и отвлекает. Уже как бы стандарт де-факто о расположение списка страниц слева. Какое бы online мануал не взять. Будь то pdf, документация на API или список классов к какой-нибудь библиотеки. Или даже список файлов в проекте хоть IDE хоть приложения типа CAD.
И еще, я бы при регистрации спрашивал бы только ник и почту. А опросник можно оставить на потом.
Мой опыт с растом на виндовс: Дальше установки не ушел :)))
1) не было для powershell сертификатов c доступом уровня "секюрити" для успешного окончания установки rust (версия виндовс - энтерпрайз 10)
2) после этого, в конце rust установка падал из за какого то "mvc" от новой "VSC"
на этом плюнул
А у меня наоборот всё как-то просто прошло, а до этого с питоном было больше телодвижений. Попробуйте ещё разок или на крайний случай в их песочнице можно с кодом поиграться (ссылка в какой-то из первых лекций есть).
А к нему докер образ не идёт случайно?
C сертификатами ни на Windows 10 Pro ни на 11 Pro проблем не испытывал. А зачем вы вообще powershell пользуетесь для этого? загрузили https://static.rust-lang.org/rustup/dist/i686-pc-windows-gnu/rustup-init.exe и запускаете из обычной командной строки
По хорошему, лучше иметь VS Studio установленным на машине - редакции Community будет вполне достаточно. Наверно можно какой-то отдельный маленький рантайм поставить - но я лично так не пробовал, у меня есть студия (и 2019 и 2022)
Там на самом деле от студии нужен только линкер. И ничто не мешает вместо тулчейна stable-x86_64-pc-windows-msvc поставить себе stable-x86_64-pc-windows-gnu (stable-gnu для краткости)
а меня установщик заставил скачивать вижуал студио плюс windows11sdk(не убрал галочку). Короче минус 10 гигов памяти
не понимаю почему люди минусуют за факты. Лучше бы шли на гитхаб и решали проблемы и зависимости с установщиком )
Эксперименты с Java/C# чет у меня такого дискомфорта не вызывали, там все плюс минус такое же имеется (ну иногда многословнее, а иногда и поудобнее).
Изучать я Rust однозначно буду и дальше. Но больна.
Начал читать, имея только шапочное знакомство с Rust - глаза зацепились за фрагмент в "Плюсы Rust", "... и без сборщика мусора" (как будто это что-то хорошее :) ). Тут вероятно было бы уместно упомнятуть "строгий контроль использования памяти, не опирающийся на сборщик мусора". В C++ нет сборщика мусора (кстати, часть языка, позволявшая интеграцию сборщика мусора, существовала некоторое время в стандарте - убрали), но нет и строго контроля, легко выстрелить в ногу. В D есть строгий контороль, но есть и сборщик мусора. В дизайне Rust сознательно отказались от сборщика мусора, что имеет далекоидущие последствия из-за более сложных мер по обеспечению строгого контроля.
Было бы классно иметь возможность скачать курс в виде PDF файла и читать офлайн в дороге и тд..
Идея интересная. Пока перед поездкой можно делать скриншот экрана, например, с помощью расширения для хрома fireshot. Все равно более одной темы за раз нет смысла загружать в память. И самое важное в обучении - это сразу кодить самому, пробовать, а что, если я по своему сделаю, ругнется ли компилятор?
Rust Book аболютно адекватен. Просто сам язык немного необычен. Он очень сильно заточен на борьбу с проблемами предыдущих поколений языков, и, если читатель не налетал многократно на все те грабли, вполне возможно, что ему такой фокус будет плохо заходить.
Ну а у тех, у кого ноги все сплошь в старых ранах от стрельбы по ногам в старые добрые времена (и все равно встречаются и свежие шрамы) - для таких это все просто музыка для ушей, и падает в подсознание очень легко.
Не спорю, адекватен, но для новичков не самый лучший старт. Глава вторая:
use std::io;
fn main() {
println!("Guess the number!");
println!("Please input your guess.");
let mut guess = String::new();
io::stdin()
.read_line(&mut guess)
.expect("Failed to read line");
println!("You guessed: {guess}");
}Тут сразу на новичка вываливается: использование библиотек, мутабельность, объект строки, заимствование, result.
Знания приносят страх.
Ну, тут от бэкграунда зависит. Те, кто хоть немного знаком c С++, или даже Java - ЭТОТ код сразу поймут даже без объяснений.
use std::io сразу ассоциируется с using namespace std; #include "<iostream>, к примеру, ну и так далее.
Вот попытка "слегка" это модифицировать - тут да, могут уже возникнуть вопросы. Но далее уже и объясняется по тексту, что и как.
Напротив, именно такой подход новичкам и нужен. Сначала даётся программа, потом объясняется каждая её строчка, со ссылками на будущие главы. Можно начать с готового примера и "играться" с ним — менять часть строк, смотреть что получилось...
Альтернативный подход, когда даётся 15 глав теории, без возможности опробовать это всё на практике пока не дочитаешь до конца, попросту глуп.
Вы описали две крайне противоположные ситуации. Истина где-то посередине. Нужно давать последовательную теоретическую базу одновременно закрепляя её практикой.
Не для любого языка это возможно.
Не соглашусь, этот подход предпочтителен не только к языкам программирования, а к любой отрасли знания. Так лучше изучается и математика и шитьё одежды.
Он может быть сколь угодно предпочтительным, но если язык требует чтобы код был написан в функции main — вам придётся либо начинать объяснять его с понятия функции (что странно), либо дать изучающему язык "заготовку" с этой функцией и обещанием вернуться к функциям позже.
У вас просто нет варианта "ничего не говорить про main".
Я может быть какой-то невероятный гений, но почему такие простые концепции как функция, переменная и даже, о ужас, указатель вызывают у людей хоть какие-то проблемы с пониманием? Чёт когда я учился программировать я понял суть секунды эдак за 4, а сложность всех проблем с этими вещами - она раскрылась уже позже с опытом и решаемыми задачами.
Вопрос-то не с пониманием функции, а с тем в каком порядке что рассказывать.
Да никак не рассказывать. Функция - понятно из математики за 5-й класс. Переменные - тем более. Просто провести аналогию и не упарываться по объяснениям пока не придёт время)
В математике функции возвращают значение. В программировании они что-то делают (особенно main). Тяжело тут аналогию провести, особенно просто…
Опять-таки, переменные в математике неизменяемые, а в программировании изменяемые придумали. И ведь этого не умолчать, не оставить на потом — это ж самые азы, если только вы не ФП рассказываете.
На Хабре есть статья про то, в какой последовательности читать растбук по главам:
Ну, мне например не нравится как там подается инфа о разбиении на модули.
Рассказ идёт с тех модулей, которые практически никому не нужны - которые внутри того же файла, не знаю как они точно называются.
А как происходит объявление и доступ к файлам модулей - почти вскользь. Реально полезная инфа может быть подчерпнута только из пары примеров кода про файловую иерархию в конце той главы или методом тыка.
И то придется дополнительно гуглить как раньше указывались пути к модулям и как сейчас.
Ну самое важное в модулях - это рассказать об областях видимости и что и как с этим делать. А где это лежит - это одна строчка объяснений, что можно mod { } заменить на mod "имя", и тогда все будет искаться в файле "имя". И все (по крайней мере, в актуальной версии Rust).
upd: я сейчас нагуглил растбук: и либо это другой растбук; либо, с того времени как я его смотрел раньше, эта часть значительно улучшилась.
Ваша реплика читается так: если человек не способен учиться на своих ошибках (иначе, откуда многочисленные самострелы?), то Rust легко попадёт ему в подсознание. Странное утверждение, мне кажется.
Мне кажется, наоборот, Rust надо учить одним из первых языков, пока человек не освоил алгоритмы. Иначе Rust вызывает недоумение, потому что не позволяет писать привычные алгоритмы без unsafe. Это лично для меня источник постоянного дискофорта. Никак не привыкну к идее, что простейшая биномиальная куча - это небезопасная структура данных.
Хм, а где в биноминальной куче нужен unsafe?
В той реализации, которую я знаю, использован replace
Но ведь replace — это безопасная функция?
Не знаю 🤷🏼♂️: внутри у неё unsafe.
Но снаружи-то unsafe нет!
То есть, если unsafe спрятать внутрь, то как бы и не считается?
Если он не нарушает языковых инвариантов — то да, для того его и придумывали как бы. Если это библиотечный код — два раза да. Если это стандартная библиотека — тем более.
То есть, если unsafe спрятать внутрь, то как бы и не считается?
Никого ведь не беспокоит, что где-то внутри условной JVM есть нативный код, который всякого натворить может?.. На джаве пишут принимая как факт, что сборка мусора работает корректно и всяких сишных UB не случится.
Мне кажется, что и ансейф надо примерно так же воспринимать. Разве что с поправкой, что авторы произвольных библиотек могут быть менее аккуратны, чем авторы самого языка и стандартной библиотеки.
В JVM можно без native реализовать большое разнообразие структур данных, в Rust без unsafe спектр возможного гораздо уже.
Совсем без native у вас прежде всего не получится JVM сделать. А выше в комментариях именно такого сорта жалоба — видите ли, mem::replace решили не интринсиком компилятора делать, а через unsafe реализовать посмели!
В проекте на условном Java можно весь native оставить на уровне JVM и принять политическое решение: для большей безопасности и переносимости, мы запрещаем код с native. В Java ME, если верно помню, вообще native не было.
В Rust для реализации многих структур данных (не для низкоуровневого доступа к железу, а именно для реализации структур данных) требуется unsafe. Более того, в таком unsafe коде часто требуется ручное управление памятью. И мы не можем принять политическое решение запретить такой код в проекте - это лишит нас эффективных структур данных.
Просто не надо кричать на каждом углу, что Rust даёт какие-то особенные гарантии безопасности. Тогда и претензий к Rust не будет.
Вы сейчас уже куда-то ушли, изначально тут обсуждалась реализация биноминальной кучи через mem::replace.
Так вот — вы согласны что это безопасный Rust, или всё ещё считаете реализацию mem::replace сложнее JVM?
В обсуждаемом коде mem::replaceиспользуется, чтобы изменить ссылку. В Java это обычное безопасное присваивание `x = y`.
Присваивание и в Rust делается через оператор =. Суть replace в том, что она ещё и возвращает старое значение.
Да, но в условном Java, можно написать: `old = x; x = new; return old` - всё вполне себе safe. В Rust приходится это делать unsafe операцией, которая нарушает гарантии на корректность операций с памятью.
Когда Rust дизайнили, никто не задумывался, что подобных конструкций в алгоритмах дочерта и больше, и что, наверное, семантика императивного языка не должна подразумевать, что подобные операции небезопасны?
Не, если кому-то нравится, то я ж не против. Но зачем всех пытаться убедить, что это хороший дизайн ЯП, что так и должно быть? Какой-то стокгольмский синдром...
Разумеется, когда Rust дизайнили — об этом подумали. Именно потому mem::replace находится в стандартной библиотеке.
Ха-ха! Вы забыли про sun.misc.Unsafe
Сложно забыть о том, о чём не знаешь. То есть, мне не нужно знать про этот Unsafe, чтобы писать всякие нетривиальные структурки данных на Java, а в Rust unsafe для таких структурок обязателен
Мне кажется, наоборот, Rust надо учить одним из первых языков, пока человек не освоил алгоритмы.
Это тоже спорно. (:
Ограничения раста проще понять вдоволь потоптавшись по граблям С или С++. Иначе может быть непонятно ради чего это всё.
Мало кто учил тот же Си, начав с Ассемблера, чтобы потоптаться по граблям Ассемблера, и понять, ради чего это всё. Проблема в том, что у опытного программиста возникают вопросы к выразительности Rust. Точно так же, как у программистов на Ассесблере возникли вопросы к Си. А новичок воспримет это всё как данность.
Rust - очень сложный для изучения и очень простой для использования язык. Связано это не с сложностью языка, а с тем, что под ковёр GC не заметаются множество понятий, которые требуют внимания от программистов. Освоив их и научившись в рамках этих понятий размышлять о коде, программист становится лучше. А компилятор ему в этом помогает, отлавливая мелкие отклонения в логике и ошибки.
В целом, стримы Jon Gjengset'а на ютубе - пока лучшее, что я видел. А Fault Lore (блог автора Rustonomicon'а) - самое жутко-прекрасное, что я читал.
Хочу заметить, что сложный для изучения не потому, что сложный, а потому, что мало кто уделяет внимания базовым вещам в обучении языка. Я приводил в статье ссылку на курс на educative.io, там всё достаточно просто изложено, почти на уровне обычных курсов по Питону.
Вы знаете, я несколько лет учу Раст, при весьма хорошем бэкграунде как в Си так и в Питоне, и я могу сказать, что Rust - очень сложный для изучения язык. При том, что есть иллюзия простоты (которая потом хорошо поддерживается компилятором для человека, который знает эту сложность), но попытка понять что такое place expression и кто является владельцем place expression начинает взрывать мозг по мере попыток думать об этом. Неявные заимствования, сравнение unsized значений, появление эфимерных ссылок в момент создания указателей...
Вы знаете, я несколько лет учу Раст, при весьма хорошем бэкграунде как в Си так и в Питоне
потерянные годы. зачем?
для абстрактных, но малоприменяемых знаний был же универ
Ну, я мог вместо изучения Rust'а пройти все части Ведьмака и Киберпанк. Это было бы засчитано за потерянные годы?
Rust - это отдушина здравого смысла и манифестация Касталии (из игры в биссер). Наконец-таки в индустрии кто-то что-то делает на совесть не срезая углы.
А ещё бонусом открывается возможность написать любую программу, которую хочешь. Даже если это рендеринг шрифтов в opengl в реальном времени 144 раза в секунду. Этой возможности мне очень сильно не хватает в питоне, где "нарисовать картинку" просто, а показать её на экране - big deal, с нюансами.
А ещё вдумчивое чтение документации по Расту открывает многие аспекты современных компьютеров. Например, если бы не Rust, я бы никогда не разобрался с linux memory model, потому что оно слишком странно написано; а в рамках примитивов Rust (окей, окей, С++ с фэнсервисом) - куда разумнее и лучше.
При этом копание в Rust не оставляет PTSD как, например, ходьба по сишным граблям с type aliasing.
Вот подмена понятий не нужна. Все написано на С, и если ты эту модель понимаешь, то понимаешь мир, иначе никакой язык тебя не спасет (ассемблер как второй вариант).
Раст это всего лишь реализация привязывания одной руки, чтобы ты второй не выстрелил в ногу.
Этакий черный квадрат Малевича. Идеал ничего.
У современного Си модель памяти соответствует С++.
Речь про https://en.cppreference.com/w/cpp/atomic/memory_order
Старинный "обычный" C никакого acquire/release не поддерживает.
Какой то странный дерейл.
С эмбедщиками пить не советую.
При чём тут эмбеддщики? Вы когда последний раз видели компьютер с одним процессором? Уже давно 2-4-6-8-12-24-32-48-64-128-256 ядер. И вот там-то модель памяти становится критически важной, потому что ошибка с режимом доступа к памяти приводит к фантастическим глюкам, включая прыжки в будущее (потому что спекулятивное исполнение).
А "sequential на всё" превращает ваш компьютер в тыкву по производительности.
Дерейл на какой то невиданный "режим доступа к памяти" и ирония в том, что раст то как раз "sequential на всё". Удачи.
я не зря упомянул эмбедщиков - они точно знают, какие у них операции атомарные, а какие - нет.
а это все из очередной попытки писать АБСОЛЮТНУЮ МАШИНУ абсолютно переносимый код
и да, про бэкграунд в питоне, лучше в приличном обществе не заикаться...
А что не так с абсолютно переносимым кодом и почему вдруг это недостаток?
да, я только что собрал виндовый бинарь из ровно того же сырца, как и линуксовый, и это было круто.
А про бэкграунд в питоне - why not? Есть жирнючие ценные проекты на нём написанные, которые нужно сопровождать. Если же учесть, что у меня основная работа вообще вокруг ансибла с testinfra строится, то что мне использовать, кроме питона? Писать модули на перле, маме на зло?
писать то можно, хвастаться не стоит =)
получается как в резюме писать про успешное окончание дет.сада
Моё резюме касается только меня и людей, которые мне будут деньги платить. Вы, вероятнее всего, считаете, что питон - это детский сад, и все благородные доны должны писать на coq (haskell, whatever). Но я подозреваю, что тщательно написанный на самом вами любимом языке программирования код окажется в большой неприятной заднице, потому что вендор железки, с которой вы хотите работать, срал на стандарты и обновления, и надо использовать netmiko, которую (увы, увы!) на coq никто не портировал. Либо лично изобретать тайминги слипов после отправки команд по устаревшей версии ssh, отсутствующей во всех современных ОС.
До Rust были языки, спроектированные "по науке". Поэтому высказывание "наконец-то" выглядит странным. Примеры: Haskell, ML, Scheme, Oberon, Algol и так далее.
Модель памяти Linux описана в терминах работы железа. Не очень понятно, что именно в этом описании "странно".
Ну, и, наконец, рендеринг шрифтов 144 раза в секунду на OpenGL от языка не зависит: шейдеры будут с одинаковой сокростью работать. От языка зависит сложность составлерия и загрузки этих шейдеров. Но, вроде, на Python это не сложно сделать. Не уверен, что сложнее, чем в Rust.
До Rust были языки, спроектированные "по науке". Поэтому высказывание "наконец-то" выглядит странным. Примеры: Haskell, ML, Scheme, Oberon, Algol и так далее.
И они всем практически мертвы, на практике не используются (еще Эйфелль). Экстраполяция очевидна
Эта наука учитывает модель вычислителя, не совсем соответствующую реальному компьютеру, что создаёт значительный оверхед (а то и глупости, типа i30 и u31 в OCaml).
Шрифты рендерятся в процессоре, а не в видеокарте, видеокарта их отображает.
И я очень хочу посмотреть как вы это будете делать на питоне без массивной коллекции so-файлов, выполняющих реальную работу.
Спасибо большое, что пишете про опечатки, я это ценю и сразу исправляю.
Очень даже не плохо) я не такой педант чтобы как-то критиковать ) вполне удобно, как обучение 50.50 , но вот как шпаргалка очень не плохо, добавил себе в закладки.
Оффтопик: картинка к статье нереалистичная. Корпус робота должен располагаться как минимум перпендикулярно земле, а не уклону, а вообще скорее даже быть наклоненным вперед, иначе камень его опрокинет и переедет.
Не имеет? Окей 😂
Зачем вы минусуете человека? Сделайте чертеж, приведите обоснование. И никогда нельзя быть на 100% уверенным что вы правы. А расположите робота перед камнем сверху (если вы таскали землю на тележке, то её можно было и толкать и тянуть) А что, если коэффициент трения действительно высокий, а что если там типа шестеренки на зубчатом механизме. А что, если... В общем можно продолжать и продолжать.
Во-первых, я его не минусовал. Когда я пришел писать ответ, минус у него был. А у меня плюс. Но к обоим этим событиям я не имею никакого отношения.
Во-вторых, задачу, конечно, можно решить с точки зрения механики, рассчитав необходимое соотношение масс робота и камня, а также коэффициент трения опоры, чтобы происходящее на картинке имело смысл. Но я этого делать не хочу. Мне достаточно того, что если бы я оказался на месте робота, то при попытке встать под таким углом, как он, мне оставалось бы лишь уповать, что камень сделан из поролона или подобного материала. Но без расчетов это всего лишь мое личное мнение.
Хорошо, что я ошибся. Просто хочу, чтобы все были чуть добрее.
Независимо от того, насколько сильны ваши руки, вам нужен центр масс справа от точки опоры чтобы компенсировать вращательный момент от камня.
Можно, конечно, и за сам камень держаться для равновесия — но тогда руки должны быть в другом положении.
А куда он денется и причём тут проскальзывание? Вращаться может любое тело, не являющееся материальной точкой.
Точка приложения усилий к камню на картинке видна так же хорошо как и наклон робота.
Вас послушать, так ни одна шестерня в автомобиле вращаться не может, потому что опирается на другие.
Можно, но так как изображено на картинке — не получится.
А причём тут вообще этот треугольник?
Каждая вершина треугольника зафиксирована (у нас же ничего не проскальзывает), рёбра жёсткие (робот крепкий, камень тоже не разваливается, точки опоры не разъезжаются). Система выглядит стабильной. Что тут не так?
Камень не "приклеен" к поверхности, поэтому вы нарисовали не треугольник — а трёхзвенную ломаную, которая случайно оказалось замкнутой. В следующий момент она разомкнётся.
Если принять, что на картинке запечатлен момент, когда камень катится с горы, и как раз начинает опрокидывать робота - тогда все ОК! :)
Не так страшен Rust, как его излагают