Можно не гадать и прикидывать, а зайти на Protondb.
Согласно передовицам газет, в СССР тоже всё отлично было.
22% из "топ тысячи" игр в стиме отмечены как нативные для линукса. То есть, даже не требующие прослойки (то, что к нативным относятся игры со встроенной прослойкой, отдельная тема для разговора).
А теперь минутка реальности: "нативная" игра может быть тупо сломана месяцами (т.е. содержать критические баги), пока разработчики не изволят починить. Почему? Потому что нецелевая платформа, проблемы тысячи юзеров никого не волнуют, когда сначала надо решить проблемы 100 тысяч юзеров на венде.
75% из того же топа относятся к Gold++ уровню совместимости на protondb, что означает, что они запускаются и работают как должны, не требуя модификаций
Эм, нет. Любой Gold — это "runs perfectly after tweaks", не говоря уж о том, что рейтинг этот выставлен по принципу "миллионы мух не могут ошибаться" (в смысле, просто по отчётам пользователей). В реальности — как повезет, во-первых это танцы с бубном, во-вторых, вам даже и после танцев может просто не повезти. Как скажем с тем же киберпанком, который на каком-то железе и на каких-то линухах просто идёт с чрезвычайно хреновым fps относительно венды, и что с этим делать — никто не знает.
Мопед не мой, я просто мимо проходил На мобилах, говорят, на голой джаве если писать — то особо сильного переиспользования кода в части UI хрен добьешься.
Эстонский стартап осилил скайп без электрона, а третья по капитализации компания мира ниасилила. Вот и все тренды.
И где он сейчас, скайп без электрона? Ну хорошо, тот-то купили, но можно было б новый запилить, не? Всё легко осиливается же, не?
К тому же, вы вот привели любимый пример вомглы электрона — ну так я вам с другой стороны приведу: дискорд. Который на электроне, и при этом очень даже неплохо шевелится, и умеет во много интересных вещей. И да, сайт дискорда переиспользует код, так что из браузера его тоже можно гонять в почти том же объеме функционала.
Приведете второй пример вомглы (teams) — мне тоже найдется, чем ответить ^_^ Хотя MS Teams это вообще просто каноничный пример bloatware, т.к. оно мало того что ресурсы жрет и убогое, так там еще и нет возможности НЕ ставить клиент, чтоб нормально этим пользоваться. Тут не в электроне дело, а в том, что некоторый софт просто убогий.
Но в тренде не JVM. В тренде Electron, и это таки две большие разницы.
Потому что с электроном у вас есть сайт и приложение, которое где-то на 90% использует один и тот же код. С JVM ваш сайт надо делать отдельно силами других людей. И дело тут не в "трендах".
А уж если мобилы еще вспомнить — ууу...
Не надо мне, пожалуйста, рассказывать о том, что там есть и что "хорошо". Потому что я собственноручно пытался. 20% — это, по прикидкам, то, что действительно просто запустится и будет работать. Отплясав от души с бубном по поводу видеокарт, контроллеров, wine, и тому подобных вещей — можно подтянуть эту цифру чуть вверх. До 30% или около того.
Ну вот лично я вам сразу предложу пройти в лес с такими предложениями, например. Потому что после работы поигрываю в игрушки, а игрушек, запускающихся на линуксе — где-то процентов 20% (да и то это завоевание очень недавних времен) от тех, что запускаются на венде.
Тут вопрос что первично, и в 2000 и сейчас с разным успехом искали серебрянную пулю,
чтобы разрабатывать "не разработчиками" потому что дорого — от специальных простых языков до визуального программирования. Сейчас в моде no-code, serverless и микросервисы — вся идея, которых давайте изолируем область разработки и косяк очередного горе-разработчика на всю систему не разрастется.А вся сложность ляжет на плечи системы, она же умная справится.
Так а вы думаете, откуда берется такое рвение-то, в поисках решений, чтоб программировать непрограммистами? Вот как раз оттуда, разработчиков не хватает. И тогда не хватало, и сейчас (еще сильнее) не хватает. Дефицит не только чипов.
В итоге людей на ту работу которую раньше требовалось 10 человек теперь нужно 80.
Ага, требовалось 10, которых нынче попросту невозможно нанять. Ну, чтоб после этого дебет с кредитом сошелся. Поэтому нанимаем 80 тех, которых нанять все еще можно.
С такой задачей лет 10 назад комфортно справились бы команда человек 15, включая бизнес-аналитика и тестировщиков. У них сейчас 160.., т.е. без начальства, сопутсвующих не IT сотрудников и подснежников уж человек 80 то точно IT занимаются.
Я думаю, что вы сильно переоцениваете сроки, за которые "10 лет назад команда человек 15" запилила бы додошечке то, что они себе там наклепали. В конце концов богатое поле анекдотов про внедренцев ERP-систем возникло не само по себе, а как раз по мотивам того, как оно в 2000-е обычно внедрялось.
Есть. А люди в основном пользуются вендой. Или, когда линухом — то с каким-нибудь KDE поверх, которое тоже жрет ресурсы за обе щеки (но при этом еще и куда более корявое и бажное, чем графическая оболочка венды).
Напоминаю, что мы все еще говорим про софт для всех. Ваш пример с Linux — это фактически ответ "если тебе это по каким-то причинам неудобно, то поди нафиг". Ну вот все эти люди идут нафиг и ставят венду.
Оптимизация != оптимизированного вусмерть кода. Это и выбор алгоритмов, и уменьшение объема данных и т.д
Ну а это как раз должны бы сразу писать нормальные программисты, без последующей оптимизации. Не пишут? Значит у вас или программисты такие, или работают они в режиме "эту фичу со сроком разработки в человеко-месяц нужно сделать еще вчера".
Тут отдельная команда оптимизаторов — это попытка вычерпать реку ложкой.
Понятно, что бабло решает. Но это не значит, что это здраво, логично и является истинной, потому что бабло. Абсурд хоть и дорогой, остается абсурдом.
Вы делаете совершенно неверный вывод. Не "бабло решает", а "иначе никто не смог". Мечтать о прекрасном софте можно очень долго, но что-то изменится только тогда, когда вы его создадите, а не помечтаете.
Требования к программистам снижаются исключительно потому, что софта надо много, а крутых программистов — настолько мало, что они даже и крошечной доли этой потребности не закрывают.
Лично я, как минимум выделил команду на оптимизацию самого прожорливого и тормозящего кода.
А команду на дальнейшую доработку оптимизированного вусмерть кода — вы тоже выделили, надеюсь? В смысле, когда ваша первая команда всё оптимизирует и в этом коде перестанут ориентироваться ваши обычные среднерыночные разработчики — кому-то придётся с этим дальше работать, не?
Причина доход\расход.
Вот именно. Софт для широких слоев пользователей вычислительной техники наиболее выгодно разрабатывать максимально дешево и продавать с относительно небольшой маржой (но всем).
Высокоэффективный софт создавать, без всяких сомнений, возможно — но тогда в пролете оказываются либо "дешево" (узкоспециализированный софт, который по определению продать можно только очень немногим — стоит как крыло от боинга), либо "быстро" (в эту категорию легко относятся все мечтания особо одухотворенных людей о новом прекрасном вебе, который надо просто сесть и сделать™).
Это вам очень сильно повезло. Потому что обычно эта самая ситуация идёт в варианте "в поте лица продолжаем катить продукт на квадратных колесах", а то еще и скатываясь в овертайм. Разумеется, любая попытка заменить колеса на круглые — встречает сильное сопротивление, и так некогда, а тут еще дивные новые предложения.
И причем в приложении к джунам — более хороших выходов из такого процесса обычно нет, это человек с длинным послужным списком еще (иногда) может чисто на авторитете смочь протащить в проект скругление колес. А ценных советов джуна обычно никто слушать не хочет.
Я тоже. А потом как "настоящий JS'ник" прихожу куда-нибудь работать и вижу там на фронте список на 100 элементов, который тормозит. Не потому, что список, и не потому, что на 100 элементов. А потому, что фронт написан настолько убого, что перерисовывается целиком на любое действие пользователя (а иногда и на бездействие тоже).
А потом прихожу работать в другое место, и вижу там то же самое. И так далее. И потом когда как пользователь хожу по тормозящему вебу — уже не удивляюсь ничему.
Дело не в HTML, и даже не в JS, а в минимизации затрат на разработку. В конце концов, я как "обычный пользователь" с андроидом вам тоже могу предъявить, что в мобилке кругом почему-то безумно тормозные и забагованные приложения. Видать, чё-то не на расте их пишут ^_^
Например, в HTML не сделать нормальные списки сообщений, в случае применения для мессенджеров. Всё тормозит.
А пацаны-то и не знают, что существует виртуализация.
Которая, кстати, становится нужна только когда ваши "нормальные списки" доходят хотя бы эдак до тысяч элементов, если вы печетесь о юзерах со старыми мобилками. И до десятков тысяч, если нет.
Если у вас "нормальные списки" начинают тормозить раньше — проблема в вас, а не в HTML.
В VSCode сталкивался только с тем, что в некоторых ситуациях он захватывал файлы проекта и не давал их удалять другим процессам. А потом и это починили.
Я не знаю, кому и что вы пытаетесь доказать, но нетрудно заметить, что по факту оно так и происходит.
Подобные требования внешних сил — это отдельное от команды явление, и ни в какие спринты оно не укладыватеся (еще бы, у сбера этих работающих-типа-по-аджайлу команд — сотни, и расписание у всех разное). В этих условиях вопрос "когда это надо сделать" вообще никак не связан (и не может быть, чисто исходя из вводных) со спринтами. Если повезет, то да, можно будет отложить, сделать, вот это всё. Если повезет.
По факту в сбере оно "Другое подразделение вывалило на вас новые требования посреди спринта? Ну, это ваши проблемы. Таких подразделений не одно, а десять, и с новыми требованиями приходят они не по одному? Всё еще ваши проблемы (с)".
В "остановиться и подумать" главное — остановиться, а не подумать. Думать-то вы всегда думаете (надеюсь). Но чтоб подумать на дальнюю перспективу, надо для начала прекратить думать на короткую.
Есть существенная разница между "не работает, и ладно" (как ваш пример с хабром), и "не работает то, за что я плачу деньги". Со второго случая спрос куда больший.
И да, у меня были и баги, и факапы, включая те, что дошли до прода. И да, я даже не нес за них прямую ответственность (потому что прямая ответственность — это сильно above pay grade обычного программиста, даже сеньора). Но косвенную — очень даже.
Вы правда считаете, что несколько быстро исправляемых случаев — это показатель того, что все очень плохо?
Нет конечно. Это показатель того, что если мне будут нужны платные курсы — деньги я понесу кому-то еще, у кого таких "быстро исправляемых случаев" нет. А так-то конечно это не "всё очень плохо".
Согласно передовицам газет, в СССР тоже всё отлично было.
А теперь минутка реальности: "нативная" игра может быть тупо сломана месяцами (т.е. содержать критические баги), пока разработчики не изволят починить. Почему? Потому что нецелевая платформа, проблемы тысячи юзеров никого не волнуют, когда сначала надо решить проблемы 100 тысяч юзеров на венде.
Эм, нет. Любой Gold — это "runs perfectly after tweaks", не говоря уж о том, что рейтинг этот выставлен по принципу "миллионы мух не могут ошибаться" (в смысле, просто по отчётам пользователей). В реальности — как повезет, во-первых это танцы с бубном, во-вторых, вам даже и после танцев может просто не повезти. Как скажем с тем же киберпанком, который на каком-то железе и на каких-то линухах просто идёт с чрезвычайно хреновым fps относительно венды, и что с этим делать — никто не знает.
Мопед не мой, я просто мимо проходилНа мобилах, говорят, на голой джаве если писать — то особо сильного переиспользования кода в части UI хрен добьешься.И где он сейчас, скайп без электрона? Ну хорошо, тот-то купили, но можно было б новый запилить, не? Всё легко осиливается же, не?
К тому же, вы вот привели любимый пример вомглы электрона — ну так я вам с другой стороны приведу: дискорд. Который на электроне, и при этом очень даже неплохо шевелится, и умеет во много интересных вещей. И да, сайт дискорда переиспользует код, так что из браузера его тоже можно гонять в почти том же объеме функционала.
Приведете второй пример вомглы (teams) — мне тоже найдется, чем ответить ^_^ Хотя MS Teams это вообще просто каноничный пример bloatware, т.к. оно мало того что ресурсы жрет и убогое, так там еще и нет возможности НЕ ставить клиент, чтоб нормально этим пользоваться. Тут не в электроне дело, а в том, что некоторый софт просто убогий.
Потому что с электроном у вас есть сайт и приложение, которое где-то на 90% использует один и тот же код. С JVM ваш сайт надо делать отдельно силами других людей. И дело тут не в "трендах".
А уж если мобилы еще вспомнить — ууу...
Не надо мне, пожалуйста, рассказывать о том, что там есть и что "хорошо". Потому что я собственноручно пытался. 20% — это, по прикидкам, то, что действительно просто запустится и будет работать. Отплясав от души с бубном по поводу видеокарт, контроллеров, wine, и тому подобных вещей — можно подтянуть эту цифру чуть вверх. До 30% или около того.
Ну вот лично я вам сразу предложу пройти в лес с такими предложениями, например. Потому что после работы поигрываю в игрушки, а игрушек, запускающихся на линуксе — где-то процентов 20% (да и то это завоевание очень недавних времен) от тех, что запускаются на венде.
Так а вы думаете, откуда берется такое рвение-то, в поисках решений, чтоб программировать непрограммистами? Вот как раз оттуда, разработчиков не хватает. И тогда не хватало, и сейчас (еще сильнее) не хватает. Дефицит не только чипов.
Ага, требовалось 10, которых нынче попросту невозможно нанять. Ну, чтоб после этого дебет с кредитом сошелся. Поэтому нанимаем 80 тех, которых нанять все еще можно.
Я думаю, что вы сильно переоцениваете сроки, за которые "10 лет назад команда человек 15" запилила бы додошечке то, что они себе там наклепали. В конце концов богатое поле анекдотов про внедренцев ERP-систем возникло не само по себе, а как раз по мотивам того, как оно в 2000-е обычно внедрялось.
Есть. А люди в основном пользуются вендой. Или, когда линухом — то с каким-нибудь KDE поверх, которое тоже жрет ресурсы за обе щеки (но при этом еще и куда более корявое и бажное, чем графическая оболочка венды).
Напоминаю, что мы все еще говорим про софт для всех. Ваш пример с Linux — это фактически ответ "если тебе это по каким-то причинам неудобно, то поди нафиг". Ну вот все эти люди идут нафиг и ставят венду.
Ну а это как раз должны бы сразу писать нормальные программисты, без последующей оптимизации. Не пишут? Значит у вас или программисты такие, или работают они в режиме "эту фичу со сроком разработки в человеко-месяц нужно сделать еще вчера".
Тут отдельная команда оптимизаторов — это попытка вычерпать реку ложкой.
Вы делаете совершенно неверный вывод. Не "бабло решает", а "иначе никто не смог". Мечтать о прекрасном софте можно очень долго, но что-то изменится только тогда, когда вы его создадите, а не помечтаете.
Требования к программистам снижаются исключительно потому, что софта надо много, а крутых программистов — настолько мало, что они даже и крошечной доли этой потребности не закрывают.
А команду на дальнейшую доработку оптимизированного вусмерть кода — вы тоже выделили, надеюсь? В смысле, когда ваша первая команда всё оптимизирует и в этом коде перестанут ориентироваться ваши обычные среднерыночные разработчики — кому-то придётся с этим дальше работать, не?
Вот именно. Софт для широких слоев пользователей вычислительной техники наиболее выгодно разрабатывать максимально дешево и продавать с относительно небольшой маржой (но всем).
Высокоэффективный софт создавать, без всяких сомнений, возможно — но тогда в пролете оказываются либо "дешево" (узкоспециализированный софт, который по определению продать можно только очень немногим — стоит как крыло от боинга), либо "быстро" (в эту категорию легко относятся все мечтания особо одухотворенных людей о новом прекрасном вебе, который надо просто сесть и сделать™).
Это вам очень сильно повезло. Потому что обычно эта самая ситуация идёт в варианте "в поте лица продолжаем катить продукт на квадратных колесах", а то еще и скатываясь в овертайм. Разумеется, любая попытка заменить колеса на круглые — встречает сильное сопротивление, и так некогда, а тут еще дивные новые предложения.
И причем в приложении к джунам — более хороших выходов из такого процесса обычно нет, это человек с длинным послужным списком еще (иногда) может чисто на авторитете смочь протащить в проект скругление колес. А ценных советов джуна обычно никто слушать не хочет.
Я тоже. А потом как "настоящий JS'ник" прихожу куда-нибудь работать и вижу там на фронте список на 100 элементов, который тормозит. Не потому, что список, и не потому, что на 100 элементов. А потому, что фронт написан настолько убого, что перерисовывается целиком на любое действие пользователя (а иногда и на бездействие тоже).
А потом прихожу работать в другое место, и вижу там то же самое. И так далее. И потом когда как пользователь хожу по тормозящему вебу — уже не удивляюсь ничему.
Дело не в HTML, и даже не в JS, а в минимизации затрат на разработку. В конце концов, я как "обычный пользователь" с андроидом вам тоже могу предъявить, что в мобилке кругом почему-то безумно тормозные и забагованные приложения. Видать, чё-то не на расте их пишут ^_^
А пацаны-то и не знают, что существует виртуализация.
Которая, кстати, становится нужна только когда ваши "нормальные списки" доходят хотя бы эдак до тысяч элементов, если вы печетесь о юзерах со старыми мобилками. И до десятков тысяч, если нет.
Если у вас "нормальные списки" начинают тормозить раньше — проблема в вас, а не в HTML.
Большой — это сколько в цифрах?
В VSCode сталкивался только с тем, что в некоторых ситуациях он захватывал файлы проекта и не давал их удалять другим процессам. А потом и это починили.
О чем и идет речь в этой ветке комментариев.
Я не знаю, кому и что вы пытаетесь доказать, но нетрудно заметить, что по факту оно так и происходит.
Подобные требования внешних сил — это отдельное от команды явление, и ни в какие спринты оно не укладыватеся (еще бы, у сбера этих работающих-типа-по-аджайлу команд — сотни, и расписание у всех разное). В этих условиях вопрос "когда это надо сделать" вообще никак не связан (и не может быть, чисто исходя из вводных) со спринтами. Если повезет, то да, можно будет отложить, сделать, вот это всё. Если повезет.
По факту в сбере оно "Другое подразделение вывалило на вас новые требования посреди спринта? Ну, это ваши проблемы. Таких подразделений не одно, а десять, и с новыми требованиями приходят они не по одному? Всё еще ваши проблемы (с)".
В "остановиться и подумать" главное — остановиться, а не подумать. Думать-то вы всегда думаете (надеюсь). Но чтоб подумать на дальнюю перспективу, надо для начала прекратить думать на короткую.
Есть существенная разница между "не работает, и ладно" (как ваш пример с хабром), и "не работает то, за что я плачу деньги". Со второго случая спрос куда больший.
И да, у меня были и баги, и факапы, включая те, что дошли до прода. И да, я даже не нес за них прямую ответственность (потому что прямая ответственность — это сильно above pay grade обычного программиста, даже сеньора). Но косвенную — очень даже.
Нет конечно. Это показатель того, что если мне будут нужны платные курсы — деньги я понесу кому-то еще, у кого таких "быстро исправляемых случаев" нет. А так-то конечно это не "всё очень плохо".