Комментарии 307
Переводчику — спасибо!
Но блин раст ночной а го трёхлетний....
Так ночным он был на момент начала портирования, в статье указано, что теперь нужный функционал в стейбле. По поводу трехлетнего голанга — самый свежий получил возможность отключения GC? Статья как раз про особенности работы с памятью и сборку мусора.
GOGC=off насколько я помню отключает сборку мусора в GO
Но ведь это отключение автоматической сборки, руками-то все-равно придется звать
runtime.GC()
Вопрос был про возможность отключить GC в Go. Я написал как это можно сделать. Причём тут "все равно звать руками"
Ну тоесть какбы причина озвучена — но решение для нее не особо искали.
Еслибы они отключили GC былобы ровнее (очевидно изза этих мыслей ошибся в чаще\реже)
Каменты к оригинальной статье правильные.
Пойнтеры в lru — оно конечно раст поможет, но memory fragmentation никуда не уйдёт; конкретно такое использование было пофикшено в го, но похоже очень хотелось раст.
jemalloc конечно спасает, посравнение с glibc, но и его можно загадить (особенно с lru на миллионы объектов) на активном долго живущем сервисе.
я видел телеком экип который по glibc не жил нормально, под jemalloc жил, но иногда становилось плохо. как только с хипа ушли — сразу все зажило как надо.
jemalloc же ныне не дефолтный аллокатор
Мне кажется у jemalloc всё очень неплохо с фрагментацией памяти. Наверное, можно придумать сценарий где он покажет себя плохо, но графики выше говорят сами за себя: вариант с увеличенным кэшем отвечает в среднем меньше чем за 20 микросекунд, тогда как изначальные графики показывают в 100-1000 раз худшие результаты.
Но спасибо что указали — на графице где раст и го не похоже что шкала логарифмическая и раст болтается в макс за 1секунду.
Увеличиваем в 8 раз кэш — и макс падает — ктото когото сильно дурит. В данном случает скорее всего при маленьком кэше были хождения в другой сервис\базу и суммарно это поднимало макс. Про кэше 8х стало существенно реже напрягать другой сервис и макс упал.
Круто — только avg на графике раст/го не особо различается. Еслибы поправили всплески GC — моглибы и не переписывать.
Расскажите, пожалуйста, почему появится memory fragmentation конкретно в этом сценарии, я тоже видел это в комментариях на hacker news, но не понял сценарий. Или просто из общих соображений, раз не GC, который компактит, то memory fragmentation?
Здесь не отключать gc нужно (это почти наверняка приведет к утечкам памяти), а использовать offheap-структуры данных, которые не находятся под управлением gc.
По поводу трехлетнего голанга — самый свежий получил возможность отключения GC?
Go умеет отключать сборщик мусора, ага. Используется для утилит, что запустили быстро отработали и целиком освободили память.
Имхо, по поводу версии ваш оппонент имел ввиду, что GC у Go время от времени совершенствуется. Правда последнее крупное изменение было более 3 лет назад.
в 1.11 ничего
1.12 — «Go 1.12 significantly improves the performance of sweeping when a large fraction of the heap remains live. This reduces allocation latency immediately following a garbage collection.»
в 1.13 ничего
Я так понял, что go спасли бы поколения в garbage collector. Они там появились?
Вот статься еще от твича blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i-learnt-to-stop-worrying-and-love-the-heap-26c2462549a2 не совсем про тоже — но суть в том, что GC latency spike можно серьезно убавить используюя sync.Pool, но есть риск что GC будет слишком часто вызываться — тогда та самая статья и кейс github.com/open-telemetry/opentelemetry-collector/pull/45
// The GC runs concurrently with mutator threads, is type accurate (aka precise), allows multiple
// GC thread to run in parallel. It is a concurrent mark and sweep that uses a write barrier. It is
// non-generational and non-compacting. Allocation is done using size segregated per P allocation
// areas to minimize fragmentation while eliminating locks in the common case.
Лучше бы они отказались от электрона в клиентском приложении.
В пользу нативных решений, например, Qt.
Я бы, скорее, подумал тогда о том, как прикрутить ReasonML к NodeGUI, если есть непреодолимое желание писать в функциональной парадигме (что, впрочем, можно делать и на typescript + fp-ts)
А что там с лицензиями? Вроде как были коммерческая + LGPL3, так и осталось уже несколько лет?
Лицензии не изменились. Основные изменения заключаются в том, что, во-первых, их фирменный инсталлер теперь будет всегда требовать аккаунт на qt.io (архивы с исходниками по-прежнему доступны без регистрации), а во-вторых, контора отказалась от концепции LTS-версий для community edition, то есть условно выходит 5.15, поддерживается полгода (выходят там, скажем, 5.15.1, 5.15.2), потом выходит 5.16, и бэкпортинг новых изменений в 5.15 бесплатно уже не производится, только за деньги.
Дело не в breaking changes, а в том, то в новых минорных версиях появляются всякие новые фичи, типа как новый scenegraph движок или поддержка aab в 5.14, которые могут быть, скажем так, не слишком стабильны, и одновременно в них выходят фиксы для багов, обнаруженных в предыдущих версиях. Смысл LTS версий был как раз в том, чтобы фиксить баги (через бэкпортинг патчей из более новых версий), не добавляя при этом потенциально нестабильные новые фичи.
Теперь смотрим, а что же у нас есть действительно кроссплатформенное? Браузер. Потому что он везде, и в него вложены охулиарды бабла. По сути, Electron (при всех его минусах и справедливой критике) открыл эру, когда те же линуксоиды могут получить приложение, с точки зрения UX не уступающее своим аналогам с винды/мака. Например, я знаю, что VSCode на всех платформах одинаково удобен и красив, а не где-то версия основная, а где-то китайская подделка. А когда всё пилилось нативно, пользователи осей с малой долей рынка либо не получали вообще нихрена, либо получали что-то глючное и сильно отстающее по темпам апдейтов (вспоминаем, например, ранний Скайп или историю с дровами nVidia). Потому что нет экономического смысла с ними возиться.
Насчет Qt. Он как бы кроссплатформенный, да не совсем. В нём нельзя добиться одинакового внешнего вида UI на всех платформах. Стандартное возражение — ну и не надо одинаковый, пусть на каждой платформе дизайн соответствует гайдам этой платформы! Звучит логично, но это тоже не выйдет. Qt рисует не настоящие нативные контролы, а имитирует их с переменным успехом — получается «эффект зловещей долины». Какие-нибудь нежные маководы проблюются.
Подытоживая: мне тоже не нравится прожорливость «электронных» приложений, но мне нравится кроссплатформенность и ради неё я готов докупить планку памяти.
В приложениях на электроне больше всего огорчает не использование памяти, а низкий fps, даже в достаточно простых приложениях.
ради неё я готов докупить планку памяти
И пользователям, которым порой приходится пользоваться вот этим вот, тоже?
Вы не так поняли. Electron ругают не за то, что элементы управления выглядят там плохо, а за сильную прожорливость. Никто не просит, чтобы контролы выглядели нативно. Вот посмотрите например на Telegram Desktop. Отлично работает на трёх платформах (но на моё субъективное мнение, код там ужасен).
Если выбирать между таким телеграмом и телеграмом на qt который ест 2 гига памяти и адски тормозит, то лучше уж то что есть.
Я не проснулся еще когда это писал, поэтому фигово сформулировал. Перед который — запятая, и предложение относится к первой части про "такой телеграм". Да, на трезвую голову выглядит очень странно, поэтому нужно такое вот длинное объяснение. Такой вот русский язык, сложный:
P.S. Да и вообще чем лучше знаю английский, тем сложнее писать на русском, несогласованные части речи, неправильные окончания… Просто беда какая-то
Телега — 650MiB. Еще и фон в беседе моргает периодически, после
перетаскивания между мониторами.
Все процессы электронного VSCode c компилятором TS в фоне — чуть больше 800MiB.
Даже WhatsApp — 400MiB, хотя он и лагает безобразно.
Хотя я сомневаюсь, что тут дело в Qt (скорее уверен в обратном).
Ну я, честно сказать, сам им не пользуюсь, не знаю, насколько он качественный. Но вот люди вроде как пишут, что в сравнении с дискордом (которым я тоже не пользуюсь) он выигрывает.
У меня телега всегда на порядок меньше, не знаю откуда у вас такие цифры
telegram-desktop попросту течёт. Уже несколько лет наблюдаю. Чем больше прогрузить чатов с мультимедийным содержимым (картинки, видео, стикеры) — тем быстрее. Может и больше натечь. Приходится садить в ограниченную по памяти контрольную группу или просто перезапускать. А на старте меньше 200 МБ ест.
Мы переехали на Zoom.
TS же денег просит за использование
Свободно качался с оф.сайта без регистрации.
Но это было порядка года назад. Как сейчас — не проверял.
Я как-то держал (точнее запускал) сервера для личных нужд как мамблы, так и TS.
Мамбла как-то попроще устроена (хотя и весит установленная в 2 раза больше, аж 30МБ).
P.S. TS последний раз запускал в феврале 2019 года судя по дате изменения файла ts3server.sqlitedb
Вот мой дискорд с кучей серверов. Да уж, разрыв просто кардинальный
Этот скриншот ни о чем не говорит. Может, дискорд только запущен, и он не успел сожрать память. Может, дискорд никто не трогал несколько часов, и он полностью свалился в своп. Числа на этой вкладке абсолютно бессмысленные.
Телеграм спокойно в фоне сидит с 70мб.
ms teams жрёт 200мб, хотя его вообще никто не трогает и в нём чатов активных нет.
Осмысленных претензий к дискорду на объем сжираемой памяти я тут тоже не увидел. За годы использования Дискорда я никогда не замечал, чтобы он покушался на память
Обычному пользователю этот оверхед побоку, судя по собранной статистике, хоть и небольшой, если ты геймер у тебя есть минимум 8, а в среднем 16гб памяти.
Так они и не являются целевой аудиторией Discord. Discord заточен именно под геймеров, там голосовые чаты с включением/выключением микрофона по глобальному хоткею, отображение запущенной сейчас игры и прочие плюшки.
А для слабых конфигураций есть сторонний Ripcord (пока что бесплатный, но автор собирается в будущем сделать его платным) и purple-discord.
нормальным функционалом
Два употреблённых в неправильном значении слова подряд — комбо! ;-)
Речь вообще не о функциях в первую очередь, а о целевой аудитории. И это не тот случай, когда целевая аудитория отличается от реальной: по наблюдениям, в основном им пользуются именно геймеры. Причём мне известны и исключения, например, чаты по патчам к Opera 12.15 и по yarn, но их мало.
Одно только но — обычно игру запускают вместе с войс чатом, а не вместо.
Есть две проблемы:
1) у дискорда есть чатик, в который можно постить видосики, картиночки, ссылочки с превьюшечками и прочую социальщину
2) сервер ТС более чем на 32 клиента стоит немало так денег, а Community License они выпилили года полтора назад, и как я понял из переписки с саппортом — возвращать не планируют.
Собственно, когда я плотно водил по сети — мы использовали тимспик для голосовой связи и телегу для чатов. Хотя, конечно, дискорд был бы удобнее, популярнее, хайповее.
За одним исключением. ТС «искаропки» позволяет записывать звук в файл. Для дискорда нативного и простого решения
Нативной записи звонков действительно нет
А маководы от электрона не блюют?
Или look-and-feel от макоси сам-собой получается?
Но ведь HTML с CSS не рисует нативные контролы. И возможности стилизации QML/QtQuick практически не уступают таковым у HTML с CSS. Эти две технологии действительно одинаковы в том, как рисуется GUI, в отличие от, к примеру, WinForms, который использует системные контролы.
Несколько стационарников с Win10 на борту, мобильник на 8-9 андроиде, макбук.
Всюду стоит скайп. Самое стабильное коммуникативное приложение из всех прочих (WhatsApp, Telegram, Slack). Самое не лагучее. Но самое жрущее память.
Однако бывали (и уверен, что будут) периоды «пмс» у скайпа — на ровном месте как начнет его корежить… Уже смирился с этим спорадическим поведением.
Само приходит, само же и уходит. Бывает несколько дней такого в среднем на квартал.
Чтобы узнать «что это такое» уже хочу в MS уходить… им же нужны тестировщики? :)
Вот не помню, какое на тот момент было приложение и чьего авторства?
10 мая 2011 года корпорация Microsoft приобрела компанию-разработчика программыВикипедия
Мессенджер, который не поддерживает хоть одну более-менее распространенную ось — гарантированно обречен на отторжение рынком.
Скажите это WhatsApp, у которого web-версия завязана на мобильном клиенте, ага.
с точки зрения UX не уступающее своим аналогам с винды/мака
За счёт ухудшения UX на винде/маке, ага. Когда виндузятникам вместо нативного Skype подсунули тормозную 8-ю версию на Electron — даже самые закоренелые его пользователи, для которых Skype — синоним звонков по компьютеру, начали плеваться.
Да и линуксоидам с этих жиробасин мало радости: вроде как есть, а пользоваться ими нереально. Уж проще под Wine запускать, тем более, в Wine Staging готовится поддержка тем GTK+3, так что и выглядеть будет нативно. Некоторые программы (сходу вспомню только AkelPad) осознанно не портируются на GNU/Linux, потому что и так хорошо работают под Wine. А с TeamViewer до 13-й версии Wine и вовсе поставляли в комплекте, пока не сделали наконец полностью нативный порт.
и ради неё я готов докупить планку памяти
Которая в современных ноутбуках нередко распаяна на плате; куда её ставить, даже при знании, желании и возможностях? Да и не всё в память упирается, важно также работоспособное аппаратное ускорение графики и даже наличие определёных процессорных инструкций, например.
Какие-нибудь нежные маководы проблюются
И от заведомо ненативных приложений проблюются. Так что кросс-платформенные решения следует рассматривать лишь как временные и по возможности пилить нативные, ничего не попишешь.
Скажите это WhatsApp, у которого web-версия завязана на мобильном клиенте, ага.Поддерживает же. Через костыль (который кстати не баг, а фича), но ведь поддерживает.
Но главное тут другое — посмотрите в каком году появился WA и в каком его конкуренты. Он фактически создал новую рыночную нишу. Ну и сегодня у него такая пользовательская база, что в отношении него правила работают уже немножко не так, как для остальных. Что дозволено Юпитеру…
Через костыль (который кстати не баг, а фича)
Благодаря этой «фиче» WhatsApp фактически недоступен для тех, кто использует только десктоп. То есть кроссплатформенность там весьма условная. Я даже не знаю, прокатит ли виртуалка/эмулятор с Android — для Viber прокатило, потому что там предусмотрена активация на планшетах без SIM. Зарегистрированные через yowsup учётки уже банят.
пользовательская база
У ICQ тоже была пользовательская база. Ну и где он теперь?
ICQ проспала мобильную революцию (это не считая ряда других косяков владельцев). Я ж не отрицаю — вполне возможно, что когда-нибудь в будущем новая звёзда скинет WA с пьедестала. Но это либо должна произойти ещё одна революция на рынке, либо Facebook совершит какие-то ну очень деструктивные шаги в развитии продукта. Пока что ни того, ни другого не предвидится и в нынешних условиях позиции WA выглядят устойчиво.
потому что сквозное end-to-end шифрование
Смысл которого в том, что переписка может расшифровываться только на одном устройстве. При этом таким устройством вполне может быть десктоп — секретные чаты в Telegram для macOS и telegram-purple тому пример. Но не в случае с WhatsApp...
ICQ проспала мобильную революцию
Jimm-то?
Но разница в том, что у телеги end-to-end только у секретных чатов (которыми мало кто и редко когда пользуется). А у вотса в таком режиме все чаты без исключения. Ну и они справедливо рассудили, что преимущественно сидящей на телефонах аудитории давать десктоп-клиент, который на самом деле будет полностью изолирован от телефонного аккаунта — смысла немного. Получатся два непересекающихся мира. А доля людей, которые хотели бы пользоваться только десктопом вообще без мобилы, видимо, исчезающе мала.
У телеги и вотса в этом смысле разные концепции просто, и нельзя однозначно сказать, какая лучше.
у телеги концепция лучше — как минимум — ты не зависишь от уровня заряда свой мобилки
но если я сижу около десктопа, значит у меня рядом есть электричество.
Или ноута. А я в дороге. И розетки нет. Или предлагаете телефон от ноута заряжать? Почему обязательно фиксироваться на десктопе? Я уж не говорю о том, что я устал от необходимости держать N+1 мессенджер на мобилке (Viber? Skype? Whatsapp? Telegram?) — там память ограничена, а все эти мессенджеры жрут заряд аккума и трафик
К сожалению, не ты это решаешь. Инерция ДРУГИХ людей сильно больше. И, предположим, это один из твоих ключевых клиентов использует мессенджер Х, а второй ключевой клиент мессенджер У. В случае вотсап проблема нерешаема, кроме как установкой мобильной версии (sic!), в то время, как с остальными — зачастую можно поставить только десктопную версию.
Это сомнительная фича. Во-первых, можно было сделать хотя бы как в Telegram — по варианту для каждого устройства. Во-вторых — а в протокол, которым веб-морда с клиентом на телефон общается, смотрели? Что там? В-третьих, хранение бэкапов в облаке в открытом виде сводит это e2e в ноль.
пользовательская база
У ICQ тоже была пользовательская база. Ну и где он теперь?
Ну дык
1) ICQ целенаправленно убивала свою пользовательскую базу годами
2) Тогда не было смартфона в каждом кармане, привязки аккаунта мессенджера к номеру телефона, привязки к обычной адресной книге. В WA так просто ID и пароль не забудешь — это уже другое поколение подхода к пользовательской базе.
Ну то есть прямая аналогия — не уместна.
Я ж не отрицаю — вполне возможно, что когда-нибудь в будущем новая звёзда скинет WA с пьедестала.
Среди вашей среды — он, наверное, и на пьедестале.
У меня — у окружающих полно других мессендежров, альтернативных.
В Китае с его огромной пользовательской базой — WA вообще не котируется.
Я бы не считал WA прямо-таки лидером.
Один из немногочисленных ведущих — да.
У меня — у окружающих полно других мессендежров, альтернативных.Это только кажется. Примерно как пользователям linux.org кажется, что в мире ну ппц сколько линуксоидов. В локальных группках — да, может быть много. Глобально — мало.
Так и с WA. Если взять широкую репрезентативную статистику (не только it-коллеги или друзья из одной группы интересов, а разные социальные слои, города, профессии, возрасты и так далее) — то оказывается WA таки лидер. Ну ок, за исключением Китая, там своя историческая специфика.
PS Если что, сам я не фанат WA, у меня другие предпочтения. Но если просто констатировать положение вещей, то вот как-то так.
В пользу чего угодно, что не браузер. Хуже, чем Электрон, нет ничего.
Полтора терабайта ОЗУ? Реально есть маки с 1536 GiB на бору?
У меня вот всего 32, это аж в 48 раз меньше.
www.apple.com/shop/buy-mac/mac-pro/tower
На жрущий хром все очень даже регулярно жалуются. И чёрт бы с ним хром один был, теперь хром свой персональный в каждом приложении. Разделения памяти под код, графику, кэши и прочее — ноль.
Свои фантазии про размеры оперативной памяти оставьте при себе, они не имеют ничего общего с реальностью, в которой существует 90% юзеров.
На рабочем компе у вас один корпоративный месенджер и одна среда разработки, причём железо явно топовое и свеженькое, как положено айтишникам. Разумеется, всё отлично работает. А вот простым смертным в домашних условиях приходится держать зоопарк мессенджеров, и если каждый отжирает несколько гигов, то это весьма ощущается.
И память — таки не единственная проблем электрона. Он банально тормознутый. Если взять какой-нибудь дискорд, то руки разрабам надо отрывать сразу, потому что обновления по полчаса каждый день при запуске — это надо постараться.
Если запустить голый хром без расширений и открыть в нём одну страничку, конечно, у вас будет 500 метров. Только если настроить десяток расширений, поработать несколько часов — эти 500 метров запросто превращаются в 5 гигов. У меня один GPU Process хрома жрёт под 2 гига запросто, если его не прибивать.
Игры в большинстве своём столько не жрут.
Зоопарк мессенджеров происходит по той простой причине, что всех согнать в один мессенджер нереально. Скайп — хром. Дискорд — хром. Слак — хром. Зулип — хром. Риот — хром. Вацап — хром. И это, мать их за ногу, только мессенджеры. А ещё есть редакторы кода, лаунчеры и прочий трэш.
Раньше была миранда. А теперь — изолированные инстансы хрома, жрущие все ресурсы на компе.
Игры в большинстве своём столько не жрут.
Я не про косынку же говорю, если открыть в стиме страницу с самыми популярными играми, то можно увидеть, что в большинстве своем они требуют от 8гб, и это минимальные требования.
Планочку, ага, а если слотов нет — старые продать.
Получи проблемы на ровном месте.
Плюс, в ноутах, например, память даже доставить — не совсем тривиально в большинстве случаев.
Ясно, что релизить с таким подходом проще, быстрее и дешевле, но пользователю от такого не легче.
Я обычный юзер, который пользуется зоопарком мессенджеров на домашнем компе. Моё фрилансерство добавляет только слак, во всех остальных обитает обычный народ, с которым я общаюсь: кто-то до сих пор торчит в скайпе, сообщество РуСО сбежало на зулип, фурри массово мигрировали в телегу, параноики скрываются в риоте, вацапом пользуется родня, а я сижу и мучаюсь со всем этим безобразием. И если на часть приложений можно забить и просто запустить в браузере или полагаться на уведомления с мобилки, то для некоторых критична интеграция с системой.
В результате "кросс-платформенные" "приложения", вроде как, есть, но мне приходится всячески их избегать. Смысл в хромовой обёртке теряется.
Я не про косынку же говорю, если открыть в стиме страницу с самыми популярными играми, то можно увидеть, что в большинстве своем они требуют от 8гб, и это минимальные требования.
Игры вполне справедливо полагают, что они единственные в системе, а не запущены в пяти экземплярах. Минимальные требования также учитывают прожорливость оси. Десятка, запущенная на 4 гигах рамы, игре банально не оставит места. Так что в требованиях хоть и пишут про 8 гигов, на деле игры жрут 2-4, редко больше.
Я, наверно, — невероятно асоциальный и некоммуникабельный тип, ибо у меня на пк только дискорд и телега.
Насчет игр, я же написал, что это — минимальные требования, для маскималок — 16+ пжалста, т.е. все-таки играм нужно столько памяти
Ну я изначально сказал родственникам "вот телеграм, либо заходите, либо не заходите, но тогда не обижайтесь". Почти все в итоге перешли. Конечно, кроме кнута есть и пряник — я помогал установить, показывал как пользоваться стикерами и т.п. Осталось только самое старшее поколение, но им телефон удобнее в любом случае.
Не пользовался им, только слышал.
Полагаю, есть некий минимальный уровень комфорта для подобного перехода.
Но это было более 7 лет назад.
Я бы тоже рад не слышать ни про зулип, ни про риот, но знакомые у меня такие вот странные. В конечном счёте и то, и другое возникло из-за того, что большинство мессенджеров требует сообщать телефон, странно модерирует контент и прочее.
Если бы открытые поделки были качественные, ещё куда ни шло. Но там даже хромовость не первым пунктом в списке проблем. Одна боль.
Раньше была миранда. А теперь —
И это у меня ещё далеко не все модули стоят ;-)
Официальные клиенты запускаю лишь ради недостающей функциональности: звонков, цитат, редактирования и т.д. А висеть онлайн этого хватает с головой.
А бывает и наоборот. skype4pidgin умеет отправлять форматированный текст и сообщения о смене статуса с произвольным содержимым. В официальных клиентах такого нет.
Глянул Pidgin. Половина плагинов в состоянии "вот инструкция на 10 страниц, как собрать плагин из сорцов". Ох.
Окей, я посижу много часов, собирая всё это безобразие, потом столько же убью на настройку. А обновлять как? Следить за каждым репозиторием и пересобирать всё по новой при каждом чихе?
Да ну в баню.
А обновлять как?
А зачем? Они и так работают. Требующие исправления поломки совместимости на моей памяти только у скайпа раз были.
Да и собирать их, как правило, несложно: плагины маленькие, кучу зависимостей и замудрённые системы сборки не используют. А обновлять — и подавно: git pull && make && sudo make install. У меня знакомый владелец Minetest-сервера моды для него так же обновляет, прямо из Git-репозиториев — не жалуется.
Ручное заполнение атрибутов пакета как раз сильно осложнит обновление. Оверкилл ради одной .so-шки, которая закидывается в /usr/lib/pidgin/. А если готовую .so-шку скачаете — тоже опакечивать её будете?
Просто в дебиане с опакечиванием сложно. В более молодежных системах это делается в пол строчки. Как по мне в любом случае лучше знать что откуда в системе берется, иначе будет помойка как раньше в винде.
Ну дык главное, что пользователь знает. А от помойки ПМ не спасут. /home, например, они обычно не контролируют, а там бардак лютейший. А кто контролируют — те изолируют хомяки приложений друг от друга, превращая GNU/Linux в подобие огороженного (и поэтому неудобного) Android.
Да не особо-то Андроид и огорожен....
А что не удобного в андроид подходе? там как раз доступ к фс почти не разделяется, одно правило для internal storage и все на сколько я помню.
Ну а в /home беспорядок потому что приложения пишут куда попало. Хотя и там часть файлов под контролем пакетных менеджеров типа npm.
По поводу "пользователь знает" — я довольно быстро забываю что я как настроил.
там как раз доступ к фс почти не разделяется
К общей — да. А вот в данные самих приложений лезть нельзя: https://source.android.com/security/app-sandbox
Хотя и там часть файлов под контролем пакетных менеджеров типа npm
Пакеты от недистрибутивных пакетных менеждеров — это только часть огромной помойки в хомяке. Самый цимес, когда один и тот же пакет может стоять и из системного ПМ, и из ПМ для ЯП.
я довольно быстро забываю что я как настроил
Полезете перенастраивать в следующий раз — вспомните ;-)
Ну и не надо лезть в данные приложений в этом и смысл :)
Почему? /usr/share на GNU/Linux открыт на чтение всем, не говоря уж о хомяке. При подходе Android же ресурсы — это часть приложения и закрыты от других приложений.
То есть продвигается программоцентричный подход вместо документоцентричного, и отделение программ от данных, как на машинах с гарвардской архитектурой — при том, что Android работает только на устройствах с фон-неймановской архитектурой. При документоцентричном подходе пользователь волен работать с файлами любой программой, без явно предусмотренных механизмов экспорта и прочих мостов взаимодействия между программами (которые проприетарщики заинтересованы не реализовывать).
Далеко ходить не надо, взять хоть банальные логи чатов в мессенджерах. В десктопных версиях они открыто лежат в ФС, можно читать чем угодно. На Android их можно достать лишь из-под рута, встроенный экспорт есть не везде.
И правильно, потому что мне не нужно чтобы кто попало читал логи чатов. Если надо будет я сделаю отдельную политику для этого. Сейчас в линуксе хомяк на чтение всем доступен и это дырища в безопасности. Хотя например те же логи других программ каждый в своей поддиректории /var/log/foo с соответствующими правами.
я сделаю отдельную политику
Но для этого, опять же, нужны права админа. С которыми и так можно что угодно.
Беда ведь в том, что чем выше безопасность — тем хуже UX. Есть случаи, когда параноидальная безопасность оправдана, но пихать её во все щели, как делают всякие UAC, WDDM, XDG-порталы, файрволы, разного рода песочницы, требующие HTTPS для всего подряд браузеры — перебор. Траблшутинг, опять же, усложняется, ведь проблемы могут возникать на пустом месте банально из-за того, что очередная заглушка по умолчанию не пускает, а не потому что реально что-то сломалось.
И как такой приложениецентричный подход вообще совместим с юниксвеем? Вы предлагаете для каждой мелкой комбинируемой исполняемой утилиты типа grep/hd/sort/git/etc. отдельно назначать юзера, группу и права доступа? На Android их и не существует вне рутового шелла в качестве first-class citizen, максимум внутри приложений вида «Терминал», которые берут все права доступа на себя.
Все правильно говорите. Но всякие комбинируемые исполняемые утилиты должны наследовать контекст и права от вызывающей их стороны. Кстати, эту проблему решает setuid флаг, когда необходимо повышение привилегий.
А как здесь поможет setuid? Назначать с ним владельцем утилиты рута — огромная дыра в безопасности, нивелирующая всю эту изоляция. Назначать владельцем отдельного юзера для этой программы — не решит проблему доступа, а ещё больше усугубит. Назначать владельцем пользовательского юзера (извините за тавтологию :)) — всё равно не даст доступа к данным других приложениях.
Ну, мы просто смотрим на проблему с разных сторон. Не вижу смысла спорить )
Назначать владельцем отдельного юзера для этой программы — не решит проблему доступа, а ещё больше усугубит.
не владельцем на файловой системе (очевидно), а правильно наследовать права в рамках дерева процессов.
Назначать с ним владельцем утилиты рута — огромная дыра в безопасности, нивелирующая всю эту изоляция.
В каком-то смысле — да, дыра. Любое повышение привилегий (в особенности — сделанное не очень правильно) — потенциальная дыра
Каждое крупное приложение в своем контейнере крутится, и при надобности имеет доступ к утилитам и файлам. Если какая то утилита типа grep то к ней можно дать доступ почти всем приложениям.
Ну и вообще как только я выхожу из терминала в мир гуи юникс вэй заканчивается.
Более того если сделать умный файл менеджер то он тоже может по песочнице делать для каждого контекста. Например чтобы открывалось два офиса один для папки Downloads а другой для TopSecret.
Какой именно UX усложняется?
Каждое крупное приложение
Крупные приложения сами по себе противоречат юниксвею.
Ну и вообще как только я выхожу из терминала в мир гуи юникс вэй заканчивается.
В Plan 9 умудрились даже GUI реализовать по заветам юниксвея. Даже, внезапно, на Win32 он прижился в части модульности и разделения ответственности — привет COM и ActiveX. Нередки случаи, когда в офисных документах какие-то элементы отрисовываются через другие приложения. Браузерные плагины (ActiveX/NPAPI/PPAPI) работали по тому же принципу — но их закапывают… Даже банальные и широкораспространённые буфер обмена и drag-n-drop можно считать грубой заменой пайпам.
один для папки Downloads а другой для TopSecret
Не разумнее ли TopSecret держать в отдельной виртуалке, а в идеале на отдельной физической машине без прямого выхода в Интернет? Зачем полумеры, и тем более зачем распространять песочницу на остальное?
Какой именно UX усложняется?
Необходимость пользователю воевать с этими ограничениями. Там разрешение дай, там проверь, не заблочил ли опять чего файрвол, там проброс добавь… утомительно. А если толковых способов обойти ограничения вообще не предусмотрено (привет проверке цифровой подписи системных файлов на Series 40 и на новых виндах), то ещё хуже.
Вспоминается недавняя статья про кубеос https://habr.com/ru/post/488234/
Виртуалка это еще одна полноценная ОС которая будет жрать ресурсы. Не говоря уже об отдельной физической машине. Зачем она нужна если можно решить правами доступа к фс? Почему-то вас бросает из крайности в крайность. Я же не говорю про каких то шпионов и гос тайнах там где отдельная машина за семью замками без доступа в интернет. Если бы браузеры не изолировали бы сайты в песочницу (хотя по сути это те же приложения только на веб платформе) то было бы все печально. Так почему таки же стратегии не применяются к приложениям на нативной платформе?
Потому что уже есть стопицот программ, которые плевать хотели на бест пректисы опесочивания средствами операционной системы. Не говоря уже о том, что в модели рисков есть уязвимости самого ядра ос. На минуточку — сколько там сейчас kloc кода в ядрах винды и линукса с учётом всех драйверов?
Я уж не говорю, что модель доступа приложения как в андроид очень грубая и по сути ни от чего не защищает, тем более, что многие приложения "на всякий случай" запрашивают привилегий больше, чем надо. А более точечная модель — сам пользователь не следит с ее настройкой и аудитом "что же это поменялось в Н+1 версии скупа, что он стал требовать новые пермишшены".
Что остаётся? Как истинным революционерам разрушить весь мир и построить все нуля. Или засунуть все в полноценные виртуалки, но огромной ценой вычресурсов
"на всякий случай" запрашивают привилегий больше
Это должно решатся заглушками, в андроиде к сожалению такого нету. Хотя некая модерация гугла по привилегиям есть.
Так и в ядре могут быть и в виртуалке уязвимости, от этого не спасешься. Больше слоев может помочь. А какие то кривые приложения использовать не обязательно, или уже для них специально виртуалка. Текущие решения на десктопной винде и линукс слабые (про мак не знаю). А вот серверный линукс почему то настроен более менее в плане разделений привилегий.
Хотя некая модерация гугла по привилегиям есть.
Да, есть маленькая, но надежда на магазины приложений — что в них не будут попадать по крайней мере откровенные вредоносы.
Больше слоев может помочь.
Нет. Больше слоев в первую очередь создают иллюзию защищенности. Усложняют аудит. И понимание происходящих процессов. Чем проще софт — тем лучше.
Зачем она нужна если можно решить правами доступа к фс?
Права доступа не спасут от уязвимостей и «технологических отверстий» в прочих местах.
Я же не говорю про каких то шпионов и гос тайнах там где отдельная машина за семью замками без доступа в интернет
То есть простым смертным такой уровень защиты ни к чему, понятно — максимум замок на двери для виду.
Если бы браузеры не изолировали бы сайты в песочницу (хотя по сути это те же приложения только на веб платформе) то было бы все печально
Ну ведь так и было: дырявые плагины, а уж ActiveX...
Ну ведь так и было: дырявые плагины, а уж ActiveX...
Но это не значит что надо и дальше так делать
Но ведь или так, или никак. Видео произвольных форматов браузеры, помимо WebKit'ных, нативно воспроизводить не умеют, например. Не говоря уж о встраивании более экзотического содержимого типа 3D-моделек. По факту — приходится портировать всё на браузерные технологии, с заведомой потерей производительности, а местами и возможностей; с системой же интегрироваться через локальные web-сервера или расширения-мосты, что тоже далеко не высокопроизводительное решение по сравнению с вызовами нативных библиотек.
А каким макаром там WhatsApp? Это ж официально запрещено.
Так он и не работает: пару дней поработал и перестал. До сих пор не знаю: то ли забанили, то ли попросту совпало с прекращением поддержки клиента для S40, которым этот плагин прикидывается.
Но вообще, охотятся вроде только за заменами первичному (мобильному) клиенту, а на обёртки к web-версии сквозь пальцы смотрят. mautrix-whatsapp и go-whatsapp вон, например, куча народу использует — о прецедентах банов пока слышно не было. А вот созданные через yowsup учётки банят.
А, видимо таки прекращение поддержки :) В libpurple очень много всякого такого, что "когда-то работало", баги у них годами висят...
Но вообще, охотятся вроде только за заменами первичному (мобильному) клиенту, а на обёртки к web-версии сквозь пальцы смотрят. mautrix-whatsapp и go-whatsapp вон, например, куча народу использует — о прецедентах банов пока слышно не было.
Звучит обнадеживающе, но что, если это просто эффект неуловимого Джо? В смысле, пока их вот таких мало, на них забивают, станет больше — начнут банить? Мне лично куда интереснее был бы вариант гейта / плагина в другом мессенджере, чем замена мобильному официальному, да.
В libpurple очень много всякого такого, что "когда-то работало"
Ну со встроенными протоколами отдельная песня, они просто тащатся ещё с 00-х и не выкидываются. При том, что года два назад друг за другом сразу три мессенджера отключились (AIM, Yahoo! IM и ICQ через OSCAR). Но последний релиз Pidgin и libpurple как раз в начале 2018-го и был. Просто потому, что разработка медленная, не всему же каждый месяц релизиться, как Chrome ;-)
пока их вот таких мало
Ну yowsup тоже не шибко распространён был. Впрочем, его могли задействовать спамеры, потому в Facebook и ополчились. А обёртки для web-версии для спамеров бесполезны: всё равно нужен парк эмуляторов Android, проще туда автокликер и всунуть.
Просто потому, что разработка медленная, не всему же каждый месяц релизиться, как Chrome ;-)
Да, но "не фиксить баги по 2 года" — всё ж чуть другое...
Впрочем, его могли задействовать спамеры, потому в Facebook и ополчились
Хороший вопрос о статистике тогда — какие еще версии банились.
6 лет назад многим проектам Cease & Desist прилетел. Баны начались позже, на останках пепелища (в основном за использование WhatsApp+ для Android).
Раньше была миранда.
Если что, в ночных сборках у нас уже есть WhatsApp и Telegram. В очень зачаточном состоянии (например, вацап умеет читать, но не умеет писать), но на то они и ночные сборки.
Был и Discord, но сплыл, когда нам недвусмысленно намекнули, забанив аккаунты, что платформа не приветствует изучение протокола для написания сторонних клиентов.
А чего сразу браузеры-то? HTA был вполне приличным, только кроме винды нигде не работал. Приложения на XUL+Gecko тоже довольно скромные в плане прожорливости, и выглядят нативно. Electron попросту наследует прожорливость Chromium.
на винде есть winapi :)
В пользу Rust'а, чего же ещё?! :)
UPD: интересно, для того же Rust+WASM есть что-то десктопное, но безбрауерное?!...
Есть. Но увы, как и всё, относящееся к Rust, разрабатывается крайне медленно.
Я вот всё, облизываясь, поглядываю на Azul.
Не стоит на него облизываться, совершенно мертворожденный проект автора, который все зависимости старательно копипастит к себе, из-за чего возникают идиотские ошибки, а поведение автора схоже с таковым у Николая Кима — вместо решения проблемы она заметается под ковер, и чинятся симптомы вместо болезни.
Например, могли бы отказаться от Electron в пользу AvaloniaUI. Почему бы и нет! Там есть и реактивные расширения, и поддержка шаблона Model View Update, если кто-то вдруг не любит объектно-ориентированный код.
ru.wikipedia.org/wiki/Chromium_Embedded_Framework
А занимается этим целый сеньер. И так гордится этой востребованной фичей, что указал аж в своем резюме на линкедине.
https://www.linkedin.com/in/emmett-coakley-12045323/
https://leonardo.osnova.io/e082d850-0428-d379-f7de-9951c6737afb/-/scale_crop/800x310/center/
Полагаю, что им легче написать одно решение для всех платформ (не заморачиваясь о производительности на стороне клиента, конечно же), чем отдельно для DirectX, для QT и для каждой из мобильных платформ.
Но ведь основную часть игры-то все равно же придётся для каждой платформы писать!
Плюс от cef в том, что интерфейс могут быстро править дизайнеры/фронтендеры, это морока огромная все напрямую в directx править каждый раз, когда дизайн меняется
При том игрок эту менюшку (в сингле) видит 2 раза за игровой сеанс: когда запускаешь игру и когда выключаешь. В самой игре интерфейс не вебовский и не тормозит.
А оценка такая низкая из-за того, что изначально обещали много больше, чем реализовали (новые катсцены, переделка сюжета, etc). Так что аргумент про веб-интерфейс вообще с оценкой не связан)
При том игрок эту менюшку (в сингле) видит 2 раза за игровой сеанс: когда запускаешь игру и когда выключаешь.
Я, например, менюшку просто не вижу, она у меня не отрисовывается :(
Да, и это официально худший релиз игры по версии metacritic...
Game is released, still very low fps at main menu screen… They fixed nothing about main menu lag and the chat panel is so laggy I cant use it. Never buying Blizzard games again.www.reddit.com/r/warcraft3/comments/dpgzw0/reforged_very_unplayable
Ну ну, используйте CEF и дальше
Зато дискорд при каждом запуске обновляется по полчаса. И интерфейс долбанутый. Личка и чаты в отдельных подпространствах. За невозможность отобразить названия серверов — хочется взять и уе. Опции отправлять по Ctrl+Enter нет до сих пор.
Очень люблю раст, но не могу не согласиться. В последний раз когда я пробовал запустить дискорд, мне десктопное приложение предложило погадать капчи: сначала найди все автобусы, потом пешеходные переходы, потом мотоциклы, потом светофоры. А потом такой "ну упс ты не слишком хорош".
Просто, потратил 20 минут на то чтобы зайти в приложение, чтобы оно сказало "вы подозрительный, фиг вам а не наш богоподобный мессенджер".
Это просто отвратительно.
Мне кажется, что Read States — это все же не служба чтения состояний, а служба статусов сообщений. И спасибо за перевод, интересно было почитать.
P.S. Что интересно, например, браузеры PaleMoon, FireFox запускаются из бинарных архивов даже не требуя установки (например при использовании загрузочного LiveCD) в указанных выше системах.
Что я делаю не так? (может кто знает :)
Вопрос к знающим: а если бы они эту свою службу на Эрланге написали, например? Он вроде как придуман для быстрых и мелких штук. Или с появлением Го и Раста нет смысла что-то писать на Эрланге?
Эрланг работает под VM с GC, что, на мой взгляд, еще печальнее Го.
Думаю что результат был бы сравним или хуже Гошного.
Насчет писать на нем — лично для меня его код всегда был чем-то инопланетным :)
увеличили объём кэша до 8 миллионов состояний Read State.
Кстати, не так уж это и много. 8 миллионов объектов по 100 байт каждый даже (что уже многовато для такой простой структурки), — это всего лишь 800 мегабайт, что далеко не так страшно.
Зависит от того как память выделяется, используется, фрагментируется. В результате эти 800Мб могут на деле занимать в 2-4 раза больше.
Хороший пример — DNS кеш — много мелких объектов. У меня был как-то Unbound нагруженный, который при настройке предельного размера кеша в 5Гб кушал в реальности около 10Гб.
Не совсем. Т.к. у каждого актора свой memory space, то сборку мусора намного легче сделать инкрементальной, без глобального stop the world, т.к. достаточно собирать мусор в рамках отдельных акторов (а это пара килобайт). В итоге, я так предполагаю, у Erlang'а в теории не должно быть spike'ов как на графике с Go.
Кэш состояний в принипе можно как-то шардировать на акторы…
Покопавшись в исходном коде Go, мы узнали, что Go принудительно запускает сборку мусора минимум каждые две минуты. Независимо от размера кучи, если GC не запускался две минуты, Go принудительно его запустит.
Шел 2020 год. А в модном языке Go GC работает как в lua 5.0 который был релизнут в 2003, а уже в 2006 появился новый релиз без этой фигни. Про java я вообще пожалуй промолчу.
www.youtube.com/watch?v=wGizKsOJQuE
Судя по популярности Go, у них нет никаких проблем. Я не нашел никаких планов по улучшению GC, ни в 1.15, ни в пропозалах для 2.0
В прошлых версиях поищите.
Были идеи — их реализовали уже, часть проблем снялась.
Новых идей, значит, пока нет.
В Go существенная часть аллокаций происходит на стеке, оттого ему не так критично иметь навороченный GC.
Проблемы стильных/модных/молодёжных языков решаются использованием С (без всяких там плюсов и решёток)
Помню я эту эпоху, когда все писалось на С.
Когда диалоговые окна «Segmentation Fault» уже даже не удивляли.
С переходом на С получаем крайне медленную и дорогую отладку, если речь не о «Hello, world».
Вроде только с расширениями, например вот https://gcc.godbolt.org/z/8_907h, для msvc будет по-другому.
Кстати, в случае с++ тоже есть нюанс, который иногда стоит иметь ввиду. Обычный static const int foo = 1 — попадет в .rdata секцию, и будет реально защищена на запись, а динамическия = foo() — работает через тот же механизм, что и си с расширением, и попадет в .data без защиты.
clang/gcc должно быть одинаково, он его должен понять. Вот msvc отличается, будет как-то так:
void __cdecl __inittime(void);
typedef void (__cdecl *_PVFV)(void);
#pragma section(".CRT$XIC_CLOCK", long, read)
#define _CRTALLOC(x) __declspec(allocate(x))
_CRTALLOC(".CRT$XIC_CLOCK") static _PVFV p_init_time = __inittime;
static unsigned __int64 start_tics;
void __cdecl __inittime()
{
#ifdef NO_HRES_CLOCK
GetSystemTimeAsFileTime((FILETIME *)&start_tics);
#else
start_tics = __g_rdtsc_timer.GetCounter();
#endif
}".CRT$XIC_CLOCK" — .CRT это чтобы он разместил этот указатель там где надо, рантайм до main() будет всю эту область проходить как массив указателей на конструкторы. Строка после $ нужна только для сортировки, если какой-то конструктор надо исполнить до другого.
Детектить достаточно саму студию по _MSC_VER, так что clang/gcc/msvc поддержать не сложно. Этот механизм наиболее правильный, т.к. он для их рантаймов стандартный для глобальных конструкторов, но на си выглядит, конечно, не красиво (для c++ тоже ровно он и используется).
Так вот, после прохождения tour.golang.org/welcome/1 я уже мог что то писать. Оно компилировалось и работало. А если не работало — то компилятор говорил что не так. Язык примитивный и все ограничивалось банальной правкой типов и т.д.
И вот я день прот… хался с Rust. Это ад какой-то. Да, Hello World с божей помощь скомпилировался. Дай думаю забабахаю простенький ендпоинт который будет принимать айдишник и брать доку с монги. Ошибки компилятора — напомнили с++ где читаешь ошибки и хрен знаешь как ее чинить… Столько всего нужно писать — макросы, импорты, неймспейсы… потом конфликты библиотек прилетели…
В интернете нет ни одного нормально рабочего примера. Могу ошибаться, но как я понял язык настолько быстро ломает свои контракты что большинство информации просто устаревает слишком быстро. А разработчики библиотек не успевают выпускать новые версии.
В общем, как я понял с ходу этот язык не осилить. Попробую прочитать книжку, хотя я уверен она уже устарела… Если осилю, попробую дать еще один шанс этому языку…
А жаль, так хотелось поиграться :(
Забавно, что у меня была прямо противоположная ситуация.
В Go я так и не смог сделать обыкновенное ожидание с тайм-аутом. Перебором нужного синтаксиса я найти не смог, методом чтения документации — тоже...
А вот в Rust всё оказалось понятно и логично.
Вот что я люблю в ГО, так это то, что тесты рядом с файликами есть даже в стандартной библиотеке. А так как язык простой, то и тесты и сорсы читаются на отлично…
Нашел неплохие лекции по Rust: www.youtube.com/watch?v=Oy_VYovfWyo&list=PLlb7e2G7aSpTfhiECYNI2EZ1uAluUqE_e
Пока 2 просмотрел. Столько нюансов и подводных камней… реально нужно понимать как компилятор работает что бы писать нормально. На порядок сложнее GO.
А вообще последние 2 года только на Node.js пишу (работаю с стартапе). И если на GO я еще могу пописать для себя, или тулзу запилить на работе just for fun, то с Rust чувствуется что трудно читать код с женериками и другими новыми для меня конструкциями языка типа восклицательного или вопросительного знака… наверное дело в привычке.
И не понял пока преимущества Result<res, err> над гошным res, err… ну кроме сахара в виде foo()?
Продолжаю исследование =)
Нее, Sleep — это просто пауза. А мне нужно было ожидание наступления события, но не дольше определенного времени.
Если ещё что-то по го непонятно, обращайтесь в телегу @GolangHouse, вам помогут. :)
И не понял пока преимущества Result<res, err> над гошным res, err… ну кроме сахара в виде foo()?
Преимущество как раз понятное: при помощи Result<T, E> можно вернуть или ответ, или ошибку, поэтому воспользоваться ответом, проигнорировав ошибку, в принципе невозможно. Ну и, в отличие от Go, не возникает вопроса, что делать, если функция вернула nil, nil.
Значит если функция вернула ошибку, у меня нет доступа к результату. А если отработала нормально, есть ли гарантия что там не NULL? (None)
None — частный случай типа Option. Он похож на Result<R, E>.
Собственно, чтобы значение могло было None, вы должны явно сказать об этом в типах. И тогда нет, не будет такой гарантии, потому, что это валидный результат, который задекларировали вы же (или другой разработчик).
А вообще, по умолчанию, всей вот этой чехарды с повсеместными nil/null/None в Rust нет (опять же, из-за явного указания Option там, где оно возможно).
На примерах:
fn do_it() -> Result<Option<MyResult>, MyError>
// Если результат Ok(_), то внутри него может быть None.
// Например, Ok(Some(result)) и Ok(None).
// Ну и Err(error).
fn do_it_force() -> Result<MyResult, MyError>
// А вот тут None невозможен, только Ok(result) или Err(error).То есть если в го (жава и т.д) мне что б понять если может прилететь nil, мне нужно просмотреть код… и найти того кто вместо *something может мне кинуть nil, то в Rust я это вижу явно, что не дает мне возможности пропустить хендлинг этого случая?
Именно.
Правда, тут есть другие проблемы:) Например, эти проверки начинают заражать ваш код. Да, для этого есть сахар, что упрощает жизнь. Но, в любом случае, вам придётся писать много преобразований из одного типа ошибки в другой или агрегировать их в discriminated unions (или, что ещё ужаснее, вызывать панику), чтобы хоть как-то разрулить многообразие ситуаций в работе программы.
let cool_result = match cool_function() {
Ok(result) => result,
Err(error) => return Err(error),
}; // длинный вариант
let cool_result = cool_function()?; // короткий вариант.К тому же, тем, кто фапает на сверхскорость Rust, подобное не нравится из-за высокой вероятности оверхеда из-за ошибки предсказания перехода процессором. Но другого выхода особо не видно, поэтому получилось то, что получилось.
Ну, пишущего на Go с его if err != nil return err заражением кода не испугать :-)
И оверхеда эти проверки дают столько же.
fn map<F, T, A>(option: Option<T>, f: F) -> Option<A> where F: FnOnce(T) -> A {
match option {
None => None,
Some(value) => Some(f(value)),
}
}Не зря кто-то потратил свое время на написание вот этого — blog.burntsushi.net/rust-error-handling
Пройдет ли с практикой чувство того что ты не читаешь код а расшифровываешь?
Ну, это обратная сторона однозначности. Вот пример — Джава тоже очень многословна. И ничего — как-то же энтерпрайз код пишут!?
Ну, я не вижу в этом фрагменте кода ничего сложного, так что наверное со временем ощущение "расшифровки" должно пройти.
Кстати, функцию выше можно переписать более коротко:
fn map<T, A>(option: Option<T>, f: impl FnOnce(T) -> A) -> Option<A> {
match option {
None => None,
Some(value) => Some(f(value)),
}
}
Но, в любом случае, вам придётся писать много преобразований из одного типа ошибки в другой или агрегировать их в discriminated unions (или, что ещё ужаснее, вызывать панику), чтобы хоть как-то разрулить многообразие ситуаций в работе программы.
Если мне пофиг на точную обработку ошибок (т. е. мне нужно просто их прокинуть наверх и распечатать), то я просто буду возвращать что-нибудь вроде anyhow::Result.
Интересный подход… есть еще языки использующие такой трюк?
Любые [современные] функциональные.
Вообще, такой трюк можно провернуть с любым современным языком кроме Go, но наличие в языке null частично испортит подобный подход.
type EventResult struct {
Event *Event
Err error
}
Другое дело, что в обычных функциях такой подход не является идиоматичным, но например в каналах такие структуры используются для проталкивания ошибок наверх потребителям.
nil, nil, значит ошибки нет, а первый nil — это вполне нормальный результат (например, slice или map) с т.з. автора функции (в неочевидных случаях автор должен уточнить в документирующем комментарии к функции).2. Игнорирование ошибок можно проконтролировать с помощью линтера errcheck (от также включен в набор линтеров golangci-lint). Что-то может подсказать и IDE (в частности, GoLand ругается
'result' may have 'nil' or other unexpected value as its corresponding error variable may be not 'nil')nil— это то, что мне практически никогда не нужно (особенно с учётом того, что добавление вnil-мапу паникует). И да, я не хочу читать документацию для того, чтобы понять, является ли в данном конкретном случае значениеnilвалидным.- В специфических случаях этот линтер не помогает. Ну и всё-таки есть разница между кодом, на который ругается линтер, и кодом, который попросту не компилируется.
2. Разница есть, но она не бесплатна — сложность языка, время компиляции, кривая обучения, уровень поддержки в IDE и т.д. Любой компилятор (линтер, ...) имеет баги для некоторых исключительных/специфических ситуаций.
Автор функции вполне может вернуть nil-мапу (не говоря уж о nil-слайсе). Это не его проблема, что вы хотите потом туда что-то добавлять
Логично предположить, что если у меня уже есть мапа, то я могу с ней что угодно делать, в том числе и элементы добавлять.
Документацию просмотреть да, придется, но вы наверно и так это делаете.
Ну да. Вот только в Rust мне достаточно посмотреть на тип, а именно — возвращает ли функция Option<Foo> или просто Foo — и больше вообще не морочить себе голову этим вопросом. Более того, если я ошибусь с типом, то у меня не скомпилируется код и компилятор укажет на место, где типчики не сошлись.
При отсутствии явных указаний в документации загромождать «страховочными» проверками результата на nil по мне не стоит, если только не поймали панику во время выполнения/прогоне тестов.
Особенно весело, если функция возвращает nil иногда. И этот случай вопроизводится в проде, но не у разработчика локально.
Я не спорю, что система типов в Rust более развита.
А что вы будете делать внутри «страховочной» проверки на nil, как будете обрабатывать эту ситуацию, которой быть вроде как быть не должно?
Функция иногда может возвращать и пустые значения других типов (строк, чисел), потому что разработчик забыл заполнить поля или случайно оставил сгенерированные заглушки. И не nil, но толку от них тоже нет, и проблемы будут только в runtime (может быть в Rust и можно реализовать compiletime-проверки с помощью макросов, например — я пока до них не добрался).
А что вы будете делать внутри «страховочной» проверки на nil, как будете обрабатывать эту ситуацию, которой быть вроде как быть не должно?
Вы про Go или Rust? В последнем nil нет.
Функция иногда может возвращать и пустые значения других типов (строк, чисел), потому что разработчик забыл заполнить поля или случайно оставил сгенерированные заглушки. И не nil, но толку от них тоже нет, и проблемы будут только в runtime
Если разработчик забудет инициализировать поля, то его код не пропустит компилятор.
2. Я имею в виду, что отсутствие явного null конечно помогает избежать части ошибок, но если разработчик забыл где-то поменять дефолтное значение инициализации (IDE сгенерировала 0 по умолчанию, например, для поля обязательного идентификатора создаваемой структуры), то компилятор на это внимания не обратит.
3. По вашей ссылке открывается что-то не то, мне кажется.
select {
case <- time.After(timeout):
println("timeout")
case <- events:
println("event")
}
В Go by Example (рекомендуется просмотреть в дополнение к другим ресурсам) есть соответствующий пример.
Выглядит, что принудительный запуск GC в сервисе, где вся память — LRU кеш на хеш-таблицах, сделал ребятам больно. Кто-то удивлён? Более примечательно, что у них при расшардировании сервиса на меньшие инстансы проблема уходила — это иллюстрирует, что GC всё же не абсолютное зло.
Кажется ожидаемым, что с определённого уровня масштаба (и уровня вырожденности поведения системы) любой «умный и универсальный» аллокатор/деаллокатор достигает границ своей универсальности. Сборщик мусора (автоматический деаллокатор) начинает болеть раньше и чаще. Но я встречал в реальной жизни проекты, которым glibc-шный malloc был недостаточно хорош, и его замена на специализированный возвращала много процентов производительности.
Почему Discord переходит с Go на Rust