Антривольтность. Просто потому что по другому оно не работало. Некоторые вещи возникают не потому что это был эволюционный отбор на это свойство, а потому что физика и химия в мире такая.
Это хорошо до тех пор пока числа не станут большими и их вдруг не станет миллиарды, и вдруг не потребуется их искать. И окажется что продакшн база разрослась и расходы на сервера стали веселыми.
Вообще это удивительно как половина комментаторов и автор статьи игнорируют объемы. Может для паспортов оверхед и будет всего (всего!) в два раза, но если мы начинаем хранить ещё всякие ИНН, телефоны, какие-нибудь внутренние идентификаторы и прочее - разница начинает наростать. Хранить гигабайт или сто гигабайт, чего бы выбрать… хмм…
А про возможные буквы - такое бывает, но обычно это что-то типа обозначения региона владельца. Оно, к слову, в енумы числовые тоже прекрасно пакуется.
Конечно печально что вообще появилась такая конструкция. Вроде и маркировка, но ощущается как костыль. Надеюсь в язык добавят что-то более изящное. Потребность в маркировке есть, но нынешний способ реализации сомнителен. Особенно вместе с mut и прочим внутри, костыль в квадрате.
UPD - имею в виду именно эту конструкцию вообще, а кейс из статьи в итоге решится стабилизацией negative_impls
На тему фильмов и музыки, которые тут упомянуты - иногда из-за невозможности купить приходится пиратить. И вроде и готов заплатить, но не берут денег. А однажды я включил фильм с эппл тв без звука и звук от пиратки с ужасным качеством видео, зато на русском. Думаю у некоторых с играми также.
Тут двойной вопрос - будет ли такой софт есть больше чем кросс-платформа на электроне. Там виртуалка не нужна, но есть нюанс...
А C# или Delphi много памяти не едят. А для какого-нибудь AutoCAD и аппарат другой берут, с экраном побольше, и скорее это будет станционар сразу с виндой.
Так что в принципе нормально, учетный софт для документов - поместится.
Ну так то банально находишься ты стоя или лежа на земле - уже по разному влияние на организм. И тело человека умеет приспосабливаться, главное чтобы хоть какая-то гравитация была, а так зазоры на всё достаточно большие и проблемы переоценены. Из таких вещей вспоминается, например, искуственные сердца, принцип которых не пульсировать, а как насос равномерно качать кровь. И люди не умирают, живут с таких, хотя это более заметное отличие от стандартных условий. Нет точного исследования по беременностям, но, скорее всего, просто наличия гравитации 1G, пусть и чуть не равномерной, должно хватать. Ну и это решает вообще основную проблему в космосе - истончение мышц и костей из-за отсутствия нагрузки. Компенсируется сейчас тренажерами на борту.
Обычно проблема в том что на разные входные данные могут получаться разные результаты, зависеть от стейта внутри, от времени или значений случайных чисел, если такие используются. И всё это время шла борьба с этим. Оттуда появились виртуальные машины, докеры, кросс-платформенность и прочее.
Вы предлагаете всё выкинуть и сказать мол и так сойдет, зато ИИ пишет код. Если это какой-нибудь развлекательный сайт это ладно, если игра - это даже забавно, уникальное прохождение. Но я уверен что вы не захотите получить списание с вашего банковского счета только потому что сегодняшняя модель не так поняла назначение вашего платежа, или лежа под аппаратом коррекции зрения случайно получить прожженную дыру в сетчатке, потому что сегодня другие входные данные.
Такое происходит чрезвычайно редко. Ну и вообще по практикам кода обычно рекомендуется всё публичное сверху иметь, а приватное внизу, просто потому что когда человек заходит посмотреть что-то в файле обычно его интересует то что публичное, конкретная верхнеуровневая логика, а какие-то тонкости реализации, вспомогательные методы будут интересовать только если что-то не понятно в публичном. А вот если всё в перемешку делать - очень сложно разобраться чего-куда, получается хаос и плохой код. Особенно если в файле 300+ строк кода. Есть, конечно, иногда кейсы когда можно было бы за публичным сразу пару приватных, которые ну очень вот связаны в этом месте, но это спорный способ реализации. Обычно сверху всё что нужно видеть в первую очередь, снизу - глубокие детали. И это я на базе опыта в JS/TS, Ruby и Rust говорю.
В Rust как раз интеллект в них завезли. С одной стороны получается круто и безопасно. С другой - это отдельный язык и вселенная, со стримами токенов и развороткой в лютые простыни и добро пожаловать в отладочный ад.
Очень жаль что победил Python, а не Ruby. Моё личное персональное мнение, которое может не совпадать с другими. Синтаксис с подчеркиваниями и переименование на лету на базе этого - выглядит как лютый костыль. А вообще в JS в своё время такое было, по конвенции ставили приватному в начале нижнее подчеркивание. А в Google было принято помечать в конце. Там защиты дополнительной не было, просто ты сразу знал куда лезешь. А потом появился TypeScript. Остаётся надеяться что Ruby воскреснет, но пока он застрял в Rails, по факту. Возможно это и погубило. А концептуально намного лучше чем Python, продуманнее и код выглядит чисто, как английский текст, без визуального мусора. И приватные методы там есть, но очень красиво сделано - пишешь private в середине класса и все методы что идут ниже - теперь приватные. И никаких подчеркиваний и никаких private на каждый метод. Идеальный способ.
Забавно что на Rust уже есть пара проектов - Leptos и Dioxus, которые решили скопировать модель React с серверными компонентами. Да так что у диоксуса тоже своё облако. Теперь и на Rust можно поиграть в серверный и клиентский код в одном файле. Только там следующий уровень сложности - попробуй отдебажить WebAssembly, собраный макросом с кастомным языком для тегов внутри Rust.
Были раньше не iframe, а просто frame. Но начиная с html 5 - больше не поддерживается.
А вообще есть такие технологии, например Hotwire для Ruby или универсальный но более тяжелый htmx. Там на запрос ты отправляешь в ответ кусок html со всем что нужно. Можно большие куски, можно и поменьше, например сообщения чата. В Hotwire там можно определить как ответ использовать - заменить контент, добавит до, после и прочее такое.
Для админок, веб-приложений толстых и прочего. Там где раньше был Flash и Java-аплеты. Например биржевой веб-терминал статикой не сделаешь. Ну и чатик банально (хотя я делал на Ucoz с авто-рефрешем в 2009 и уже тогда это было устаревше). В общем применение то есть и много где.
Другое дело что не соразмерный инструмент тащат туда куда не нужно. Но как выше сказано - какой же ты сеньор если на реакте не пишешь, любители статики с простыми скриптами - это к джунам.
Ну а серверные компоненты нужны, помимо прочего, чтобы монетизировать реакт через облачные услуги. Грязный и болезненный способ, но теперь в документации реакта попробуй найти не фулстак версию, а create-react-app задеприкейтили. Комьюнити выросло, пора пожинать плоды.
Всё равно это не отвечает на вопрос почему PHP ниже. Но может просто я не осведомлен? Ок, открываем HH и видим 534 вакансии в Москве на PHP, 1030 на Go и 33 на Delphi. Возможно это из-за того что рейтинг международный? Может быть, но мне кажется что в мире перекос будет тоже примерно такой же, возможно с локальными моментами вроде Ruby, который в СНГ не популярен, а в США и Японии встречается чаще. Но это не на порядки раз.
И я не хейтер Delphi, вообще ни разу, сам когда-то немного касался этого мира в 2009. Но я хейтер этого рейтинга, потому что он показывает погоду на Марсе.
На Ruby, к слову, 82 вакансии, а его в топ 20 вообще нет.
Тогда я только рад, но в моем инфополе оно не появлялось слишком давно и ни одного проекта на нем не знаю, из новых. Оттого и вопрос как он оказался выше PHP и GO.
Антривольтность. Просто потому что по другому оно не работало. Некоторые вещи возникают не потому что это был эволюционный отбор на это свойство, а потому что физика и химия в мире такая.
Это хорошо до тех пор пока числа не станут большими и их вдруг не станет миллиарды, и вдруг не потребуется их искать. И окажется что продакшн база разрослась и расходы на сервера стали веселыми.
Вообще это удивительно как половина комментаторов и автор статьи игнорируют объемы. Может для паспортов оверхед и будет всего (всего!) в два раза, но если мы начинаем хранить ещё всякие ИНН, телефоны, какие-нибудь внутренние идентификаторы и прочее - разница начинает наростать. Хранить гигабайт или сто гигабайт, чего бы выбрать… хмм…
А про возможные буквы - такое бывает, но обычно это что-то типа обозначения региона владельца. Оно, к слову, в енумы числовые тоже прекрасно пакуется.
PhantomDataКонечно печально что вообще появилась такая конструкция. Вроде и маркировка, но ощущается как костыль. Надеюсь в язык добавят что-то более изящное. Потребность в маркировке есть, но нынешний способ реализации сомнителен. Особенно вместе с mut и прочим внутри, костыль в квадрате.
UPD - имею в виду именно эту конструкцию вообще, а кейс из статьи в итоге решится стабилизацией
negative_implsНа тему фильмов и музыки, которые тут упомянуты - иногда из-за невозможности купить приходится пиратить. И вроде и готов заплатить, но не берут денег. А однажды я включил фильм с эппл тв без звука и звук от пиратки с ужасным качеством видео, зато на русском. Думаю у некоторых с играми также.
В интернете никто не знает что ты кот (с)
Тут двойной вопрос - будет ли такой софт есть больше чем кросс-платформа на электроне. Там виртуалка не нужна, но есть нюанс...
А C# или Delphi много памяти не едят. А для какого-нибудь AutoCAD и аппарат другой берут, с экраном побольше, и скорее это будет станционар сразу с виндой.
Так что в принципе нормально, учетный софт для документов - поместится.
А если поделить бублик ещё и на отсеки, как в морских кораблях сейчас, то будет ещё надежнее. Ну и можно жилые помещения герметизировать отдельно.
Ну так то банально находишься ты стоя или лежа на земле - уже по разному влияние на организм. И тело человека умеет приспосабливаться, главное чтобы хоть какая-то гравитация была, а так зазоры на всё достаточно большие и проблемы переоценены. Из таких вещей вспоминается, например, искуственные сердца, принцип которых не пульсировать, а как насос равномерно качать кровь. И люди не умирают, живут с таких, хотя это более заметное отличие от стандартных условий. Нет точного исследования по беременностям, но, скорее всего, просто наличия гравитации 1G, пусть и чуть не равномерной, должно хватать. Ну и это решает вообще основную проблему в космосе - истончение мышц и костей из-за отсутствия нагрузки. Компенсируется сейчас тренажерами на борту.
Есть всякий бизнес-софт и гос-софт, который умеет только вот винду. Собственно это основное назначение виртуалки.
Обычно проблема в том что на разные входные данные могут получаться разные результаты, зависеть от стейта внутри, от времени или значений случайных чисел, если такие используются. И всё это время шла борьба с этим. Оттуда появились виртуальные машины, докеры, кросс-платформенность и прочее.
Вы предлагаете всё выкинуть и сказать мол и так сойдет, зато ИИ пишет код. Если это какой-нибудь развлекательный сайт это ладно, если игра - это даже забавно, уникальное прохождение. Но я уверен что вы не захотите получить списание с вашего банковского счета только потому что сегодняшняя модель не так поняла назначение вашего платежа, или лежа под аппаратом коррекции зрения случайно получить прожженную дыру в сетчатке, потому что сегодня другие входные данные.
Такое происходит чрезвычайно редко. Ну и вообще по практикам кода обычно рекомендуется всё публичное сверху иметь, а приватное внизу, просто потому что когда человек заходит посмотреть что-то в файле обычно его интересует то что публичное, конкретная верхнеуровневая логика, а какие-то тонкости реализации, вспомогательные методы будут интересовать только если что-то не понятно в публичном. А вот если всё в перемешку делать - очень сложно разобраться чего-куда, получается хаос и плохой код. Особенно если в файле 300+ строк кода. Есть, конечно, иногда кейсы когда можно было бы за публичным сразу пару приватных, которые ну очень вот связаны в этом месте, но это спорный способ реализации. Обычно сверху всё что нужно видеть в первую очередь, снизу - глубокие детали. И это я на базе опыта в JS/TS, Ruby и Rust говорю.
В Rust как раз интеллект в них завезли. С одной стороны получается круто и безопасно. С другой - это отдельный язык и вселенная, со стримами токенов и развороткой в лютые простыни и добро пожаловать в отладочный ад.
Очень жаль что победил Python, а не Ruby. Моё личное персональное мнение, которое может не совпадать с другими. Синтаксис с подчеркиваниями и переименование на лету на базе этого - выглядит как лютый костыль. А вообще в JS в своё время такое было, по конвенции ставили приватному в начале нижнее подчеркивание. А в Google было принято помечать в конце. Там защиты дополнительной не было, просто ты сразу знал куда лезешь. А потом появился TypeScript. Остаётся надеяться что Ruby воскреснет, но пока он застрял в Rails, по факту. Возможно это и погубило. А концептуально намного лучше чем Python, продуманнее и код выглядит чисто, как английский текст, без визуального мусора. И приватные методы там есть, но очень красиво сделано - пишешь private в середине класса и все методы что идут ниже - теперь приватные. И никаких подчеркиваний и никаких private на каждый метод. Идеальный способ.
Забавно что на Rust уже есть пара проектов - Leptos и Dioxus, которые решили скопировать модель React с серверными компонентами. Да так что у диоксуса тоже своё облако. Теперь и на Rust можно поиграть в серверный и клиентский код в одном файле. Только там следующий уровень сложности - попробуй отдебажить WebAssembly, собраный макросом с кастомным языком для тегов внутри Rust.
Были раньше не iframe, а просто frame. Но начиная с html 5 - больше не поддерживается.
А вообще есть такие технологии, например Hotwire для Ruby или универсальный но более тяжелый htmx. Там на запрос ты отправляешь в ответ кусок html со всем что нужно. Можно большие куски, можно и поменьше, например сообщения чата. В Hotwire там можно определить как ответ использовать - заменить контент, добавит до, после и прочее такое.
Для админок, веб-приложений толстых и прочего. Там где раньше был Flash и Java-аплеты. Например биржевой веб-терминал статикой не сделаешь. Ну и чатик банально (хотя я делал на Ucoz с авто-рефрешем в 2009 и уже тогда это было устаревше). В общем применение то есть и много где.
Другое дело что не соразмерный инструмент тащат туда куда не нужно. Но как выше сказано - какой же ты сеньор если на реакте не пишешь, любители статики с простыми скриптами - это к джунам.
Ну а серверные компоненты нужны, помимо прочего, чтобы монетизировать реакт через облачные услуги. Грязный и болезненный способ, но теперь в документации реакта попробуй найти не фулстак версию, а create-react-app задеприкейтили. Комьюнити выросло, пора пожинать плоды.
Всё равно это не отвечает на вопрос почему PHP ниже. Но может просто я не осведомлен? Ок, открываем HH и видим 534 вакансии в Москве на PHP, 1030 на Go и 33 на Delphi. Возможно это из-за того что рейтинг международный? Может быть, но мне кажется что в мире перекос будет тоже примерно такой же, возможно с локальными моментами вроде Ruby, который в СНГ не популярен, а в США и Японии встречается чаще. Но это не на порядки раз.
И я не хейтер Delphi, вообще ни разу, сам когда-то немного касался этого мира в 2009. Но я хейтер этого рейтинга, потому что он показывает погоду на Марсе.
На Ruby, к слову, 82 вакансии, а его в топ 20 вообще нет.
Тогда я только рад, но в моем инфополе оно не появлялось слишком давно и ни одного проекта на нем не знаю, из новых. Оттого и вопрос как он оказался выше PHP и GO.
Следующий уровень абстракции - попросить ИИ читать Хабр вместо себя.
Смотришь на таблицу лидеров, видишь Delphi, закрываешь таблицу.
Очень спорный рейтинг.