А зачем вам отдельный пакет config? Очень часто это просто ненужно.
Опять же, как я делаю:
1. В текущем пакет есть структура `Config`.
2. Структура `Config` содержит конфигурацию все других пакетов.
3. Все обработка конфиг файла в пакете `main`.
Если брать ваш случай, то библиотека не должна работать с конфиг файлом (только структуры и их валидация, а не как вы примеры делали с .NET). Если уже есть такое, то при любой ситуации вернуть ошибку. Библиотеки никогда не должны принимать решения, только делегация. Вот и все.
Я разве написал, что мне что-то не нравится на работе? Работой полностью доволен. А вот чем недоволен — написал в первом предложении.
Как я понял, программирование на Go является частью вашей работы, если вам это не нравится (программировать на Go) — то вам не нравится ваша работа. Или вам нравится программировать на Go?
Дайте, пожалуйста, ссылки на посты которые мне необходимо почитать.
Очень часто забавляет сравнение Go c С, Rust, Python, Java, Pony, C#, Haskell, Erlang, Javascript, etc одновременно. Типа:
1. Go плохой, потому что в Rust <что-то> сделано лучше.
2. Go плохой, потому что в Python <что-то> сделано лучше.
3. Go плохой, потому что в Pony <что-то> сделано лучше.
4. Go плохой, потому что в Java <что-то> сделано лучше.
5. Go плохой, потому что в Haskell <что-то> сделано лучше.
…
С конфиг файла, но тут уже вы решите что делать с нечитаемым файлом или его отсутствием, а не полагаться на разработчика библиотеки (вернет ли он ошибку или панику?).
Кстати, вот тут ваше мнение расходиться со второй репликой (про прокидование на верх).
Второе, чем больше библиотек, тем больше конфиг файлов? А потом еще разный формат — один хочет yaml, второй toml, третий ini.
> Я вообще не припомню уязвимости в .net, которые нужно было бы закрывать.
Идеальный .net.
Вот java мы недавно апдейтили. У нас просто принято делать апдейты безопасности (даже не критические, критические мы сразу же обновляем) периодически.
Библиотека не должна принимать как параметр файл с конфигурацией.
Когда я пишу какой-нибудь сервис, который имеет конфигурационный файл, я делаю следующее:
1. Создаю дефолтный конфиг.
2. Если конфиг файл не был определен — использую дефолтный конфиг.
3. Если конфиг файл определен — читаю конфиг файл и переписываю дефолтный конфиг (тот, что был создан сначала).
4. Если, когда конфиг файл определен, но что-то идет не так — файла нету, он не читаемый или конфиг не валидный — останавливаю сервис. Тогда упадет только один инстанс, а все другие будут раниться с правильной конфигурацией (пропагация деплоймента остановится).
Зависит от того, насколько критичен конфиг. Eсли не можете загрузить конфиг, можно использовать дефолтный конфиг и WARN в лог или stderr вывести. Если конфиг критичен — то остановить старт.
Обновлять рантайм — м? В дотнете рантайм не обновляется, если проект сделан под core 2.0, то на нем и запускается всю жизнь, пока лид не решит сделать судьбоносное решение и обновить версию. Что будет сделано путём исправление одного dockerfile. Не вижу, чем должна быть проблема.
То есть security upgrades не принято делать в .NET?
Вот не уверен, что компилятор Go быстрее csc.
Можете протестировать. Но я там еще написал, кроме компилятора.
тем что не надо обновлять/патчить тот же JVM на всех серверах, где это ранится. А если докер — то тут надо следить за тем, что используют программисты и обновлять какой-нибудь базовый image.
Деплоймент будет гораздо быстрее — компилятор быстрее, плюс не нужно тянуть кучи зависимостей типа docker image с OS, сам docker image будет максимально маленький.
И все в этом духе.
Как часто вы случайно удаляли последний элемент в списке?
У меня никогда такого не случалось.
Ошибка — это то, что вам нужно исправить. Вот с удалением (или добавлением) запятой после редактирования кода я сталкивался — json был невалидный.
2. Ну когда вам нужно реализовать интерфейс, что бы использовать его в библиотеке, то все ок, да. Часто люди упрощают и передают один и тот же обьект, который реализует несколько интерфейсов.
А
loadConfig
уже парсит конфиг файл и валидирует его в соответствии со структурой.Опять же, как я делаю:
1. В текущем пакет есть структура `Config`.
2. Структура `Config` содержит конфигурацию все других пакетов.
3. Все обработка конфиг файла в пакете `main`.
Если брать ваш случай, то библиотека не должна работать с конфиг файлом (только структуры и их валидация, а не как вы примеры делали с .NET). Если уже есть такое, то при любой ситуации вернуть ошибку. Библиотеки никогда не должны принимать решения, только делегация. Вот и все.
Как я понял, программирование на Go является частью вашей работы, если вам это не нравится (программировать на Go) — то вам не нравится ваша работа. Или вам нравится программировать на Go?
Комменты вот тут
habr.com/post/422049
habr.com/post/421411
Я вот считаю так — если вам что-то не нравится на работе, может следует что-то поменять?
1. Go плохой, потому что в Rust <что-то> сделано лучше.
2. Go плохой, потому что в Python <что-то> сделано лучше.
3. Go плохой, потому что в Pony <что-то> сделано лучше.
4. Go плохой, потому что в Java <что-то> сделано лучше.
5. Go плохой, потому что в Haskell <что-то> сделано лучше.
…
Я могу точно такой же код на Go написать.
гугл показывает персональные результаты, я гуглом не пользуюсь, вот сейчас попробовал —
rust lang undef
дополняется все с растом,undefined
— C++.> А lang кроме го ни один язык не называют, ни тот же С, ни какие-то еще.
Зачем вы тогда rust lang написали?
С конфиг файла, но тут уже вы решите что делать с нечитаемым файлом или его отсутствием, а не полагаться на разработчика библиотеки (вернет ли он ошибку или панику?).
Кстати, вот тут ваше мнение расходиться со второй репликой (про прокидование на верх).
Второе, чем больше библиотек, тем больше конфиг файлов? А потом еще разный формат — один хочет yaml, второй toml, третий ini.
Ах интерпрайз.
IMO, библиотека должна работать с конфигурационным объектом, а не файлом.
Я наверное не понял контекст, ну не падайте раз так, WARNING в лог тогда. Для юзер приложений это может и лучше, для backend — лучше падать.
Идеальный .net.
Вот java мы недавно апдейтили. У нас просто принято делать апдейты безопасности (даже не критические, критические мы сразу же обновляем) периодически.
Когда я пишу какой-нибудь сервис, который имеет конфигурационный файл, я делаю следующее:
1. Создаю дефолтный конфиг.
2. Если конфиг файл не был определен — использую дефолтный конфиг.
3. Если конфиг файл определен — читаю конфиг файл и переписываю дефолтный конфиг (тот, что был создан сначала).
4. Если, когда конфиг файл определен, но что-то идет не так — файла нету, он не читаемый или конфиг не валидный — останавливаю сервис. Тогда упадет только один инстанс, а все другие будут раниться с правильной конфигурацией (пропагация деплоймента остановится).
только
То есть security upgrades не принято делать в .NET?
Можете протестировать. Но я там еще написал, кроме компилятора.
Деплоймент будет гораздо быстрее — компилятор быстрее, плюс не нужно тянуть кучи зависимостей типа docker image с OS, сам docker image будет максимально маленький.
И все в этом духе.
Получается 100% защита от случайного удаления любой строки.
Как тебе такое, 5oclock?
У меня никогда такого не случалось.
Ошибка — это то, что вам нужно исправить. Вот с удалением (или добавлением) запятой после редактирования кода я сталкивался — json был невалидный.
в данном случае Go упрощает деплоймент и поддержку приложений.