Т.е. система жизнеобеспечения доверена некому динамически изменяемому кем-то стороннему облачному сервису, не покрытому даже автотестами, плюс по дороге к которому есть как минимум с десяток точек отказа (экскаватор на недублированной отоволоконной линии, ветер с деревьями, отключения света в районной РЭС вместе с коммутаторами провайдеров, непредсказуемые глюки с блокировками РКН)?
Ну в принципе - да, практически гениальная реализация умного дома.
Очень надежно. По всем канонам промышленной автоматики.
Почти идеальная реализация ошибок могла бы выглядеть примерно так, через structured binding (или destructuring, кому как нравится):
do {
auto [result, error] = TheService::callService(params);
switch (error) {
case TheService::ErrorCodes::TIMEOUT_REACHED:
System::fatal("TheService Not Available");
case TheService::ErrorCodes::RETRY:
System::sleep(TheService::DEFAULT_EXT_CALL_TIMEOUT);
break;
case TheService::ErrorCodes::OK:
return result;
}
} while (true);
Код условный, реальный чуть посложнее будет. Но ключевой момент тут показан: TheService::ErrorCodes это enum c конечным числом значений. И если функция TheService::callService начинает еще какой-то четвертый тип ошибок возвращать (добавили еще одно значение в enum), то компилятор нам сразу высветит все switch места, где нет case обработки этого нового типа ошибки, и их нужно срочно пойти дописать.
А лямбдо-монады - это лишь синтаксический сахар, да есть есть весьма широкая категория любителей так спагетти-кодировать, и наверное нужно уважать их культурные отличия. Но проблему расширения контрактов, в данном случае возможных кодов ошибок, и проверку их соблюдения компилятором (покрытия всех возможных кодов) все эти чудесные трудно читабельные формы callback-ов не решают от слова никак, нужно идти и вычитывать код каждый раз.
Все это конечно невероятно увлекательно, как и книга Дж.К.Дейта. Но в реальности PostgreSQL стал популярен в РФ как замена MSSQL для 1С, и в последние годы повсеместно в мире - как более менее подобная и работоспособная замена Oracle RDBMS.
Да, уже в чем-то лучше, местами даже сильно лучше, но в целом еще развиваться и развиваться даже до уровня 9i/10g/11g, 25 летней давности: трассировка, поддержка отладчика plpgsql в IDE, оптимизатор SQL, кластеризация, все это пока еще сильно недоделано, в сравнении.
Забавно, я не знал, что С (1972) появился намного позже BASIC (1962) и COBOL (1959).
А так - про именно C++ все сказано еще Луговским на sql.ru и на lurkmore, с тех пор ничего не изменилось. Единственное что изменилось - это появился Kotlin с его эпическими 2500 страницами манула только на сам язык, который я никак не могу осилить - засыпаю или забрасываю на каких-нибудь расчудесных Companion objects, Sealed Classes и прочем энтропическом сахаре. И аналогично Nim и прочие Zig (с Rust), с тем же самым эффектом - листаешь, и не понимаешь, чего авторам не хватало-то, что они пытаются сказать? Крейты трейты понапридумывали, зачем? Просто чтоб быть не как все?
Единственно что было свежее за годы - это Q/K/KDB+, и то просто как концепция, что можно очень хитро написать интерпретатор так, что он целиком залезет в L1 и начнет работать даже сильно быстрее компилируемого кода. Это было прям откровение.
Так вот, найти нужную библиотеку на С++ без STL, а уж тем более без рантайма, не представляется возможным. Чаще всего нужно сериализацию/десериализацию, какое-нибудь шифрование, консольная графика и lock-free алггоритмы. Всё что существует в С++ требует кучу и рантайм. На С можно кое-что найти, но не в пакетных менеджерах. И собрать это без помощи ИИ сложно, т.к. варианты сборки без рантайма очень слабо документированы.
С++ библиотеки чуть менее чем все требуют STL и Heap, это так, тут особо добавить нечего: или смириться c STL или просто никогда ими не пользоваться (благо там почти всегда есть альтернативы на ANSI C).
По поводу особо сложной сборки C библиотек - а вот тут странно. Они как правило есть в виде .rpm или .deb пакетов, или в составе ОС или в сторонних репозиториях вроде EPEL или COPR, и в чем там трудность их установить - лично для меня загадка. А если их нет в виде готовых .rpm, то в 90% случаев там autoconf, или CMake, да и пересобрать их прям заново из отдельных .c и .h файлов это вопрос пары часов, как правило там нет никакого rocket science. Windows выбрасываем из задачи. Там почти всегда боль и страдания. Хотя некоторым нравится.
Lock-free алгоритмы - это практически всегда header-only что-то, вокруг CAS построенное. Консольная графика - не знаю что это, наверное ncurses? Те-же mcurses вроде есть везде и для всего. LVGL? Тоже есть. Зачем там Rust?
Шифрование - тоже должна быть давно решенная тема, OpenSSL, GnuTLS, Mbed TLS, wolfSSL. Ни одно из озвученного выше пока не мотивирует вот прям бросать все и срочно переходить на Rust.
На Rust огромный выбор, все в пакетном менеджере, и 1-2 строками в системе сборки включается no_std режим, и оно просто собирается и работает. Как вы думаете, на каком языке бизнес начнет новый проект, если хотя бы проверит доступность библиотек? По моим наблюдениям, в этой области Rust уже заменил С++ и отгрыз некоторую долю у С.
Звучит больше как реклама пакетного менеджера Rust. Но я пока не увидел конкретных примеров какой-то недоступности библиотек С. Чего именно не хватает? Удобства? Мануалов? Хотя могу согласиться с тем, что vcpkg и conan это еще те монстры, при этом, что удивительно, еще и довольно заброшенные в части новых версий библиотек.
Но я вот не помню ни одной реальной сложности подключить код особо редкой или специфической С библиотеки или "правильно" через системные .so зависимости, пересборку через .srpm, или... даже просто локально, просто напрямую распаковав файлы из .tar.gz для статической линковки и сборки через CMake. Там обычно все сводится к паре десятков файлов, задача максимум на один рабочий день, это все никогда не было недостижимой задачей вроде сборки Chrome или LibreOffice для какой Haiku OS или патча KDE4 для FreeBSD.
Масса примеров, статей. Никакой AI там особо и не нужен, любой middle dev с парой-тройкой лет опыта должен справиться. Без опыта конечно непривычно, но так без опыта и Java проект сейчас просто так не собрать, maven / artifactory и все вокруг него это еще те танцы с бубном, с разбегу туда не закатишься.
Справедливости ради это только если Release/rebuild all the world делать.
А если в режиме правка-отладка, то скорость сборки и запуска даже очень больших проектов может занимать секунды. Нужно просто уметь в PCH, и разного рода модули - от .so/.dll до .ixx/.cxx, тысячи мануалов разложены в интернетах на этот счет.
Д. Лакос же уже две книжки написал про это (заново открыв для себя и мира известные еще со времен Delphi Packages, но тем не менее).
Для С-style строк даже никаких библиотек не нужно, все работает и так.
std::string это лишь одна из библиотечных реализаций строк, ничто не мешает сделать и собственную, заменив "стандартную" (чего нельзя в C#, там только то что изначально завезли, только то и пользуйте)
А так - вон в Erlang вообще изначально нет строк (некие списки символов вместо них), и ничего, отличный язык по отзывам некоторых.
Собственно почему строка, список или хештаблица должны быть частью языка, а не свободно реализуемыми и заменяемыми библиотечными функциями?
А если мне не подходит стандартная реализация строк, почему меня кто-то должен ограничивать? К примеру я пишу код для микроконтроллеров, и никакой HEAP с RAII и jemalloc мне не нужен, у меня MISRA, которая явно запрещает динамическую аллокацию памяти.
как это здорово, что не надо писать отдельно файлы .h и .сpp!
Странный комментарий. В современном мире уже .ixx и .сxx, в C++ уже несколько лет как завезли модули. Да и Separation of Concerns это не такая и плохая штука, отделение интерфейса от реализации. То, что в "современных" ЯП все валится в кучу - это не так уж и хорошо. Вместо того, чтоб пробежаться по заголовочному файлу - теперь нужно отдельно генерировать рядом документацию, просто чтоб пользователь библиотеки не потерялся в спецификациях и знал, что можно трогать, а что нельзя. И в IDE делать отдельные символьные browserы по иерархиям классов, т.е. .h файлы просто переехали в другое место, а суть же отделения интерфейса от реализации никуда и не делась.
А продуктивность это такое - любой бухгалтер с Excel может быть в сотни раз продуктивнее целого отдела программистов, это смотря как оценивать продуктивность.
C++ даже в 2026-м году может работать без runtime, т.е. без stdlib++/STL и прочих Boost. Даже exceptions можно из него выбросить прям на старте. Можно полностью заменить new/delete, переделав их на старте на GC, ARC, или Arena Allocator и т.п. И это все равно будет C++. А STL это просто библиотека, не часть языка, хоть ее и пытаются позиционировать как неотделимую от языка, но это слава богу не так, пока ее еще можно полностью выбросить из зависимостей.
Подобная гибкость сразу дает недостижимые никому иному 100500 очков и ложит абсолютно всех на лопатки на старте, включая Swift, Kotlin и даже Rust.
C# - это просто yet another Java style Enterprise bloatware, в котором декларируется наличие библиотек для всего что угодно. А по сути эдакий 1C на супер-пупер стероидах. Но по факту там неизлечимая родовая травма - жестко вкодированный на системном уровне UTF-16. Ну и GC окончательно выводит его из технологического трека долгосрочной перспективы, т.к. GC в принципе не способен эффективно работать с кучами на десятки гигабайт, базы данных и ОС на нем точно никогда не написать. GC offheap - это костыль, а не решение. Веб странички, CRUD и простенькие UI - это да, но не более того. Даже Office на С# так и не смогли переписать, да и в самой Windows перешли на Webkit/Electron для UI, что уже говорит о многом. Плюс C# проприетарный и не true open source. И даже неповоротливую Java в которой до сих пор нет тех же properties - так и не смог победить, практически нигде.
Swift и тот смог уйти от UTF-16 и переехать на UTF-8, но не C#. C++ даже с STL в этом плане может в любые кодировки. Swift кстати, в сравнении со всеми остальными именно как язык на самом деле прям сильно хорош, и мог бы быть перспективным в целом, но в нем намертво прикручен ARC, что, увы, делает его тупиковым решением на длинной дистанции.
Так что альтернатив С++ нет (да и не было никогда).
Rust с его прям очень странными девиациями вроде "на объект может быть только одна мутабельная ссылка" выглядит скорее как агрессивно-религиозная секта пуританцев. А по факту уже 15 лет прошло, а даже coreutils толком не смогли на нем переписать, процесс все еще идет. Зато поломали вообще всем рендеринг True Type шрифтов (включая всех, которые на WebKit/Electron), других достижений и не вспомнить. Да и очень далеко не все готовы разделять подобную rust-аскезу, автор zig не даст соврать. Хайп вокруг Rust понятен, особенно подогретый уже недоступными ссылками "рекомендаций" АНБ, NASA и прочих White House, но на Silver buller он не тянет. Попытка заменить С++ по сути прогорела, если сразу не взлетело, сколько не рассказывай, что на C++ уже нельзя новые проекты открывать, но по факту на выходе получилась просто еще одна экосистема, в ряду Java, C#.NET, D, Go и прочих сообществ "С++ заменителей" появилось еще одно бесценное пополнение: Rust сообщество просто добавят своей энтропии с еще одной парой десятков невиданных реализаций веб серверов и JSON и YAML парсеров, которых к слову и под C++, и под C в избытке, а у HR-ов и PR-ов добавится головной боли на собеседованиях, так дальше все и поплывем в неведомые дали этого вашего энтерпрайз кодирования очередных CRUD UI.
То же самое с курьерами и сиделками — их труд тяжело автоматизировать, и он будет только дорожать
С сиделками ладно, а у курьеров что за уникальные навыки? Яндекс роботы доставщики по улицам уже который год катаются. Или ими люди из ЦУП по wifi-вебкамере управляют?
Офисных клерков да, сократят, но их и так постоянно сокращают, профессии бюрократ уже много сотни лет, и столько-же лет они стремятся поглотить все доступные ресурсы работодателя, методом создания новых рабочих мест себе подобных, это бесконечная эволюционная борьба.
В exceptions на самом деле ничего особо правильного и элегантного нет. Это лишь "модернизированная" форма GOTO. Причем с т.з. зрения современного программирования безнадежно устаревшая, примерно как как и UTF-16 или UTF-32
В более современных Go, Rust, Zig от exceptions отказались намеренно, заменив на монады с парой <Result>, enum <ErrorCode>, проверяемые по
switch (ErrorCode) {
case :
case :
}
По элементарной причине - при добавлении нового типа ошибки нужно получить от компилятора Warnings, что вот тут и тут нарушается контракт, у вас пропущены жестко перечисляемые секции с case и этот новый код из соответствующего enum у вас вот тут и тут не обрабатывается, допишите пожалуйста вот там и там условия для обработки, чтоб не нарушать контракты.
Классический пример: функция recv(), получения сетевых пакетов. Вот неожиданно появился новый тип errno==EGAIN на блокирующися сокетах (в Windows его нет, в Linux есть), и теперь нужно пойти все вызовы recv() перепроверить и дописать повторные обработки, т.к. это и не ошибка вовсе, а законный поток управления - нужно не падать и не плакать в лог, а просто сделать вызов еще раз.
В Java такое с проверяемыми компилятором контрактами в теории тоже было бы возможно, если бы для каждого кода ошибки делали бы свои классы исключений. Но глядя на SQLException.getErrorCode() и подобные понимаешь, что никакой элегантности там уже никогда не будет, корректность принесена в жертву обратной совместимости. Может и хотели как лучше, а получилось как всегда.
Ну и про "элегантность" NullPointerExceptions уже не одну сотню баянов порвали, эта архитектурная ошибка на миллиард обсуждалась миллионы раз.
И это мы еще про panic() и fail fast не поговорили.
выполнитьecho * в пустом и непустом каталоге, объяснить разницу в поведении. ну или ок, echo *.xml, или не echo, а любая иная команда.
Я еще не видел ни одного Senior-level DevOps-а который бы смог сходу пояснить это поведение и почему и зачем было именно так сделано. Только судорожно глотали воздух и срочно бежали перечитывать Bash Reference.
Никто никого пока еще не принуждает, Госуслуги работают и без MAX
См. выше
Практически все граждане сами сливают все что можно и нельзя, хранят пароли незашифрованные в onenote и прочих obsidian, overnote, в т.ч. пересылают пароли через gmail и telegram в открытом виде, вместе со сканами паспорта и прочих СНИЛС. Microsoft Edge вон в памяти хранит пароли незашифрованные, любой сисадмин по сетке может просканировать память машин сотрудников и получить базу паролей, и что изменилось? Где волны хейта? А так-то да, только Max поперек встал, у всех остальных с инфобезопасностью нет проблем, нужно дружно держаться за Telegram и gmail любой ценой, ни в коем случае на max и mail.ru не переходить, иначе ужас что.
Кстати что случится-то? Есть реальные секретные секреты? Пароль от приватного github с домашним PET проектом nonewsql базы данных на Zig товарищ майор узнает и на допросе пристыдит и заругает, скажет что на Rust надо было писать или что произойдет?
О чем эта статья? Озвученные 15 фич для обывателя, ни разу не прочитавшему EULA до конца - выглядят просто как штатные функции Whatsapp, Telegram и Skype, которые наконец-то сделали и в Max, ура.
Даже Павел Дуров признавал, что Android и iOS имеют слишком много контроля над пользовательскими данными и приложениями, и эти ОС нельзя называть защищенными.
А в свете операции Триангуляция (см. википедию) все эти разговоры о приватности и защищенности выглядят и вовсе как фарс. Оказывается можно было просто сделать видеозвонок любому человек и получить полный контроль над его телефоном и данными. И? Сколько человек выбросило свои iPhone после операции Триангуляция и сколько человек вообще о ней знает?
В наше время защищенные коммуникации - это наверное отдельно стоящий в бетонном подвале компьютер, подключенный лишь к бензиновому генератору, который сообщения пять раз кодирует в модифицированном GnuPG и потом записывает на CD-RW для последующей передачи его через компьютер, подключенным к интернету в соседнем здании. Все остальное это лишь спекуляции о доверии, которого по определению быть не может до тех пор, пока ОС может произвольно читать память процессов и приостанавливать их, и пока она сама может коммуницировать со своим вендором-разработчиком.
Верить что ты в iOS поставил галочку "отключить автоматические обновления" и теперь со стороны облаков apple и не apple тебе по интернету не прилетит некий blob кода для исполнения без твоего согласия - это какой-то верх наивности.
писать (генерировать) [новый] код, вследствие чего ускоряет и упрощает разработку.
Разработчик пишет новый код в лучшем случае 10% времени, в реальности еще меньше.
В остальное время разработчик читает чужой код, делает review, читает всякое бессознательное по условиям задач, рефакторит layered legacy, разгребает backlog и техдолг, чинит тесты и главное - выбрасывает старый мертвый код или переписывает шаблонный код в абстракции и прочий model driven. Чем ему тут поможет ИИ? Подбросит в десятки раз больше строк для review, refactoring и неизбежного dead code elimination? И сократит доступное время для написания нового кода с 10% до 0.1%?
Да, AI может быть прикольным для расширения кругозора, вроде "подскажи, как это можно сделать эффективнее" или "как вот это обычно делается". Может ускорить в разы забег по документации и по форумам, может выдавать даже вполне годные начальные шаблоны вызовов сторонних API и прочих вебсервисов, которые как правило нужно тут-же переписать/адаптировать, но это проще, чем с нуля писать самому, тут экономия времени неоспорима.
Но экономить время генерацией нового кода, который якобы даже читать на Review не нужно - это нонсенс, для команды в целом это просто обуза в виде еще одного джуниора, который за год создает два новых рабочих места для таких же джуниоров, которые создадут за год уже четыре новых рабочих места... и так пока проект не закроют по причине неуправляемости.
Из всего перечисленного только REST это устойчивое, хорошее решение.
Хотя если воспринимать REST как просто синоним CRUD - то он будет всегда, ибо CRUD вечен, ибо фундаментален, как двойная запись, Лука Пачоли не даст соврать.
Но если говорить про браузеры - то с одной стороны есть HTMX, правда странно, почему он не набирает обороты, видно хайпа маловато.
С другой стороны браузеры должны рано или поздно окончательно пройти эволюцию в сторону эдакого продвинутого RDP или X терминала, где никакой написанной (и читаемой) человеком логики не будет, а все будет управляться протоколом со стороны бэкэнда и его моделями и состояниями. Попытки уже были, и к слову небезуспешные (GWT / gmail как пример). И в такой концепции неизбежен дрейф в сторону бинарных протоколов обмена, человеку все равно читать их не нужно будет. На сервер-сайде уже давно стрейфовали, см. все эти ваши ProtocolBuffers и прочие TIBCO/LBM/MQTT/Kafka
Поаккуратнее там с желаниями, Codex уже умеет быть assigned за issue,
Да всеми руками за. Если это реально научится делать тривиальщину вроде добавления новых полей или записей в справочниках - то всеми руками за. И если сможет быть чуть умнее, чем PC-Lint или Coverity - тоже отлично.
Но пока тот код, что этот ваш AI генерит - в основном эпическое рукалицо. Примерно как совсем джуну перепоручить и потом руками самому править, выбрасывая глупости целыми страницами и оставляя вместо сотен строк одну-две по задаче релевантные и осмысленные. Да, иногда так проще, чем самому бегать по google/sof/документации шаблоны собирать, но не более того.
Но нужно отдать должное - иногда бывают и просветления.
К примеру я не знал что конструкция decltype(auto) это мина замедленного действия в случае ref& ссылок на возвращаемые переменные из стека, т.к. никогда ей и не пользовался. Наступил в копипасте чужого кода, и оно мне весело пояснило все о моих (вернее не моих) умственных способностях, был сильно впечатлен. Ну и ок, заменил на проверенный auto & , вечер прошел не зря :)
Но рассказы бывших коллег о том, что они на JIRA натравили AI агента и он за них сам закрывает 90% задач - так это наверное еще на сами задачи надо посмотреть.
В реальности же я еще не видел ни одного подобного примера успешно закрытой JIRA. Зато девиаций, галюцинаций и просто даже некомпилирующийся код - это хоть вагонами отгружай, каждый день.
Если окончательно закроют "лунную программу" - то это на самом деле хорошая новость. С практической точки зрения это лишь бессмысленная трата времени и денег, примерно как и МКС, где все стороны уже много лет как не знают чем реально полезным занять экипажи. Что они там изучают? Как спичка горит в невесомости, и как быстро вырастет овес при космических скоростях? Очень нужные науке знания, да.
С учетом отсутствия магнитного поля на Луне и регулярных вспышек на Солнце и потоков радиации - там довольно быстро погибнут не только растения в оранжереях, но и электроника.
Или бурить туннели подземные и там и сидеть постоянно. А с какой целью? Риголит и гелий-3 собирать? А потом его куда?
А так то да, про спейсшатлы, запускаемые каждую неделю на Луну и обратно, мы такое уже слышали и не раз.
Лучше бы сконцентрировались на массировании спутниковой группировки цифровой связи и систем оптико-электронного зондирования, эту задачу нужно было решить еще позавчера.
Т.е. система жизнеобеспечения доверена некому динамически изменяемому кем-то стороннему облачному сервису, не покрытому даже автотестами, плюс по дороге к которому есть как минимум с десяток точек отказа (экскаватор на недублированной отоволоконной линии, ветер с деревьями, отключения света в районной РЭС вместе с коммутаторами провайдеров, непредсказуемые глюки с блокировками РКН)?
Ну в принципе - да, практически гениальная реализация умного дома.
Очень надежно. По всем канонам промышленной автоматики.
Хорошая попытка, но нет.
Почти идеальная реализация ошибок могла бы выглядеть примерно так, через structured binding (или destructuring, кому как нравится):
Код условный, реальный чуть посложнее будет. Но ключевой момент тут показан: TheService::ErrorCodes это enum c конечным числом значений. И если функция TheService::callService начинает еще какой-то четвертый тип ошибок возвращать (добавили еще одно значение в enum), то компилятор нам сразу высветит все switch места, где нет case обработки этого нового типа ошибки, и их нужно срочно пойти дописать.
А лямбдо-монады - это лишь синтаксический сахар, да есть есть весьма широкая категория любителей так спагетти-кодировать, и наверное нужно уважать их культурные отличия. Но проблему расширения контрактов, в данном случае возможных кодов ошибок, и проверку их соблюдения компилятором (покрытия всех возможных кодов) все эти чудесные трудно читабельные формы callback-ов не решают от слова никак, нужно идти и вычитывать код каждый раз.
Про лямбды и углы опережения ни слова. Статья уровня "детский сад", можно даже не начинать читать.
Все это конечно невероятно увлекательно, как и книга Дж.К.Дейта. Но в реальности PostgreSQL стал популярен в РФ как замена MSSQL для 1С, и в последние годы повсеместно в мире - как более менее подобная и работоспособная замена Oracle RDBMS.
Да, уже в чем-то лучше, местами даже сильно лучше, но в целом еще развиваться и развиваться даже до уровня 9i/10g/11g, 25 летней давности: трассировка, поддержка отладчика plpgsql в IDE, оптимизатор SQL, кластеризация, все это пока еще сильно недоделано, в сравнении.
И про APEX/LowCode там тоже отдельный разговор.
Забавно, я не знал, что С (1972) появился намного позже BASIC (1962) и COBOL (1959).
А так - про именно C++ все сказано еще Луговским на sql.ru и на lurkmore, с тех пор ничего не изменилось. Единственное что изменилось - это появился Kotlin с его эпическими 2500 страницами манула только на сам язык, который я никак не могу осилить - засыпаю или забрасываю на каких-нибудь расчудесных Companion objects, Sealed Classes и прочем энтропическом сахаре. И аналогично Nim и прочие Zig (с Rust), с тем же самым эффектом - листаешь, и не понимаешь, чего авторам не хватало-то, что они пытаются сказать? Крейты трейты понапридумывали, зачем? Просто чтоб быть не как все?
Единственно что было свежее за годы - это Q/K/KDB+, и то просто как концепция, что можно очень хитро написать интерпретатор так, что он целиком залезет в L1 и начнет работать даже сильно быстрее компилируемого кода. Это было прям откровение.
С++ библиотеки чуть менее чем все требуют STL и Heap, это так, тут особо добавить нечего: или смириться c STL или просто никогда ими не пользоваться (благо там почти всегда есть альтернативы на ANSI C).
По поводу особо сложной сборки C библиотек - а вот тут странно. Они как правило есть в виде .rpm или .deb пакетов, или в составе ОС или в сторонних репозиториях вроде EPEL или COPR, и в чем там трудность их установить - лично для меня загадка. А если их нет в виде готовых .rpm, то в 90% случаев там autoconf, или CMake, да и пересобрать их прям заново из отдельных .c и .h файлов это вопрос пары часов, как правило там нет никакого rocket science. Windows выбрасываем из задачи. Там почти всегда боль и страдания. Хотя некоторым нравится.
Lock-free алгоритмы - это практически всегда header-only что-то, вокруг CAS построенное. Консольная графика - не знаю что это, наверное ncurses? Те-же mcurses вроде есть везде и для всего. LVGL? Тоже есть. Зачем там Rust?
Шифрование - тоже должна быть давно решенная тема, OpenSSL, GnuTLS, Mbed TLS, wolfSSL. Ни одно из озвученного выше пока не мотивирует вот прям бросать все и срочно переходить на Rust.
Звучит больше как реклама пакетного менеджера Rust. Но я пока не увидел конкретных примеров какой-то недоступности библиотек С. Чего именно не хватает? Удобства? Мануалов? Хотя могу согласиться с тем, что vcpkg и conan это еще те монстры, при этом, что удивительно, еще и довольно заброшенные в части новых версий библиотек.
Но я вот не помню ни одной реальной сложности подключить код особо редкой или специфической С библиотеки или "правильно" через системные .so зависимости, пересборку через .srpm, или... даже просто локально, просто напрямую распаковав файлы из .tar.gz для статической линковки и сборки через CMake. Там обычно все сводится к паре десятков файлов, задача максимум на один рабочий день, это все никогда не было недостижимой задачей вроде сборки Chrome или LibreOffice для какой Haiku OS или патча KDE4 для FreeBSD.
Масса примеров, статей. Никакой AI там особо и не нужен, любой middle dev с парой-тройкой лет опыта должен справиться. Без опыта конечно непривычно, но так без опыта и Java проект сейчас просто так не собрать, maven / artifactory и все вокруг него это еще те танцы с бубном, с разбегу туда не закатишься.
Справедливости ради это только если Release/rebuild all the world делать.
А если в режиме правка-отладка, то скорость сборки и запуска даже очень больших проектов может занимать секунды. Нужно просто уметь в PCH, и разного рода модули - от .so/.dll до .ixx/.cxx, тысячи мануалов разложены в интернетах на этот счет.
Д. Лакос же уже две книжки написал про это (заново открыв для себя и мира известные еще со времен Delphi Packages, но тем не менее).
Для С-style строк даже никаких библиотек не нужно, все работает и так.
std::string это лишь одна из библиотечных реализаций строк, ничто не мешает сделать и собственную, заменив "стандартную" (чего нельзя в C#, там только то что изначально завезли, только то и пользуйте)
А так - вон в Erlang вообще изначально нет строк (некие списки символов вместо них), и ничего, отличный язык по отзывам некоторых.
Собственно почему строка, список или хештаблица должны быть частью языка, а не свободно реализуемыми и заменяемыми библиотечными функциями?
А если мне не подходит стандартная реализация строк, почему меня кто-то должен ограничивать? К примеру я пишу код для микроконтроллеров, и никакой HEAP с RAII и jemalloc мне не нужен, у меня MISRA, которая явно запрещает динамическую аллокацию памяти.
Странный комментарий. В современном мире уже .ixx и .сxx, в C++ уже несколько лет как завезли модули. Да и Separation of Concerns это не такая и плохая штука, отделение интерфейса от реализации. То, что в "современных" ЯП все валится в кучу - это не так уж и хорошо. Вместо того, чтоб пробежаться по заголовочному файлу - теперь нужно отдельно генерировать рядом документацию, просто чтоб пользователь библиотеки не потерялся в спецификациях и знал, что можно трогать, а что нельзя. И в IDE делать отдельные символьные browserы по иерархиям классов, т.е. .h файлы просто переехали в другое место, а суть же отделения интерфейса от реализации никуда и не делась.
А продуктивность это такое - любой бухгалтер с Excel может быть в сотни раз продуктивнее целого отдела программистов, это смотря как оценивать продуктивность.
Зачем CMake? Мир намного проще устроен, все делается в одну строку:
[user@home ~]$ cat hello.cppextern "C" int puts(const char*); int main() { puts("hello world\n"); return 0; }[user@home ~]$ clang++ hello.cpp && ./a.outhello worldC++ даже в 2026-м году может работать без runtime, т.е. без stdlib++/STL и прочих Boost.
Даже exceptions можно из него выбросить прям на старте.
Можно полностью заменить new/delete, переделав их на старте на GC, ARC, или Arena Allocator и т.п. И это все равно будет C++. А STL это просто библиотека, не часть языка, хоть ее и пытаются позиционировать как неотделимую от языка, но это слава богу не так, пока ее еще можно полностью выбросить из зависимостей.
Подобная гибкость сразу дает недостижимые никому иному 100500 очков и ложит абсолютно всех на лопатки на старте, включая Swift, Kotlin и даже Rust.
C# - это просто yet another Java style Enterprise bloatware, в котором декларируется наличие библиотек для всего что угодно. А по сути эдакий 1C на супер-пупер стероидах. Но по факту там неизлечимая родовая травма - жестко вкодированный на системном уровне UTF-16. Ну и GC окончательно выводит его из технологического трека долгосрочной перспективы, т.к. GC в принципе не способен эффективно работать с кучами на десятки гигабайт, базы данных и ОС на нем точно никогда не написать. GC offheap - это костыль, а не решение. Веб странички, CRUD и простенькие UI - это да, но не более того. Даже Office на С# так и не смогли переписать, да и в самой Windows перешли на Webkit/Electron для UI, что уже говорит о многом. Плюс C# проприетарный и не true open source. И даже неповоротливую Java в которой до сих пор нет тех же properties - так и не смог победить, практически нигде.
Swift и тот смог уйти от UTF-16 и переехать на UTF-8, но не C#. C++ даже с STL в этом плане может в любые кодировки. Swift кстати, в сравнении со всеми остальными именно как язык на самом деле прям сильно хорош, и мог бы быть перспективным в целом, но в нем намертво прикручен ARC, что, увы, делает его тупиковым решением на длинной дистанции.
Так что альтернатив С++ нет (да и не было никогда).
Rust с его прям очень странными девиациями вроде "на объект может быть только одна мутабельная ссылка" выглядит скорее как агрессивно-религиозная секта пуританцев. А по факту уже 15 лет прошло, а даже coreutils толком не смогли на нем переписать, процесс все еще идет. Зато поломали вообще всем рендеринг True Type шрифтов (включая всех, которые на WebKit/Electron), других достижений и не вспомнить. Да и очень далеко не все готовы разделять подобную rust-аскезу, автор zig не даст соврать. Хайп вокруг Rust понятен, особенно подогретый уже недоступными ссылками "рекомендаций" АНБ, NASA и прочих White House, но на Silver buller он не тянет. Попытка заменить С++ по сути прогорела, если сразу не взлетело, сколько не рассказывай, что на C++ уже нельзя новые проекты открывать, но по факту на выходе получилась просто еще одна экосистема, в ряду Java, C#.NET, D, Go и прочих сообществ "С++ заменителей" появилось еще одно бесценное пополнение: Rust сообщество просто добавят своей энтропии с еще одной парой десятков невиданных реализаций веб серверов и JSON и YAML парсеров, которых к слову и под C++, и под C в избытке, а у HR-ов и PR-ов добавится головной боли на собеседованиях, так дальше все и поплывем в неведомые дали этого вашего энтерпрайз кодирования очередных CRUD UI.
С сиделками ладно, а у курьеров что за уникальные навыки? Яндекс роботы доставщики по улицам уже который год катаются. Или ими люди из ЦУП по wifi-вебкамере управляют?
Офисных клерков да, сократят, но их и так постоянно сокращают, профессии бюрократ уже много сотни лет, и столько-же лет они стремятся поглотить все доступные ресурсы работодателя, методом создания новых рабочих мест себе подобных, это бесконечная эволюционная борьба.
В exceptions на самом деле ничего особо правильного и элегантного нет. Это лишь "модернизированная" форма GOTO. Причем с т.з. зрения современного программирования безнадежно устаревшая, примерно как как и UTF-16 или UTF-32
В более современных Go, Rust, Zig от exceptions отказались намеренно, заменив на монады с парой <Result>, enum <ErrorCode>, проверяемые по
switch (ErrorCode) {case :case :}По элементарной причине - при добавлении нового типа ошибки нужно получить от компилятора Warnings, что вот тут и тут нарушается контракт, у вас пропущены жестко перечисляемые секции с
caseи этот новый код из соответствующего enum у вас вот тут и тут не обрабатывается, допишите пожалуйста вот там и там условия для обработки, чтоб не нарушать контракты.Классический пример: функция recv(), получения сетевых пакетов. Вот неожиданно появился новый тип errno==EGAIN на блокирующися сокетах (в Windows его нет, в Linux есть), и теперь нужно пойти все вызовы recv() перепроверить и дописать повторные обработки, т.к. это и не ошибка вовсе, а законный поток управления - нужно не падать и не плакать в лог, а просто сделать вызов еще раз.
В Java такое с проверяемыми компилятором контрактами в теории тоже было бы возможно, если бы для каждого кода ошибки делали бы свои классы исключений. Но глядя на SQLException.getErrorCode() и подобные понимаешь, что никакой элегантности там уже никогда не будет, корректность принесена в жертву обратной совместимости. Может и хотели как лучше, а получилось как всегда.
Ну и про "элегантность" NullPointerExceptions уже не одну сотню баянов порвали, эта архитектурная ошибка на миллиард обсуждалась миллионы раз.
И это мы еще про panic() и fail fast не поговорили.
выполнить
echo *в пустом и непустом каталоге, объяснить разницу в поведении.ну или ок,
echo *.xml,или неecho, а любая иная команда.Я еще не видел ни одного Senior-level DevOps-а который бы смог сходу пояснить это поведение и почему и зачем было именно так сделано. Только судорожно глотали воздух и срочно бежали перечитывать Bash Reference.
Никто никого пока еще не принуждает, Госуслуги работают и без MAX
См. выше
Практически все граждане сами сливают все что можно и нельзя, хранят пароли незашифрованные в onenote и прочих obsidian, overnote, в т.ч. пересылают пароли через gmail и telegram в открытом виде, вместе со сканами паспорта и прочих СНИЛС. Microsoft Edge вон в памяти хранит пароли незашифрованные, любой сисадмин по сетке может просканировать память машин сотрудников и получить базу паролей, и что изменилось? Где волны хейта? А так-то да, только Max поперек встал, у всех остальных с инфобезопасностью нет проблем, нужно дружно держаться за Telegram и gmail любой ценой, ни в коем случае на max и mail.ru не переходить, иначе ужас что.
Кстати что случится-то? Есть реальные секретные секреты? Пароль от приватного github с домашним PET проектом nonewsql базы данных на Zig товарищ майор узнает и на допросе пристыдит и заругает, скажет что на Rust надо было писать или что произойдет?
О чем эта статья? Озвученные 15 фич для обывателя, ни разу не прочитавшему EULA до конца - выглядят просто как штатные функции Whatsapp, Telegram и Skype, которые наконец-то сделали и в Max, ура.
Даже Павел Дуров признавал, что Android и iOS имеют слишком много контроля над пользовательскими данными и приложениями, и эти ОС нельзя называть защищенными.
А в свете операции Триангуляция (см. википедию) все эти разговоры о приватности и защищенности выглядят и вовсе как фарс. Оказывается можно было просто сделать видеозвонок любому человек и получить полный контроль над его телефоном и данными. И? Сколько человек выбросило свои iPhone после операции Триангуляция и сколько человек вообще о ней знает?
В наше время защищенные коммуникации - это наверное отдельно стоящий в бетонном подвале компьютер, подключенный лишь к бензиновому генератору, который сообщения пять раз кодирует в модифицированном GnuPG и потом записывает на CD-RW для последующей передачи его через компьютер, подключенным к интернету в соседнем здании. Все остальное это лишь спекуляции о доверии, которого по определению быть не может до тех пор, пока ОС может произвольно читать память процессов и приостанавливать их, и пока она сама может коммуницировать со своим вендором-разработчиком.
Верить что ты в iOS поставил галочку "отключить автоматические обновления" и теперь со стороны облаков apple и не apple тебе по интернету не прилетит некий blob кода для исполнения без твоего согласия - это какой-то верх наивности.
Разработчик пишет новый код в лучшем случае 10% времени, в реальности еще меньше.
В остальное время разработчик читает чужой код, делает review, читает всякое бессознательное по условиям задач, рефакторит layered legacy, разгребает backlog и техдолг, чинит тесты и главное - выбрасывает старый мертвый код или переписывает шаблонный код в абстракции и прочий model driven. Чем ему тут поможет ИИ?
Подбросит в десятки раз больше строк для review, refactoring и неизбежного dead code elimination? И сократит доступное время для написания нового кода с 10% до 0.1%?
Да, AI может быть прикольным для расширения кругозора, вроде "подскажи, как это можно сделать эффективнее" или "как вот это обычно делается". Может ускорить в разы забег по документации и по форумам, может выдавать даже вполне годные начальные шаблоны вызовов сторонних API и прочих вебсервисов, которые как правило нужно тут-же переписать/адаптировать, но это проще, чем с нуля писать самому, тут экономия времени неоспорима.
Но экономить время генерацией нового кода, который якобы даже читать на Review не нужно - это нонсенс, для команды в целом это просто обуза в виде еще одного джуниора, который за год создает два новых рабочих места для таких же джуниоров, которые создадут за год уже четыре новых рабочих места... и так пока проект не закроют по причине неуправляемости.
Хотя если воспринимать REST как просто синоним CRUD - то он будет всегда, ибо CRUD вечен, ибо фундаментален, как двойная запись, Лука Пачоли не даст соврать.
Но если говорить про браузеры - то с одной стороны есть HTMX, правда странно, почему он не набирает обороты, видно хайпа маловато.
С другой стороны браузеры должны рано или поздно окончательно пройти эволюцию в сторону эдакого продвинутого RDP или X терминала, где никакой написанной (и читаемой) человеком логики не будет, а все будет управляться протоколом со стороны бэкэнда и его моделями и состояниями. Попытки уже были, и к слову небезуспешные (GWT / gmail как пример).
И в такой концепции неизбежен дрейф в сторону бинарных протоколов обмена, человеку все равно читать их не нужно будет. На сервер-сайде уже давно стрейфовали, см. все эти ваши ProtocolBuffers и прочие TIBCO/LBM/MQTT/Kafka
Да всеми руками за. Если это реально научится делать тривиальщину вроде добавления новых полей или записей в справочниках - то всеми руками за. И если сможет быть чуть умнее, чем PC-Lint или Coverity - тоже отлично.
Но пока тот код, что этот ваш AI генерит - в основном эпическое рукалицо. Примерно как совсем джуну перепоручить и потом руками самому править, выбрасывая глупости целыми страницами и оставляя вместо сотен строк одну-две по задаче релевантные и осмысленные. Да, иногда так проще, чем самому бегать по google/sof/документации шаблоны собирать, но не более того.
Но нужно отдать должное - иногда бывают и просветления.
К примеру я не знал что конструкция decltype(auto) это мина замедленного действия в случае ref& ссылок на возвращаемые переменные из стека, т.к. никогда ей и не пользовался. Наступил в копипасте чужого кода, и оно мне весело пояснило все о моих (вернее не моих) умственных способностях, был сильно впечатлен. Ну и ок, заменил на проверенный auto & , вечер прошел не зря :)
Но рассказы бывших коллег о том, что они на JIRA натравили AI агента и он за них сам закрывает 90% задач - так это наверное еще на сами задачи надо посмотреть.
В реальности же я еще не видел ни одного подобного примера успешно закрытой JIRA. Зато девиаций, галюцинаций и просто даже некомпилирующийся код - это хоть вагонами отгружай, каждый день.
Если окончательно закроют "лунную программу" - то это на самом деле хорошая новость. С практической точки зрения это лишь бессмысленная трата времени и денег, примерно как и МКС, где все стороны уже много лет как не знают чем реально полезным занять экипажи. Что они там изучают? Как спичка горит в невесомости, и как быстро вырастет овес при космических скоростях? Очень нужные науке знания, да.
С учетом отсутствия магнитного поля на Луне и регулярных вспышек на Солнце и потоков радиации - там довольно быстро погибнут не только растения в оранжереях, но и электроника.
Или бурить туннели подземные и там и сидеть постоянно. А с какой целью? Риголит и гелий-3 собирать? А потом его куда?
А так то да, про спейсшатлы, запускаемые каждую неделю на Луну и обратно, мы такое уже слышали и не раз.
Лучше бы сконцентрировались на массировании спутниковой группировки цифровой связи и систем оптико-электронного зондирования, эту задачу нужно было решить еще позавчера.