Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 21
Всё так! Но есть ли такой язык, в котором всё хорошо и ничего не бесит и со статической типизацией? Подскажите такой язык, буду прогать на нём просто для души.
Уже было.
Тут либо я совсем уж тупой, либо лыжи не едут.
Если вы угадали
[hello world !], то вы знаете больше, чем кто-либо должен знать о причудах дурацкого языка программирования.
Мы создали слайс 0:0 по массиву и отправили его в функцию. В функции мы решили при помощи append растянуть массив. Append по слайсу, Карл! Потом удивляемся а почему не отработало.
Go не удовлетворился одной ошибкой на миллиард долларов, поэтому они решили иметь два варианта
NULL.
nil как отсутствие ссылки и nil как отсутствие значения, сначала люди ноют, что документация в каком-либо продукте плохая, а затем сами её не читают.
Постойте, что? Почему
errиспользуется повторно дляfoo2()?
Берем и именуем внешние и внутренние поля скоупов по разному и получаем однозначное предсказуемое поведение.
Потом удивляемся а почему не отработало.
Оно сработало. Просто неожиданно. :)
Тут либо я совсем уж тупой, либо лыжи не едут.
Лыжи не едут. Срезы в go устроены так: структура (ссылка на буфер, размер, вместимость). Пока кол-во вставляемых элементов не превышает вместимость среза - они просто дописываются в буфер и увеличивается размер. Если превышено - увеличивается вместимость, выделяется новый буфер, память копируется в него, переключаемся на новый буфер. И далее как выше. Вместимость кратна степени двойки.
Первый случай:
a - срез с размером 3, вместимостью 4.
Передаём в функцию срез с него с тем же буфером, размером 1, вместимостью 4.
Добавляем один элемент. Это не превышает вместимость, буфер остаётся прежним, NIGHTMARE пишется в буфер, переписывая world.
Второй случай.
Добавляем 4 элемента, это превышает вместимость - размер, по этому в функции буфер среза копируется, отвязывая его от буфера исходного среза и добавляет в него элементы. Но буфер исходного среза не затронут.
По этому я и написал в первой статье тот каммент.
С самого начала же проговаривается, что slice это структура данных только указывающая на массив. Очевидно, что и при копировании скопируется только slice, а не массив на который он указывает.
Насчет defer, кажется можно сделать так
f, err := openFile()
if err != nil {
return nil, err
}
defer function() {
if cerr := f.Close(); cerr != nil && err == nill {
err = cerr
}
}()
if err := f.Write(something()); err != nil {
return nil, err
}
– Бэрримор, кто снова воет на болотах!?
– Гоферы, сэр....
Дык это не гоферы воют, а джависты, которые пришли в го с какими-то своими представлениями и не читали документацию и best practice. Плюс набрали всяких синтетических примеров типа как на собеседованиях задают. У нормальных гоферов все в порядке, потому что код как в статье никто в реале не пишет.
P.S. странно, что автор не докопался до контекстов и горутин. Вот где пострадать можно! А то давайте в 100500 раз поноем про область видимости ошибки в го - явно, что автор сам на языке не писал нормально :-)
Код был бы намного легче читать, если бы область видимости
errбыла меньше. Но это синтаксически невозможно в Go.
Почему же синтаксически невозможно? Можно обработку по блокам раскидать:
var bar Type1
{
var err error
bar, err = foo()
if err != nil {
return err
}
}
{
if err := foo2(); err != nil {
return err
}
}
Человек не выучил и не разобрался в Golang. И начинает писать на нем как привык в XYZ. Вот и результат - поток чуши. Нет бы покритиковать GC к примеру (есть что критиковать).
Об том и речь, что у тех, кто написал на языке больше одного проекта, совершенно другие боли.
Это автор явно не трогал горутины, каналы и контекст. Вот там вот дофига не очевидного.
Тут есть еще такая ловушка, как результат позиционирования "Golang простой и ничего там такого нет".
И многие потому решают что документацию читать - не надо. понимать как работает Runtime и компоненты - не надо. Сдедить за релизами и изменением поведения - не надо.
а ведь это нет так - нюансов много и разбираться надо без дураков
На самом деле все ещё интереснее.
Го простой. Но только по синтаксису.
В го можно писать без многопоточности, каналов, синхронизаций и прочей магии просто тупо в лоб как на PHP, но тогда в чем смысл его брать?
Асинхронности и её синхронизация это тема в принципе непростая и здравый смысл здесь часто работает не очевидно :-)
И это я ещё про оптимизации по памяти ничего не писал.
Было же уже тут не так давно https://habr.com/ru/companies/ruvds/articles/941106/
Человек не удосужился выучить Golang и требует, чтобы в нем было то, к чему он привык в условной Java. Особенно "умилили" претензии к defer который назван "глупым"
Всё правильно написано.
Не надо привыкать к глюкам, надо чтоб глюков не было.
Но это всё равно мелкие недостатки, не страшно
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему Go до сих пор меня раздражает?