Pull to refresh
11
0
Максим @SabMakc

User

Send message

В Draw.io Integration есть очень интересная фича с редактированием файлов *.drawio.svg - получается SVG-файл (т.е. картинка/схема) для markdown-документа и drawio-файл для редактирования непосредственно в VSCode.

Все было хорошо и понятно, пока не дошли до мап. Стоит немного рассказать, что за эвакуация и зачем она нужна. И в контексте хеш-таблиц насколько вообще общепринят термин эвакуации? Обычно говорят о росте хеш-таблицы и о переносе ее элементов (как раз эвакуации).
И такой вопрос: в go рост таблицы асинхронен? Зачем хранить старый bucket, если рост при вставке элемента происходит синхронно для хеш-таблиц обычно?

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

Спасибо! Лично мне статья по ссылке показалась намного более целостной.

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

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

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

Я согласен, что тут туториал среднего уровня - быстро прочитал и в закладки (если надо, скорее всего, потом через поиск материал искаться будет). Но это справедливо только для людей "сильно в теме".
И на узкоспециализированном профильном ресурсе - я бы сказал "ОК, нет вопросов". Или для документации EDK II / Tianocore - отличная статья, спору нет.

Но в данном случае, для хабра... Не знаю, не знаю... Лично для меня, сработало введение - привлекло внимание, заставило пройти под кат... Интересно стало что за зверь такой "Orange Pi 5" и с чем его едят...
А внутри - просто инструкция "как установить EDK II" из множества консольных команд. Которые дают дают пример "как это сделать", но не дают понимания "что мы делаем" и "зачем мы это делаем".

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

На мой взгляд, статье сильно не хватает введения.

Нас заинтересовал первый образец серии 5/5B/5+, а именно Orange Pi 5, на предмет того, как на данном устройстве поведет себя EDK II и можно ли его использовать так, как мы привыкли работать с обычными ПК.

  • Кто такие "мы"? Статья в личном блоге, а не в корпоративном.

  • Что такое EDK II, зачем он нужен и какие проблемы решает?

  • Аналогично и с toolchain - начинаем установку с него, но для чего он нужен - непонятно.

И в конце-концов, так и не раскрыта тема - можно ли использовать Orange Pi 5 в роли обычного ПК, как мы привыкли работать с обычными ПК? Самый интересный вопрос на самом деле...

Я скорее к тому, что в ситуации "на все публичное надо писать доки" и "не нужны доки на тесты" есть очень простой выход - не делать тесты публичными классами.

И принцип не нарушается и доки на тесты не надо писать.

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

Отдельно хотелось бы отметить требование писать документацию на всё публичное – все публичные классы и методы. Это требование кажется логичным, если бы не одно “но”. Юнит-тесты тоже публичные, каждый тест публичный.

jUnit позволяет использовать package-private тестовые классы и методы (т.е. без модификатора доступа).

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

Compared with Linux containers, WasmEdge could be 100x faster at start-up and 20% faster at runtime.

A WasmEdge app could take 1/100 of the size of a similar Linux container app.

Заявления с сайта wasmedge. Впрочем, объективность подобных заявлений под большим вопросом. Ни примеров, ни методики измерения не указано.

Максимум - готов поверить, что такие приложения могут занимать значительно меньше места. Впрочем, образы на базе alpine тоже занимают значительно меньше места относительно прочих образов, так что и тут остается открытым вопрос - с чем и как сравнивали.

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

Лично я считаю - что определенные проблемы у Rust в плане сложности есть. Вы говорите - что не так все плохо. Должен сказать, что эти две позиции ни капли не противоречат друг другу.

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

По моему, мы уже N комментариев только и говорим, что о том как влияет навороченность языка на (не)очевидность кода. (:

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

Выше не стал спорить с этим утверждением, а вот сейчас не удержусь: мне JavaScript простым не кажется.

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

Лично мне в JS не нравится два фактора:

  • Динамическиая типизация - плохо работает IDE, много ошибок всплывает в рантайме (впрочем, тут спасет TypeScript).

    • Но TypeScript - это скорее C#, от JavaScript осталось очень мало.

  • Инфраструктура. Все очень быстро меняется, много кода низкого качества и сама по себе инфраструктура стала очень самобытной (тут TypeScript уже не спасает). Для изучения/погружения требуется очень много времени и сил, а знания очень быстро устаревают.

Для "быстро написать/переписать" раст уж точно не лучший выбор.

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

А я наоборот считаю, что чем больше проект, тем важнее становятся инструменты абстрагирования и сильная/навороченная типизация.

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

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

SQLx. Ну и я всё-таки считаю, что проверка запросов на этапе компиляции того стоит. Кстати, в ридми написано "Compile-time checked queries (if you want)".

Полезная фича, но сорцы начинают зависеть и от схемы в БД, и от используемой СУБД. Будь это чистой кодогенерацией: подключился к БД - нагенерил код - используешь. Я бы сказал - да, мега-фича (особенно если опционально). Но в режиме постоянного подключения - скорее вызывает неудобство. Это может быть удобно в случае, если ты один работаешь надо "домашним" проектом, не заморачиваясь ни версионностью БД, ни CI/CD, ни сборкой Docker-образов и т.д. Подправил БД - подправил запросы - работаешь дальше. А в командной разработке, особенно если БД активно развивается - лучше не надо.

Справедливости ради, на днях обнаружил, что у sqlx есть "Offline Mode" - можно выгрузить представление БД в виде JSON, и если DATABASE_URL в env не задано, то будет использоваться этот файл. Что позволяет успешно работать с проектом без постоянного подключения к БД. И в релизе 0.7 (который сейчас готовится) работа в Offline Mode становится приоритетным подходом, что, на мой взгляд, абсолютно оправдано.

Скажем, хаскель мне достаточно интересен и симпатичен, но я его толком не знаю.

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

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

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

А запутанный код можно писать и городя упоротые иерархии наследования и даже в процедурном стиле.

Запутанный код - это результат в первую очередь истории развития кода и навыков разработчика. Никогда не видел, чтобы специально писали запутанный код. Влияние именно языка тут достаточно вторично.

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

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

В части Rust преимущества может и перевешивают потенциальные проблемы. Но тут главный вопрос - для кого перевешивают?

  • Для опытного разработчика - да, перевешивают.

  • Для начинающего разработчика - нет.

  • Для соло-разработки - да, возможно.

  • Для командной разработки - сомневаюсь.

  • Для небольших проектов - да, перевешивают. Вообще, возможность "быстро переписать если что", может оправдать практически любые эксперименты.

  • Для больших проектов - опять же сомневаюсь, что перевешивают.

А если учесть, что опыт/размер команды/размер проекта - это независимые и недетерминированные факторы, то получаем трехмерное пространство оценки...

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

А во всех остальных случаях есть нюансы...

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

Хотя и не сказать, что эти ниши не пересекаются - например, в части написания микросервисов - что Rust, что Java (что куча других языков) чувствуют себя прекрасно.

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

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

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

Системных языков в целом не так уж и много. И безопасность кода (включая UB) - это типичная проблема именно C/C++, а не Java/C#.

Но да, в части системных языков, Rust - это серьезная альтернатива C/C++.

Тут забавная ситуация: не так уж редко слышно мнение в дуже "хочу раст, но более простой". Вплоть до того, что люди хотят раст со сборкой мусора просто из-за удобств вроде паттерн матчинга, карго и т.д. Меня это несколько удивляет.

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

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

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

Я никогда не топил за "тупой" код. Я топлю за читаемость кода. За легко-понимаемый код. Чтобы взглянул и сразу понял, что именно тут творится и как именно это работает. И у Rust-а, на мой взгляд, именно с читаемостью кода есть проблемы. В части "что именно творится" мешают макросы, а в части "как именно это работает" мешает вывод типов. Да, это очень гибкие и мощные инструменты. Но их гибкость и мешает пониманию кода.

То, что код на Rust выглядит достаточно просто (и компактно), не делает его легким для понимания. Да, с опытом и практикой, код станет легче читать и понимать. Но это никогда не станет достаточно простым делом, особенно при знакомстве с новым проектом.

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

Но опять же - это все ИМХО "с моей колокольни", а моя колокольня - это Java/Golang, а не C/C++. С точки зрения разработчика C/C++, Rust может выглядеть совсем по другому.

Information

Rating
Does not participate
Location
Россия
Registered
Activity