На какой ОС вы сидите прямо сейчас?
Anonymous Poll
50%
Linux (Arch, Ubuntu, Debian...)
0%
Windows (чистая или с WSL)
0%
macOS (для работы и жизни)
50%
Dual-boot (Linux + Windows)
0%
Экзотика (BSD, Haiku и др.)
Вы когда-нибудь пробовали редактировать длинную команду в терминале, используя только стрелочки на клавиатуре? Тот еще мазохизм. Одно неловкое движение, и вы случайно стираете половину сложного bash-скрипта или длинного curl-запроса с десятком заголовков.
Есть скрытая фича, которая экономит кучу нервов и времени, но о ней почему-то знают немногие.
В следующий раз, когда вы поймете, что ваша команда в терминале разрастается до размеров романа, просто нажмите комбинацию:
Зажмите Ctrl и по очереди нажмите X, а затем E.
Магия! Ваш терминал мгновенно откроет текущую команду в полноценном текстовом редакторе. Обычно это Vim или Nano, в зависимости от того, что настроено в системе по умолчанию.
Здесь вы можете спокойно редактировать текст: копировать, вставлять, использовать поиск, разбивать команду на несколько строк для читаемости. Как только вы закончите, просто сохраните файл и выйдете из редактора. В Vim это :wq, в Nano — Ctrl+O и Ctrl+X.
Сразу после выхода отредактированная команда автоматически выполнится в терминале.
Как это настроить под себя?
По умолчанию система открывает тот редактор, который прописан в переменной окружения EDITOR. Если у вас открывается неудобный дефолтный редактор, это легко исправить. Просто добавьте в свой файл конфигурации (.bashrc или .zshrc) строчку:
export EDITOR="nano"
Вместо nano можно вписать vim, mcedit или даже "code --wait", если хотите редактировать команды в VS Code.
Этот лайфхак особенно спасает, когда нужно быстро набросать цикл for прямо в консоли или когда вы скопировали огромную команду из документации и хотите быстро поправить в ней параметры перед запуском. Больше никакого бесконечного зажатия стрелочки влево.
Пользуетесь этой фичей или по старинке мучаете стрелочки и Ctrl+A / Ctrl+E? Делитесь своими любимыми хоткеями для терминала в комментариях, соберем базу полезных шорткатов.
📍 Подпишись на создателей: https://t.me/linuxexe
Есть скрытая фича, которая экономит кучу нервов и времени, но о ней почему-то знают немногие.
В следующий раз, когда вы поймете, что ваша команда в терминале разрастается до размеров романа, просто нажмите комбинацию:
Зажмите Ctrl и по очереди нажмите X, а затем E.
Магия! Ваш терминал мгновенно откроет текущую команду в полноценном текстовом редакторе. Обычно это Vim или Nano, в зависимости от того, что настроено в системе по умолчанию.
Здесь вы можете спокойно редактировать текст: копировать, вставлять, использовать поиск, разбивать команду на несколько строк для читаемости. Как только вы закончите, просто сохраните файл и выйдете из редактора. В Vim это :wq, в Nano — Ctrl+O и Ctrl+X.
Сразу после выхода отредактированная команда автоматически выполнится в терминале.
Как это настроить под себя?
По умолчанию система открывает тот редактор, который прописан в переменной окружения EDITOR. Если у вас открывается неудобный дефолтный редактор, это легко исправить. Просто добавьте в свой файл конфигурации (.bashrc или .zshrc) строчку:
export EDITOR="nano"
Вместо nano можно вписать vim, mcedit или даже "code --wait", если хотите редактировать команды в VS Code.
Этот лайфхак особенно спасает, когда нужно быстро набросать цикл for прямо в консоли или когда вы скопировали огромную команду из документации и хотите быстро поправить в ней параметры перед запуском. Больше никакого бесконечного зажатия стрелочки влево.
Пользуетесь этой фичей или по старинке мучаете стрелочки и Ctrl+A / Ctrl+E? Делитесь своими любимыми хоткеями для терминала в комментариях, соберем базу полезных шорткатов.
📍 Подпишись на создателей: https://t.me/linuxexe
🛠 Инструмент дня: ripgrep
Если ты до сих пор ищешь по проекту через grep -R, попробуй rg.
Пример:
rg "TODO|FIXME"
ripgrep быстрый, по умолчанию уважает .gitignore и удобно показывает контекст. Для больших репозиториев разница чувствуется сразу.
Полезные варианты:
rg -n "pattern" — с номерами строк
rg --files — список файлов проекта
rg -t py "async def" — искать только в Python-файлах
Один из тех инструментов, после которых назад возвращаться не хочется.
📍 Подпишись на создателей: https://t.me/linuxexe
Если ты до сих пор ищешь по проекту через grep -R, попробуй rg.
Пример:
rg "TODO|FIXME"
ripgrep быстрый, по умолчанию уважает .gitignore и удобно показывает контекст. Для больших репозиториев разница чувствуется сразу.
Полезные варианты:
rg -n "pattern" — с номерами строк
rg --files — список файлов проекта
rg -t py "async def" — искать только в Python-файлах
Один из тех инструментов, после которых назад возвращаться не хочется.
📍 Подпишись на создателей: https://t.me/linuxexe
💡 Bash/Zsh: !! и !$
Две короткие подстановки, которые реально ускоряют работу:
!! — повторить предыдущую команду
!$ — взять последний аргумент предыдущей команды
Пример:
mkdir /tmp/test-project
cd !$
Вторая команда превратится в:
cd /tmp/test-project
А если забыл sudo:
sudo !!
Терминал любит тех, кто знает его маленькие трюки.
📍 Подпишись на создателей: https://t.me/linuxexe
Две короткие подстановки, которые реально ускоряют работу:
!! — повторить предыдущую команду
!$ — взять последний аргумент предыдущей команды
Пример:
mkdir /tmp/test-project
cd !$
Вторая команда превратится в:
cd /tmp/test-project
А если забыл sudo:
sudo !!
Терминал любит тех, кто знает его маленькие трюки.
📍 Подпишись на создателей: https://t.me/linuxexe
🔐 Linux security: проверь SSH-доступ
Минимальный чек-лист для сервера:
1. Отключить вход root по SSH:
PermitRootLogin no
2. Отключить парольный вход, если используешь ключи:
PasswordAuthentication no
3. Проверить, кто вообще может логиниться:
AllowUsers your_user
После изменения конфига не закрывай текущую SSH-сессию сразу. Сначала открой вторую и проверь вход.
Так ты не заблокируешь сам себя из-за опечатки.
📍 Подпишись на создателей: https://t.me/linuxexe
Минимальный чек-лист для сервера:
1. Отключить вход root по SSH:
PermitRootLogin no
2. Отключить парольный вход, если используешь ключи:
PasswordAuthentication no
3. Проверить, кто вообще может логиниться:
AllowUsers your_user
После изменения конфига не закрывай текущую SSH-сессию сразу. Сначала открой вторую и проверь вход.
Так ты не заблокируешь сам себя из-за опечатки.
📍 Подпишись на создателей: https://t.me/linuxexe
🧩 Как systemd запускает сервисы простыми словами
systemd читает unit-файлы, понимает зависимости и запускает сервисы в нужном порядке.
Например, если приложению нужна сеть, unit может указать:
After=network-online.target
Главные команды:
systemctl status nginx — состояние сервиса
systemctl restart nginx — перезапуск
journalctl -u nginx -f — живые логи
systemd не просто «запускает демоны». Он ещё следит за процессами, логирует, рестартит при падении и помогает понять, почему сервис не поднялся.
📍 Подпишись на создателей: https://t.me/linuxexe
systemd читает unit-файлы, понимает зависимости и запускает сервисы в нужном порядке.
Например, если приложению нужна сеть, unit может указать:
After=network-online.target
Главные команды:
systemctl status nginx — состояние сервиса
systemctl restart nginx — перезапуск
journalctl -u nginx -f — живые логи
systemd не просто «запускает демоны». Он ещё следит за процессами, логирует, рестартит при падении и помогает понять, почему сервис не поднялся.
📍 Подпишись на создателей: https://t.me/linuxexe
🛠 Инструмент дня: ripgrep
Если ты до сих пор ищешь по проекту через grep -R, попробуй rg.
Пример:
rg "TODO|FIXME"
ripgrep быстрый, по умолчанию уважает .gitignore и удобно показывает контекст. Для больших репозиториев разница чувствуется сразу.
Полезные варианты:
rg -n "pattern" — с номерами строк
rg --files — список файлов проекта
rg -t py "async def" — искать только в Python-файлах
Один из тех инструментов, после которых назад возвращаться не хочется.
📍 Подпишись на создателей: https://t.me/linuxexe
Если ты до сих пор ищешь по проекту через grep -R, попробуй rg.
Пример:
rg "TODO|FIXME"
ripgrep быстрый, по умолчанию уважает .gitignore и удобно показывает контекст. Для больших репозиториев разница чувствуется сразу.
Полезные варианты:
rg -n "pattern" — с номерами строк
rg --files — список файлов проекта
rg -t py "async def" — искать только в Python-файлах
Один из тех инструментов, после которых назад возвращаться не хочется.
📍 Подпишись на создателей: https://t.me/linuxexe
🔐 Linux security: проверь SSH-доступ
Минимальный чек-лист для сервера:
1. Отключить вход root по SSH:
PermitRootLogin no
2. Отключить парольный вход, если используешь ключи:
PasswordAuthentication no
3. Проверить, кто вообще может логиниться:
AllowUsers your_user
После изменения конфига не закрывай текущую SSH-сессию сразу. Сначала открой вторую и проверь вход.
Так ты не заблокируешь сам себя из-за опечатки.
📍 Подпишись на создателей: https://t.me/linuxexe
Минимальный чек-лист для сервера:
1. Отключить вход root по SSH:
PermitRootLogin no
2. Отключить парольный вход, если используешь ключи:
PasswordAuthentication no
3. Проверить, кто вообще может логиниться:
AllowUsers your_user
После изменения конфига не закрывай текущую SSH-сессию сразу. Сначала открой вторую и проверь вход.
Так ты не заблокируешь сам себя из-за опечатки.
📍 Подпишись на создателей: https://t.me/linuxexe
🛠 Инструмент дня: ripgrep
Если ты до сих пор ищешь по проекту через grep -R, попробуй rg.
Пример:
rg "TODO|FIXME"
ripgrep быстрый, по умолчанию уважает .gitignore и удобно показывает контекст. Для больших репозиториев разница чувствуется сразу.
Полезные варианты:
rg -n "pattern" — с номерами строк
rg --files — список файлов проекта
rg -t py "async def" — искать только в Python-файлах
Один из тех инструментов, после которых назад возвращаться не хочется.
📍 Подпишись на создателей: https://t.me/linuxexe
Если ты до сих пор ищешь по проекту через grep -R, попробуй rg.
Пример:
rg "TODO|FIXME"
ripgrep быстрый, по умолчанию уважает .gitignore и удобно показывает контекст. Для больших репозиториев разница чувствуется сразу.
Полезные варианты:
rg -n "pattern" — с номерами строк
rg --files — список файлов проекта
rg -t py "async def" — искать только в Python-файлах
Один из тех инструментов, после которых назад возвращаться не хочется.
📍 Подпишись на создателей: https://t.me/linuxexe
📰 Brain scans of 5,832 adolescents (8-11 years) found that stronger amygdala responses to emotional faces predicted different social outcomes two years later: increased amygdala activity for girls predicted more involvement with their peers, but predicted less involvement for boys
Источник (r/science): https://www.reddit.com/r/science/comments/1ux2ouc/brain_scans_of_5832_adolescents_811_years_found/
📍 Подпишись на создателей: https://t.me/linuxexe
Источник (r/science): https://www.reddit.com/r/science/comments/1ux2ouc/brain_scans_of_5832_adolescents_811_years_found/
📍 Подпишись на создателей: https://t.me/linuxexe
Reddit
From the science community on Reddit: Brain scans of 5,832 adolescents (8-11 years) found that stronger amygdala responses to emotional…
Explore this post and more from the science community
🛠 Инструмент дня: ripgrep
Если ты до сих пор ищешь по проекту через grep -R, попробуй rg.
Пример:
rg "TODO|FIXME"
ripgrep быстрый, по умолчанию уважает .gitignore и удобно показывает контекст. Для больших репозиториев разница чувствуется сразу.
Полезные варианты:
rg -n "pattern" — с номерами строк
rg --files — список файлов проекта
rg -t py "async def" — искать только в Python-файлах
Один из тех инструментов, после которых назад возвращаться не хочется.
📍 Подпишись на создателей: https://t.me/linuxexe
Если ты до сих пор ищешь по проекту через grep -R, попробуй rg.
Пример:
rg "TODO|FIXME"
ripgrep быстрый, по умолчанию уважает .gitignore и удобно показывает контекст. Для больших репозиториев разница чувствуется сразу.
Полезные варианты:
rg -n "pattern" — с номерами строк
rg --files — список файлов проекта
rg -t py "async def" — искать только в Python-файлах
Один из тех инструментов, после которых назад возвращаться не хочется.
📍 Подпишись на создателей: https://t.me/linuxexe
📜 Open source факт: Linux начинался не как «большой проект»
В 1991 году Линус Торвальдс выложил ядро как личный эксперимент для своего компьютера. Никакого плана захватить серверы, облака, Android и embedded-мир тогда не было.
Сила Linux оказалась не только в коде, а в модели разработки: тысячи людей могли читать, чинить, портировать и улучшать систему под свои задачи.
Итог: сегодня Linux работает в серверах, роутерах, телефонах, суперкомпьютерах и куче устройств, о которых пользователь даже не думает.
📍 Подпишись на создателей: https://t.me/linuxexe
В 1991 году Линус Торвальдс выложил ядро как личный эксперимент для своего компьютера. Никакого плана захватить серверы, облака, Android и embedded-мир тогда не было.
Сила Linux оказалась не только в коде, а в модели разработки: тысячи людей могли читать, чинить, портировать и улучшать систему под свои задачи.
Итог: сегодня Linux работает в серверах, роутерах, телефонах, суперкомпьютерах и куче устройств, о которых пользователь даже не думает.
📍 Подпишись на создателей: https://t.me/linuxexe
💡 Bash/Zsh: !! и !$
Две короткие подстановки, которые реально ускоряют работу:
!! — повторить предыдущую команду
!$ — взять последний аргумент предыдущей команды
Пример:
mkdir /tmp/test-project
cd !$
Вторая команда превратится в:
cd /tmp/test-project
А если забыл sudo:
sudo !!
Терминал любит тех, кто знает его маленькие трюки.
📍 Подпишись на создателей: https://t.me/linuxexe
Две короткие подстановки, которые реально ускоряют работу:
!! — повторить предыдущую команду
!$ — взять последний аргумент предыдущей команды
Пример:
mkdir /tmp/test-project
cd !$
Вторая команда превратится в:
cd /tmp/test-project
А если забыл sudo:
sudo !!
Терминал любит тех, кто знает его маленькие трюки.
📍 Подпишись на создателей: https://t.me/linuxexe
🔐 Linux security: проверь SSH-доступ
Минимальный чек-лист для сервера:
1. Отключить вход root по SSH:
PermitRootLogin no
2. Отключить парольный вход, если используешь ключи:
PasswordAuthentication no
3. Проверить, кто вообще может логиниться:
AllowUsers your_user
После изменения конфига не закрывай текущую SSH-сессию сразу. Сначала открой вторую и проверь вход.
Так ты не заблокируешь сам себя из-за опечатки.
📍 Подпишись на создателей: https://t.me/linuxexe
Минимальный чек-лист для сервера:
1. Отключить вход root по SSH:
PermitRootLogin no
2. Отключить парольный вход, если используешь ключи:
PasswordAuthentication no
3. Проверить, кто вообще может логиниться:
AllowUsers your_user
После изменения конфига не закрывай текущую SSH-сессию сразу. Сначала открой вторую и проверь вход.
Так ты не заблокируешь сам себя из-за опечатки.
📍 Подпишись на создателей: https://t.me/linuxexe
БукТок в ТикТоке — это что вообще такое и почему это тупо
Если ты хоть раз открывал ТикТок и попадал в алгоритм БукТока, ты понимаешь о чём речь. Десятки тысяч роликов, где человек держит книгу, смотрит в камеру с задумчивым лицом, говорит "эта книга изменила мою жизнь" — и всё. Ни цитаты, ни мысли, ни даже нормального пересказа. Просто эстетика чтения без самого чтения.
Движение называется БукТок. Формально это сообщество любителей книг в ТикТоке. Неформально — это соревнование по количеству красиво сфотографированных стопок книг и слезливых реакций на финалы Young Adult романов.
Вот типичный ролик: девушка достаёт книгу из посылки, нюхает её, ставит на полку рядом с ещё пятьюдесятью непрочитанными. Миллион просмотров. Комментарии — "я тоже так делаю", "OMG я заказала эту же", "расскажи про неё". Про книгу — ничего. Вообще.
Или другой формат: "книги, которые я не смогла дочитать". Список из пяти классических романов, которые считаются сложными. Виновные — Достоевский, Толстой, Маркес. Подача — как будто сам факт того, что книга не зашла за вечер, делает её плохой. Видео набирает полмиллиона просмотров от людей, которые радостно соглашаются, что классика скучная.
В чём реальная проблема
БукТок создал культуру потребления образа читателя вместо самого чтения. Важно не что ты прочитал, а как это выглядит. Полки должны быть эстетичными. Закладки — дорогими. Кофе рядом с книгой — обязательно.
Алгоритм ТикТока усиливает это до предела. Короткий ролик с эмоциональной реакцией на финал книги бьёт любой вдумчивый разбор. Зачем объяснять идеи Кафки, если можно просто поплакать в камеру держа "Процесс" в руках?
Отдельный жанр — рейтинги книг по "романтике". Берётся серьёзная литература и оценивается по тому, достаточно ли там любовной линии. Всё, что не про любовь — скучно и не заслуживает внимания.
Практический вывод
Если тебе интересны реальные книжные рекомендации — БукТок не лучшее место. Там работает та же механика, что и везде в соцсетях: побеждает эмоция, а не содержание.
Лучше работают старые форматы. Длинные рецензии на LiveLib или Goodreads, где человек реально разбирает книгу. Подкасты про литературу, где есть время объяснить контекст. Книжные каналы в том же Телеграме, где аудитория меньше, но разговор предметный.
БукТок — это не про книги. Это про эстетику человека, который читает. А это разные вещи, хотя алгоритм очень старательно делает вид, что нет.
📍 Подпишись на создателей: https://t.me/linuxexe
Если ты хоть раз открывал ТикТок и попадал в алгоритм БукТока, ты понимаешь о чём речь. Десятки тысяч роликов, где человек держит книгу, смотрит в камеру с задумчивым лицом, говорит "эта книга изменила мою жизнь" — и всё. Ни цитаты, ни мысли, ни даже нормального пересказа. Просто эстетика чтения без самого чтения.
Движение называется БукТок. Формально это сообщество любителей книг в ТикТоке. Неформально — это соревнование по количеству красиво сфотографированных стопок книг и слезливых реакций на финалы Young Adult романов.
Вот типичный ролик: девушка достаёт книгу из посылки, нюхает её, ставит на полку рядом с ещё пятьюдесятью непрочитанными. Миллион просмотров. Комментарии — "я тоже так делаю", "OMG я заказала эту же", "расскажи про неё". Про книгу — ничего. Вообще.
Или другой формат: "книги, которые я не смогла дочитать". Список из пяти классических романов, которые считаются сложными. Виновные — Достоевский, Толстой, Маркес. Подача — как будто сам факт того, что книга не зашла за вечер, делает её плохой. Видео набирает полмиллиона просмотров от людей, которые радостно соглашаются, что классика скучная.
В чём реальная проблема
БукТок создал культуру потребления образа читателя вместо самого чтения. Важно не что ты прочитал, а как это выглядит. Полки должны быть эстетичными. Закладки — дорогими. Кофе рядом с книгой — обязательно.
Алгоритм ТикТока усиливает это до предела. Короткий ролик с эмоциональной реакцией на финал книги бьёт любой вдумчивый разбор. Зачем объяснять идеи Кафки, если можно просто поплакать в камеру держа "Процесс" в руках?
Отдельный жанр — рейтинги книг по "романтике". Берётся серьёзная литература и оценивается по тому, достаточно ли там любовной линии. Всё, что не про любовь — скучно и не заслуживает внимания.
Практический вывод
Если тебе интересны реальные книжные рекомендации — БукТок не лучшее место. Там работает та же механика, что и везде в соцсетях: побеждает эмоция, а не содержание.
Лучше работают старые форматы. Длинные рецензии на LiveLib или Goodreads, где человек реально разбирает книгу. Подкасты про литературу, где есть время объяснить контекст. Книжные каналы в том же Телеграме, где аудитория меньше, но разговор предметный.
БукТок — это не про книги. Это про эстетику человека, который читает. А это разные вещи, хотя алгоритм очень старательно делает вид, что нет.
📍 Подпишись на создателей: https://t.me/linuxexe
📰 SQLite should have (Rust-style) editions
Источник (r/programming): https://www.reddit.com/r/programming/comments/1uxgmmq/sqlite_should_have_ruststyle_editions/
📍 Подпишись на создателей: https://t.me/linuxexe
Источник (r/programming): https://www.reddit.com/r/programming/comments/1uxgmmq/sqlite_should_have_ruststyle_editions/
📍 Подпишись на создателей: https://t.me/linuxexe
Почему умные люди ненавидят C++ сильнее всего
Есть интересная закономерность. Чем лучше человек понимает программирование — тем злее он говорит о C++. Новички его боятся. Мидлы терпят. А по-настоящему опытные разработчики смотрят на него с таким выражением лица, будто им предложили починить ядерный реактор отвёрткой из IKEA.
Почему так?
Потому что гении видят язык насквозь. И то, что они там видят, им не нравится.
C++ — это не просто сложный язык. Это язык, который накапливал фичи 40 лет, никогда ничего не выбрасывая. Каждый стандарт добавлял новый слой поверх старого. Сейчас это Франкенштейн, где мирно сосуществуют сырые указатели из 1983 года, концепты из C++20 и три разных способа инициализировать переменную, которые ведут себя по-разному в зависимости от фазы луны.
Умный человек сразу замечает: язык не имеет единой философии. В Python всё — объект. В Haskell всё — функция. В C++ всё — исторически сложилось.
Вот конкретный пример который сводит с ума
Возьми простую задачу — создать вектор из трёх единиц.
std::vector<int> v1(3, 1); — три элемента со значением 1
std::vector<int> v2{3, 1}; — два элемента: 3 и 1
Одна пара скобок меняет смысл полностью. Это не баг. Это "фича" uniform initialization из C++11, которая конфликтует со старым синтаксисом. Комитет знал об этом. Оставили как есть.
Или undefined behavior. В большинстве языков если ты написал что-то неправильно — получишь ошибку. В C++ ты можешь написать технически компилируемый код, который будет работать нормально на твоей машине, нормально на CI, а на продакшне в пятницу вечером тихо съест память и уйдёт. И это не просто баг — это поведение, которое стандарт явно оставил "неопределённым", чтобы дать компиляторам свободу оптимизировать.
Гений понимает: это не просто сложность. Это непоследовательность, возведённая в принцип.
Люди вроде Линуса Торвальдса, Джоэла Спольски, Дейкстры в своё время — они не ненавидели C++ потому что он сложный. Они ненавидели его потому что он сложный без достаточной причины. Потому что за этой сложностью не стоит красивая модель мира — стоит комитет из 200 человек с противоречивыми хотелками и груз обратной совместимости.
При этом C++ никуда не денется
Игры, операционные системы, базы данных, браузерные движки — всё это на C++. Потому что скорость реальная, контроль реальный, и замены пока нет. Rust пытается, но там своя боль.
Практический вывод такой: если ты пишешь на C++ и тебе не больно — ты ещё не писал достаточно. Если тебе больно — добро пожаловать в клуб. Здесь все злые, кофе крепкий и undefined behavior подстерегает за каждым углом.
📍 Подпишись на создателей: https://t.me/linuxexe
Есть интересная закономерность. Чем лучше человек понимает программирование — тем злее он говорит о C++. Новички его боятся. Мидлы терпят. А по-настоящему опытные разработчики смотрят на него с таким выражением лица, будто им предложили починить ядерный реактор отвёрткой из IKEA.
Почему так?
Потому что гении видят язык насквозь. И то, что они там видят, им не нравится.
C++ — это не просто сложный язык. Это язык, который накапливал фичи 40 лет, никогда ничего не выбрасывая. Каждый стандарт добавлял новый слой поверх старого. Сейчас это Франкенштейн, где мирно сосуществуют сырые указатели из 1983 года, концепты из C++20 и три разных способа инициализировать переменную, которые ведут себя по-разному в зависимости от фазы луны.
Умный человек сразу замечает: язык не имеет единой философии. В Python всё — объект. В Haskell всё — функция. В C++ всё — исторически сложилось.
Вот конкретный пример который сводит с ума
Возьми простую задачу — создать вектор из трёх единиц.
std::vector<int> v1(3, 1); — три элемента со значением 1
std::vector<int> v2{3, 1}; — два элемента: 3 и 1
Одна пара скобок меняет смысл полностью. Это не баг. Это "фича" uniform initialization из C++11, которая конфликтует со старым синтаксисом. Комитет знал об этом. Оставили как есть.
Или undefined behavior. В большинстве языков если ты написал что-то неправильно — получишь ошибку. В C++ ты можешь написать технически компилируемый код, который будет работать нормально на твоей машине, нормально на CI, а на продакшне в пятницу вечером тихо съест память и уйдёт. И это не просто баг — это поведение, которое стандарт явно оставил "неопределённым", чтобы дать компиляторам свободу оптимизировать.
Гений понимает: это не просто сложность. Это непоследовательность, возведённая в принцип.
Люди вроде Линуса Торвальдса, Джоэла Спольски, Дейкстры в своё время — они не ненавидели C++ потому что он сложный. Они ненавидели его потому что он сложный без достаточной причины. Потому что за этой сложностью не стоит красивая модель мира — стоит комитет из 200 человек с противоречивыми хотелками и груз обратной совместимости.
При этом C++ никуда не денется
Игры, операционные системы, базы данных, браузерные движки — всё это на C++. Потому что скорость реальная, контроль реальный, и замены пока нет. Rust пытается, но там своя боль.
Практический вывод такой: если ты пишешь на C++ и тебе не больно — ты ещё не писал достаточно. Если тебе больно — добро пожаловать в клуб. Здесь все злые, кофе крепкий и undefined behavior подстерегает за каждым углом.
📍 Подпишись на создателей: https://t.me/linuxexe