Если следовать вашей терминологии, то нет владельца приватного ключа - это же просто число, нельзя быть владельцем числа.
Вцелом аналогия с банком некорректна т.к. если начать разбираться то окажется что для того чтобы нолики-единички как-то в суде к "физическим" понятиям о собственности привязать есть большой правовой аппарат (например безналичный рубль не собственность, для того чтобы его можно было, например, наследовать есть отдельный кусок в законе).
Представьте себе что я заплатил денег поэту за крутую скороговорку, могу я запретить другим ее произносить?
Биткоин как минимум во многих странах это просто циферки, за математические операции с которыми какие-то чудики платят деньги, но от этого собственность ни на числа, ни на математику они не приобретают.
Цифровой рубль даёт властям полный контроль над активами граждан, включая возможность моментальной блокировки и изъятия денежных средств с любого счёта в любой момент времени.
Если вы игнорируете необходимость юридически значимого обоснования подобного действия, то ваше утверждение не содержит значимой информации: обычный счет в любом банке точно также могут заблокировать - безналичный рубль тут аналогичен цифровому. Если необходимость юридически значемого обоснования вы не игнорируете - тезис неверен полностью, т.к. не любой счет в любой момент времени, а только в рамках имеющегося юридического обоснования.
Потому в ходу появился термин «у.е.», то есть условная единица, под которой чаще всего понимали доллар. В «у.е.» было проще выражать цены и вести расчёты. И это не была история чёрного рынка. Сотовые операторы в начале 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 минут ручной работы на месте.
Вы похоже не инженер а математик - инженерия она прикладная, с реалиям физического мира жестко связана, а у вас идет игнорирование окружающего.
Если следовать вашей терминологии, то нет владельца приватного ключа - это же просто число, нельзя быть владельцем числа.
Вцелом аналогия с банком некорректна т.к. если начать разбираться то окажется что для того чтобы нолики-единички как-то в суде к "физическим" понятиям о собственности привязать есть большой правовой аппарат (например безналичный рубль не собственность, для того чтобы его можно было, например, наследовать есть отдельный кусок в законе).
Представьте себе что я заплатил денег поэту за крутую скороговорку, могу я запретить другим ее произносить?
Биткоин как минимум во многих странах это просто циферки, за математические операции с которыми какие-то чудики платят деньги, но от этого собственность ни на числа, ни на математику они не приобретают.
Если вы игнорируете необходимость юридически значимого обоснования подобного действия, то ваше утверждение не содержит значимой информации: обычный счет в любом банке точно также могут заблокировать - безналичный рубль тут аналогичен цифровому. Если необходимость юридически значемого обоснования вы не игнорируете - тезис неверен полностью, т.к. не любой счет в любой момент времени, а только в рамках имеющегося юридического обоснования.
Что-то я совсем иначе это помнню - сотовая связь уже и в нулевых была прямо в долларах/центах, карты оплаты прямо в них номинировались, потом это официально запретили, и в этот момент появились у.е., которые дальше уже были вытеснены рублями.
Кажется приведенный пример несколько противоречит концепции бессознательного решения на базе замеченных но неосознанных признаков - в тот момент когда выполнялось действие снаряд еще даже заряжен не был
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 минут ручной работы на месте.
Вы похоже не инженер а математик - инженерия она прикладная, с реалиям физического мира жестко связана, а у вас идет игнорирование окружающего.