А что если ошибка начала возникать с какой-то периодичностью у всех пользователей?
Ну вот тогда уже начнут зажигаться красные лампочки и слаться SMSки.
Вы сами себе это придумали. У меня не один инстанс
Тогда откуда взялись ваши же слова про недопустимость падения?
и даже если бы был один я бы(бизнес, который меня нанял) деньги бы не терял
Опять двадцать пять. Если инстранс один, то их может, внезапно, стать и ноль — по совершенно независящим от вас причинам. И либо для вас это допустимо, либо нет. Если это недопустимо — то вам нужно дублирование. И проблем с C++ нет. Если допустимо… то допустимо — и проблем нет изначально.
У Вас какое-то странное представление о бизнесе. Конечно, первое что предпримет средней руки организация — начнёт скупать ЦОДы по всему миру и нанимать С++-богов, которые наклепают им профессиональный софт, который крешится и повреждает данные на каждый чих.
Знаете — эту сказку про белого бычка пора кончать. Про это Джоел уже тоже писал. Если вы — «средней руки бизнес» и не можете себе позволить качественный софт, то вы берёте условного «дешёвого индуса», Java и получаете… что-то. Оно кривое, косое, неудобное и глючит — но оно дёшево стоило, а это для вас главное.
Если вы можете себе это позволить и вам нужно качество — то вы нанимаете нормальных программистов и даёте им в руки C++ или MISRA C++ или вообще Аду.
Если бы все эти ужасы про C++ и мнимые преимущества GC и Java имели какое-то отношение к реальности — то мы бы все сейчас пользовались браузерами на Java (или C#) и подобными же Web-серверами. Потому что сегодня это — самые очевидные точки для атака на вашу безопасность на любом предприятии, независимо от масштабов.
Однако же реальность, в нашем мире — совсем другая. И выше отрицание очевидного ничего тут не изменит.
Если речь идёт про 90е (а речь похоже о них), то там ипотеку давали под 36% в валюте и попытавшись в неё ввязаться можно было с большей вероятностью оказаться на улице, чем в новой квартире.
Зачем держать множество ссылок, если можно ссылаться на один объект, и его модифицировать(или менять через прокси)?
Обычное RCU. Если вам не требуется, чтобы данные были верны именно на текущую миллисекунду, то гораздо проще разрешить продолжать использовать старые данные для тех запросов, которые начали исполняться во время получения обновления… а уже новые — будут идти с обновлёнными данными.
С++ позволит Вам вычислить по прошлогоднему курсу, позапрошлогоднему, вообще любому курсу. Стало намного лучше?
Да. Если, вдруг, компьютер выдаст кому-то, как у Хайнлайна, «чек на 10 000 000 000 000 185,15 долларов-купонов» — то, во-первых, по этому чеку никто никому ничего не выдаст, а во-вторых — это будет немедленно поводом начать разбираться в том, что у нас тут в системе происходит.
Мы читаем, какие битые данные?
Не влазящие в буфер, например.
Никакой С++ вас от падения цода не спасёт.
Это почему вы так в этом уверены? Вы когда-нибудь читали о том, что где-то данные Gmail стали недоступны из-за того, что ему кабель в Орегоне перерезали? Нет? А почему нет? Подумайте над этим.
И если ваш ответ: «этого не произошло потому что их датацентры никто никогда не отключал»… то ответ неверный. Мы точно знаем, что это случалось — просто потому что это тожетестируется.
Другое дело когда Ваша супер надёжая прога крешится и все в панике с дебагером в зубах начинают искать ошибку, а на Java в кибане появляется красноречивый стектрейс.
Во-первых с чего вы решили, что когда программа закрешится — там не будет стектрейса. Во-вторых — какая паника? Запрос пошлют три раза, после чего тому, кто его инициировал, покажут сообщение об ошибке и всё. Три упавших сервера как легли, так и поднимутся.
И пока Вы ищите, бизнес теряет деньги.
Это извините, у вас он будет терять деньги если вы всё завязали на один instance одного сервера и он, несмотря на все костыли, упадёт. У нас — об инциденте никто и не узнает, кроме тех, кому нужно будет код чинить.
Дальнейшие рассуждения(про железо) пропущу что-бы не разводить полемику(по моему мнению никакого отношения к реальности они не имеют).
Ну да, ведь так же легко засунуть голову в песок и сделать вид, что проблемы не существует.
Вы хорошо описали, почему не стоит слушаться заказчика (с этим я в принципе согласен), но не описали, почему нужно слушаться Вас.
А с этим всё проще — меня не нужно слушаться если со мной не работать. А если работать — то вопрос, как бы, отпадает.
Просто поймите, что для рядового программиста Вы и есть тот самый заказчик.
А! Вы в этом смысле. Я даже как-то не подумал, что тут можно так понять.
Ну не верит он, что в этом sql нужен O(logn), что делать?
Делать свою версию, если он в ней уверен. Только потом ему нужно будет доказать, что она лучше.
Понимаете — у любого заказчика (и у меня в том числе) всегда есть в запасе опция «не принять работу». И мне это сделать гораздо проще, так как в отличие от менеджера с его семью красными линиями я могу это всё сделать и сам.
Ну а если у вас не примут работу раз, два, три… десять… то тут уже и об увольнении можно говорить — так ведь?
Поймите, рядовым программистам тоже нужно откуда-то получать фидбек
Того, что они от своих коллег и заказчиков получают — недостаточно?
И откуда я знаю, добрался он до этой части кода или нет.
А почему это для вас, в принципе, важно? У нас есть компоненты, которые начинают использловаться и через год после написания. И человек, написавший этот компонент — может и уволиться (или просто перейти в другой отдел), к моменту, когда этот компонент кто-то, кроме автотетестов «пощупает».
И обнаружить закладки такого рода — было бы очень неприятно.
Да и не нужно это: если у вашего компонента никогда ничего не ломается без этих ваших закладок, то я вам завидую белой завистью.
Вот, из свеженького: наши очередные правки подобрали… и наш компонент поломал всем, кто его использует, билд. Ну кто мог предположить что макрос CHECK можно использовать в constexpr-выражении… но только если ты не используешь clang-tidy?
Пришлось забивать костыль. Upstream, надо сказать должное, отреагировал быстро, в следующей версии костыль можно будет убрать.
И вот такого… хватает безо всяких искусственно вставленных проблем.
А зачем? У меня есть замечательный телефон, на котором прекрасно работают приложения.
А у меня есть телефон, где они работают отвратительно, когда батарейка садится и скорость процессора снижается.
Объясните нормально задачу.
Это не задача, а решение. Задача простая: наш сервис перегружает сервер, раздающий, скажем, курс валют из-за того, что мы туда посылаем миллион QPS. Нас попросили это исправить. Так как курс валют меняется редко, то напрашивающееся решения — кеширование.
Дальше — беда: как известно в программировании есть только две сложные вещи: инвалидация кэша и наименование сущностей. Мы с первой проблемой не справились и продолжаем где-то держать ссылку на курсы валют, которые были загружены при первом образщении. А сервис обновления мастер-таблицу периодически в памяти обновляет и старые данные стирает.
Так вот в C++ в этом месте образуется «висячая ссылка», программа упадёт и мы её починим. А в Java — мы будет пересчитывать данные по курсу годичной давности, пока это аудит не заметит и нам штраф не выпишут…
В любом случае — здесь Java максимум вернёт устаревшие данные. С++ же сокорее вернёт устаревшие, может вернуть вообще рандом. Да и сегфолда тут не будет.
Сегофолт будет, когда fortify обнаружит «битые» данные.
Т.е. Вы считаете что невозможность корректно обработать ошибку — преимущество С++?
Как раз невозможность корректно обработать ошибку наблюдается в вашей «ынтырпрайз системе» на Java. Вот тут: Неожиданное завершение Java программы — недопустимо(речь о enterprise и серверах).
Если ваша система не готова к том, что у вас вдруг, внезапно, отрубят целиком датацентр — то она ненадёжна. Потому что такое иногда случается. А если вы готовы к тому, что у вас, вдруг, исчезают из системы отдельные датацентры, сервера, и процессы — то падение процесса — не есть что-то страшное. Вот и всё.
К сожалению по историческим причинам (когда-то компьютеры миллионы долларов за штуку стоили, покупать в количестве 10x было невозможно) очень много «ынтырпрайза» построено именно как ненадёжные системы — с одним центральным уязвимым компьютером. Да, его стараются сделать понадёжнее, там могут даже иногда стоять несколько процессоров с горячей заменой и прочие чудеса — но всё равно это паллиатив. Потому что от пожара или, не знаю, Боинга в небоскрёб — это всё равно не защитит.
Что самое смешное — сделать надёжную систему будет ещё и дешевле, так как вместо IBM Z с космическим ценником вы можете использовать куда как более дешёвое железо. И да — оно будет дешевле даже с учётом многократного дублирования.
И, что характерно, ни один из этих проектов ничего под ART не транслирует.
Да, сделать виртуальную машину, поверх которой можно запустить и C++ и Go и Java и вообще всё, что угодно — как бы можно…
Вот только это делает проблемы с GC ещё более неприятными. Так как теперь, когда вы пишите программ на Go — вы должны учитывать не только особенности оригинальной реализации, но ещё и gccgo и RemObjects и прочего, прочего, прочего.
Да, можно вставть в позу и объяснять, что это у всех «неправильный» C#, а «правильный» — только под Windows (или, шире, там где .NET Core портировали)… но с C++ таких вещей — гораздо меньше.
Разные компиляторы могут геренить разный код, кто-то лучще, кто-то хуже, но разница там не «1ns vs 1s»…
Как ни странно оба эти качества необходимы для того, чтобы получить качественный результат. И как и все банальности, касающиеся IT они обсосаны давным давно.
Если коротко, то игнорировать требования заказчика необходимо, так как он не знает чего хочет (знал бы — был не заказчиком, а вашим коллегой) — и делать это нужно тогда, когда заказчик явно требует вещей, которые ему не нужны. Ссылку на этот опус я Джоеля уже давал.
Sql-запрос за логарифм, а не зна O(n) — это в 99% случаев существенное замедление программы на ровном месте. И да, нужно уметь замечать, когда такое происходит и исправлять. И про это Джоел писал (он вообще, похоже успел описать все «банальные истины», какие существуют в мире IT… но они их можно крутить как угодно — но это всё равно истины).
Я вообще не понимаю что вас удивляет. Ну вот рассмотрите человека более традиционной, всем понятной, профессии. Ну, например, плотника. Приходит к вам кто-то и заказывает табуретку с ногами разной длины. Объяснений нет: «Вам ставят задачи, вы их решаете». Плотник, естественно, говорит вам, что это не табуретка, а чёрт знает что и требует пояснений. Оно нормально или нет? Или нормально сделать табуретку, а потом получать от клиента жалобы, что даже несмотря на ноги разной длины она на его кривом полу стоять отказывается?
Иногда можно убедить плотника сделать «что-то странное» произнеся магические слова «под мою ответственность» и дав ему чертежи… но в целом отказ делать вещь, которая потом принесёт ему только головную боль — в случае с плотником сомнений не вызывает.
С другой стороны, если тот же плотник сделает табуретку использовав для этого золотые гвозди или, наоборот, какою-нибудь дешёвую, но токсичную деревеплиту — вряд ли он заслужит эпитета «хороший», ведь так?
Так почему тот же самый подход к программированию вызывает вопросы?
Никто не гарантирует что х1 так же внезапно не закончится, когда весь ваш департамент заменят на простой скрипт/сдадут индусам-аутсорсерам/ваш «гений»-руководитель уволится.
Поверьте, «индусов» способных грамотно спроектировать оборудование для нефтедобычи — в мире не так много.
Лучше уж год получать х5, а затем будет ещё 4 года за которые можно будет освоить любую более воствребованную и денежную специальность.
Вот только люди, так рассуждающие, почему-то до сих пор так и воюют с индусами-аутсорсерами, в то время, как люди, меряющие успех не только деньгами — часто получают совсем другие деньги.
Потому что никакой, ну вот никакой гарантии того, что в специальность, которую вы освоите за эти 4 года не набегут индусами-аутсорсеры — нет.
А вот если вы сохраните компанию, где есть специальность, которой в мире человек 100 владеют — то лет через 5-10 сможете зарабатывать весьма неплохие деньги.
Да, есть специальности, в которых компании всё равно проиграли, и всё равно всё закрылось… но есть и те, где разработчики вполне себе получают неплохие деньги.
Запустите на процессоре где-нибудь в 200-300MHz, потом говорите. Аккуратно написанный C++ код на таком «летает».
Конечно если писать всё через задний проход, то тормоза можно устроить на любом языке.
В С++ это не работает — т.к. нет единого интерфейса для взаимодействия библиотек.
Это как?
Насколько я понимаю, это вообще не имеет отношение к перечисленным проблемам.
А к чему это имеет отношение? Вы вообще когда-либо видели хоть от кого-нибудь задание «сделать так, чтобы программы выдала чёрт-знает-что, не важно что, главное чтобы не упала»?
Нет же. Задачи пишутся для решения кокретных задач. И то, что в случае с C++ задача очевидным образом не решена (программа падает), а в случае с Java он неочевидным образом не решена (программа возвращает чушь)… так для бизнеса первый вариант предпочтительнее даже.
Неожиданное завершение Java программы — недопустимо(речь о enterprise и серверах).
Если у вас «enterprise» — это «нам нужно не дорого, а очень дорого», тогда да.
А если вы хотите дёшево, тогда проще разрешить программам падать и обеспечить надёжность с помощью дублирования. Ну и, конечно, каждая программа должна выполнять одну задачу.
То, что в enterprise до сих пор, зачастую, делается не так — это просто доведение принципа «работает — не трогай» до предела, до маразма, до апофигея. Ситуации, когда у вас, действительно, требуется, чтобы всё крутилось на одной машине редки, как единороги. В большинстве случаев всё упиратся в подход «так отцы и деды делали, так и мы будем делать».
Забавно только, что как раз «деды» отлично без GC обходились, а их «внукам» — он просто вот позарез необходим.
Это если у тебя специальность такая, что новое место и новая зарплата гарантированы.
А если ты спец с редкой специальностью, то выбор — либо уйти обрано на x1 и продолжать работать ещё несколько лет, либо — получать год x5, а потом работать уборщиком.
При таком раскладе x5 уже не выглядит так привлекательно…
Редактировал, вроде всё хорошо. Икеей не пользовался, что это должно мне показать?
Посмотрите если будете там. У них программа как раз на вот этих вот «бизнес-языках», где любая операция занимает секунд по 5-10. Притом, что данных в базе у них явно на порядок меньше, чем в Wikipedia.
И не нужно мне говорить про то, что «ведь IKEA нужна супернадёжность» — это нифига не так. Единственное, что должно происходить надёжно — это финальная «фиксация» заказа, когда он становится готовым к оплате… да даже и там это, на самом деле, не требуется: вы же можете заказать со стелажа товар, который оттуда кто-то уже забрал!
То есть фактически только учёт на кассе должен быть 100% надёжным… ну и тогда с какого перепуго оно всё тормозит нещадно?
Это и так понятно, но в любом случае без ГЦ придётся потратить больше времени как на разработку, так и на поддержку.
Совершенно неочевидно. ARC (и его аналоги в C++ и Rust) вполне достаточен для разруливания 99% проблем. А последний 1% и с GC всё равно проблемный.
Без значимых преимуществ.
Значимое преимущество — предсказуемое время работы и потребление памяти. Для GUI — это важно.
Даже «идеальный код» с ГЦ проще писать и поддерживать по сравнению с «идеальным кодом» без него.
Нет. Как я уже сказал: ARC, «умные указатели» и «арены» (в C++), borrow checker (в Rust) решают подавляющее большинство проблем.
А патологические случаи могут быть как в пользу GC, так и наоборот.
Но в _любом_ другом софте на С++, написанным профессионалом любого уровня, неизбежно есть полный набор этих ошибок.
А в Java их нет? Хотите сказать что никогда не получали документов, где фигурировали устаревшие данные или вообще данные от других людей?
Просто то, что в C++ приведёт, скорее всего, к падению — в Java приведёт к неверным результатам. Скажем если у вас где-то в памяти табличка с какими-нибудь курсами валют, но при обновлении ссылку на неё забывают обновить. В C++ будет «висячая ссылка» и программа упадёт, а в Java — она даст невероные результаты. И тут уж я не знаю что лучше.
Да, что выпадания «в кору» у C++ случается часто — все знают. А вот про альтернативу в Java (а это неверные рассчитаные результаты) — почему-то забывают…
В типичной для бизнеса модели взаимодействия, скорость практически всегда упирается в бд, а Java и так довольно быстрая.
А вы никогда не редактировали Wikipedia? Или хотя бы просматривали? И не сравнимали это с тем, как работает, скажем, программа по заказу товара в IKEA? Думаете покуптели IKEA делают больше заказов в секунду, чем посетители Wikipedia — правок в базе Wikipedia?
И бизнес готов переплачивать в замен на (относительную)надежность и скорость разработки и поддержки.
Бизнес вначале нанимает условных «дешёвых индусов», которые порождают ад в коде… а потом уже поздно.
Тут уместнее всего примерно такой диалог (сказанный в совсем другое время по совсем другому поводу, но суть передающий на 100%):
— Теперь еще один технический вопрос — имейте в виду, товарищ Клямер, технический, а не припнципиальный, — скажите, коротко только, почему вам нужно не сорок воспитателей, а пятнадцать, и почему вы против оклада в сорок рублей?
Я подумал и ответил:
— Видите ли, если коротко говорить: сорок сорокарублевых педагогов могут привести к полному разложению не только коллектив беспризорных, но и какой угодно коллектив.
Бритый вдруг откинулся на спинку кресла в открытом закатистом смехе и, показывая пальцем, спросил сквозь слезы:
— И даже коллектив, состоящий из Клямеров?
— Неизбежно, — ответил я серьезно.
Вот и условные «индусы» пытающиеся решать задачу методом добавления случайных мутаций в код с последующим прогоном тестов — могут привести код на любом языке в невменяемое состояние. Просто код с GC (и, особенно, на Java) дольше сопротивляется, вот и всё.
Будьте уверены, когда у вас килотонна взаимодействующих компонентов разного качества, и вам нужно срочно добавить/изменить функционал, последнее с чем Вы захотите столкнуться — это ub, повреждение данных, segfault, утечки и прочие радости, которые неизбежно приносит С++.
Не привносит. Всё, что нужно делать — не включать в вашу программу код написанный «индусами». Запускать их в другом процессе или вообще общаться по сети.
Да и какое дело GC одного языка до объектов другого?
Ну дык программа-то у вас одна! И если объект α (на Java — скажем «главная программа») имеет ссылку на объект β (на C# — скажем «главное окно»), который имеет ссылку на объект γ (снова на Java — скажем notificaion message)… то вам же нужно добиться как-то, чтобы ART Runtime не удалил «ненужный» ему более объект B. А на него ведь в «Java-мире» ссылок-то, идущих от корня, уже и нетути…
Мне не хватает силы эротических фантазий такое представить. Посмотреть бы на код.
хотя напрашивается решение просто транслировать вызовы системному GC.
О, это прекрасная идея, да. Начнём с нескольких постулатов.
Все объекты в памяти, управляемой GC ART соотвествуют модели объектов ART
Модель объектов ART нигде не зафиксирована и, более того, меняется от версии к версии Android
Никаких value-объектов (о которых нам тут много хорошего рассказали и которые весьма важны для программ на C# и Go) в этой модели не предусмотрено
Как будем «транспилировать»?
В принципе, наверное я неправ, и вложенные GC вполне себе работоспособны,
Ну… истина посередине, на самом деле. Вложенные схемы ARC или просто malloc/free — более, чем работоспособны. Вот просто вообще никаких проблем. Они никак друг от друга не зависят и «глобальных знаний» о программе не требуют.
Два же GC можно, в принципе, подружить между собой — введя простслойку с malloc/free и разработав соотвествующий API. Это работает, но регулярно приводит ко всем проблемам, которые вы наблюдаете в системах с ARC (утечки памяти), malloc/free (memory corruption, deadlocks и прочее) и, разумеется GC (фризы и прочее) — и всё это одновременно.
Прекрасный, прекрасный, великолепный результат! Просто, что называется, «всё жизнь мечтали».
Java-объекты, однако. Нет, понятно, что если у вас программы на C# никак с пользователем не общается, выглядит как чёрный квадрат Малевича и только батарейку потихоньку жрёт — то проблем не будет.
Но пользователи вряд ли оценят.
А вот если вас с самим Android'ом придётся общаться — то тут вы уже начнёте создавать разного рода Java-объекты (этот API в Android только в виде Java-API существует). И вам нужно будет как-то сделать так, чтобы эти объекты не исчезали пока они нужны C# программе.
Обычно тут без довольно «толстой» прослойки на C++ (или, сегодя, можно уже на Rust) не обходится.
Вроде есть какие-то эксплоиты, которые могут пробраться в телефон даже если он не презентует себя как USB-устройство (в меню «Use USB to» выбрано «Charge this device»), но тут надо чётко знать — какие именно там устройство и какой чипсет на маме и тому подобное.
Ни одного вируса, этим занимающегося, вроде как никто никогда не видел…
В вашем контракте не написано, что вы работаете работу за зарплату?
Нет — про «работать работу» там не написано. И про «исполнение всех хотелок» — тоже.
Вам ставят задачи, вы их решаете. Не будете решать — уволят, наймут другого.
Вы знаете — в контору, которая так ставит вопрос я и сам работать не пойдут. Потому что, как я уже сказал, 90% «хотелок» — просто бессмысленны. И нужно не думать как их сделать, что сделать вместо них. Как в в известной статье:
Хороший дизайнер интерьера постоянно приносит эскизы клиенту и вещи, из которых он может выбрать. Но они никогда не обсуждают с клиентом расположение посудомоечной машины. Она находится рядом с умывальником и не важно, чего хочет клиент. Нет смысла тратить время на обсуждения, где должна находиться посудомоечная машина — она должна быть рядом с умывальником, даже не начинайте разговор об этом; пусть клиенты изливают свои дизайнерские потуги делая какие-то безвредные вещи вроде изменения своего мнения 200 раз о том, нужно ли использовать для столешницы итальянский гранит или мексиканскую плитку, или норвежскую древесину.
Вот то же самое и с фронтэндом (да и с бекэндом и с чем угодно): если у заказчика возникают странные идеи (типа установки этого этой самой машины на чердаке), потому что он вычитал что это будет клёво — вы это просто игнорируете. Через неделю он всё равно всё забудет. Если клиент дотошный и всё перепроверяет — делаете так, чтобы всё было по спецификации, но работать с этим было невозможно. Он сам откажется.
Делать нужно то, для чего вы понимаете какова будет конечная цель. И нет, «так написано в документе, который мы согласовали после трёх совещаний» — это нифига не конечная цель. Конечная цель — она от бизнеса зависит. От того, как он деньги зарабатывать собрался. Если у вас нет цепочки, связывающей заработанные деньги с теми требованиями, что у вас на столе — то это всё вообще не требования, которые нужно исполнять, а «хотелки».
Это очепятка была. Не хочу я вдаваться в эти подробности.
А надо бы. Потому что хаос возникает там и только там, где вы допускаете его возникновение.
Да легко: кто вообще пользуется этим дурацким Firefox? Полтора пользователя, которые никому не нужны?
Принимается. В рамочку и на стену. А теперь посчитаем: Firefox пользуются 9.92% пользователей. И на них забили. То есть «порог отсечения» у нас — что-то в районе 3-5%. Теперь вы тут рассказываете про «мозоль на лбу»… у какого процента пользователей эти самые ноутбуки с тасчринами от HP или Lenovo? 0.1%? 1%? Вряд ли больше.
Ну а тогда они отлично идут туда же, куда и пользователи Firefox. И всё. И нет хаоса.
Если бизнес принесёт статистику, где покажет, что вот конкретно у вас таких пользователей 50% (ну например вы делаете сайт для школ, а им централизованно такие лапотомы закупили) — тогда да, придётся корячиться.
Но у вас не могут быть одновременно 50% пользователей с лаптопами HP или Levono, 50% пользователей iPhone и 50% пользователей Android. Математика, знаете ли.
Так что снова никакого хаоса.
Разруха — она не в клозетах, разруха — она в головах.
Ваша самоуверенность вполне типична для back end разработчика, который заглядывал во front end пару раз, не осилил, и теперь делает очень категоричные заявления о том, что реально нужно для большей части сайтов.
С вашей самоуверенностью в том, что никаких других программистов, кроме фронтэндеров и бакэндеров в природе не бывает — это всё равно не сравнить.
Видимо компиляторы или, скажем, софт для вашей стиральной машины — они самозарождаются. Ну или может их эльфы в другой вселенной пишут.
Если вы относите в категорию «не осилил» отказ от игры в игру «чего изволите» — то вы на 100% правы.
А так — я и фронтэнд делал, для стартапа, который потом купили за неплохие деньги и Win32 GUI (для другого стартапа) и пролжоения для мобильных устройств (нет, не для сотовых), лет пять назад пилил порт GCC на одну интересную архитектуру… и нет, «не осилил» — нигде не было. Но и «чего изволите» — не было тоже.
Один только проект был, когда я был «молодой и зелёный» и когда я одну кнопку добавлял две недели (потому что её мог налисовать, там где этого хотел заказчик, только драйвер, а он не имел доступа к GUI, а API изначально не предполагал передачу данных в эту сторону по инициативе приложения, так что его пришлось менять… в общем много чего там было).
Когда я это всё обсудил с заказчиком, то он, конечно, мне всё это оплатил (совестливый был человек, мы с ним потом ещё много лет работали), но задал разумный вопрос: «а почему, когда выяснилось, что это — задача не на два часа, а на две недели… я, чёрт побери, не обсудил это со мной?»
Мой ответ «ну так же было в техзадании написано» его, мягко скажем, не воодушевил. Именно тогда, задолго до чтения статьи Джоела — я понял, что заказчик, в общем-то нифига не понимает что ему реально нужно.
Чуть позже я обнаружил, что есть-таки случаи, когда заказчик твёрдо уверен в том, что он знает что ему нужно… это тогда, когда заказчик — это не конечный заказчик, но посредник (ваш менежер или продажник или, может быть, менеджер со стороны закачика)… но тут ещё смешнее: все эти люди продают мою, ещё не сделанную работу — и берут за это деньги.
Ну так в этом случае это они у меня на крючке, а не я у них: деньги-то они уже получили (или считают, что получили), а работу-то я не сделал. И если я её не сделаю — то вся их долгая деятельность по уговору реального заказчика и подписанию договоров — полетит коту под хвост.
Единственный вариант, когда с заказчиком в принципе никак нельзя договорится, потому что он может вас уволить и нанять на ваше место «дядю Васю с улицы» — это когда то, что вы делаете, может сделать любой дядя вася надёргав кусков куда со StackOverflow… но стоит ли за такую работу держаться?
Остальные запрещения прерываний действуют одинаково на все программы, что с GC, что без.
Нет. Вот ни разу не так. Обычному аллокатору или ARC не интересно и не нужно знать — что там происходит в других потоках. Вся работа с памятью — локальная (tcmalloc, скажем, выделает пулы как раз под потоки и большинство аллокаций оттуду обслуживает).
Более того — если у вас будут части, написанные на разных языках — они могут использовать разные схемы работы с памятью… и это не вызовет никаких проблем.
Для GC это, в некоторых случаях необходимо. Соотвественно GC начинает влиять на потоки, где его деятельность не нужна и неинтересна.
Это проблемы частной реализации, не более. Зачем?
Потому что если он этого делать не будет, то возможна, например, ситуация, когда объект Java удерживает объект C#, а тот, в свою очередь, держит другой объект Java. Если GC не сможет эту цепочку отследить — то это добром не кончится.
Так делать нельзя, это ничем не лучше запрещенной тематики использования в проге и в dll двух менеджеров памяти, а точнее частный случай такого.
Я даже не знаю — смеяться тут или плакать. Вы вообще так, в принципе, в курсе, что если вы статически линкуете MSVCRT в вашу DLL'ку (а это вполне себе не редкость), то у вас в программе будет 2, 3, 10 менеджеров памяти? Что куча народу так делала 10, 20 и более лет назад… и сегодня делает.
Ну Ok, ладно, допустим мы приняли парадигму, что два GC в одном процессе у нас жить не должны. Годится.
Теперь мы хотим портировать программу на C# (ну или Go — неважно) под Android, где в каждом процессе уже есть GC от ART. Который ни про C#, ни про Go не знает или знать не будет.
Тогда откуда взялись ваши же слова про недопустимость падения?
Опять двадцать пять. Если инстранс один, то их может, внезапно, стать и ноль — по совершенно независящим от вас причинам. И либо для вас это допустимо, либо нет. Если это недопустимо — то вам нужно дублирование. И проблем с C++ нет. Если допустимо… то допустимо — и проблем нет изначально.
Знаете — эту сказку про белого бычка пора кончать. Про это Джоел уже тоже писал. Если вы — «средней руки бизнес» и не можете себе позволить качественный софт, то вы берёте условного «дешёвого индуса», Java и получаете… что-то. Оно кривое, косое, неудобное и глючит — но оно дёшево стоило, а это для вас главное.
Если вы можете себе это позволить и вам нужно качество — то вы нанимаете нормальных программистов и даёте им в руки C++ или MISRA C++ или вообще Аду.
Если бы все эти ужасы про C++ и мнимые преимущества GC и Java имели какое-то отношение к реальности — то мы бы все сейчас пользовались браузерами на Java (или C#) и подобными же Web-серверами. Потому что сегодня это — самые очевидные точки для атака на вашу безопасность на любом предприятии, независимо от масштабов.
Однако же реальность, в нашем мире — совсем другая. И выше отрицание очевидного ничего тут не изменит.
Да. Если, вдруг, компьютер выдаст кому-то, как у Хайнлайна, «чек на 10 000 000 000 000 185,15 долларов-купонов» — то, во-первых, по этому чеку никто никому ничего не выдаст, а во-вторых — это будет немедленно поводом начать разбираться в том, что у нас тут в системе происходит.
Не влазящие в буфер, например.
Это почему вы так в этом уверены? Вы когда-нибудь читали о том, что где-то данные Gmail стали недоступны из-за того, что ему кабель в Орегоне перерезали? Нет? А почему нет? Подумайте над этим.
И если ваш ответ: «этого не произошло потому что их датацентры никто никогда не отключал»… то ответ неверный. Мы точно знаем, что это случалось — просто потому что это тоже тестируется.
Во-первых с чего вы решили, что когда программа закрешится — там не будет стектрейса. Во-вторых — какая паника? Запрос пошлют три раза, после чего тому, кто его инициировал, покажут сообщение об ошибке и всё. Три упавших сервера как легли, так и поднимутся.
Это извините, у вас он будет терять деньги если вы всё завязали на один instance одного сервера и он, несмотря на все костыли, упадёт. У нас — об инциденте никто и не узнает, кроме тех, кому нужно будет код чинить.
Ну да, ведь так же легко засунуть голову в песок и сделать вид, что проблемы не существует.
А! Вы в этом смысле. Я даже как-то не подумал, что тут можно так понять.
Делать свою версию, если он в ней уверен. Только потом ему нужно будет доказать, что она лучше.
Понимаете — у любого заказчика (и у меня в том числе) всегда есть в запасе опция «не принять работу». И мне это сделать гораздо проще, так как в отличие от менеджера с его семью красными линиями я могу это всё сделать и сам.
Ну а если у вас не примут работу раз, два, три… десять… то тут уже и об увольнении можно говорить — так ведь?
Того, что они от своих коллег и заказчиков получают — недостаточно?
А почему это для вас, в принципе, важно? У нас есть компоненты, которые начинают использловаться и через год после написания. И человек, написавший этот компонент — может и уволиться (или просто перейти в другой отдел), к моменту, когда этот компонент кто-то, кроме автотетестов «пощупает».
И обнаружить закладки такого рода — было бы очень неприятно.
Да и не нужно это: если у вашего компонента никогда ничего не ломается без этих ваших закладок, то я вам завидую белой завистью.
Вот, из свеженького: наши очередные правки подобрали… и наш компонент поломал всем, кто его использует, билд. Ну кто мог предположить что макрос
CHECKможно использовать вconstexpr-выражении… но только если ты не используешьclang-tidy?Пришлось забивать костыль. Upstream, надо сказать должное, отреагировал быстро, в следующей версии костыль можно будет убрать.
И вот такого… хватает безо всяких искусственно вставленных проблем.
Интерфейс USB асинхронный, знаете ли.
Это не задача, а решение. Задача простая: наш сервис перегружает сервер, раздающий, скажем, курс валют из-за того, что мы туда посылаем миллион QPS. Нас попросили это исправить. Так как курс валют меняется редко, то напрашивающееся решения — кеширование.
Дальше — беда: как известно в программировании есть только две сложные вещи: инвалидация кэша и наименование сущностей. Мы с первой проблемой не справились и продолжаем где-то держать ссылку на курсы валют, которые были загружены при первом образщении. А сервис обновления мастер-таблицу периодически в памяти обновляет и старые данные стирает.
Так вот в C++ в этом месте образуется «висячая ссылка», программа упадёт и мы её починим. А в Java — мы будет пересчитывать данные по курсу годичной давности, пока это аудит не заметит и нам штраф не выпишут…
Сегофолт будет, когда fortify обнаружит «битые» данные.
Как раз невозможность корректно обработать ошибку наблюдается в вашей «ынтырпрайз системе» на Java. Вот тут:
Неожиданное завершение Java программы — недопустимо(речь о enterprise и серверах).
Если ваша система не готова к том, что у вас вдруг, внезапно, отрубят целиком датацентр — то она ненадёжна. Потому что такое иногда случается. А если вы готовы к тому, что у вас, вдруг, исчезают из системы отдельные датацентры, сервера, и процессы — то падение процесса — не есть что-то страшное. Вот и всё.
К сожалению по историческим причинам (когда-то компьютеры миллионы долларов за штуку стоили, покупать в количестве 10x было невозможно) очень много «ынтырпрайза» построено именно как ненадёжные системы — с одним центральным уязвимым компьютером. Да, его стараются сделать понадёжнее, там могут даже иногда стоять несколько процессоров с горячей заменой и прочие чудеса — но всё равно это паллиатив. Потому что от пожара или, не знаю, Боинга в небоскрёб — это всё равно не защитит.
Что самое смешное — сделать надёжную систему будет ещё и дешевле, так как вместо IBM Z с космическим ценником вы можете использовать куда как более дешёвое железо. И да — оно будет дешевле даже с учётом многократного дублирования.
Да, сделать виртуальную машину, поверх которой можно запустить и C++ и Go и Java и вообще всё, что угодно — как бы можно…
Вот только это делает проблемы с GC ещё более неприятными. Так как теперь, когда вы пишите программ на Go — вы должны учитывать не только особенности оригинальной реализации, но ещё и gccgo и RemObjects и прочего, прочего, прочего.
Да, можно вставть в позу и объяснять, что это у всех «неправильный» C#, а «правильный» — только под Windows (или, шире, там где .NET Core портировали)… но с C++ таких вещей — гораздо меньше.
Разные компиляторы могут геренить разный код, кто-то лучще, кто-то хуже, но разница там не «1ns vs 1s»…
Если коротко, то игнорировать требования заказчика необходимо, так как он не знает чего хочет (знал бы — был не заказчиком, а вашим коллегой) — и делать это нужно тогда, когда заказчик явно требует вещей, которые ему не нужны. Ссылку на этот опус я Джоеля уже давал.
Sql-запрос за логарифм, а не зна O(n) — это в 99% случаев существенное замедление программы на ровном месте. И да, нужно уметь замечать, когда такое происходит и исправлять. И про это Джоел писал (он вообще, похоже успел описать все «банальные истины», какие существуют в мире IT… но они их можно крутить как угодно — но это всё равно истины).
Я вообще не понимаю что вас удивляет. Ну вот рассмотрите человека более традиционной, всем понятной, профессии. Ну, например, плотника. Приходит к вам кто-то и заказывает табуретку с ногами разной длины. Объяснений нет: «Вам ставят задачи, вы их решаете». Плотник, естественно, говорит вам, что это не табуретка, а чёрт знает что и требует пояснений. Оно нормально или нет? Или нормально сделать табуретку, а потом получать от клиента жалобы, что даже несмотря на ноги разной длины она на его кривом полу стоять отказывается?
Иногда можно убедить плотника сделать «что-то странное» произнеся магические слова «под мою ответственность» и дав ему чертежи… но в целом отказ делать вещь, которая потом принесёт ему только головную боль — в случае с плотником сомнений не вызывает.
С другой стороны, если тот же плотник сделает табуретку использовав для этого золотые гвозди или, наоборот, какою-нибудь дешёвую, но токсичную деревеплиту — вряд ли он заслужит эпитета «хороший», ведь так?
Так почему тот же самый подход к программированию вызывает вопросы?
Вот только люди, так рассуждающие, почему-то до сих пор так и воюют с индусами-аутсорсерами, в то время, как люди, меряющие успех не только деньгами — часто получают совсем другие деньги.
Потому что никакой, ну вот никакой гарантии того, что в специальность, которую вы освоите за эти 4 года не набегут индусами-аутсорсеры — нет.
А вот если вы сохраните компанию, где есть специальность, которой в мире человек 100 владеют — то лет через 5-10 сможете зарабатывать весьма неплохие деньги.
Да, есть специальности, в которых компании всё равно проиграли, и всё равно всё закрылось… но есть и те, где разработчики вполне себе получают неплохие деньги.
Конечно если писать всё через задний проход, то тормоза можно устроить на любом языке.
Это как?
А к чему это имеет отношение? Вы вообще когда-либо видели хоть от кого-нибудь задание «сделать так, чтобы программы выдала чёрт-знает-что, не важно что, главное чтобы не упала»?
Нет же. Задачи пишутся для решения кокретных задач. И то, что в случае с C++ задача очевидным образом не решена (программа падает), а в случае с Java он неочевидным образом не решена (программа возвращает чушь)… так для бизнеса первый вариант предпочтительнее даже.
Если у вас «enterprise» — это «нам нужно не дорого, а очень дорого», тогда да.
А если вы хотите дёшево, тогда проще разрешить программам падать и обеспечить надёжность с помощью дублирования. Ну и, конечно, каждая программа должна выполнять одну задачу.
То, что в enterprise до сих пор, зачастую, делается не так — это просто доведение принципа «работает — не трогай» до предела, до маразма, до апофигея. Ситуации, когда у вас, действительно, требуется, чтобы всё крутилось на одной машине редки, как единороги. В большинстве случаев всё упиратся в подход «так отцы и деды делали, так и мы будем делать».
Забавно только, что как раз «деды» отлично без GC обходились, а их «внукам» — он просто вот позарез необходим.
А уж если вспомнить про то, что ART компилирует байткод во время установки приложения, а не после его загрузки… так и совсем «весело».
Да, у нас ART. Который принимает Dalvik-байткод и компилирует его в нативное приложение во время установки.
Ну как? Полегчало? Стало вам легче вот в это вот транслировать CLR байткод?
А никакого друого интерфейса к GC у вас нету. Никаких API, позволяющих отделить его от ARTа нет и не будет — Гуглу это нафиг не надо.
А если ты спец с редкой специальностью, то выбор — либо уйти обрано на x1 и продолжать работать ещё несколько лет, либо — получать год x5, а потом работать уборщиком.
При таком раскладе x5 уже не выглядит так привлекательно…
И не нужно мне говорить про то, что «ведь IKEA нужна супернадёжность» — это нифига не так. Единственное, что должно происходить надёжно — это финальная «фиксация» заказа, когда он становится готовым к оплате… да даже и там это, на самом деле, не требуется: вы же можете заказать со стелажа товар, который оттуда кто-то уже забрал!
То есть фактически только учёт на кассе должен быть 100% надёжным… ну и тогда с какого перепуго оно всё тормозит нещадно?
Совершенно неочевидно. ARC (и его аналоги в C++ и Rust) вполне достаточен для разруливания 99% проблем. А последний 1% и с GC всё равно проблемный.
Значимое преимущество — предсказуемое время работы и потребление памяти. Для GUI — это важно.
Нет. Как я уже сказал: ARC, «умные указатели» и «арены» (в C++), borrow checker (в Rust) решают подавляющее большинство проблем.
А патологические случаи могут быть как в пользу GC, так и наоборот.
А в Java их нет? Хотите сказать что никогда не получали документов, где фигурировали устаревшие данные или вообще данные от других людей?
Просто то, что в C++ приведёт, скорее всего, к падению — в Java приведёт к неверным результатам. Скажем если у вас где-то в памяти табличка с какими-нибудь курсами валют, но при обновлении ссылку на неё забывают обновить. В C++ будет «висячая ссылка» и программа упадёт, а в Java — она даст невероные результаты. И тут уж я не знаю что лучше.
Да, что выпадания «в кору» у C++ случается часто — все знают. А вот про альтернативу в Java (а это неверные рассчитаные результаты) — почему-то забывают…
Ну как бы уже тот факт, что IKVM существует, а ничего подобного в обраную сторону никто никогда не делал — говорит о много.
Впрочем и IKVM тоже уже Legacy, официальное решение — устраивать прослойки между двумя GC. Со всеми вытекающими.
Бизнес вначале нанимает условных «дешёвых индусов», которые порождают ад в коде… а потом уже поздно.
Тут уместнее всего примерно такой диалог (сказанный в совсем другое время по совсем другому поводу, но суть передающий на 100%):
Вот и условные «индусы» пытающиеся решать задачу методом добавления случайных мутаций в код с последующим прогоном тестов — могут привести код на любом языке в невменяемое состояние. Просто код с GC (и, особенно, на Java) дольше сопротивляется, вот и всё.
Не привносит. Всё, что нужно делать — не включать в вашу программу код написанный «индусами». Запускать их в другом процессе или вообще общаться по сети.
Ну попробуйте глянуть в исходники Xamarin.Android.
О, это прекрасная идея, да. Начнём с нескольких постулатов.
Как будем «транспилировать»?
Ну… истина посередине, на самом деле. Вложенные схемы ARC или просто malloc/free — более, чем работоспособны. Вот просто вообще никаких проблем. Они никак друг от друга не зависят и «глобальных знаний» о программе не требуют.
Два же GC можно, в принципе, подружить между собой — введя простслойку с malloc/free и разработав соотвествующий API. Это работает, но регулярно приводит ко всем проблемам, которые вы наблюдаете в системах с ARC (утечки памяти), malloc/free (memory corruption, deadlocks и прочее) и, разумеется GC (фризы и прочее) — и всё это одновременно.
Прекрасный, прекрасный, великолепный результат! Просто, что называется, «всё жизнь мечтали».
Но пользователи вряд ли оценят.
А вот если вас с самим Android'ом придётся общаться — то тут вы уже начнёте создавать разного рода Java-объекты (этот API в Android только в виде Java-API существует). И вам нужно будет как-то сделать так, чтобы эти объекты не исчезали пока они нужны C# программе.
Обычно тут без довольно «толстой» прослойки на C++ (или, сегодя, можно уже на Rust) не обходится.
Вроде есть какие-то эксплоиты, которые могут пробраться в телефон даже если он не презентует себя как USB-устройство (в меню «Use USB to» выбрано «Charge this device»), но тут надо чётко знать — какие именно там устройство и какой чипсет на маме и тому подобное.
Ни одного вируса, этим занимающегося, вроде как никто никогда не видел…
Вы знаете — в контору, которая так ставит вопрос я и сам работать не пойдут. Потому что, как я уже сказал, 90% «хотелок» — просто бессмысленны. И нужно не думать как их сделать, что сделать вместо них. Как в в известной статье:
Вот то же самое и с фронтэндом (да и с бекэндом и с чем угодно): если у заказчика возникают странные идеи (типа установки этого этой самой машины на чердаке), потому что он вычитал что это будет клёво — вы это просто игнорируете. Через неделю он всё равно всё забудет. Если клиент дотошный и всё перепроверяет — делаете так, чтобы всё было по спецификации, но работать с этим было невозможно. Он сам откажется.
Делать нужно то, для чего вы понимаете какова будет конечная цель. И нет, «так написано в документе, который мы согласовали после трёх совещаний» — это нифига не конечная цель. Конечная цель — она от бизнеса зависит. От того, как он деньги зарабатывать собрался. Если у вас нет цепочки, связывающей заработанные деньги с теми требованиями, что у вас на столе — то это всё вообще не требования, которые нужно исполнять, а «хотелки».
А надо бы. Потому что хаос возникает там и только там, где вы допускаете его возникновение.
Принимается. В рамочку и на стену. А теперь посчитаем: Firefox пользуются 9.92% пользователей. И на них забили. То есть «порог отсечения» у нас — что-то в районе 3-5%. Теперь вы тут рассказываете про «мозоль на лбу»… у какого процента пользователей эти самые ноутбуки с тасчринами от HP или Lenovo? 0.1%? 1%? Вряд ли больше.
Ну а тогда они отлично идут туда же, куда и пользователи Firefox. И всё. И нет хаоса.
Если бизнес принесёт статистику, где покажет, что вот конкретно у вас таких пользователей 50% (ну например вы делаете сайт для школ, а им централизованно такие лапотомы закупили) — тогда да, придётся корячиться.
Но у вас не могут быть одновременно 50% пользователей с лаптопами HP или Levono, 50% пользователей iPhone и 50% пользователей Android. Математика, знаете ли.
Так что снова никакого хаоса.
Разруха — она не в клозетах, разруха — она в головах.
С вашей самоуверенностью в том, что никаких других программистов, кроме фронтэндеров и бакэндеров в природе не бывает — это всё равно не сравнить.
Видимо компиляторы или, скажем, софт для вашей стиральной машины — они самозарождаются. Ну или может их эльфы в другой вселенной пишут.
Если вы относите в категорию «не осилил» отказ от игры в игру «чего изволите» — то вы на 100% правы.
А так — я и фронтэнд делал, для стартапа, который потом купили за неплохие деньги и Win32 GUI (для другого стартапа) и пролжоения для мобильных устройств (нет, не для сотовых), лет пять назад пилил порт GCC на одну интересную архитектуру… и нет, «не осилил» — нигде не было. Но и «чего изволите» — не было тоже.
Один только проект был, когда я был «молодой и зелёный» и когда я одну кнопку добавлял две недели (потому что её мог налисовать, там где этого хотел заказчик, только драйвер, а он не имел доступа к GUI, а API изначально не предполагал передачу данных в эту сторону по инициативе приложения, так что его пришлось менять… в общем много чего там было).
Когда я это всё обсудил с заказчиком, то он, конечно, мне всё это оплатил (совестливый был человек, мы с ним потом ещё много лет работали), но задал разумный вопрос: «а почему, когда выяснилось, что это — задача не на два часа, а на две недели… я, чёрт побери, не обсудил это со мной?»
Мой ответ «ну так же было в техзадании написано» его, мягко скажем, не воодушевил. Именно тогда, задолго до чтения статьи Джоела — я понял, что заказчик, в общем-то нифига не понимает что ему реально нужно.
Чуть позже я обнаружил, что есть-таки случаи, когда заказчик твёрдо уверен в том, что он знает что ему нужно… это тогда, когда заказчик — это не конечный заказчик, но посредник (ваш менежер или продажник или, может быть, менеджер со стороны закачика)… но тут ещё смешнее: все эти люди продают мою, ещё не сделанную работу — и берут за это деньги.
Ну так в этом случае это они у меня на крючке, а не я у них: деньги-то они уже получили (или считают, что получили), а работу-то я не сделал. И если я её не сделаю — то вся их долгая деятельность по уговору реального заказчика и подписанию договоров — полетит коту под хвост.
Единственный вариант, когда с заказчиком в принципе никак нельзя договорится, потому что он может вас уволить и нанять на ваше место «дядю Васю с улицы» — это когда то, что вы делаете, может сделать любой дядя вася надёргав кусков куда со StackOverflow… но стоит ли за такую работу держаться?
Более того — если у вас будут части, написанные на разных языках — они могут использовать разные схемы работы с памятью… и это не вызовет никаких проблем.
Для GC это, в некоторых случаях необходимо. Соотвественно GC начинает влиять на потоки, где его деятельность не нужна и неинтересна.
Потому что если он этого делать не будет, то возможна, например, ситуация, когда объект Java удерживает объект C#, а тот, в свою очередь, держит другой объект Java. Если GC не сможет эту цепочку отследить — то это добром не кончится.
Я даже не знаю — смеяться тут или плакать. Вы вообще так, в принципе, в курсе, что если вы статически линкуете MSVCRT в вашу DLL'ку (а это вполне себе не редкость), то у вас в программе будет 2, 3, 10 менеджеров памяти? Что куча народу так делала 10, 20 и более лет назад… и сегодня делает.
Ну Ok, ладно, допустим мы приняли парадигму, что два GC в одном процессе у нас жить не должны. Годится.
Теперь мы хотим портировать программу на C# (ну или Go — неважно) под Android, где в каждом процессе уже есть GC от ART. Который ни про C#, ни про Go не знает или знать не будет.
Ваши действия?