Вы имеете в виду повторить долбанутую логику слайса из Go? При большом желании конечно можно (прикрутить к вектору счётчик ссылок, следать структуру-обёртку с методом append повторяющим поведение из Go и т. п.) — только зачем нормальному программисту хотеть повторять долбанутую логику?
(карма мне кажется несправедливо слитой, поставил плюсик, несмотря на несогласие с мнением)
Напишите функцию с прототипом, как у Umask, которая для линуха вызтвает syscall.Umask, а для венды не делает ничего.
Как конкретно написать?
Закрытие файла - это действие с глобальными side-effect-ами.
Ну, если это критично (для большинства скорее всего нет, но ладно), то RAII всё ещё позволяет программисту контролировать, когда закрыть файл — просто не удаляя переменную, пока файл ещё должен быть открыт. И одновременно с этим позволяет программисту не забыть закрытие файла, автоматически закрывая его в конце области видимости или типа того. Как по мне — сплошные плюсы
Сделайте функцию (или тип), которые делают то, что вам надо, платформенно-зависимым способом с платформенно-независимым интерфейсом.
Давайте рассмотрим реальный пример из моей практики — Umask. В юниксах его надо вызвать, в винде его не существует и соответственно можно не делать ничего. Какой максимально компактный кроссплатформенный код для этого можно написать?
А если вы со своим RAII забудете мьютекс не отпустить, а захватить?
И снова — одним лишь C++ мир не ограничивается, есть как минимум один язык, в котором без захвата мьютекса вы в принципе не сможете получить доступ к данным
Я не хочу try-finally
А ваше описание в точности соответствует try-finally. Ну, с поправкой на отсутствие исключений
Это настолько же плохо, насколько плоха необходимость открывать файлы перед использованием.
Это хуже. Компилятор не может знать, какие файлы нужно открывать (поэтому это приходится прописывать вручную в коде) — зато он прекрасно знает, какие файлы нужно закрывать (те, которые уже открыты) и когда их нужно закрывать (в конце области видимости или в момент последнего использования). Заставлять программиста делать то, что может сделать компилятор — пустая трата времени и мозгов
если %s потратил время, полноценно прошел процесс обучения, поработал с книгой и прошел практику, то он просто не видит ничего неестественного в %s
Это можно сказать не только про Go и даже не только про программирование, а вообще про любую деятельность. Человек умеет привыкать к странному и отрицать странность странного
На всякий случай имейте в виду, что одним лишь C++ мир не ограничивается и есть как минимум один язык, в котором полностью идентичный код из второго примера будет выглядеть так:
let bar = foo()?;
foo2();
И не нужно гадать, что там с областью видимости переменной err и используется ли она где-то дальше в функции: нет переменной — не проблем 🙃
Обработка ошибок при этом по-прежнему присутствует.
можно управлять условной компиляцией с помощью имени файла
Всё ещё неудобно: какой-нибудь один платформозависимый вызов, который можно было бы запихнуть в один if, приходится размазывать как минимум на два файла с кучей копипаста
append сделан в Go очень по-Сишному. Любому человеку с опытом программирования на Си он очень понятен и интуитивен.
Что, разумеется, тоже показывает Go далеко не с лучшей стороны
Отличный механизм
Который очень удобно забывать прописывать? Лучше уж RAII
включить какую-то общую логику, которая отрабатывает на выходе
Вы хотите try-finally
Управление "внешними" ресурсами делается вручную.
И это плохо. Программист не должен тратить своё драгоценное время на делание того, что может сделать сам компилятор (опять же RAII)
Если у Вас смешиваются строки в разных кодировках в одном контексте, у вас какая-то архитектурная проблема
Да, архитектурная проблема в языке, который в принципе позволяет смешивать несмешиваемое
и надо с ней явно разобраться
Например, сменив язык на тот, который не позволяет смешивать несмешиваемое 🙃
создали UNIX, C, namespaces
Вы так говорите, как будто это примеры чего-то высококачественного)
Вы налили кучу прикольной воды, но так и не объяснили, нахрена переменная err является глобальной (в пределах функции) — даже в вашем собственном примере
если у нас есть два разных типа их не стоит сравнивать
Тогда нахрена Go позволяет это делать?
Также очевидно что пока в интерфейсе и type и data равны nil, то и весь интерфейс равен nil.
Абсолютно неочевидно: отсутствие значения и значение с двумя пустыми значениями внутри — сильно разные вещи
fyne и ebitengine
В контексте данного поста — оффтопик
если уже мы говорим о вопросах к системе тэгов, то её проблема гораздо больше чем то что build-тэги вешаются только на файлы а не на конкретные функции.
То есть тут вы с автором поста по сути согласны
пока length меньше capacity
И этот источник непредсказуемости — одна из многих причин, почему слайсы в Go ужасны
совершенно точно тратит больше ресурсов системы и ограничивает программиста в его экспрессии.
Ну а так как этот вывод был сделан из лжи — он, разумеется, тоже ложный
доказав безосновательность 4 из 8 претензий
0 из 8, как я показал выше, вы занимались лишь ложью и передёргиванием
буду ожидать от 5 тысяч рублей
Я не готов оплачивать ложь и передёргивание, так что, видимо, остановимся на следующем: автор — не тролль, Go — кривое непредсказуемое невыразительное говно, Rust — blazingly fast memory safe 🚀
Допустим, я мимокрокодил, который выбирает язык программирования по постам вроде этого, спасите меня от потенциально неверного решения, разоблачите тролля или типа того)
Проблема не в самом факте установки дополнительных пакетов, а в том, что django-cfg навязывает вполне конкретный их набор и запрещает его пользователям иметь своё собственное мнение относительно «minimal and essential»
Для проекта, который «делает конфигурирование для Django нормальным», единственная «minimal and essential» зависимость — это сам Django и больше ничего (при этом он упомянут как «peer dependency» и вообще не указан в зависимостях, лол). Ну может ещё pydantic, но тоже спорно (но сейчас не об этом). Все остальные постгресы, редисы и дрфы должны быть максимум в опциональных зависимостях для подтягивания аннотаций типов, а не навязываться
Ну а если это подаётся как «production-ready фреймворк для быстрого развертывания Django проектов», то его будут использовать только те, чьё мнение о «production-ready» на 100% совпадает с мнением автора — то есть скорее всего только сам автор
production-ready фреймворк для быстрого развертывания Django проектов
Кажется, пару комментариев назад это заявлялось всего лишь типобезопасным конфигурированием
Если нужен production-ready проект за 10 минут
Заточенный под ваши личные нужды и хотелки. Из чего следует, что использовать django-cfg не будет никто кроме вас (кстати к django-revolution это тоже относится)
Никто не называет их "bloatware"
Я называю и принципиально не использую (да и в общем-то сам Django тоже bloatware на самом деле, я бы его распилил на десяток пакетов поменьше)
Потому что оно на самом деле закрывает локальную сессию и создаёт новую RDP-сессию, перенося туда ранее открытые программы — в этом можно убедиться, пронаблюдав изменение значения столбца «Сеанс» на вкладке «Пользователи» в диспетчере задач
Просто пробросьте порт до RDP любым удобным способом, хоть через VPN (но скорее всего любой способ будет подразумевать наличие сервера или иного устройства с белым IP)
Если вы будете создавать новую сессию через обычный RDP (неважно с NAT или без), винда заблокирует экран автоматически, потому что по умолчанию не может быть двух сессий с одним пользователем
Aspia не для такого кейса, сессия должна существовать заранее
Но в следующей версии вроде как должен будет появиться проброс портов, так что должно быть возможно подключиться к RDP используя Aspia Relay в качестве прокси (но этот самый Aspia Relay придётся установить на каком-нибудь сервере с белым IP)
Вы имеете в виду повторить долбанутую логику слайса из Go? При большом желании конечно можно (прикрутить к вектору счётчик ссылок, следать структуру-обёртку с методом append повторяющим поведение из Go и т. п.) — только зачем нормальному программисту хотеть повторять долбанутую логику?
(карма мне кажется несправедливо слитой, поставил плюсик, несмотря на несогласие с мнением)
Как конкретно написать?
Ну, если это критично (для большинства скорее всего нет, но ладно), то RAII всё ещё позволяет программисту контролировать, когда закрыть файл — просто не удаляя переменную, пока файл ещё должен быть открыт. И одновременно с этим позволяет программисту не забыть закрытие файла, автоматически закрывая его в конце области видимости или типа того. Как по мне — сплошные плюсы
Давайте рассмотрим реальный пример из моей практики — Umask. В юниксах его надо вызвать, в винде его не существует и соответственно можно не делать ничего. Какой максимально компактный кроссплатформенный код для этого можно написать?
И снова — одним лишь C++ мир не ограничивается, есть как минимум один язык, в котором без захвата мьютекса вы в принципе не сможете получить доступ к данным
А ваше описание в точности соответствует try-finally. Ну, с поправкой на отсутствие исключений
Это хуже. Компилятор не может знать, какие файлы нужно открывать (поэтому это приходится прописывать вручную в коде) — зато он прекрасно знает, какие файлы нужно закрывать (те, которые уже открыты) и когда их нужно закрывать (в конце области видимости или в момент последнего использования). Заставлять программиста делать то, что может сделать компилятор — пустая трата времени и мозгов
Это можно сказать не только про Go и даже не только про программирование, а вообще про любую деятельность. Человек умеет привыкать к странному и отрицать странность странного
На всякий случай имейте в виду, что одним лишь C++ мир не ограничивается и есть как минимум один язык, в котором полностью идентичный код из второго примера будет выглядеть так:
И не нужно гадать, что там с областью видимости переменной
errи используется ли она где-то дальше в функции: нет переменной — не проблем 🙃Обработка ошибок при этом по-прежнему присутствует.
Всё ещё неудобно: какой-нибудь один платформозависимый вызов, который можно было бы запихнуть в один if, приходится размазывать как минимум на два файла с кучей копипаста
Что, разумеется, тоже показывает Go далеко не с лучшей стороны
Который очень удобно забывать прописывать? Лучше уж RAII
Вы хотите try-finally
И это плохо. Программист не должен тратить своё драгоценное время на делание того, что может сделать сам компилятор (опять же RAII)
Да, архитектурная проблема в языке, который в принципе позволяет смешивать несмешиваемое
Например, сменив язык на тот, который не позволяет смешивать несмешиваемое 🙃
Вы так говорите, как будто это примеры чего-то высококачественного)
Покажете пример на примере второго примера из статьи?
Ладно, на самом деле что-то похожее на объяснение всё-таки присутствует:
Только вот мне непонятно, почему такими микрооптимизациями должен заниматься программист, а не компилятор
Вы налили кучу прикольной воды, но так и не объяснили, нахрена переменная
errявляется глобальной (в пределах функции) — даже в вашем собственном примереТогда нахрена Go позволяет это делать?
Абсолютно неочевидно: отсутствие значения и значение с двумя пустыми значениями внутри — сильно разные вещи
В контексте данного поста — оффтопик
То есть тут вы с автором поста по сути согласны
И этот источник непредсказуемости — одна из многих причин, почему слайсы в Go ужасны
Это, разумеется, ложь:
Ну а так как этот вывод был сделан из лжи — он, разумеется, тоже ложный
0 из 8, как я показал выше, вы занимались лишь ложью и передёргиванием
Я не готов оплачивать ложь и передёргивание, так что, видимо, остановимся на следующем: автор — не тролль, Go — кривое непредсказуемое невыразительное говно, Rust — blazingly fast memory safe 🚀
Всё, в чём «чувак тотально не разобрался»?
Допустим, я мимокрокодил, который выбирает язык программирования по постам вроде этого, спасите меня от потенциально неверного решения, разоблачите тролля или типа того)
Помогите нам тотально разобраться?
А стоит ли это считать уязвимостью в таком случае?
У почтового сервера Stalwart возможность выполнения произвольного кода не только есть, но ещё и официально документирована 🤔
Проблема не в самом факте установки дополнительных пакетов, а в том, что django-cfg навязывает вполне конкретный их набор и запрещает его пользователям иметь своё собственное мнение относительно «minimal and essential»
Для проекта, который «делает конфигурирование для Django нормальным», единственная «minimal and essential» зависимость — это сам Django и больше ничего (при этом он упомянут как «peer dependency» и вообще не указан в зависимостях, лол). Ну может ещё pydantic, но тоже спорно (но сейчас не об этом). Все остальные постгресы, редисы и дрфы должны быть максимум в опциональных зависимостях для подтягивания аннотаций типов, а не навязываться
Ну а если это подаётся как «production-ready фреймворк для быстрого развертывания Django проектов», то его будут использовать только те, чьё мнение о «production-ready» на 100% совпадает с мнением автора — то есть скорее всего только сам автор
На моём проде MySQL и я не вижу существенных причин менять его на постгрес
memcached никто не отменял
На первый взгляд выглядит потенциально полезным, но зачем его навязывать как обязательную зависимость?
Ужасен и принципиально не делаю в своих проектах, я предпочитаю что-нибудь RPC-подобное, а индустрия вообще предпочитает GraphQL
Я так и не понял зачем мне DRF, ни в одном моём проекте его нет
Кажется, пару комментариев назад это заявлялось всего лишь типобезопасным конфигурированием
Заточенный под ваши личные нужды и хотелки. Из чего следует, что использовать django-cfg не будет никто кроме вас (кстати к django-revolution это тоже относится)
Я называю и принципиально не использую (да и в общем-то сам Django тоже bloatware на самом деле, я бы его распилил на десяток пакетов поменьше)
Точно так же, как это делают всякие тимвьюверы
Ну лол, с таким набором «minimal and essential» сразу до свидания
К сожалению для нас и к счастью для них, ядро под GPLv2
Потому что оно на самом деле закрывает локальную сессию и создаёт новую RDP-сессию, перенося туда ранее открытые программы — в этом можно убедиться, пронаблюдав изменение значения столбца «Сеанс» на вкладке «Пользователи» в диспетчере задач
Просто пробросьте порт до RDP любым удобным способом, хоть через VPN (но скорее всего любой способ будет подразумевать наличие сервера или иного устройства с белым IP)
Если вы будете создавать новую сессию через обычный RDP (неважно с NAT или без), винда заблокирует экран автоматически, потому что по умолчанию не может быть двух сессий с одним пользователем
Aspia не для такого кейса, сессия должна существовать заранее
Но в следующей версии вроде как должен будет появиться проброс портов, так что должно быть возможно подключиться к RDP используя Aspia Relay в качестве прокси (но этот самый Aspia Relay придётся установить на каком-нибудь сервере с белым IP)