Comments 25
Всё так! Но есть ли такой язык, в котором всё хорошо и ничего не бесит и со статической типизацией? Подскажите такой язык, буду прогать на нём просто для души.
Может, этот?
Purebasic)))
Gleam: https://gleam.run/
Про него был подкаст недавно у "Подлодки"
C#
Может Rust? Говорят это язык для души)
Есть (мало кто знает что он изначально отечественный) язык Kotlin, и в нём действительно всё прекрасно)
Уже было.
Тут либо я совсем уж тупой, либо лыжи не едут.
Если вы угадали
[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 под капотом, что такое вообще nill, как работает распределение памяти, не думаю что все эти вопросы возникли
Почему Go до сих пор меня раздражает?