Потому в ходу появился термин «у.е.», то есть условная единица, под которой чаще всего понимали доллар. В «у.е.» было проще выражать цены и вести расчёты. И это не была история чёрного рынка. Сотовые операторы в начале 2000-х вполне официально выражали стоимость своих услуг в «у.е.». Некоторые товары или услуги также стоили именно «у.е.». А в коммерческих магазинах начала 90-х у вас бы спокойно приняли доллары.
Что-то я совсем иначе это помнню - сотовая связь уже и в нулевых была прямо в долларах/центах, карты оплаты прямо в них номинировались, потом это официально запретили, и в этот момент появились у.е., которые дальше уже были вытеснены рублями.
Кажется приведенный пример несколько противоречит концепции бессознательного решения на базе замеченных но неосознанных признаков - в тот момент когда выполнялось действие снаряд еще даже заряжен не был
Объясняли клиенту, почему его запрос обрабатывался 5 секунд (потому что GC)
Пока что сценарии нагрузочного тестирования отвечают ПРОМ-нагрузке подобное не требуется. Вцелом у вас почему-то во всем GC виноват, хотя, например, плохая работа с конкурентными ресурсами убьет производительность в любом языке.
Дебажили OOM в продакшене из-за неочевидного retain в лямбде
Никогда - в ПРОД запрещен дебаг службой безопасности.
Пересобирали весь кластер из-за security-дыры в Spring-зависимости?
У вас странная фиксация на необходимости пересборки при обновлении зависимостей, обновлять зависимости приходилось не раз, но если мы говорим про Spring то это никогда не было задачей даже на день - свежие версии выходят, о изменениях настроек по-умолчанию и api известно сильно заранее.
А к Zig новые версии не выходят? Или в имеющихся каким-то образом гарантируется отсутствие ошибок в генерируемой компилятором коде?
В Zig тесты показывают, где я накосячил
Zig пишут люди, они могут ошибаться - их ошибки также могут проявляться во время нагрузочного тестирования.
В Java тесты показывают, где JVM решила устроить фестиваль сборки мусора
Ошибки разработчика также могут быть видны во время нагрузочного тестирования
Если для вас «не знать Spring» = «не разбираться в разработке» — поздравляю, вы идеальный кандидат на позицию «корпоратного программиста года»
Показатель для меня не знать инструменты и пытаться судить о них.
Забавно, что вы считаете, будто проблема решается «покупкой памяти». Видимо, никогда не сталкивались с тем, как GC под нагрузкой превращается в русскую рулетку — когда приложение внезапно замирает на секунду, потому что JVM решила почистить бардак, который сама же и создала.
Видимо вы не вкурсе насчет разных GC в современной Java, прежде чем пересказывать историю из нулевых актуализовали бы собственные знания.
Если для вас DI — это просто «вынести new», тогда Spring с его 15 слоями абстракции — это как стрелять из пушки по воробьям
Вы похоже просто не вкурсе Java-мира. Не то что бы знание java-мира обязательно, но рассуждать о том в чем не разбираетесь должно быть стыдно
P.S. Кстати, если уж говорить о деньгах — интересно, сколько стоит месяц простоя из-за того, что GC не справился с нагрузкой?
А Zig нагрузочного тестирования не требует? Или вам кажется что в мире Java нет такого?
Или час дебага «магического» поведения Spring-приложения?
Если для разработчика поведение его собственного инструмента "магическое", то это вопросы к конкретному разработчику, а не к инструменту.
Надо писать на PHP — потому что «программистов много».
Вы это сами придумали, PHP не единственный популярный язык
Надо нанимать первого попавшегося — потому что «дешевле»
Вы это сами придумали, вам указали на то что в условиях выбора из большого числа кандидатов шанс найти подходящего укладывающегося в бюджет выше
Надо молиться, чтобы «автобус» не приехал — потому что иначе проект развалится
Вы это сами придумали, вам указали на то что в рамках малого числа кандидатов шанс того что вы останетесь с вундервафлей которую никто не может запустить после перезагрузки сервера выше
Но почему-то Bun.sh, Uber и TigerBeetle как-то рискнули и выбрали Zig — и, кажется, у них всё работает
В работоспособности Zig никто не сомневался, вы уверены что работаете в Uber или конторе сопоставимого размера? Возможности по найму специалистов сильно зависят от размера конторы.
Еще как - Собачье сердце не на пустом месте писалось. Если вы вдруг жируете 1 в нескольких комнатах вас вполне могли переселить, а ваше жилье отдавать кому нужнее, или уплотнить - запрет на создание коммуналок это уже очень позднее явление. А кроме того, если у вас вдруг появлялась новая квартира (например вы ее как раз в кооперативе купили) то ваше предыдущее жилье будьте добры сдать государству.
Это даже лицемернее чем сказать Ока примерный аналог Бентли. Что артель, что колхоз (сельскохозяйственная артель) не могли решить ни что им делать, ни как, савхозам спускали что и когда им сеять, артели придавали производствам, которые диктовали что и сколько делать, и почем сдавать государству. С ООО при таком подходе общее разве что то что и там и там как-то коллектив собирается, и названия можно похожие выбирать.
другие говорят, что код — это то, что написано руками
придумали глупость и приписали другим, отличный реторический прием. Код можно писать хоть задницей, важно кто модель этого кода создает - разработчик у себя в голове, или LLM. Если бы был способ быстро перегрузить созданную в голове разработчика модель в LLM, то и спора бы не было - никто же не спорит о полезности, например, зоны Брока. В таком случае это действительно был бы просто новый, очень полезный инструмент.
Скорость развития детёнышей многих видов обезьян также превышает скорость развития человека, примерно до 3 лет. Взрослые особи на этом уровне развития в итоге и остаются.
Кажется вы путаете "кандидаты особо не нужны" с "какие попало кандидаты не нужны" - то что рынок завален кандидатами пишущими хелловорд и идущими собеседоваться на позиции миддл+ (ещё и пытающимися в процессе собеседования использоваться нейронки/друга на телефоне) увы но правда.
Проблема ли это для кандидатов которые нормально оценивают свой уровень? увы но да - их искать тяжело т.к. неадекватные кандидаты создают нагрузку на собеседующих
У вас ошибка в сравнении - если вы хотите сравнивать то что было и то что сейчас, то надо сравнивать близкое/идентичное по функционалу. Большая хрупкость современных телефонов по сравнению со старыми в их несопастовимо более высокой сложности, а сложность продиктована принципиально изменившимися требованиями к функциональности. Вы же берете не коррелирующую со сложностью (однозначно одной из важных причин большей хрупкости) метрику - стоимость, и назначаете ее эталоном тождественности старого и нового устройства, по законам логики в такой ситуации получаете неизвестно что - из лжи может следовать и истина и ложь.
Кажется я вам привел пример не относящийся к перечисленным вами и в котором "потолок" такой что не многие дотягиваются - это первое что вспомнилось, такого реально много, сильно больше чем описываемые вами отрасли. Для того чтобы ваш посыл звучал сколько-нибудь истинно нужно его трансформировать в "Не на каждом производстве нужен высококласный инженер" - с таким было бы трудно спорить.
Попытка поднять "потолок" в задаче уже оптимизированной под конкретные условия, диктуемые обстоятельствами в которых задача выполняется, почти всегда обречена на провал - понятно что никто не хочет своими деньгами рисковать. Если хотите высокий "потолок" в производстве мебели то вам в космос, на Луну/Марс, возможно на Северный Полюс или под воду - там условия решения задачи иные, большой простор для изобретения новых способов производства мебели.
Так потому и не делают - это дополнительная работа, малейшая ошибка в которой приведет к провалу - не встанет шкаф на 2мм и привет. Мебель все равно приедет разобранной, иначе в квартиру нормально не внесешь. Вот и выбирайте что вам - риск переделывать и возить по 10 раз, при точных размерах прямо со станка, или допуски и 5 минут ручной работы на месте.
Вы похоже не инженер а математик - инженерия она прикладная, с реалиям физического мира жестко связана, а у вас идет игнорирование окружающего.
Страшная тайна про кухни - их собирают с применением доработки лобзиком потому что помещения в которые их ставят неидеальны - углы не 90 градусов, стены не идеально ровные, и т.д. Чтобы сделать кухню точно под место нужно делать точную 3d модель помещения - в этот момент разговоры про то что нынешний процесс трудоемок идут в утиль.
Кроме того у вас ошибка в терминологии: кустарное производство - это если бы вам при привозили на объект лист ДСП, оргалит, и дальше вы бы из него все выпиливали, когда у вас приезжает набор деталей некоторые из которых нужно подогнать по-месту это НЕ кустарное производство
Вцелом насчет статьи - посыл даже не лежит в направлении истины. Простой пример - телеком-оборудование вы не упомянули в списке, а задачи разработки базовых станций требуют весьма высоких инженерных навыков. Это далеко не единственное что можно вспомнить, но с учётом вашей жесткой риторики, возведения местечкового наблюдения уровня "не везде серьезные инженеры нужны" в абсолют данного примера достаточно чтобы показать ложность вашего утверждения.
Я понятия не имею что у автора решения в программе, я только о том говорю, что сам по себе факт наличия какого-то подхода к решению не должен и не может служить доводом в пользу того, что новые подходы невозможны, или априори хуже (при условии что подходы действительно новые, конечно).
Что-то я совсем иначе это помнню - сотовая связь уже и в нулевых была прямо в долларах/центах, карты оплаты прямо в них номинировались, потом это официально запретили, и в этот момент появились у.е., которые дальше уже были вытеснены рублями.
Кажется приведенный пример несколько противоречит концепции бессознательного решения на базе замеченных но неосознанных признаков - в тот момент когда выполнялось действие снаряд еще даже заряжен не был
Epsilon GC. Какой вопрос такой ответ.
Пока что сценарии нагрузочного тестирования отвечают ПРОМ-нагрузке подобное не требуется. Вцелом у вас почему-то во всем GC виноват, хотя, например, плохая работа с конкурентными ресурсами убьет производительность в любом языке.
Никогда - в ПРОД запрещен дебаг службой безопасности.
У вас странная фиксация на необходимости пересборки при обновлении зависимостей, обновлять зависимости приходилось не раз, но если мы говорим про Spring то это никогда не было задачей даже на день - свежие версии выходят, о изменениях настроек по-умолчанию и api известно сильно заранее.
А к Zig новые версии не выходят? Или в имеющихся каким-то образом гарантируется отсутствие ошибок в генерируемой компилятором коде?
Zig пишут люди, они могут ошибаться - их ошибки также могут проявляться во время нагрузочного тестирования.
Ошибки разработчика также могут быть видны во время нагрузочного тестирования
Показатель для меня не знать инструменты и пытаться судить о них.
Видимо вы не вкурсе насчет разных GC в современной Java, прежде чем пересказывать историю из нулевых актуализовали бы собственные знания.
Вы похоже просто не вкурсе Java-мира. Не то что бы знание java-мира обязательно, но рассуждать о том в чем не разбираетесь должно быть стыдно
А Zig нагрузочного тестирования не требует? Или вам кажется что в мире Java нет такого?
Если для разработчика поведение его собственного инструмента "магическое", то это вопросы к конкретному разработчику, а не к инструменту.
Вы это сами придумали, PHP не единственный популярный язык
Вы это сами придумали, вам указали на то что в условиях выбора из большого числа кандидатов шанс найти подходящего укладывающегося в бюджет выше
Вы это сами придумали, вам указали на то что в рамках малого числа кандидатов шанс того что вы останетесь с вундервафлей которую никто не может запустить после перезагрузки сервера выше
В работоспособности Zig никто не сомневался, вы уверены что работаете в Uber или конторе сопоставимого размера? Возможности по найму специалистов сильно зависят от размера конторы.
Похоже вы мало имели дел с драконом :)
Spring есть за что критиковать (как вцелом и любой достаточно большой фреймворк), но всё-таки он до сих пор сильно легче в использовании чем EJB
Еще как - Собачье сердце не на пустом месте писалось. Если вы вдруг жируете 1 в нескольких комнатах вас вполне могли переселить, а ваше жилье отдавать кому нужнее, или уплотнить - запрет на создание коммуналок это уже очень позднее явление. А кроме того, если у вас вдруг появлялась новая квартира (например вы ее как раз в кооперативе купили) то ваше предыдущее жилье будьте добры сдать государству.
Это совсем не похоже на собственность.
Это даже лицемернее чем сказать Ока примерный аналог Бентли. Что артель, что колхоз (сельскохозяйственная артель) не могли решить ни что им делать, ни как, савхозам спускали что и когда им сеять, артели придавали производствам, которые диктовали что и сколько делать, и почем сдавать государству. С ООО при таком подходе общее разве что то что и там и там как-то коллектив собирается, и названия можно похожие выбирать.
А с квартирами как? В собственности были?
лучше чем считать чужие возможности что-то развивать для всех обычно получается только считать чужие возможности что-то развивать для себя
придумали глупость и приписали другим, отличный реторический прием. Код можно писать хоть задницей, важно кто модель этого кода создает - разработчик у себя в голове, или LLM. Если бы был способ быстро перегрузить созданную в голове разработчика модель в LLM, то и спора бы не было - никто же не спорит о полезности, например, зоны Брока. В таком случае это действительно был бы просто новый, очень полезный инструмент.
плохой перевод, как будто остальные типы незначимые - по приколу делаются и значимости не несут
правильнее по-русски этот тип называть "объект-значение", нет лишних смыслов от прилагательного "значимый"
Скорость развития детёнышей многих видов обезьян также превышает скорость развития человека, примерно до 3 лет. Взрослые особи на этом уровне развития в итоге и остаются.
Так проблемы и нет, при условии что вы хотите именно за требуемое эти деньги получать, проблема возникает когда эти деньги хотят получать за хелловорд
Кажется вы путаете "кандидаты особо не нужны" с "какие попало кандидаты не нужны" - то что рынок завален кандидатами пишущими хелловорд и идущими собеседоваться на позиции миддл+ (ещё и пытающимися в процессе собеседования использоваться нейронки/друга на телефоне) увы но правда.
Проблема ли это для кандидатов которые нормально оценивают свой уровень? увы но да - их искать тяжело т.к. неадекватные кандидаты создают нагрузку на собеседующих
У вас ошибка в сравнении - если вы хотите сравнивать то что было и то что сейчас, то надо сравнивать близкое/идентичное по функционалу. Большая хрупкость современных телефонов по сравнению со старыми в их несопастовимо более высокой сложности, а сложность продиктована принципиально изменившимися требованиями к функциональности. Вы же берете не коррелирующую со сложностью (однозначно одной из важных причин большей хрупкости) метрику - стоимость, и назначаете ее эталоном тождественности старого и нового устройства, по законам логики в такой ситуации получаете неизвестно что - из лжи может следовать и истина и ложь.
Кажется я вам привел пример не относящийся к перечисленным вами и в котором "потолок" такой что не многие дотягиваются - это первое что вспомнилось, такого реально много, сильно больше чем описываемые вами отрасли. Для того чтобы ваш посыл звучал сколько-нибудь истинно нужно его трансформировать в "Не на каждом производстве нужен высококласный инженер" - с таким было бы трудно спорить.
Попытка поднять "потолок" в задаче уже оптимизированной под конкретные условия, диктуемые обстоятельствами в которых задача выполняется, почти всегда обречена на провал - понятно что никто не хочет своими деньгами рисковать. Если хотите высокий "потолок" в производстве мебели то вам в космос, на Луну/Марс, возможно на Северный Полюс или под воду - там условия решения задачи иные, большой простор для изобретения новых способов производства мебели.
Так потому и не делают - это дополнительная работа, малейшая ошибка в которой приведет к провалу - не встанет шкаф на 2мм и привет. Мебель все равно приедет разобранной, иначе в квартиру нормально не внесешь. Вот и выбирайте что вам - риск переделывать и возить по 10 раз, при точных размерах прямо со станка, или допуски и 5 минут ручной работы на месте.
Вы похоже не инженер а математик - инженерия она прикладная, с реалиям физического мира жестко связана, а у вас идет игнорирование окружающего.
Страшная тайна про кухни - их собирают с применением доработки лобзиком потому что помещения в которые их ставят неидеальны - углы не 90 градусов, стены не идеально ровные, и т.д. Чтобы сделать кухню точно под место нужно делать точную 3d модель помещения - в этот момент разговоры про то что нынешний процесс трудоемок идут в утиль.
Кроме того у вас ошибка в терминологии: кустарное производство - это если бы вам при привозили на объект лист ДСП, оргалит, и дальше вы бы из него все выпиливали, когда у вас приезжает набор деталей некоторые из которых нужно подогнать по-месту это НЕ кустарное производство
Вцелом насчет статьи - посыл даже не лежит в направлении истины. Простой пример - телеком-оборудование вы не упомянули в списке, а задачи разработки базовых станций требуют весьма высоких инженерных навыков. Это далеко не единственное что можно вспомнить, но с учётом вашей жесткой риторики, возведения местечкового наблюдения уровня "не везде серьезные инженеры нужны" в абсолют данного примера достаточно чтобы показать ложность вашего утверждения.
Я понятия не имею что у автора решения в программе, я только о том говорю, что сам по себе факт наличия какого-то подхода к решению не должен и не может служить доводом в пользу того, что новые подходы невозможны, или априори хуже (при условии что подходы действительно новые, конечно).