Go по-прежнему полон проблем

что можно сделать полезного с umask-ом

Создать Unix-сокет безопасным образом (без гонки на Chmod) в момент запуска программы, ещё до момента появления других потоков/горутин

Go по-прежнему полон проблем

Лишние скакания по файлам я считаю снижением читаемости (но впадать в другую крайность и пихать вообще всё в один файл, конечно, тоже не надо)

Go по-прежнему полон проблем

Если стоит цель не забыть закрытие файла, то лично я готов потерпеть 1% присваиваний nil в нетривиальных случаях ради того, чтобы в остальных 99% случаев меня не заставляли помнить про defer и RAII снимал с меня лишнюю нагрузку на мозг

Go по-прежнему полон проблем

Если предполагается, что файл нужно будет потом закрыть в какой-то определённый момент, то его неизбежно придётся положить в какую-то внешнюю переменную независимо от языка программирования, там он и переживёт зону видимости (а если пофиг, то можно явно пропустить деструктор вызовом std::mem::forget и создать утечку файла до конца работы программы — впрочем, мы тут вроде наоборот пытаемся с этим бороться)

Go по-прежнему полон проблем

Но я не уверен, что лучше

Лучше иметь возможность выбора по ситуации)

new/delete

А тут опять одним лишь C++ мир не ограничивается, в ранее упоминавшемся языке объект файла создаётся через вполне естественные File::open и File::create (ну а close таки отсутствует потому что RAII)

Go по-прежнему полон проблем

umask_linux.go

umask_windows.go

Ну то есть ровно то, что я ранее и написал:

Всё ещё неудобно: какой-нибудь один платформозависимый вызов, который можно было бы запихнуть в один if, приходится размазывать как минимум на два файла с кучей копипаста

Повтор сигнатуры функции, впрочем, слабо тянет на «кучу» копипаста — но это всё ещё копипаст и всё ещё два файла вместо одной строчки

А Вам не кажется, что управлять временем жизни файла как-то естественнее в терминах операций с файлом, чем в терминах создания/удаления переменной?

В реальном мире, в котором программисты любого уровня гениальности постоянно совершают ошибки — не кажется; RAII выглядит разумным компромиссом между «естественностью» и надёжностью/безопасностью

Go по-прежнему полон проблем

не меняя алгоритм

Вы имеете в виду повторить долбанутую логику слайса из Go? При большом желании конечно можно (прикрутить к вектору счётчик ссылок, следать структуру-обёртку с методом append повторяющим поведение из Go и т. п.) — только зачем нормальному программисту хотеть повторять долбанутую логику?

(карма мне кажется несправедливо слитой, поставил плюсик, несмотря на несогласие с мнением)

Go по-прежнему полон проблем

Напишите функцию с прототипом, как у Umask, которая для линуха вызтвает syscall.Umask, а для венды не делает ничего.

Как конкретно написать?

Закрытие файла - это действие с глобальными side-effect-ами.

Ну, если это критично (для большинства скорее всего нет, но ладно), то RAII всё ещё позволяет программисту контролировать, когда закрыть файл — просто не удаляя переменную, пока файл ещё должен быть открыт. И одновременно с этим позволяет программисту не забыть закрытие файла, автоматически закрывая его в конце области видимости или типа того. Как по мне — сплошные плюсы

Go по-прежнему полон проблем

Сделайте функцию (или тип), которые делают то, что вам надо, платформенно-зависимым способом с платформенно-независимым интерфейсом.

Давайте рассмотрим реальный пример из моей практики — Umask. В юниксах его надо вызвать, в винде его не существует и соответственно можно не делать ничего. Какой максимально компактный кроссплатформенный код для этого можно написать?

А если вы со своим RAII забудете мьютекс не отпустить, а захватить?

И снова — одним лишь C++ мир не ограничивается, есть как минимум один язык, в котором без захвата мьютекса вы в принципе не сможете получить доступ к данным

Я не хочу try-finally

А ваше описание в точности соответствует try-finally. Ну, с поправкой на отсутствие исключений

Это настолько же плохо, насколько плоха необходимость открывать файлы перед использованием.

Это хуже. Компилятор не может знать, какие файлы нужно открывать (поэтому это приходится прописывать вручную в коде) — зато он прекрасно знает, какие файлы нужно закрывать (те, которые уже открыты) и когда их нужно закрывать (в конце области видимости или в момент последнего использования). Заставлять программиста делать то, что может сделать компилятор — пустая трата времени и мозгов

Go по-прежнему полон проблем

если %s потратил время, полноценно прошел процесс обучения, поработал с книгой и прошел практику, то он просто не видит ничего неестественного в %s

Это можно сказать не только про Go и даже не только про программирование, а вообще про любую деятельность. Человек умеет привыкать к странному и отрицать странность странного

Go по-прежнему полон проблем

В C++ будет абсолютно то же самое.

Ровно так же, как в C/C++

На всякий случай имейте в виду, что одним лишь C++ мир не ограничивается и есть как минимум один язык, в котором полностью идентичный код из второго примера будет выглядеть так:

let bar = foo()?;
foo2();

И не нужно гадать, что там с областью видимости переменной err и используется ли она где-то дальше в функции: нет переменной — не проблем 🙃

Обработка ошибок при этом по-прежнему присутствует.

можно управлять условной компиляцией с помощью имени файла

Всё ещё неудобно: какой-нибудь один платформозависимый вызов, который можно было бы запихнуть в один if, приходится размазывать как минимум на два файла с кучей копипаста

append сделан в Go очень по-Сишному. Любому человеку с опытом программирования на Си он очень понятен и интуитивен.

Что, разумеется, тоже показывает Go далеко не с лучшей стороны

Отличный механизм

Который очень удобно забывать прописывать? Лучше уж RAII

включить какую-то общую логику, которая отрабатывает на выходе

Вы хотите try-finally

Управление "внешними" ресурсами делается вручную.

И это плохо. Программист не должен тратить своё драгоценное время на делание того, что может сделать сам компилятор (опять же RAII)

Если у Вас смешиваются строки в разных кодировках в одном контексте, у вас какая-то архитектурная проблема

Да, архитектурная проблема в языке, который в принципе позволяет смешивать несмешиваемое

и надо с ней явно разобраться

Например, сменив язык на тот, который не позволяет смешивать несмешиваемое 🙃

создали UNIX, C, namespaces

Вы так говорите, как будто это примеры чего-то высококачественного)

Go по-прежнему полон проблем

Это как, синтаксис Go не позволяет сократить область видимости переменной? Это наглая ложь.

Покажете пример на примере второго примера из статьи?

Go по-прежнему полон проблем

но так и не объяснили, нахрена переменная err является глобальной (в пределах функции)

Ладно, на самом деле что-то похожее на объяснение всё-таки присутствует:

переиспользование переменных [...] служит для [...] экономии памяти

Только вот мне непонятно, почему такими микрооптимизациями должен заниматься программист, а не компилятор

Go по-прежнему полон проблем

Первый пример

Вы налили кучу прикольной воды, но так и не объяснили, нахрена переменная err является глобальной (в пределах функции) — даже в вашем собственном примере

если у нас есть два разных типа их не стоит сравнивать

Тогда нахрена Go позволяет это делать?

Также очевидно что пока в интерфейсе и type и data равны nil, то и весь интерфейс равен nil.

Абсолютно неочевидно: отсутствие значения и значение с двумя пустыми значениями внутри — сильно разные вещи

fyne и ebitengine

В контексте данного поста — оффтопик

если уже мы говорим о вопросах к системе тэгов, то её проблема гораздо больше чем то что build-тэги вешаются только на файлы а не на конкретные функции.

То есть тут вы с автором поста по сути согласны

пока length меньше capacity

И этот источник непредсказуемости — одна из многих причин, почему слайсы в Go ужасны

Раст нас заставляет сделать копию вектора

Это, разумеется, ложь:

fn foo(a: &mut Vec<&str>) {
    a.push("NIGHTMARE");
}
fn main() {
    let mut a = vec!["Hello", "world", "!"];
    foo(&mut a);
    println!("{:?}", a);
}

совершенно точно тратит больше ресурсов системы и ограничивает программиста в его экспрессии.

Ну а так как этот вывод был сделан из лжи — он, разумеется, тоже ложный

доказав безосновательность 4 из 8 претензий

0 из 8, как я показал выше, вы занимались лишь ложью и передёргиванием

буду ожидать от 5 тысяч рублей

Я не готов оплачивать ложь и передёргивание, так что, видимо, остановимся на следующем: автор — не тролль, Go — кривое непредсказуемое невыразительное говно, Rust — blazingly fast memory safe 🚀

Go по-прежнему полон проблем

Всё, в чём «чувак тотально не разобрался»?

Допустим, я мимокрокодил, который выбирает язык программирования по постам вроде этого, спасите меня от потенциально неверного решения, разоблачите тролля или типа того)

Go по-прежнему полон проблем

Помогите нам тотально разобраться?

Как мы нашли уязвимость в Mailcow, или немного о безопасности в open source

понадобится доступ к веб-панели администратора приложения

А стоит ли это считать уязвимостью в таком случае?

У почтового сервера Stalwart возможность выполнения произвольного кода не только есть, но ещё и официально документирована 🤔

Окей, Джанго, у меня к тебе несколько вопросов

Проблема не в самом факте установки дополнительных пакетов, а в том, что django-cfg навязывает вполне конкретный их набор и запрещает его пользователям иметь своё собственное мнение относительно «minimal and essential»

Для проекта, который «делает конфигурирование для Django нормальным», единственная «minimal and essential» зависимость — это сам Django и больше ничего (при этом он упомянут как «peer dependency» и вообще не указан в зависимостях, лол). Ну может ещё pydantic, но тоже спорно (но сейчас не об этом). Все остальные постгресы, редисы и дрфы должны быть максимум в опциональных зависимостях для подтягивания аннотаций типов, а не навязываться

Ну а если это подаётся как «production-ready фреймворк для быстрого развертывания Django проектов», то его будут использовать только те, чьё мнение о «production-ready» на 100% совпадает с мнением автора — то есть скорее всего только сам автор

Окей, Джанго, у меня к тебе несколько вопросов

psycopg2

На моём проде MySQL и я не вижу существенных причин менять его на постгрес

redis

memcached никто не отменял

django-filter

На первый взгляд выглядит потенциально полезным, но зачем его навязывать как обязательную зависимость?

REST API

Ужасен и принципиально не делаю в своих проектах, я предпочитаю что-нибудь RPC-подобное, а индустрия вообще предпочитает GraphQL

без DRF

Я так и не понял зачем мне DRF, ни в одном моём проекте его нет

Окей, Джанго, у меня к тебе несколько вопросов

production-ready фреймворк для быстрого развертывания Django проектов

Кажется, пару комментариев назад это заявлялось всего лишь типобезопасным конфигурированием

Если нужен production-ready проект за 10 минут

Заточенный под ваши личные нужды и хотелки. Из чего следует, что использовать django-cfg не будет никто кроме вас (кстати к django-revolution это тоже относится)

Никто не называет их "bloatware"

Я называю и принципиально не использую (да и в общем-то сам Django тоже bloatware на самом деле, я бы его распилил на десяток пакетов поменьше)