Удалёнка: опыт и лайфхаки
Реклама
Комментарии 306
+7

Так ночным он был на момент начала портирования, в статье указано, что теперь нужный функционал в стейбле. По поводу трехлетнего голанга — самый свежий получил возможность отключения GC? Статья как раз про особенности работы с памятью и сборку мусора.

+7

Но ведь это отключение автоматической сборки, руками-то все-равно придется звать
runtime.GC()

0

Вопрос был про возможность отключить GC в Go. Я написал как это можно сделать. Причём тут "все равно звать руками"

+4
Это не отключает сборщик мусора, а только отключает его автовызов через определённое время. В любом случае, чтобы мусор удалился, нам нужно звать сборщик мусора.
+1
Авторы статьи именно на это и жаловались — типа не могли GC отключить и она всеравно вызывалась просто с максимально длинным интервалом.
Ну тоесть какбы причина озвучена — но решение для нее не особо искали.
+6
Автор статьи прекрасно понимал что сборщик мусора рано или поздно всё равно придется вызываться. Они не хотели его отключить, они хотели запускать его чаще, чтобы сгладить пиковые нагрузки.
+1
GC вызывалась редко изза малого изменения по памяти. А «тормозила» изза большого количества объектов. Более часто вызывать им бы не помогло — былибы более частые пики. Кейс на пики кстати до сих пор висит. Но sync.Poll помогает.
Еслибы они отключили GC былобы ровнее (очевидно изза этих мыслей ошибся в чаще\реже)
+5

Каменты к оригинальной статье правильные.
Пойнтеры в lru — оно конечно раст поможет, но memory fragmentation никуда не уйдёт; конкретно такое использование было пофикшено в го, но похоже очень хотелось раст.

+3
а почему не уйдет memory fragmentation? В теории дефолтный аллокатор раста достаточно умный чтобы использовать slab аллокацию для обьектов похожего размера. Если у них много одинаковых записей в кеше то новые записи должны отлично записываться в блоки освобожденные от старых записей…
+2
авторы не говорят о размерах объектов (или даже точнее обходят), но то что они хранили пойнтеры в lru говорит, что данные не гомогенные (наверняка еще и строки).
jemalloc конечно спасает, посравнение с glibc, но и его можно загадить (особенно с lru на миллионы объектов) на активном долго живущем сервисе.

я видел телеком экип который по glibc не жил нормально, под jemalloc жил, но иногда становилось плохо. как только с хипа ушли — сразу все зажило как надо.
+1
ой да — ну тогда все еще печальнее если обычный glibc используется
+2

Мне кажется у jemalloc всё очень неплохо с фрагментацией памяти. Наверное, можно придумать сценарий где он покажет себя плохо, но графики выше говорят сами за себя: вариант с увеличенным кэшем отвечает в среднем меньше чем за 20 микросекунд, тогда как изначальные графики показывают в 100-1000 раз худшие результаты.

+1
Фрагментация и lockup time не связанны.

Но спасибо что указали — на графице где раст и го не похоже что шкала логарифмическая и раст болтается в макс за 1секунду.
Увеличиваем в 8 раз кэш — и макс падает — ктото когото сильно дурит. В данном случает скорее всего при маленьком кэше были хождения в другой сервис\базу и суммарно это поднимало макс. Про кэше 8х стало существенно реже напрягать другой сервис и макс упал.
Круто — только avg на графике раст/го не особо различается. Еслибы поправили всплески GC — моглибы и не переписывать.
0
эмм… плохо себе представляю как это возможно — стек-то не резиновый
+3

Расскажите, пожалуйста, почему появится memory fragmentation конкретно в этом сценарии, я тоже видел это в комментариях на hacker news, но не понял сценарий. Или просто из общих соображений, раз не GC, который компактит, то memory fragmentation?

0

Здесь не отключать gc нужно (это почти наверняка приведет к утечкам памяти), а использовать offheap-структуры данных, которые не находятся под управлением gc.

+18

По-моему опыту проще брать язык без ГЦ, чем начинать вот эту чехарду с выделением кучи памяти в byte[] и примитивный ад-хок менеджер памяти.

+2
По поводу трехлетнего голанга — самый свежий получил возможность отключения GC?

Go умеет отключать сборщик мусора, ага. Используется для утилит, что запустили быстро отработали и целиком освободили память.

Имхо, по поводу версии ваш оппонент имел ввиду, что GC у Go время от времени совершенствуется. Правда последнее крупное изменение было более 3 лет назад.
+1
1.10 — прямо релиз ноут таки секцию целую про GC имеет
в 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 ничего
+3

Я так понял, что go спасли бы поколения в garbage collector. Они там появились?

0
Вроде есть sync.Pool для этого. Правда не так автоматически красиво.

Вот статься еще от твича 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
0
Нет пока, исходник.
// 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.
0
В комментариях отписали, что со временем пробовали новые версии, картина не менялась.
+56

Лучше бы они отказались от электрона в клиентском приложении.

-7

Электрон, конечно, плох, но он здорово удешевляет разработку. Тот же Qt вот недавно лицензию сменил.

+1
В прошлом году начали пилить NodeGUI. Идея похожа на Электрон, но «под капотом» Qt.
+1
У Revery под капотом всё тот же Electron, так что от архаичного JavaScript избавимся, но от Chromium с его прожорливостью — увы, нет.

Я бы, скорее, подумал тогда о том, как прикрутить ReasonML к NodeGUI, если есть непреодолимое желание писать в функциональной парадигме (что, впрочем, можно делать и на typescript + fp-ts)
0

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


Я revery не пользовался, но они вроде пишут на своей странице, что "мы как Electron, но не Electron — мы меньше и быстрее".

0

А что там с лицензиями? Вроде как были коммерческая + LGPL3, так и осталось уже несколько лет?

+1

Лицензии не изменились. Основные изменения заключаются в том, что, во-первых, их фирменный инсталлер теперь будет всегда требовать аккаунт на qt.io (архивы с исходниками по-прежнему доступны без регистрации), а во-вторых, контора отказалась от концепции LTS-версий для community edition, то есть условно выходит 5.15, поддерживается полгода (выходят там, скажем, 5.15.1, 5.15.2), потом выходит 5.16, и бэкпортинг новых изменений в 5.15 бесплатно уже не производится, только за деньги.

0
Первое не очень (хотя наверняка есть где-то выложенные сборки), а второе — ну и пофиг, в принципе, разве нет? Breaking Changes у них между «средними» версиями обычно не бывают.
+1

Дело не в breaking changes, а в том, то в новых минорных версиях появляются всякие новые фичи, типа как новый scenegraph движок или поддержка aab в 5.14, которые могут быть, скажем так, не слишком стабильны, и одновременно в них выходят фиксы для багов, обнаруженных в предыдущих версиях. Смысл LTS версий был как раз в том, чтобы фиксить баги (через бэкпортинг патчей из более новых версий), не добавляя при этом потенциально нестабильные новые фичи.

0
Так ведь это фреймворк, никто не заставляет использовать новые процедуры и классы для новых фич же, разве нет?
+2
Не все так просто. Например, в Qt 5.13 ради реализации каких-то там новых фич минимальная поддерживаемая версия Android стала 5.0 вместо 4.4 в 5.12, и если вы просто пересоберете свое Android-приложение с 5.13 ради того, чтобы избавиться от какого-то бага, для которого в 5.13 был выпущен фикс, у вас приложение тупо перестанет работать на ряде телефонов, на которых оно раньше прекрасно работало, хотя никаких изменений в СВОЙ код вы не вносили. В основном да, Qt'шники стараются ничего не ломать, например, тот же новый scenegraph движок в 5.14 — это opt-in, который надо специально включать, но так бывает не всегда.
+17
Понимаете, для мессенджера критически важно быть кроссплатформенным. Мессенджер, который не поддерживает хоть одну более-менее распространенную ось — гарантированно обречен на отторжение рынком.

Теперь смотрим, а что же у нас есть действительно кроссплатформенное? Браузер. Потому что он везде, и в него вложены охулиарды бабла. По сути, Electron (при всех его минусах и справедливой критике) открыл эру, когда те же линуксоиды могут получить приложение, с точки зрения UX не уступающее своим аналогам с винды/мака. Например, я знаю, что VSCode на всех платформах одинаково удобен и красив, а не где-то версия основная, а где-то китайская подделка. А когда всё пилилось нативно, пользователи осей с малой долей рынка либо не получали вообще нихрена, либо получали что-то глючное и сильно отстающее по темпам апдейтов (вспоминаем, например, ранний Скайп или историю с дровами nVidia). Потому что нет экономического смысла с ними возиться.

Насчет Qt. Он как бы кроссплатформенный, да не совсем. В нём нельзя добиться одинакового внешнего вида UI на всех платформах. Стандартное возражение — ну и не надо одинаковый, пусть на каждой платформе дизайн соответствует гайдам этой платформы! Звучит логично, но это тоже не выйдет. Qt рисует не настоящие нативные контролы, а имитирует их с переменным успехом — получается «эффект зловещей долины». Какие-нибудь нежные маководы проблюются.

Подытоживая: мне тоже не нравится прожорливость «электронных» приложений, но мне нравится кроссплатформенность и ради неё я готов докупить планку памяти.
+19
В Qt легко добиться одинакового внешнего вида на всех платформах как при использовании стандартных виджетов (CSS/кастомная тема), так и при использовании Qt Quick. Добиться дизайна по гайдам платформы опять же в Qt легче, чем в браузере.
В приложениях на электроне больше всего огорчает не использование памяти, а низкий fps, даже в достаточно простых приложениях.
+1
В 99% случаев это объясняется только кривостью рук авторов этих приложений.

Сам браузерный движок при прямых руках может обеспечить достаточный fps для плавной работы UI.
+6
ради неё я готов докупить планку памяти

И пользователям, которым порой приходится пользоваться вот этим вот, тоже?
+7

Вы не так поняли. Electron ругают не за то, что элементы управления выглядят там плохо, а за сильную прожорливость. Никто не просит, чтобы контролы выглядели нативно. Вот посмотрите например на Telegram Desktop. Отлично работает на трёх платформах (но на моё субъективное мнение, код там ужасен).

+3
Он плохо работает на трех платформах. Как минимум плохо на Windows 10 с 2 мониторами где разный dpi.
+2

Если выбирать между таким телеграмом и телеграмом на qt который ест 2 гига памяти и адски тормозит, то лучше уж то что есть.

+2
Тот Telegram Desktop, который сейчас есть, как раз и написан на Qt.
0

Я не проснулся еще когда это писал, поэтому фигово сформулировал. Перед который — запятая, и предложение относится к первой части про "такой телеграм". Да, на трезвую голову выглядит очень странно, поэтому нужно такое вот длинное объяснение. Такой вот русский язык, сложный:


image


P.S. Да и вообще чем лучше знаю английский, тем сложнее писать на русском, несогласованные части речи, неправильные окончания… Просто беда какая-то

0
Так себе написан, если честно.
Телега — 650MiB. Еще и фон в беседе моргает периодически, после
перетаскивания между мониторами.
Все процессы электронного VSCode c компилятором TS в фоне — чуть больше 800MiB.
Даже WhatsApp — 400MiB, хотя он и лагает безобразно.

Хотя я сомневаюсь, что тут дело в Qt (скорее уверен в обратном).
0

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

0

У меня телега всегда на порядок меньше, не знаю откуда у вас такие цифры

0
$ ps -o vsz,rss,comm 16316
   VSZ   RSS COMMAND
1993048 344464 telegram-deskto

(работает уже пару дней).


350 Мб — это не 650, но все равно непозволительно много, конечно. Не понимаю, куда ему столько...

+2

telegram-desktop попросту течёт. Уже несколько лет наблюдаю. Чем больше прогрузить чатов с мультимедийным содержимым (картинки, видео, стикеры) — тем быстрее. Может и больше натечь. Приходится садить в ограниченную по памяти контрольную группу или просто перезапускать. А на старте меньше 200 МБ ест.

-11
У вас наверное линукс на десктопе. Или мак. Неудивительно, что Телеграм там течёт.
0

На виндовс такого не наблюдаю. Так что наверное проблемы работы с какой-то мультимедийной библиотекой под линукс.

0
а что с ним не так? специально поэкспериментировала, проблем выявить не удалось.
-3
телега написана же олипиадниками? Дуров так говорил, но не знаю имел ли он ввиду только ядро или клиенты тоже
0
Так говорил Зара… тьфу, Дуров. (тм)

Невалидный источник для информации, так-то.
+12
В противовес вам я и все мои знакомые не готовы покупать планку памяти ради оверхеда дискорда, когда стандартный войс чат требует ~10-30 мб RAM максимум. Поэтому мы все используем Team Speak 3 и вам советуем.
+5

Этот зум сжирает батарею телефона со 100 до 0 за час видеоконференции. А, к примеру, час просмотра видео с какого-нибудь ютуба или стрима на твиче кушает в районе 10%. Так что шило на мыло, по-моему. Про дискорд сказать, увы, ничего не могу. Из продолжительных были только звонки без видео.

0
Новый teamspeak, с одним клиентом на сервере. Даже сырая версия по сравнению с дискордом меньше потребляет :)
image
0
Он до сих пор только бета-тестерам доступен, да?
0
Сервер с ограниченным количеством подключаемых клиентов (емнип, до 100 подключений) — бесплатен.
Свободно качался с оф.сайта без регистрации.
Но это было порядка года назад. Как сейчас — не проверял.
0
Сейчас (как и год назад) лимит — 32 подключения. 64 — 55 баксов, итд вплоть до 500
0
Всё равно хватает аналогов для голосового общения (хотя бы та же опенсорсная бесплатная мамбла, разве что нет некоторых свистоперделок).
Я как-то держал (точнее запускал) сервера для личных нужд как мамблы, так и TS.
Мамбла как-то попроще устроена (хотя и весит установленная в 2 раза больше, аж 30МБ).

P.S. TS последний раз запускал в феврале 2019 года судя по дате изменения файла ts3server.sqlitedb
0
Чуть выше:
TS последний раз запускал в феврале 2019 года
Запамятовал за такое время.
+1

image
Вот мой дискорд с кучей серверов. Да уж, разрыв просто кардинальный

0

Этот скриншот ни о чем не говорит. Может, дискорд только запущен, и он не успел сожрать память. Может, дискорд никто не трогал несколько часов, и он полностью свалился в своп. Числа на этой вкладке абсолютно бессмысленные.

0
Ну у меня дискорд, например, прямо сейчас во время разговора жрёт 150~200мб, с учётом всех его процессов.
Телеграм спокойно в фоне сидит с 70мб.
ms teams жрёт 200мб, хотя его вообще никто не трогает и в нём чатов активных нет.
0

Если у вас телега жрёт 70 метров, то вы смотрите не на ту вкладку. Вот телега на запуске:


Working set: 191MB; Commit size: 162MB

0
А в Details сейчас 100мб. На той вкладке — тоже сейчас 100мб. Так что хз. Через Get-Process выдаёт 170mb. PeakWorkingSet — 300мб
0

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

+4

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

+2

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


А для слабых конфигураций есть сторонний Ripcord (пока что бесплатный, но автор собирается в будущем сделать его платным) и purple-discord.

+1
То что Discord обладает нормальным функционалом не делает его «геймерским».
+5
То, что Discord позиционируется на аудиторию геймеров — общеизвестный факт. Это блин написано прямым текстом на главной странице их сайта.
+1
нормальным функционалом

Два употреблённых в неправильном значении слова подряд — комбо! ;-)


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

+4

Одно только но — обычно игру запускают вместе с войс чатом, а не вместо.

+1
Всем хорош тимспик — для своей задачи — голосовой координации групп.

Есть две проблемы:
1) у дискорда есть чатик, в который можно постить видосики, картиночки, ссылочки с превьюшечками и прочую социальщину
2) сервер ТС более чем на 32 клиента стоит немало так денег, а Community License они выпилили года полтора назад, и как я понял из переписки с саппортом — возвращать не планируют.
0
Согласен с вами в том плане, что дискорд реально удобнее всего остального. Но на этом его положительные качества заканчиваются…
+1
телега с этим вроде тоже отлично справляется. юзал её на винде/линуксе/айфоне и никаких претензий ни разу (только к роскомнадзору)
0
Так вот: насколько мне известно, их и нет.

Собственно, когда я плотно водил по сети — мы использовали тимспик для голосовой связи и телегу для чатов. Хотя, конечно, дискорд был бы удобнее, популярнее, хайповее.

За одним исключением. ТС «искаропки» позволяет записывать звук в файл. Для дискорда нативного и простого решения нет я не нашёл.
+4

А маководы от электрона не блюют?
Или look-and-feel от макоси сам-собой получается?

0
Там из всего look-and-feel только светофор в углу окна (закрыть, свернуть, развернуть). Все остальное внутри окна происходит. Мне норм, не напрягает.
+5

Но ведь HTML с CSS не рисует нативные контролы. И возможности стилизации QML/QtQuick практически не уступают таковым у HTML с CSS. Эти две технологии действительно одинаковы в том, как рисуется GUI, в отличие от, к примеру, WinForms, который использует системные контролы.

0

HTML нарисует нативные контролы, если CSS не будет мешать ему

+2

Ну… Не совсем. Это отдано на откуп браузеру и внешний вид отличается. Например формы десяточные — как выглядят кнопки в системе — вы не сможете просто так нарисовать, только примерно повторить. Я сейчас над этим вопросом мучаюсь.


Набросал буквально только что:
image

+7
Согласен с вами, но… вот ранний скайп хоть как-то но работал, пусть и был вырвиглазным. Нынешнее лагучее поделие лучше бы никогда не рождалось на свет. Везде оно одинаково отвратительное. Если бы не общение с заказчиками — никогда бы не использовал его)
-1
И согласен, и нет.
Несколько стационарников с Win10 на борту, мобильник на 8-9 андроиде, макбук.
Всюду стоит скайп. Самое стабильное коммуникативное приложение из всех прочих (WhatsApp, Telegram, Slack). Самое не лагучее. Но самое жрущее память.

Однако бывали (и уверен, что будут) периоды «пмс» у скайпа — на ровном месте как начнет его корежить… Уже смирился с этим спорадическим поведением.
Само приходит, само же и уходит. Бывает несколько дней такого в среднем на квартал.

Чтобы узнать «что это такое» уже хочу в MS уходить… им же нужны тестировщики? :)
-1
Когда я пользовался скайпом на андроиде (а было это лет 7 назад), он тоже работал вполне стабильно и комфортно, но за одним исключением — жрал батарею. Стоило оставить телефон на ночь со скайпом онлайн, и к утру от батари оставалась половина. А без скайпа ну процентов 10 за ночь уходило.
Вот не помню, какое на тот момент было приложение и чьего авторства?
+1
Эта дата вопрос никак не проясняет, потому что MS стала выкатывать свои версии приложений далеко не сразу.
+1
М/б, потому что поначалу разрабатывала клиент та же команда?
-2
А мне вот интересно, сможет ли теоретически flutter занять эту мультиплатформенную нишу. Вроде бы он уже сейчас работает везде, даже в веб, хоть и в бета-версии. Плюс он нативен.
0

С какого перепугу он стал нативным? Flutter рисует интерфейс чуть ли не самой обычной канвой.

+2
Мессенджер, который не поддерживает хоть одну более-менее распространенную ось — гарантированно обречен на отторжение рынком.

Скажите это WhatsApp, у которого web-версия завязана на мобильном клиенте, ага.


с точки зрения UX не уступающее своим аналогам с винды/мака

За счёт ухудшения UX на винде/маке, ага. Когда виндузятникам вместо нативного Skype подсунули тормозную 8-ю версию на Electron — даже самые закоренелые его пользователи, для которых Skype — синоним звонков по компьютеру, начали плеваться.


Да и линуксоидам с этих жиробасин мало радости: вроде как есть, а пользоваться ими нереально. Уж проще под Wine запускать, тем более, в Wine Staging готовится поддержка тем GTK+3, так что и выглядеть будет нативно. Некоторые программы (сходу вспомню только AkelPad) осознанно не портируются на GNU/Linux, потому что и так хорошо работают под Wine. А с TeamViewer до 13-й версии Wine и вовсе поставляли в комплекте, пока не сделали наконец полностью нативный порт.


и ради неё я готов докупить планку памяти

Которая в современных ноутбуках нередко распаяна на плате; куда её ставить, даже при знании, желании и возможностях? Да и не всё в память упирается, важно также работоспособное аппаратное ускорение графики и даже наличие определёных процессорных инструкций, например.


Какие-нибудь нежные маководы проблюются

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

0
Скажите это WhatsApp, у которого web-версия завязана на мобильном клиенте, ага.
Поддерживает же. Через костыль (который кстати не баг, а фича), но ведь поддерживает.
Но главное тут другое — посмотрите в каком году появился WA и в каком его конкуренты. Он фактически создал новую рыночную нишу. Ну и сегодня у него такая пользовательская база, что в отношении него правила работают уже немножко не так, как для остальных. Что дозволено Юпитеру…
+3
Через костыль (который кстати не баг, а фича)

Благодаря этой «фиче» WhatsApp фактически недоступен для тех, кто использует только десктоп. То есть кроссплатформенность там весьма условная. Я даже не знаю, прокатит ли виртуалка/эмулятор с Android — для Viber прокатило, потому что там предусмотрена активация на планшетах без SIM. Зарегистрированные через yowsup учётки уже банят.


пользовательская база

У ICQ тоже была пользовательская база. Ну и где он теперь?

+1
Да, это фича, потому что сквозное end-to-end шифрование. Да, не очень удобно, но либо одно, либо другое.

ICQ проспала мобильную революцию (это не считая ряда других косяков владельцев). Я ж не отрицаю — вполне возможно, что когда-нибудь в будущем новая звёзда скинет WA с пьедестала. Но это либо должна произойти ещё одна революция на рынке, либо Facebook совершит какие-то ну очень деструктивные шаги в развитии продукта. Пока что ни того, ни другого не предвидится и в нынешних условиях позиции WA выглядят устойчиво.
+1
потому что сквозное end-to-end шифрование

Смысл которого в том, что переписка может расшифровываться только на одном устройстве. При этом таким устройством вполне может быть десктоп — секретные чаты в Telegram для macOS и telegram-purple тому пример. Но не в случае с WhatsApp...


ICQ проспала мобильную революцию

Jimm-то?

0
Может десктоп быть таким устройством.
Но разница в том, что у телеги end-to-end только у секретных чатов (которыми мало кто и редко когда пользуется). А у вотса в таком режиме все чаты без исключения. Ну и они справедливо рассудили, что преимущественно сидящей на телефонах аудитории давать десктоп-клиент, который на самом деле будет полностью изолирован от телефонного аккаунта — смысла немного. Получатся два непересекающихся мира. А доля людей, которые хотели бы пользоваться только десктопом вообще без мобилы, видимо, исчезающе мала.
У телеги и вотса в этом смысле разные концепции просто, и нельзя однозначно сказать, какая лучше.
0

у телеги концепция лучше — как минимум — ты не зависишь от уровня заряда свой мобилки

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

Или ноута. А я в дороге. И розетки нет. Или предлагаете телефон от ноута заряжать? Почему обязательно фиксироваться на десктопе? Я уж не говорю о том, что я устал от необходимости держать N+1 мессенджер на мобилке (Viber? Skype? Whatsapp? Telegram?) — там память ограничена, а все эти мессенджеры жрут заряд аккума и трафик

-1
Госпади, ну не нужен N+1 — просто не ставьте. Я так и поступаю. А есть много людей, которые используют вотс как единственный мессенджер (не считая социалок) и их всё устраивает, потому что вокруг много таких же.
+3

К сожалению, не ты это решаешь. Инерция ДРУГИХ людей сильно больше. И, предположим, это один из твоих ключевых клиентов использует мессенджер Х, а второй ключевой клиент мессенджер У. В случае вотсап проблема нерешаема, кроме как установкой мобильной версии (sic!), в то время, как с остальными — зачастую можно поставить только десктопную версию.

+1

Это сомнительная фича. Во-первых, можно было сделать хотя бы как в Telegram — по варианту для каждого устройства. Во-вторых — а в протокол, которым веб-морда с клиентом на телефон общается, смотрели? Что там? В-третьих, хранение бэкапов в облаке в открытом виде сводит это e2e в ноль.

+1
пользовательская база


У ICQ тоже была пользовательская база. Ну и где он теперь?


Ну дык

1) ICQ целенаправленно убивала свою пользовательскую базу годами
2) Тогда не было смартфона в каждом кармане, привязки аккаунта мессенджера к номеру телефона, привязки к обычной адресной книге. В WA так просто ID и пароль не забудешь — это уже другое поколение подхода к пользовательской базе.

Ну то есть прямая аналогия — не уместна.

Я ж не отрицаю — вполне возможно, что когда-нибудь в будущем новая звёзда скинет WA с пьедестала.


Среди вашей среды — он, наверное, и на пьедестале.
У меня — у окружающих полно других мессендежров, альтернативных.
В Китае с его огромной пользовательской базой — WA вообще не котируется.

Я бы не считал WA прямо-таки лидером.
Один из немногочисленных ведущих — да.
-2
У меня — у окружающих полно других мессендежров, альтернативных.
Это только кажется. Примерно как пользователям linux.org кажется, что в мире ну ппц сколько линуксоидов. В локальных группках — да, может быть много. Глобально — мало.

Так и с WA. Если взять широкую репрезентативную статистику (не только it-коллеги или друзья из одной группы интересов, а разные социальные слои, города, профессии, возрасты и так далее) — то оказывается WA таки лидер. Ну ок, за исключением Китая, там своя историческая специфика.

PS Если что, сам я не фанат WA, у меня другие предпочтения. Но если просто констатировать положение вещей, то вот как-то так.
+2

Не только Китай, есть много стран, где лидируют другие мессенджеры: LINE (Япония, Тайвань, Туркменистан), Viber (Украина, Беларусь, Босния и Герцеговина), Telegram (Иран, Узбекистан, Эфиопия).

+27

В пользу чего угодно, что не браузер. Хуже, чем Электрон, нет ничего.

-1
конкретики какой-нибудь добавить было бы прекрасно, а то большинство хают электрон на чем свет стоит, не предъявляя ничего, кроме «да вы видели, как он память жрет!!!», как вы браузером пользуетесь, и не плюетесь-то? И это во времена мак про с полутора терабайтами оперативной памяти. Я, например, тот же дискорд использую каждый день, в нашей команде это основной инструмент для голосового общения, и никто не жаловался, да и с вс кодом проблем вроде как нет. Андройд студией никто чтоль не пользовался?
+1

Полтора терабайта ОЗУ? Реально есть маки с 1536 GiB на бору?
У меня вот всего 32, это аж в 48 раз меньше.

+11

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


Свои фантазии про размеры оперативной памяти оставьте при себе, они не имеют ничего общего с реальностью, в которой существует 90% юзеров.


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


И память — таки не единственная проблем электрона. Он банально тормознутый. Если взять какой-нибудь дискорд, то руки разрабам надо отрывать сразу, потому что обновления по полчаса каждый день при запуске — это надо постараться.

-5
Ну реальность сейчас — 8+гб, даже в ноем относительно старом пятилетнем ноуте 8, проблем особых тоже не вижу. Мои фантазии не о том, что у каждого стоит по терабайту в пк, а про то, что достаточно странно в наше время смотреть на потребление в 500мб для простых юзеров. Да, потребление памяти серьезное, открыл сейчас хром и вс, первый — 500мб, второй — 650, не то, чтобы сильно много, и уж точно не гигабайты. Простые смертные, играя в простейшие игры, задействуют сильно больше. Да и про «зоопарк месседжеров», это как раз таки очень специфичный случай, ибо кому нужен на пк этот зоопарк, каким-нибудь менеджерам, которые в один меседжер всех согнать не смогли? И весь ли этот зоопарк на электроне? Вот про разделение памяти — да, аргумент, но опять же, простому пользователю заметно это не будет, или будет, если 10 приложений на электроне открыть
+6

Если запустить голый хром без расширений и открыть в нём одну страничку, конечно, у вас будет 500 метров. Только если настроить десяток расширений, поработать несколько часов — эти 500 метров запросто превращаются в 5 гигов. У меня один GPU Process хрома жрёт под 2 гига запросто, если его не прибивать.


Игры в большинстве своём столько не жрут.


Зоопарк мессенджеров происходит по той простой причине, что всех согнать в один мессенджер нереально. Скайп — хром. Дискорд — хром. Слак — хром. Зулип — хром. Риот — хром. Вацап — хром. И это, мать их за ногу, только мессенджеры. А ещё есть редакторы кода, лаунчеры и прочий трэш.


Раньше была миранда. А теперь — изолированные инстансы хрома, жрущие все ресурсы на компе.

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

Я не про косынку же говорю, если открыть в стиме страницу с самыми популярными играми, то можно увидеть, что в большинстве своем они требуют от 8гб, и это минимальные требования.
+2

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

0
Если вы чувствуете, что оперативной памяти не достаточно — это проблема, а что там уже вы будете продавать или докупать — решение, а не «проблемы на ровном месте».
+1
Я чувствую, что мне достаточно, пока все мессенджеры и прочие не переходят на отдельный инстанс барузера, который начинает пожирать память как не в себя, о чем и говорит Athari.
Ясно, что релизить с таким подходом проще, быстрее и дешевле, но пользователю от такого не легче.
+3

Я обычный юзер, который пользуется зоопарком мессенджеров на домашнем компе. Моё фрилансерство добавляет только слак, во всех остальных обитает обычный народ, с которым я общаюсь: кто-то до сих пор торчит в скайпе, сообщество РуСО сбежало на зулип, фурри массово мигрировали в телегу, параноики скрываются в риоте, вацапом пользуется родня, а я сижу и мучаюсь со всем этим безобразием. И если на часть приложений можно забить и просто запустить в браузере или полагаться на уведомления с мобилки, то для некоторых критична интеграция с системой.


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


Я не про косынку же говорю, если открыть в стиме страницу с самыми популярными играми, то можно увидеть, что в большинстве своем они требуют от 8гб, и это минимальные требования.

Игры вполне справедливо полагают, что они единственные в системе, а не запущены в пяти экземплярах. Минимальные требования также учитывают прожорливость оси. Десятка, запущенная на 4 гигах рамы, игре банально не оставит места. Так что в требованиях хоть и пишут про 8 гигов, на деле игры жрут 2-4, редко больше.

0
Не похожи вы на обычного юзера по вашему же описанию, 99% людей, я уверен, в жизни не слышали ни про риот, ни про зулип. Слак, вс код и другие вещи, относящиеся к работе — тоже не про это.
Я, наверно, — невероятно асоциальный и некоммуникабельный тип, ибо у меня на пк только дискорд и телега.
Насчет игр, я же написал, что это — минимальные требования, для маскималок — 16+ пжалста, т.е. все-таки играм нужно столько памяти
0

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

+1
Ну я изначально сказал родственникам "вот телеграм, либо заходите, либо не заходите, но тогда не обижайтесь". Почти все в итоге перешли.

У меня чё-т так с джаббером не прокатило.

+1

Не пользовался им, только слышал.


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

0
Т.е вы несознательно поставили своих родственников в положение того самого абстрактного юзера, которого мы тут обсуждаем. С вами они общаются только в телеге, а со всеми остальными такими же в других мессенджерах.
0

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


Если бы открытые поделки были качественные, ещё куда ни шло. Но там даже хромовость не первым пунктом в списке проблем. Одна боль.

0
Я один, похоже не пользуюсь мессенджерами (оочень редко вотсап) — только чат Upwork и комменты в хабре/на ютубе. Похоже я — капитан Немо
+1

Апворковый клиент вместе со своим чатом — тоже хром.

0
Клиент идет лесом, если работа с фиксированной оплатой — только хром, ну еще рабочее окружение но это уже не по теме.
0
В Оперу встроены ВК, Вотсап, Телеграм, Фейсбук. Худо бедно, на несколько (десяток) процессов разных хромиумов меньше.
0
Заголовок спойлера
А при включенной боковой панели
opera://settings/manageSidebar
и одной из галочек для соц.сетей можно кликнуть по иконке появившейся на этой самой боковой панели и открыть в панели как бы мобильную версию своей страницы.
+1

Ну то есть это веб-морды, которые, в случае той же телеги или воцапа, ограничены по фичам относительно полноценного клиента?

+3
Раньше была миранда. А теперь —

Pidgin


И это у меня ещё далеко не все модули стоят ;-)


Официальные клиенты запускаю лишь ради недостающей функциональности: звонков, цитат, редактирования и т.д. А висеть онлайн этого хватает с головой.


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

+1

Глянул Pidgin. Половина плагинов в состоянии "вот инструкция на 10 страниц, как собрать плагин из сорцов". Ох.


Окей, я посижу много часов, собирая всё это безобразие, потом столько же убью на настройку. А обновлять как? Следить за каждым репозиторием и пересобирать всё по новой при каждом чихе?


Да ну в баню.

+1
А обновлять как?

А зачем? Они и так работают. Требующие исправления поломки совместимости на моей памяти только у скайпа раз были.


Да и собирать их, как правило, несложно: плагины маленькие, кучу зависимостей и замудрённые системы сборки не используют. А обновлять — и подавно: git pull && make && sudo make install. У меня знакомый владелец Minetest-сервера моды для него так же обновляет, прямо из Git-репозиториев — не жалуется.

+1

Ручное заполнение атрибутов пакета как раз сильно осложнит обновление. Оверкилл ради одной .so-шки, которая закидывается в /usr/lib/pidgin/. А если готовую .so-шку скачаете — тоже опакечивать её будете?

0

Просто в дебиане с опакечиванием сложно. В более молодежных системах это делается в пол строчки. Как по мне в любом случае лучше знать что откуда в системе берется, иначе будет помойка как раньше в винде.

0

Ну дык главное, что пользователь знает. А от помойки ПМ не спасут. /home, например, они обычно не контролируют, а там бардак лютейший. А кто контролируют — те изолируют хомяки приложений друг от друга, превращая GNU/Linux в подобие огороженного (и поэтому неудобного) Android.

+1

А что не удобного в андроид подходе? там как раз доступ к фс почти не разделяется, одно правило для internal storage и все на сколько я помню.
Ну а в /home беспорядок потому что приложения пишут куда попало. Хотя и там часть файлов под контролем пакетных менеджеров типа npm.
По поводу "пользователь знает" — я довольно быстро забываю что я как настроил.

+2
там как раз доступ к фс почти не разделяется

К общей — да. А вот в данные самих приложений лезть нельзя: https://source.android.com/security/app-sandbox


Хотя и там часть файлов под контролем пакетных менеджеров типа npm

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


я довольно быстро забываю что я как настроил

Полезете перенастраивать в следующий раз — вспомните ;-)

0

Почему? /usr/share на GNU/Linux открыт на чтение всем, не говоря уж о хомяке. При подходе Android же ресурсы — это часть приложения и закрыты от других приложений.


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


Далеко ходить не надо, взять хоть банальные логи чатов в мессенджерах. В десктопных версиях они открыто лежат в ФС, можно читать чем угодно. На Android их можно достать лишь из-под рута, встроенный экспорт есть не везде.

+2

И правильно, потому что мне не нужно чтобы кто попало читал логи чатов. Если надо будет я сделаю отдельную политику для этого. Сейчас в линуксе хомяк на чтение всем доступен и это дырища в безопасности. Хотя например те же логи других программ каждый в своей поддиректории /var/log/foo с соответствующими правами.

+1
я сделаю отдельную политику

Но для этого, опять же, нужны права админа. С которыми и так можно что угодно.


Беда ведь в том, что чем выше безопасность — тем хуже UX. Есть случаи, когда параноидальная безопасность оправдана, но пихать её во все щели, как делают всякие UAC, WDDM, XDG-порталы, файрволы, разного рода песочницы, требующие HTTPS для всего подряд браузеры — перебор. Траблшутинг, опять же, усложняется, ведь проблемы могут возникать на пустом месте банально из-за того, что очередная заглушка по умолчанию не пускает, а не потому что реально что-то сломалось.


И как такой приложениецентричный подход вообще совместим с юниксвеем? Вы предлагаете для каждой мелкой комбинируемой исполняемой утилиты типа grep/hd/sort/git/etc. отдельно назначать юзера, группу и права доступа? На Android их и не существует вне рутового шелла в качестве first-class citizen, максимум внутри приложений вида «Терминал», которые берут все права доступа на себя.

0

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

0

А как здесь поможет setuid? Назначать с ним владельцем утилиты рута — огромная дыра в безопасности, нивелирующая всю эту изоляция. Назначать владельцем отдельного юзера для этой программы — не решит проблему доступа, а ещё больше усугубит. Назначать владельцем пользовательского юзера (извините за тавтологию :)) — всё равно не даст доступа к данным других приложениях.

0

Ну, мы просто смотрим на проблему с разных сторон. Не вижу смысла спорить )


Назначать владельцем отдельного юзера для этой программы — не решит проблему доступа, а ещё больше усугубит.

не владельцем на файловой системе (очевидно), а правильно наследовать права в рамках дерева процессов.


Назначать с ним владельцем утилиты рута — огромная дыра в безопасности, нивелирующая всю эту изоляция.

В каком-то смысле — да, дыра. Любое повышение привилегий (в особенности — сделанное не очень правильно) — потенциальная дыра

0
Архитектуру доступа к файлам нужно пересматривать, факт.
0

Каждое крупное приложение в своем контейнере крутится, и при надобности имеет доступ к утилитам и файлам. Если какая то утилита типа grep то к ней можно дать доступ почти всем приложениям.
Ну и вообще как только я выхожу из терминала в мир гуи юникс вэй заканчивается.
Более того если сделать умный файл менеджер то он тоже может по песочнице делать для каждого контекста. Например чтобы открывалось два офиса один для папки Downloads а другой для TopSecret.
Какой именно UX усложняется?

0
Каждое крупное приложение

Крупные приложения сами по себе противоречат юниксвею.


Ну и вообще как только я выхожу из терминала в мир гуи юникс вэй заканчивается.

В Plan 9 умудрились даже GUI реализовать по заветам юниксвея. Даже, внезапно, на Win32 он прижился в части модульности и разделения ответственности — привет COM и ActiveX. Нередки случаи, когда в офисных документах какие-то элементы отрисовываются через другие приложения. Браузерные плагины (ActiveX/NPAPI/PPAPI) работали по тому же принципу — но их закапывают… Даже банальные и широкораспространённые буфер обмена и drag-n-drop можно считать грубой заменой пайпам.


один для папки Downloads а другой для TopSecret

Не разумнее ли TopSecret держать в отдельной виртуалке, а в идеале на отдельной физической машине без прямого выхода в Интернет? Зачем полумеры, и тем более зачем распространять песочницу на остальное?


Какой именно UX усложняется?

Необходимость пользователю воевать с этими ограничениями. Там разрешение дай, там проверь, не заблочил ли опять чего файрвол, там проброс добавь… утомительно. А если толковых способов обойти ограничения вообще не предусмотрено (привет проверке цифровой подписи системных файлов на Series 40 и на новых виндах), то ещё хуже.

+1

Виртуалка это еще одна полноценная ОС которая будет жрать ресурсы. Не говоря уже об отдельной физической машине. Зачем она нужна если можно решить правами доступа к фс? Почему-то вас бросает из крайности в крайность. Я же не говорю про каких то шпионов и гос тайнах там где отдельная машина за семью замками без доступа в интернет. Если бы браузеры не изолировали бы сайты в песочницу (хотя по сути это те же приложения только на веб платформе) то было бы все печально. Так почему таки же стратегии не применяются к приложениям на нативной платформе?

0

Потому что уже есть стопицот программ, которые плевать хотели на бест пректисы опесочивания средствами операционной системы. Не говоря уже о том, что в модели рисков есть уязвимости самого ядра ос. На минуточку — сколько там сейчас kloc кода в ядрах винды и линукса с учётом всех драйверов?
Я уж не говорю, что модель доступа приложения как в андроид очень грубая и по сути ни от чего не защищает, тем более, что многие приложения "на всякий случай" запрашивают привилегий больше, чем надо. А более точечная модель — сам пользователь не следит с ее настройкой и аудитом "что же это поменялось в Н+1 версии скупа, что он стал требовать новые пермишшены".


Что остаётся? Как истинным революционерам разрушить весь мир и построить все нуля. Или засунуть все в полноценные виртуалки, но огромной ценой вычресурсов

0
"на всякий случай" запрашивают привилегий больше

Это должно решатся заглушками, в андроиде к сожалению такого нету. Хотя некая модерация гугла по привилегиям есть.
Так и в ядре могут быть и в виртуалке уязвимости, от этого не спасешься. Больше слоев может помочь. А какие то кривые приложения использовать не обязательно, или уже для них специально виртуалка. Текущие решения на десктопной винде и линукс слабые (про мак не знаю). А вот серверный линукс почему то настроен более менее в плане разделений привилегий.

+1
Хотя некая модерация гугла по привилегиям есть.

Да, есть маленькая, но надежда на магазины приложений — что в них не будут попадать по крайней мере откровенные вредоносы.


Больше слоев может помочь.

Нет. Больше слоев в первую очередь создают иллюзию защищенности. Усложняют аудит. И понимание происходящих процессов. Чем проще софт — тем лучше.

0
Зачем она нужна если можно решить правами доступа к фс?

Права доступа не спасут от уязвимостей и «технологических отверстий» в прочих местах.


Я же не говорю про каких то шпионов и гос тайнах там где отдельная машина за семью замками без доступа в интернет

То есть простым смертным такой уровень защиты ни к чему, понятно — максимум замок на двери для виду.


Если бы браузеры не изолировали бы сайты в песочницу (хотя по сути это те же приложения только на веб платформе) то было бы все печально

Ну ведь так и было: дырявые плагины, а уж ActiveX...

0
Ну ведь так и было: дырявые плагины, а уж ActiveX...

Но это не значит что надо и дальше так делать

0

Но ведь или так, или никак. Видео произвольных форматов браузеры, помимо WebKit'ных, нативно воспроизводить не умеют, например. Не говоря уж о встраивании более экзотического содержимого типа 3D-моделек. По факту — приходится портировать всё на браузерные технологии, с заведомой потерей производительности, а местами и возможностей; с системой же интегрироваться через локальные web-сервера или расширения-мосты, что тоже далеко не высокопроизводительное решение по сравнению с вызовами нативных библиотек.

+1

Так он и не работает: пару дней поработал и перестал. До сих пор не знаю: то ли забанили, то ли попросту совпало с прекращением поддержки клиента для S40, которым этот плагин прикидывается.


Но вообще, охотятся вроде только за заменами первичному (мобильному) клиенту, а на обёртки к web-версии сквозь пальцы смотрят. mautrix-whatsapp и go-whatsapp вон, например, куча народу использует — о прецедентах банов пока слышно не было. А вот созданные через yowsup учётки банят.

0

А, видимо таки прекращение поддержки :) В libpurple очень много всякого такого, что "когда-то работало", баги у них годами висят...


Но вообще, охотятся вроде только за заменами первичному (мобильному) клиенту, а на обёртки к web-версии сквозь пальцы смотрят. mautrix-whatsapp и go-whatsapp вон, например, куча народу использует — о прецедентах банов пока слышно не было.

Звучит обнадеживающе, но что, если это просто эффект неуловимого Джо? В смысле, пока их вот таких мало, на них забивают, станет больше — начнут банить? Мне лично куда интереснее был бы вариант гейта / плагина в другом мессенджере, чем замена мобильному официальному, да.

0
В libpurple очень много всякого такого, что "когда-то работало"

Ну со встроенными протоколами отдельная песня, они просто тащатся ещё с 00-х и не выкидываются. При том, что года два назад друг за другом сразу три мессенджера отключились (AIM, Yahoo! IM и ICQ через OSCAR). Но последний релиз Pidgin и libpurple как раз в начале 2018-го и был. Просто потому, что разработка медленная, не всему же каждый месяц релизиться, как Chrome ;-)


пока их вот таких мало

Ну yowsup тоже не шибко распространён был. Впрочем, его могли задействовать спамеры, потому в Facebook и ополчились. А обёртки для web-версии для спамеров бесполезны: всё равно нужен парк эмуляторов Android, проще туда автокликер и всунуть.

0
Просто потому, что разработка медленная, не всему же каждый месяц релизиться, как Chrome ;-)

Да, но "не фиксить баги по 2 года" — всё ж чуть другое...


Впрочем, его могли задействовать спамеры, потому в Facebook и ополчились

Хороший вопрос о статистике тогда — какие еще версии банились.

0

6 лет назад многим проектам Cease & Desist прилетел. Баны начались позже, на останках пепелища (в основном за использование WhatsApp+ для Android).

+1

А чего сразу браузеры-то? HTA был вполне приличным, только кроме винды нигде не работал. Приложения на XUL+Gecko тоже довольно скромные в плане прожорливости, и выглядят нативно. Electron попросту наследует прожорливость Chromium.

+2

В пользу Rust'а, чего же ещё?! :)
UPD: интересно, для того же Rust+WASM есть что-то десктопное, но безбрауерное?!...

0

Есть. Но увы, как и всё, относящееся к Rust, разрабатывается крайне медленно.
Я вот всё, облизываясь, поглядываю на Azul.

+3

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

0
В плане написания кроссплатформенных не веб приложений есть стандарт WASI. А вот чем GUI рисовать кроссплатформенно без браузера — про это я не знаю.
0

Понятное дело, что это просто катастрофа. Но вектор именно такой.

+6
Вау, вместо того, что отрисовать gui напрямую через Vulkan (или DirectX), мы устраиваем браузер, который имеет кучу накладных расходов и кучу ограничений.
-7

Полагаю, что им легче написать одно решение для всех платформ (не заморачиваясь о производительности на стороне клиента, конечно же), чем отдельно для DirectX, для QT и для каждой из мобильных платформ.

+6

Но ведь основную часть игры-то все равно же придётся для каждой платформы писать!

+2
У Valve например HUD под Source 2 (Dota 2, CS:GO) реализован через Panorama — их собственный фреймворк на основе CSS/JS/HTML. Эта штука неплохо облегчает жизнь как собственным UI-разработчикам, так и модмейкерам, потому что достаточно базовых знаний в фронтенде.
0
Ещё гуй КСГО использует флэш (в ресурсах были swf-файлы, емнип).
0

А так же игры Бесезды (начиная, кажется, с TES:V), Ведьмак… Флеша на удивление много.

+3

Плюс от cef в том, что интерфейс могут быстро править дизайнеры/фронтендеры, это морока огромная все напрямую в directx править каждый раз, когда дизайн меняется

+1
Минус в том, что платят за интерфейс (в играх) игроки. И у переиздания W3 на метакритике от игроков оценка 0.5 из 10. И очень часто пишут про лагающую менюшку. Ту самую, что на CEF
+2

При том игрок эту менюшку (в сингле) видит 2 раза за игровой сеанс: когда запускаешь игру и когда выключаешь. В самой игре интерфейс не вебовский и не тормозит.


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

+1
Не только из-за этого. Те, кто играл в выпущенный в 2004 году The Frozen Throne получили по сути даунгрейд — игра стала требовательнее к железу, EULA кастомных игр стало намного жестче, пропали ладдер, кастомные кампании, гильдии. Все это в замен на графическое обновление сомнительного качества.
+1
При том игрок эту менюшку (в сингле) видит 2 раза за игровой сеанс: когда запускаешь игру и когда выключаешь.

Я, например, менюшку просто не вижу, она у меня не отрисовывается :(

+3

Да, и это официально худший релиз игры по версии metacritic...

+1

И вполне оправдано. Оригинальный вар3 лучше во всем, чем рефордж. Только теперь в оригинальный варкрафт3 не поиграешь.

+5
К их чести, работает он куда лучше того же Слака. Слак за неделю работы гигабайты памяти сжирает, Дискорд этим не страдает.
+1
Тут не могу не согласиться. Разработчики Discord на славу постарались над производительностью интерфейса, он действительно намного быстрее электронных собратьев. Но всё же иногда UI даёт слабину, и что-то мне подсказывает, что исправить это «молотку и долоту» уже не под силу.

Для любознательных
«Молоток и долото», а если быть точным, «Hammer & Chisel» — старое название организации, разработавшей Discord.
0

Зато дискорд при каждом запуске обновляется по полчаса. И интерфейс долбанутый. Личка и чаты в отдельных подпространствах. За невозможность отобразить названия серверов — хочется взять и уе. Опции отправлять по Ctrl+Enter нет до сих пор.

+1

Личка и чаты по отдельности — Must have. Ибо приоритет чатов чаще всего — уровня помойки

-4
Удивительно что это Windows-only проблема, на Linux у меня редко до 600мб доходит, у коллег же на винде и по 3гб бывает сжирает. На линукс вообще с электроном всё лучше, у меня постоянно 3 приложения открыты (slack, insomnia, vscode) ну и хром >20 вкладок, в среднем всё это жрёт 6-7гб ОЗУ. На винде у меня бы уже 16гб по швам разошлись.
+2
Это, скорее, Win7 проблема. На Win10 у меня Слак редко до 500мб доходит.
+1
Использую уже годы Slack в припиненой вкладке в Firefox, и ничего страшного не происходит.
+1
Чинят утечки временами. Помнится год где то назад слак в такой же запиненной вкладке утекал за сутки на 2гб. С тех пор сижу в электроне, ибо он не течет почти =(
+3

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


Просто, потратил 20 минут на то чтобы зайти в приложение, чтобы оно сказало "вы подозрительный, фиг вам а не наш богоподобный мессенджер".


Это просто отвратительно.

+1

Мне кажется, что Read States — это все же не служба чтения состояний, а служба статусов сообщений. И спасибо за перевод, интересно было почитать.

+2

Служба состояний прочитаного больше подходит, кажется

0

Тогда уж служба состояний чтения. Или служба состояний непрочитанного.

-1
Попробовал скачать и запустить десктопное Discord приложение под Xenialpup и Ubuntu (Убунта даже не в курсе, что есть такой софт и предупреждает об неизвестном источнике его получения) — не запустился.

P.S. Что интересно, например, браузеры PaleMoon, FireFox запускаются из бинарных архивов даже не требуя установки (например при использовании загрузочного LiveCD) в указанных выше системах.
Что я делаю не так? (может кто знает :)
+3

Никто не знает что конкретно вы делаете.
Из snap пакета Дискорд ставится и запускается без особых проблем.

0
Да и официальный deb-пакет никуда не девался (в любом случае приложение самообновляющееся).
+1

Вопрос к знающим: а если бы они эту свою службу на Эрланге написали, например? Он вроде как придуман для быстрых и мелких штук. Или с появлением Го и Раста нет смысла что-то писать на Эрланге?

+1

Эрланг работает под VM с GC, что, на мой взгляд, еще печальнее Го.


Думаю что результат был бы сравним или хуже Гошного.


Насчет писать на нем — лично для меня его код всегда был чем-то инопланетным :)

0
Как мне видится из текста статьи — им нужно работать с огромным объектом(LRU кешем) размещенным в памяти. Философия Ерланг предполагает что вы запускаете тысячи fiber «тредов» на каждый из которых выделяется малое количество памяти и которые работают не изменяя объекты в памяти а копируя их значения. В остальных юз кейзах где не нужны тысячи файберов Erlang вряд ли блистает производительностью. К тому же там тот же самый GC.
0
увеличили объём кэша до 8 миллионов состояний Read State.

Кстати, не так уж это и много. 8 миллионов объектов по 100 байт каждый даже (что уже многовато для такой простой структурки), — это всего лишь 800 мегабайт, что далеко не так страшно.

0

Зависит от того как память выделяется, используется, фрагментируется. В результате эти 800Мб могут на деле занимать в 2-4 раза больше.


Хороший пример — DNS кеш — много мелких объектов. У меня был как-то Unbound нагруженный, который при настройке предельного размера кеша в 5Гб кушал в реальности около 10Гб.

+1
>К тому же там тот же самый GC.

Не совсем. Т.к. у каждого актора свой memory space, то сборку мусора намного легче сделать инкрементальной, без глобального stop the world, т.к. достаточно собирать мусор в рамках отдельных акторов (а это пара килобайт). В итоге, я так предполагаю, у Erlang'а в теории не должно быть spike'ов как на графике с Go.

Кэш состояний в принипе можно как-то шардировать на акторы…
+1
дискорд… самый шакальный мессенджер из всех что я видел. смайлики за деньги… совести у них нету. единственное что в нем хорошо — голосовые звонки, остальное ужс
+4
Покопавшись в исходном коде Go, мы узнали, что Go принудительно запускает сборку мусора минимум каждые две минуты. Независимо от размера кучи, если GC не запускался две минуты, Go принудительно его запустит.

Шел 2020 год. А в модном языке Go GC работает как в lua 5.0 который был релизнут в 2003, а уже в 2006 появился новый релиз без этой фигни. Про java я вообще пожалуй промолчу.
0
Пока ничего особенного. Когда выйдет 5.4, тогда появятся поколения.
0
Это да. Вопрос в том что в чем проблема разработчикам Go посмотреть работы по GC существующие?
0
Судя по популярности Go, у них нет никаких проблем. Я не нашел никаких планов по улучшению GC, ни в 1.15, ни в пропозалах для 2.0
0
Судя по популярности когда-то у перла, си, пхп,… небыло никаких проблем.
0
Судя по популярности Go, у них нет никаких проблем. Я не нашел никаких планов по улучшению GC, ни в 1.15, ни в пропозалах для 2.0


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

+2

А что с этой популярностью?


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


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

-2

В Go существенная часть аллокаций происходит на стеке, оттого ему не так критично иметь навороченный GC.

-5
Проблемы стильных/модных/молодёжных языков решаются использованием С (без всяких там плюсов и решёток)
+1
Проблемы стильных/модных/молодёжных языков решаются использованием С (без всяких там плюсов и решёток)


Помню я эту эпоху, когда все писалось на С.
Когда диалоговые окна «Segmentation Fault» уже даже не удивляли.

С переходом на С получаем крайне медленную и дорогую отладку, если речь не о «Hello, world».
+1
Как уронить JVM? Возьмите JNI, его стандартное поведение — ронять JVM (с)
+2

О, раз тут есть знатоки С без всяких там плюсов...


Не далее как вчера мне потребовалось один раз потокобезопасно инициализировать статическую переменную. На плюсах я бы сделал


static const auto foo = get_foo();

и всё было бы потокобезопасно и эффективно. Но на C так нельзя, так что как добиться аналогичной эффективности на C?


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

0

Вроде только с расширениями, например вот https://gcc.godbolt.org/z/8_907h, для msvc будет по-другому.
Кстати, в случае с++ тоже есть нюанс, который иногда стоит иметь ввиду. Обычный static const int foo = 1 — попадет в .rdata секцию, и будет реально защищена на запись, а динамическия = foo() — работает через тот же механизм, что и си с расширением, и попадет в .data без защиты.

0

С расширениями стрёмно, так как я их не могу проверить на том же MSVC, да и атрибут constructor я у clang'а сходу не нашёл.


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


Можно ещё было бы на атомиках делать, но писать руками такое тоже не очень хочется.

0

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++ тоже ровно он и используется).

-1
Именно эта статья сподвигла меня попробовать Rust. Помню как первый раз GO учил. В принципе за спиной уже был php, java, js, python (c++ и C# помню только со времен учебы что-то).

Так вот, после прохождения tour.golang.org/welcome/1 я уже мог что то писать. Оно компилировалось и работало. А если не работало — то компилятор говорил что не так. Язык примитивный и все ограничивалось банальной правкой типов и т.д.

И вот я день прот… хался с Rust. Это ад какой-то. Да, Hello World с божей помощь скомпилировался. Дай думаю забабахаю простенький ендпоинт который будет принимать айдишник и брать доку с монги. Ошибки компилятора — напомнили с++ где читаешь ошибки и хрен знаешь как ее чинить… Столько всего нужно писать — макросы, импорты, неймспейсы… потом конфликты библиотек прилетели…

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

В общем, как я понял с ходу этот язык не осилить. Попробую прочитать книжку, хотя я уверен она уже устарела… Если осилю, попробую дать еще один шанс этому языку…

А жаль, так хотелось поиграться :(
+4

Забавно, что у меня была прямо противоположная ситуация.


В Go я так и не смог сделать обыкновенное ожидание с тайм-аутом. Перебором нужного синтаксиса я найти не смог, методом чтения документации — тоже...


А вот в Rust всё оказалось понятно и логично.

0
Как так, если даже в документации есть пример: golang.org/pkg/time/#example_Sleep
Вот что я люблю в ГО, так это то, что тесты рядом с файликами есть даже в стандартной библиотеке. А так как язык простой, то и тесты и сорсы читаются на отлично…

Нашел неплохие лекции по 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()?

Продолжаю исследование =)
0

Нее, Sleep — это просто пауза. А мне нужно было ожидание наступления события, но не дольше определенного времени.

0

То, что там нужно было select использовать — я и так понял. Но у меня не получилось положить значение из канала в существующую переменную (почему в существующую — потому что по тайм-ауту нужно было использовать значение по умолчанию).

+5
И не понял пока преимущества Result<res, err> над гошным res, err… ну кроме сахара в виде foo()?

Преимущество как раз понятное: при помощи Result<T, E> можно вернуть или ответ, или ошибку, поэтому воспользоваться ответом, проигнорировав ошибку, в принципе невозможно. Ну и, в отличие от Go, не возникает вопроса, что делать, если функция вернула nil, nil.

+1
То есть вся соль в том что Rust функция возвращает как бы всегда 1 результат? Интересный подход… есть еще языки использующие такой трюк?

Значит если функция вернула ошибку, у меня нет доступа к результату. А если отработала нормально, есть ли гарантия что там не NULL? (None)
+2

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).
+4
Интересно…

То есть если в го (жава и т.д) мне что б понять если может прилететь nil, мне нужно просмотреть код… и найти того кто вместо *something может мне кинуть nil, то в Rust я это вижу явно, что не дает мне возможности пропустить хендлинг этого случая?
+2

Именно.


Правда, тут есть другие проблемы:) Например, эти проверки начинают заражать ваш код. Да, для этого есть сахар, что упрощает жизнь. Но, в любом случае, вам придётся писать много преобразований из одного типа ошибки в другой или агрегировать их в discriminated unions (или, что ещё ужаснее, вызывать панику), чтобы хоть как-то разрулить многообразие ситуаций в работе программы.


let cool_result = match cool_function() {
    Ok(result) => result,
    Err(error) => return Err(error),
}; // длинный вариант
let cool_result = cool_function()?; // короткий вариант.

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

0

Ну, пишущего на Go с его if err != nil return err заражением кода не испугать :-)


И оверхеда эти проверки дают столько же.

+1
Это да… меня пока что пугает вот такое. Ломает мне мозг.

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

Пройдет ли с практикой чувство того что ты не читаешь код а расшифровываешь?
0

Ну, это обратная сторона однозначности. Вот пример — Джава тоже очень многословна. И ничего — как-то же энтерпрайз код пишут!?

+1

Ну, я не вижу в этом фрагменте кода ничего сложного, так что наверное со временем ощущение "расшифровки" должно пройти.


Кстати, функцию выше можно переписать более коротко:


fn map<T, A>(option: Option<T>, f: impl FnOnce(T) -> A) -> Option<A> {
    match option {
        None => None,
        Some(value) => Some(f(value)),
    }
}
0
А почему не использовать map у option? В расте, как я вижу, такой метод есть. В функциональных языках обычно результат из option не вытаскивают, пока это возможно, а работают внутри него.
Или and_then.
+1
Но, в любом случае, вам придётся писать много преобразований из одного типа ошибки в другой или агрегировать их в discriminated unions (или, что ещё ужаснее, вызывать панику), чтобы хоть как-то разрулить многообразие ситуаций в работе программы.

Если мне пофиг на точную обработку ошибок (т. е. мне нужно просто их прокинуть наверх и распечатать), то я просто буду возвращать что-нибудь вроде anyhow::Result.

+2
Интересный подход… есть еще языки использующие такой трюк?

Любые [современные] функциональные.


Вообще, такой трюк можно провернуть с любым современным языком кроме Go, но наличие в языке null частично испортит подобный подход.

0
Почему в Go то нельзя, чем он отличается в данном кейсе от других современных языков с null? Да, нет generic-ов, но можно добавить структуру вручную:
type EventResult struct {
	Event *Event
	Err   error
}

Другое дело, что в обычных функциях такой подход не является идиоматичным, но например в каналах такие структуры используются для проталкивания ошибок наверх потребителям.
+3
Да, нет generic-ов, но можно добавить структуру вручную:

return &EventResult{} // good luck handling it
+2
Интересный подход… есть еще языки использующие такой трюк?

Любой язык с полноценными ADT, от хаскеля до какого-нибудь окамля.

0
1. С т.з. вызывающего кода — если функция вернула 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')
+4
  1. nil — это то, что мне практически никогда не нужно (особенно с учётом того, что добавление в nil-мапу паникует). И да, я не хочу читать документацию для того, чтобы понять, является ли в данном конкретном случае значение nil валидным.
  2. В специфических случаях этот линтер не помогает. Ну и всё-таки есть разница между кодом, на который ругается линтер, и кодом, который попросту не компилируется.
0
1. Автор функции вполне может вернуть nil-мапу (не говоря уж о nil-слайсе). Это не его проблема, что вы хотите потом туда что-то добавлять (если это явно не продиктовано семантикой функции), а остальные операции с nil-мапой и так работают, так что это вполне легальный результат. Документацию просмотреть да, придется, но вы наверно и так это делаете. При отсутствии явных указаний в документации загромождать «страховочными» проверками результата на nil по мне не стоит, если только не поймали панику во время выполнения/прогоне тестов.
2. Разница есть, но она не бесплатна — сложность языка, время компиляции, кривая обучения, уровень поддержки в IDE и т.д. Любой компилятор (линтер, ...) имеет баги для некоторых исключительных/специфических ситуаций.
+1
Автор функции вполне может вернуть nil-мапу (не говоря уж о nil-слайсе). Это не его проблема, что вы хотите потом туда что-то добавлять

Логично предположить, что если у меня уже есть мапа, то я могу с ней что угодно делать, в том числе и элементы добавлять.


Документацию просмотреть да, придется, но вы наверно и так это делаете.

Ну да. Вот только в Rust мне достаточно посмотреть на тип, а именно — возвращает ли функция Option<Foo> или просто Foo — и больше вообще не морочить себе голову этим вопросом. Более того, если я ошибусь с типом, то у меня не скомпилируется код и компилятор укажет на место, где типчики не сошлись.


При отсутствии явных указаний в документации загромождать «страховочными» проверками результата на nil по мне не стоит, если только не поймали панику во время выполнения/прогоне тестов.

Особенно весело, если функция возвращает nil иногда. И этот случай вопроизводится в проде, но не у разработчика локально.

+1
В Go вам надо помнить эту особенность и при добавлении в «чужой» map (что на практике и не так часто встречается) проверять на nil. В других языках с nullable-типами проверять нужно все операции.
Я не спорю, что система типов в Rust более развита.
А что вы будете делать внутри «страховочной» проверки на nil, как будете обрабатывать эту ситуацию, которой быть вроде как быть не должно?
Функция иногда может возвращать и пустые значения других типов (строк, чисел), потому что разработчик забыл заполнить поля или случайно оставил сгенерированные заглушки. И не nil, но толку от них тоже нет, и проблемы будут только в runtime (может быть в Rust и можно реализовать compiletime-проверки с помощью макросов, например — я пока до них не добрался).
0
А что вы будете делать внутри «страховочной» проверки на nil, как будете обрабатывать эту ситуацию, которой быть вроде как быть не должно?

Вы про Go или Rust? В последнем nil нет.


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

Если разработчик забудет инициализировать поля, то его код не пропустит компилятор.

0
1. Я про Go.
2. Я имею в виду, что отсутствие явного null конечно помогает избежать части ошибок, но если разработчик забыл где-то поменять дефолтное значение инициализации (IDE сгенерировала 0 по умолчанию, например, для поля обязательного идентификатора создаваемой структуры), то компилятор на это внимания не обратит.
3. По вашей ссылке открывается что-то не то, мне кажется.
+1
Не решается ли первое добавлением своего zero value object? Другое дело что это будет конвенцией за которой тяжело уследить в большой команде или кросс тим разработке. По идее компилятор раста забирает на себя эту работу… что есть хороше как я понимаю.
0
Не решается ли первое добавлением своего zero value object?

Не решается, потому что наследования в Go нет, поэтому прозрачно подменить тип не получится.

-3
Давай пример, посмотрим. В Го сложно напортачить. У меня вот прямо вчера был тесткейз с растом, который компилировался, но не работал, как я хочу (выложу в соответствующей статье как нибудь, связан с _удобным_ синтаксисом вызова ф-ций).
0
Без примера кода непонятно в чем именно проблема, но скорее всего надо использовать select вместе с time.After (time.NewTimer) — в простейшем случае что-то типа:
select {
case <- time.After(timeout):
	println("timeout")
case <- events:
	println("event")
}

В Go by Example (рекомендуется просмотреть в дополнение к другим ресурсам) есть соответствующий пример.
+2
Эпичные пики q95 по 200-300мс, конечно. Оценить эпичность мешает незнание, как в их мониторинге агрегация идёт, конечно — по суммарной гистограмме или как максимум сигнала (от гистограмм с более высоким разрешением).
Выглядит, что принудительный запуск GC в сервисе, где вся память — LRU кеш на хеш-таблицах, сделал ребятам больно. Кто-то удивлён? Более примечательно, что у них при расшардировании сервиса на меньшие инстансы проблема уходила — это иллюстрирует, что GC всё же не абсолютное зло.
Кажется ожидаемым, что с определённого уровня масштаба (и уровня вырожденности поведения системы) любой «умный и универсальный» аллокатор/деаллокатор достигает границ своей универсальности. Сборщик мусора (автоматический деаллокатор) начинает болеть раньше и чаще. Но я встречал в реальной жизни проекты, которым glibc-шный malloc был недостаточно хорош, и его замена на специализированный возвращала много процентов производительности.
0
А интересно windows-версия скайпа таки с дельфи ушла или до сих пор там и сидит? Последнее упоминание в сети я нашёл за 14-й год, тогда ещё не ушли.
0

Возьмите исполняемый файл, на него натравить PeID или аналог и посмотрите сами. Делов-то

Только полноправные пользователи могут оставлять комментарии.  , пожалуйста.