Как стать автором
Обновить

Комментарии 44

Сейчас тоже занимаюсь изучением, но я пришёл со стороны php/js/ts, плюс лет 25 назад совсем чуть-чуть знакомился с ассемблером и си, в школе изучал паскаль и немного ковырялся в делфи.

В Go для меня самое сложное — это то, что учебники не погружаются в каждую библиотеку, типа того же strconv, а приводят лишь по паре функций. Приходится брать следующий учебник, пропускать там процентов 80%, выискивая новое. Например, в первом моём учебнике не была упомянута cap(), не сказано, что у append() может быть третий параметр.

Конечно, я загляну в документацию и сам прочитаю, но это же учебник, пусть обучает меня полностью.

Мои ближайшие цели в плане практики: конвертер картинок в webp с уменьшением в 2 раза (это для 4k), замена php в моей личной считалке расходов, а потом попробую ради интереса что-то позапускать на телефоне или в wasm.

А вы от учебника по математике тоже требуете перечисления всех возможных чисел?

Учебник на то и учебник, чтобы не разъяснять все буквально, но как минимум давать достоверную информацию. В случае с append достаточно было бы привести сигнатуру, чтобы учащийся мог понять, что возможен и третий, не обязательный, параметр, а не замалчивать о его существовании. Тот, кто учится, уже сам должен обратиться к спецификации и изучить для чего этот параметр нужен

Что за третий параметр у append()? Это так называют вариативность второго агрумента(...Type)?

Прошу прощенья. Подразумевал make().

В учебнике математики когда умножение проходят множитель не пропускают

Ага, а при делении говорят, что нельзя на 0 делить, хотя в математике можно....

Видимо, смотря какого уровня учебник. Наверное, я слишком многого жду, если хочу, чтобы одна книга сделала меня специалистом. Я готов даже на книгу в 2000 страниц, но таких не пишут.

Сейчас читаю Михалис Цукалос - «Golang для профи», на 50-й странице, качественно идёт, плотно.

Конечно, я загляну в документацию и сам прочитаю, но это же учебник, пусть обучает меня полностью

Учебник вообще это помощник учителю, не ученику.

Учебник вообще это помощник учителю, не ученику

Вы не обидитесь, если я в голос посмеюсь над этой вашей фразой?

Лучше прочтя первый учебник сразу ставить проектные цели и гуглить необходимые для их реализации функции / библиотеки.

Цели есть, но я жду, когда, прочитав другие учебники, узнаю, как решать их правильно. А то, в других комментах уже ругались на счёт того, что я для себя реализовал JS-овый .forEach у silce. Мол, тут так не принято. Хотя учебники пишут, что функциональный стиль в Go допусти́м.

Конечно, я некоторый код пишу, что-то пробую, чтобы разобраться, но есть стремление делать правильно. А то, я в первые годы писал только для себя, как мне было удобно и привычно, сейчас даже смотреть страшно. Когда я школе решил попробовать C после Pascal, я себе задефайнил фигурные скобки на begin и end, потому что так было привычно.

 у append() может быть третий параметр.

https://pkg.go.dev/builtin#append

Ну может потому и не сказано, что его нет..?

Ооой, только сейчас понял свою ошибку. Не append, а make!

доку читайте, там все есть

Я это понимаю, но речь об учебниках. Я не хочу читать сразу всё. Хочется взять какую-то продуманную последовательную программу обучения и двигаться планомерно.

Тоже пописывал на питоне и тоже переполз в go.
Python довольно удобен для прототипирования, когда нужно быстро что-то попробовать - там минимальный бойлерплейт кода. Но делать что то серьезное - библиотеки и вот тут начинаются .... сложности. Поддержка решений тоже вызывает много вопросов.

Golang - это уже уже серьезнее. В нем самая фишка это каналы и горутины, но с ними уже тоже становится не так просто. И мыслить в парадигме параллельной обработки данных - нужно научится. В питоне можно в async поиграться, но это совсем не то что go-routine, а процессы питона - слишком тяжеловесны.
Но чем радует go - это быстрая сборка, которая просто вызывает ощущение, что ты пишешь на интерпретируемом языке.
А какие там приятные плюшки, когда идешь в контейнерезацию - это просто песня. CGO фтопку = 0 зависимостей все в одном бинарике, и сборка контейнера последней стадии FROM scratch с единственными бинариком (хотя моет еще сертификаты для поддержки HTTPS запросов может потребоваться).

Про Python полностью согласен. Для MVP наверное лучший вариант.

О, а вот в контейнеризацию ещё не погружался, посмотрю. Спасибо за направление!

Контейнер и Го , просто идеальная связка ... Бинарник мелкий , образ тоже

Плюсы у го конечно есть. Сборка в один файл, статическая типизация, большая скорость работы, горутины.

Но и минусы тоже есть. Меньше библиотек, чем на питоне. На питоне можно писать гораздо больше всего.

Мне понравился го, но я вернулся на питон.

Ну, логично, что с Numba код на питоне будет выполняться по скорости сопоставимо с Go - вы ж его скомпилировали в бинарник.
У Go есть киллер-фича - стандартная библиотека Go написана на Go :-) Это значит, что вы у каждой функции или метода стандартной библиотеки можете код посмотреть. Это очень полезно для изучения.

Вау! Это классно!

У Go есть киллер-фича - стандартная библиотека Go написана на Go

Стандартная библиотека сей написана на сях, стандартная библиотека жабы — на Java, стандартная библиотека Delphi в былые времена — на Delphi. Это «киллер-фича» — норма для компилируемых языков.

имхо, go надо сравнивать с rust.

Зачем? Абсолютно разные языки, в разных парадигмах для разных задач.

Да не сказал бы. В общем и целом да, Раст несколько более системный и низкоуровневый.

Но он гораздо ближе к Go, чем Питон.

А если брать экосистему вокруг Tokio там - так это вообще почти чистый Go (каналы, всякие WaitGroup и прочее). Разве что горутины заменить футурами :)

У го и раста абсолютно разные модели организации памяти, разные модели асинхроности, модели контрактов, диспетчеризации, разные модели метапрограммирования, разные алгоритмы реализации генераторов, разные системы типов(вернее сказать что в расте есть алгебраические типы в отличии от го), разный подход к системе пакетов и т.д. Между джавой и го гораздо больше общего, чем между го и растом.

экосистему вокруг Tokio там - так это вообще почти чистый Go 

Ничего общего у токио и го нет, стэкфулл и стэклесс корутины дают абсолютно разный подход к написанию кода - там где у раста 4х цветные функции(асинхроные+лайфтайм), у го проблемы цветных функций нет в принципе. А каналы есть и в C#, и в джаве и в С++ и где угодно, где вы можете сделать потокобезопастную очередь, это вещь абсолютно не привязанная к языку.

Ух как вас вштырило.

Я говорил больше про схожесть синтаксиса и некоторых механизмов, а не внутреннее устройство горутин и асинков. Основная идея, что общего с Растом у Го больше, чем с питоном.

А так то под капотом языки, конечно, совсем разные.

Я говорил больше про схожесть синтаксиса 

Какие из этих примеров кода по вашему больше похожи между собой?

 parts := strings.Split(input, ",")

 frequency := make(map[string]int)

 for _, word := range parts {
    frequency[word]++
 }
 let parts = input.split(',');

 let mut frequency = HashMap::new();

 for word in parts { 
    *frequency.entry(word).or_insert(0) += 1;
 }
parts = input.split(',')

frequency = {}

for word in parts:
    frequency[word] = frequency.get(word, 0) + 1

Я бы хотел почитать про четырех цветные функции в расте. Найдется ссылочка?

Про цветные функции полно статей, вот например https://habr.com/ru/articles/466337/

Но в расте помимо двух цветов(асинхронная и синхронная) еще и лайфтаймы есть - добавьте лайфтам в существующую функцию и вам скорее всего придется добавить лайфтайм и в функцию выше по стэку и дальше и дальше, точно так же как с асинком. В результате комбинаторно у нас получается 4 варианта функций с правилами вызова - 4 цвета.

Понравилось сравнение языков, где в тесте есть чтение из БД. Надо было удалить остальные шаги теста, сравнить Питон с С++ и написать: вывод - Питон такой же быстрый, как С++!

Да, соглашусь)

В следующей строке "функция ReadFile возвращает", поэтому чтобы не дублировать слово выбрал "передают".

В итоге решил довериться утверждению, что Python во многом похож на Go — на нем и остановился.

Ну вообще-то, Go - это такой C 2.0. Сишные уши там прямо отовсюду торчат.

Например, понимаете ли вы, что когда вы делаете subslicing of slice:

a := []int{1,2,3,4,5}
b := a[1:3]

то у этих двух слайсов общая память? Т.е., если вы напишете a[1] = 5, то b[0] тоже изменится.

А вот если вы к какому-нибудь из этих слайсов сделаете append, то его память может реалоцироваться (а може и не, в зависимости от наличия зарезервированного места в хвосте), и тогда они станут независимыми друг от друга.

Для сишника это совершенно очевидное, ожидаемое поведение. Для питониста - ну, я не уверен...

go build -o multiply.so -buildmode=c-shared multiply.go

Это - очень опасный подход. Фактически, вы создали на Go динамически загружаемую библиотеку (shared library), экспортирующую функции с сишным соглашением о вызовах (Go так умеет, да), и используете ее из Питона.

Проблема в том, что:

  1. Каждая гошная shared library содержит внутри себя собственную копию Go runtime

  2. Два экземпляра Go runtime не могут ужиться в одном процессе.

Т.е., пока у вас такой модуль один, все будет ОК. Как только их появится два (причем второй может появиться не от вас, а откуда-нибудь еще), всё сломается. Причем возможно даже не упадёт, а будет глючить самым неожиданным образом.

Не советую так делать, если вы не эксперт во внутренностях Go.

Для питониста это как раз будет очевидно, так как там любые сложные структуры (читай кроме чисел и подобного) копируются по указателю, а не по значению.

А достичь полной глубокой копии структуры данных без танцев сложно :) Нужно всякие модули deepcopy юзать.

Насколько часто в Go приходится писать boilerplate code?

до появления Generics - всегда. Изначально язык и позиционировался как замена скриптам, но как и в случае скриптов, на нем стали колбасить все, что можно наколбасить, и пришлось второпях эволюционировать.

Каких скриптов?

Изначально язык позиционировался для написания сетевых сервисов, в оной роли он и используется обычно.

Микросервисов, если точнее. И утилит, которые изначально писались скриптами, которые по мере развития становились громоздкими.

Мда…. Они придумали C#.
Доброе утро!

Ну в Go как бы есть вывод типов. Указывать в каждом месте не обязательно.

Про какие-то конторы написали, что они используют go, а то что Docker так-то тоже на go написан, не написали.

Непорядок...

Зарегистрируйтесь на Хабре, чтобы оставить комментарий