Советую ознакомиться с документацией по select, особенно на пункт 2, дабы не наткнуться в какой то момент на потерянные данные. Для решения проблемы «приоритезации» опций внутри селекта, насколько я знаю, пока нет общего решения, можно погуглить golang select priority, решения есть, разной степени странности.
5. не даст скомпилировать, про себя могу сказать, что делаю такие ошибки крайней редко.
7. частая проблема, пару раз очень долго разбирался с кодом, спасает metalinter, прикрутил в atom, теперь вижу все такие блоки, без подсказок может стать адом.
6. Это особенность синтаксиса, грубо говоря, слева от := могут быть только имена переменных.
8. nil это константа без типа, язык строготипизированный, чтоб не творить магии, «дефолтного» типа нет.
12. Лучше почитать в офф доке, слайс, это ссылка на массив + пара доп полей, для обеспечения динамического поведения.
13. Я думаю посыл в том, чтобы ходить по индексу, и изменять значение.
22. Это и правда ужасно, когда первый раз наткнулся на exit(1), в Fatalf, я не ожидал такого поведения, с тех пор пользуюсь другими библиотеками.
в atom/vim-go это решается использованием утилиты goimports, которая сама проставляет или удаляет импорты. Пока не используется кастомная сборка (gb и прочие), работает очень сносно.
Вы правы, в процессе перевода тоже хотелось отметить недопонимание автора механизма append (если не хватает capacity в текущем слайсе, по сути создается новый), но, поскольку это перевод, оставил как есть.
1. Непонятно, почему утилитарные функции должны засорять общий namespace? Этот php-style, простыни функций, и это плохо.
2. В каком кейсе вам нужно получить «получить данные запроса полный состав которых и тип которых вам заранее неизвестен»? Когда вам нужен велосипед, вы используете велосипед. Еще раз, то можно сделать, и да, после динамических языков, это будет очень неудобно, и это нормально.
4. Это привычки из нетипизированных языков.
5. Опять же вкусовщина, мне кажется, что проще иметь отдельный файл, который содержит все «платформозависимые» фичи. + если уж хочется что то такеого есть runtime
вот поэтому я называю автора языка школьником не имеющим достаточного опыта, для того, чтобы понять, где это понадобится.
Я попросил привести кейс, если вы используете инкапсуляцию, у вас не будет проблем
Почему это должна быть отдельная функция?
if _, err := os.Stat("/path/to/whatever"); os.IsNotExist(err), одно условие, понятное вполне
2.
По поводу «select * from table»
Язык строготипизированный, поэтому результат потребуется описать, через хаки можно разобрать результат как map[string]sql.RawBytes, это не очень удобно, но, возможно, решит вашу проблему.
3.
По областям видимости
Можно подробнее описать проблесный кейс? Для каких то кейсов подойдет gorename, для других придется или ручками изменять, или надеяться на ide, но где это не понадобится?
4.
func get() (int64, err) {}
i int
err error
i, err = get() // Ошибка, которую нельзя исправить в этой строке
Тут да, Роб Пайк против сложных авто приведений, придется использовать дополнительную переменную.
7. частая проблема, пару раз очень долго разбирался с кодом, спасает metalinter, прикрутил в atom, теперь вижу все такие блоки, без подсказок может стать адом.
6. Это особенность синтаксиса, грубо говоря, слева от := могут быть только имена переменных.
8. nil это константа без типа, язык строготипизированный, чтоб не творить магии, «дефолтного» типа нет.
12. Лучше почитать в офф доке, слайс, это ссылка на массив + пара доп полей, для обеспечения динамического поведения.
13. Я думаю посыл в том, чтобы ходить по индексу, и изменять значение.
22. Это и правда ужасно, когда первый раз наткнулся на exit(1), в Fatalf, я не ожидал такого поведения, с тех пор пользуюсь другими библиотеками.
2. В каком кейсе вам нужно получить «получить данные запроса полный состав которых и тип которых вам заранее неизвестен»? Когда вам нужен велосипед, вы используете велосипед. Еще раз, то можно сделать, и да, после динамических языков, это будет очень неудобно, и это нормально.
4. Это привычки из нетипизированных языков.
5. Опять же вкусовщина, мне кажется, что проще иметь отдельный файл, который содержит все «платформозависимые» фичи. + если уж хочется что то такеого есть runtime
Я попросил привести кейс, если вы используете инкапсуляцию, у вас не будет проблем
1.
Почему это должна быть отдельная функция?
if _, err := os.Stat("/path/to/whatever"); os.IsNotExist(err), одно условие, понятное вполне
2.
Язык строготипизированный, поэтому результат потребуется описать, через хаки можно разобрать результат как map[string]sql.RawBytes, это не очень удобно, но, возможно, решит вашу проблему.
3.
Можно подробнее описать проблесный кейс? Для каких то кейсов подойдет gorename, для других придется или ручками изменять, или надеяться на ide, но где это не понадобится?
4.
Тут да, Роб Пайк против сложных авто приведений, придется использовать дополнительную переменную.
5.
Вы смотрели на ключи сборки?
Ну и вкусовщина
для платформозависимого кода, очень неплохо