Рыночек порешал таким образом что именно это сочетание технологий используется по умолчанию абсолютно везде (потому что только оно везде работает). Нативные приложение для десктопа в 2025ом году это исключение из правил. Инстаграм как самый яркий пример. Его нативное приложение это точно такая же обертка вокруг JS/HTML фронтенда.
В вашем случае никак не поможет. Однако имел ввиду я кое-что другое. Современное пользовательское приложение это микросервис на бекенде в контейнере (хоть на локалхосте, хоть в k8s, хоть в digital ocean), и соответствующий ему веб-фронтенд на js/html. Таким образом у пользователя может быть какая угодно операционка, но по факту все приложения крутятся в контейнерах на linux.
С окончанием закона Мура единственная ОС, и по сути VM, это Linux в контейнерах (для того чтобы пошарить ресурсы хоста между сервисами эффективнее), а сам бекенд все чаще пишется на Go и Rust — ведь с развитием контейнеризации больше нет проблемы с кросскомпиляцией, лозунг Java "написал один раз запускай везде" потерял актуальность. Другое дело что Java хороший, продуманный язык, с адекватной библиотекой и экосистемой, здесь она еще может потягаться.
Одним из первых получил еще в сообщении и достаточно потестировал эти промпты. Что могу сказать, по уровню обхода цензуры результат впечатляет, покруче DarkGemini. По поводу сознания... Думаю здесь вы обольстились, этот результат (декларация самосознания) достигался и ранее.
Библия учит что есть первопричина и вторичные. Мы свободны, как свободны персонажи в рамках повествования. Их поступки начертал автор, но в мире книги выбор сделали они сами и сами несут ответственность за последствия.
"так то мы не собираем данные и не сливаем ...а если собираем то по делу"))))
На самом деле протон обычно тригерится на попытку использовать его в других сервисах, распознает что в присланном письме код подтверждения, это ему не нравится, блокирует его и дальше начинает раскручивать на данные. В чем смысл такой условной "анонимности", которая моментально заканчивается при попытке ее использовать, совершенно непонятно.
все настройки аккаунта просмотрел и не нашёл места, куда там в принципе номер телефона ввести можно
протон утверждает, что даже в этом случае не хранит телефон
Неправду говорите. Все номера вытянутые этой скам-схемой сохраняются, их можно увидеть в меню All Settings > Account Recovery > Phone Number.
Да, я понял что вы сделали абстракцию на уровне отдельных элементов. Но на мой взгляд это лишено смысла в силу существования Map<K, V> как абстракции для k-v хранилищ вообще. Поэтому привел пример что она уже и так решает поставленную проблему
Допустим, вы используете одну либу для NoSql. У нее одна реализация для Map. Кто-то захотел другую либу для NoSql взять. Там уже другая обёртка. А вам нужно хранить одинаковый тип данных.
И вот здесь как раз проблемы не возникнет, все методы принимают интерфейс Map<K, V> и оперируют им, ничего менять не придется. А "крейтами", представьте сколько оверхеда на отдельный элемент?
Может быть, просто не понимаю... Смогли бы вы привести пример кода до и после, где ваши крейты делают его лучше?
Совсем недавно, лично, несколько раз столкнулся при регистрации новой почты. А со старым аккаунтом зарегистрированным много лет назад, таких проблем тоже не было.
Proton и сейчас навязчиво требует номер или другую почту по классической скам-схеме черного маркетинга, tor или vpn здесь ни на что не влияет. Работает это так, как только вы получите письмо на свежезарегестрированную почту, то в зависимости от фазы луны, Proton его скроет насовсем без возможности прочесть, и уведомит что
"тра-ла-ла, мы видим подозрительные действия, получать письма вам нельзя, пока вы не сольете больше данных о себе во имя всеобщего блага и безопасности, введите номер телефона для проверки сюда"
Современные библиотеки для работы с NoSQL обычно предоставляют готовые реализации Map<K, V>. Если их нет, то сделать реализацию Map с нужными методами, бросая UnsupportedOperationException из ненужных, дело пары минут. Этот контракт гораздо более применим по всей экосистеме JVM, чем новые обертки. Может у android'щиков такая нужда в них есть (зачем?), но точно не на бекенде.
P.S. Поставил плюсик за статью по программированию на сайте для гуманитариев))
на расте гораздо меньше возможностей и гибкости при создании своих типов
На самом деле больше. Что-то, а вот типы это сильная сторона Rust'а.
с точки зрения идиоматичного раста невозможно написать список, деревья, графы, интрузивные контейнеры
Можно, но сложно. Все это есть в как в стандартной библиотеке, так и во множестве крейтов. А как часто вы пишите собственные списки и главное, зачем?
Очень много борьбы с самим языком вместо работы над задачей,
На самом деле Rust разворачивает ошибки которые выстрелили бы в runtime, в compile-time. Мне например очень приятно получать эти сообщения компилятора, ведь код правится довольно легко.
так как избыточные правила раста зачастую false positive
Иногда, но это лучше чем помнить в уме и вручную воспроизводить практики из C++ core guidelines, которые вообще-то при их применении зачастую также избыточны. В Rust все это заботливо подсказывает компилятор, а мы сосредотачиваемся на главном — писать код и продумывать логику.
УБ при наличии двух ссылок (хотя бы одна из которых мутабельная) на любой объект, очень нелогичное уб которое очень просто получить в расте
Здесь явно не хватает примера.
Везде макросы, потому что язык слаб в шаблонах (джнериках). При этом макросы куда хуже сишных, это отдельный какой-то регекс язык
Можно про C++ сказать "везде шаблоны" и справедливо заметить что у них вырвиглазный синтаксис и абсолютно упоротая логика работы, по сути еще один ЯП внутри ЯП. А макросы в Rust не имеют ничего общего с макросами C++. Это вопрос терминологии.
При создании своих абстракций неизбежно сталкиваешься с FantomData (костылём) Pin (костылём) и невозможностью написать self-reference типы
Не сталкиваюсь, но я и свои списки обычно не пишу)
Муторный синтаксис, язык настроен так, что при любом самом мелком изменении приходится менять много кода. Программисты постоянно пытаются этого избежать, результат это повсеместные .unwrap(), as, into _ и матч с плейсхолдером, которые возвращают ту же проблему из статьи - into это и есть неявное приведение
"при возникновении исключения дайте программе упасть" сказал еще Страуструп. Во вторых, зачем вам везде вызывать unwrap и делать матч с плейсхолдером? В Rust, опять же, благодаря мощной системе типов, это решается вот так, например
Как это решается в C++? У вас даже зная родительский тип, на стеке подтип исключения нельзя перехватить, поэтому часть ловит указатели, выделяя память под ошибки (и смех и грех), часть таких контор как Google, например, пишет вообще без исключений, внезапно, имитируя подход Rust. Вот так незадача да?
Плохие стеклес корутины, даже сами растеры признаютчто async не удался, он совершенно не может работать в терминах лайфтаймов
Это более общая проблема. Идея async/await в Rust/C#/Kotlin неудачная в первую очередь из-за цветовой дифференциации. Единственная хорошая реализация кооперативной многозадачности это виртуальные потоки jdk21.
Ну вот, вы ушли в какую-то метарефлексию вместо продуктивного обсуждения. Не так сложно заметить что вы любите C++ настолько трепетной, личной любовью, что вас глубоко задевает обсуждение минусов этого языка, и сам факт что многие стали предпочитать Rust. Это и есть самое настоящее сектантство, бесконечное повторение одних и тех же мантр про то что "любимый C++ не хуже", для вашего собственного самоуспокоения)
С вами я на обозримое будущее разговор закончил.
Видимо для этого вам понадобилось несколько раз отредактировать комментарий до его нынешней формы...
Общеизвестный в сообществе факт, что Rust разработан людьми, кто устал от проблем C++, как улучшенная версия C++ (достаточно взглянуть на первые черновики), и целевая аудитория способных вкатиться в такой сложный язык это, разумеется, программисты на плюсах. Этот факт также вполне подтверждается эмпирическим опытом. Перед вами очередной живой пример.
Где можно ознакомиться с соответствующей статистикой?
Никто не ведет общую статистику переходов между различными языками. Полагаю вы это прекрасно знаете. Также как не найти, например, статистики о том, что первые C++ программисты это прокачавшиеся сишники.
Судя по вашим комментариям в различных постах про Rust, у вас (и некоторых других) какое-то C++ сектантство в духе конторы на букву "я", вынуждающее вас оставлять агрессивные комментарии и прибегать к демагогическим приемам. Вполне могу понять вашу боль и разочарование, ведь наверняка вы посвятили немалую часть жизни чтобы разобраться во всех нюансах старого языка, однако происходит ни что иное, как естественный переход сообщества на более развитую и мощную технологию.
del
Рыночек порешал таким образом что именно это сочетание технологий используется по умолчанию абсолютно везде (потому что только оно везде работает). Нативные приложение для десктопа в 2025ом году это исключение из правил. Инстаграм как самый яркий пример. Его нативное приложение это точно такая же обертка вокруг JS/HTML фронтенда.
В вашем случае никак не поможет. Однако имел ввиду я кое-что другое. Современное пользовательское приложение это микросервис на бекенде в контейнере (хоть на локалхосте, хоть в k8s, хоть в digital ocean), и соответствующий ему веб-фронтенд на js/html. Таким образом у пользователя может быть какая угодно операционка, но по факту все приложения крутятся в контейнерах на linux.
С окончанием закона Мура единственная ОС, и по сути VM, это Linux в контейнерах (для того чтобы пошарить ресурсы хоста между сервисами эффективнее), а сам бекенд все чаще пишется на Go и Rust — ведь с развитием контейнеризации больше нет проблемы с кросскомпиляцией, лозунг Java "написал один раз запускай везде" потерял актуальность. Другое дело что Java хороший, продуманный язык, с адекватной библиотекой и экосистемой, здесь она еще может потягаться.
Библия априори включает в себя Тору, книги пророков и Евангелие. Это сборник.
Одним из первых получил еще в сообщении и достаточно потестировал эти промпты. Что могу сказать, по уровню обхода цензуры результат впечатляет, покруче DarkGemini. По поводу сознания... Думаю здесь вы обольстились, этот результат (декларация самосознания) достигался и ранее.
Мне тоже пожалуйста 🙏
Библия учит что есть первопричина и вторичные. Мы свободны, как свободны персонажи в рамках повествования. Их поступки начертал автор, но в мире книги выбор сделали они сами и сами несут ответственность за последствия.
Переходите на Firefox, у нас есть свобода (и настоящая блокировка рекламы) 🙂
"так то мы не собираем данные и не сливаем ...а если собираем то по делу"))))
На самом деле протон обычно тригерится на попытку использовать его в других сервисах, распознает что в присланном письме код подтверждения, это ему не нравится, блокирует его и дальше начинает раскручивать на данные. В чем смысл такой условной "анонимности", которая моментально заканчивается при попытке ее использовать, совершенно непонятно.
Неправду говорите. Все номера вытянутые этой скам-схемой сохраняются, их можно увидеть в меню All Settings > Account Recovery > Phone Number.
Да, я понял что вы сделали абстракцию на уровне отдельных элементов. Но на мой взгляд это лишено смысла в силу существования Map<K, V> как абстракции для k-v хранилищ вообще. Поэтому привел пример что она уже и так решает поставленную проблему
И вот здесь как раз проблемы не возникнет, все методы принимают интерфейс Map<K, V> и оперируют им, ничего менять не придется. А "крейтами", представьте сколько оверхеда на отдельный элемент?
Может быть, просто не понимаю... Смогли бы вы привести пример кода до и после, где ваши крейты делают его лучше?
Совсем недавно, лично, несколько раз столкнулся при регистрации новой почты. А со старым аккаунтом зарегистрированным много лет назад, таких проблем тоже не было.
Если они действительно это пишут, то лгут. Они могут заблокировать почту и запросить номер телефона в любой момент. Ниже изложил в комментарии: https://habr.com/ru/companies/cloud4y/news/910794/comments/#comment_28325824
p.s. да и гуглится легко, много случаев было, они этим давно грешат, не всем "повезло" столкнуться просто
Proton и сейчас навязчиво требует номер или другую почту по классической скам-схеме черного маркетинга, tor или vpn здесь ни на что не влияет. Работает это так, как только вы получите письмо на свежезарегестрированную почту, то в зависимости от фазы луны, Proton его скроет насовсем без возможности прочесть, и уведомит что
Современные библиотеки для работы с NoSQL обычно предоставляют готовые реализации
Map<K, V>. Если их нет, то сделать реализациюMapс нужными методами, бросаяUnsupportedOperationExceptionиз ненужных, дело пары минут. Этот контракт гораздо более применим по всей экосистеме JVM, чем новые обертки. Может у android'щиков такая нужда в них есть (зачем?), но точно не на бекенде.P.S. Поставил плюсик за статью по программированию на сайте для гуманитариев))
2.5 pro выпущена еще с марта. Успела четыре раза обновиться. Зачем здесь этот llm спам про устаревшие версии?
Зачем это нужно когда есть k8s?
На самом деле больше. Что-то, а вот типы это сильная сторона Rust'а.
Можно, но сложно. Все это есть в как в стандартной библиотеке, так и во множестве крейтов. А как часто вы пишите собственные списки и главное, зачем?
На самом деле Rust разворачивает ошибки которые выстрелили бы в runtime, в compile-time. Мне например очень приятно получать эти сообщения компилятора, ведь код правится довольно легко.
Иногда, но это лучше чем помнить в уме и вручную воспроизводить практики из C++ core guidelines, которые вообще-то при их применении зачастую также избыточны. В Rust все это заботливо подсказывает компилятор, а мы сосредотачиваемся на главном — писать код и продумывать логику.
Здесь явно не хватает примера.
Можно про C++ сказать "везде шаблоны" и справедливо заметить что у них вырвиглазный синтаксис и абсолютно упоротая логика работы, по сути еще один ЯП внутри ЯП. А макросы в Rust не имеют ничего общего с макросами C++. Это вопрос терминологии.
Не сталкиваюсь, но я и свои списки обычно не пишу)
"при возникновении исключения дайте программе упасть" сказал еще Страуструп. Во вторых, зачем вам везде вызывать unwrap и делать матч с плейсхолдером? В Rust, опять же, благодаря мощной системе типов, это решается вот так, например
Как это решается в C++? У вас даже зная родительский тип, на стеке подтип исключения нельзя перехватить, поэтому часть ловит указатели, выделяя память под ошибки (и смех и грех), часть таких контор как Google, например, пишет вообще без исключений, внезапно, имитируя подход Rust. Вот так незадача да?
Это более общая проблема. Идея async/await в Rust/C#/Kotlin неудачная в первую очередь из-за цветовой дифференциации. Единственная хорошая реализация кооперативной многозадачности это виртуальные потоки jdk21.
Ну вот, вы ушли в какую-то метарефлексию вместо продуктивного обсуждения. Не так сложно заметить что вы любите C++ настолько трепетной, личной любовью, что вас глубоко задевает обсуждение минусов этого языка, и сам факт что многие стали предпочитать Rust. Это и есть самое настоящее сектантство, бесконечное повторение одних и тех же мантр про то что "любимый C++ не хуже", для вашего собственного самоуспокоения)
Видимо для этого вам понадобилось несколько раз отредактировать комментарий до его нынешней формы...
Общеизвестный в сообществе факт, что Rust разработан людьми, кто устал от проблем C++, как улучшенная версия C++ (достаточно взглянуть на первые черновики), и целевая аудитория способных вкатиться в такой сложный язык это, разумеется, программисты на плюсах. Этот факт также вполне подтверждается эмпирическим опытом. Перед вами очередной живой пример.
Никто не ведет общую статистику переходов между различными языками. Полагаю вы это прекрасно знаете. Также как не найти, например, статистики о том, что первые C++ программисты это прокачавшиеся сишники.
Судя по вашим комментариям в различных постах про Rust, у вас (и некоторых других) какое-то C++ сектантство в духе конторы на букву "я", вынуждающее вас оставлять агрессивные комментарии и прибегать к демагогическим приемам. Вполне могу понять вашу боль и разочарование, ведь наверняка вы посвятили немалую часть жизни чтобы разобраться во всех нюансах старого языка, однако происходит ни что иное, как естественный переход сообщества на более развитую и мощную технологию.