Комментарии 44
Сейчас тоже занимаюсь изучением, но я пришёл со стороны php/js/ts, плюс лет 25 назад совсем чуть-чуть знакомился с ассемблером и си, в школе изучал паскаль и немного ковырялся в делфи.
В Go для меня самое сложное — это то, что учебники не погружаются в каждую библиотеку, типа того же strconv, а приводят лишь по паре функций. Приходится брать следующий учебник, пропускать там процентов 80%, выискивая новое. Например, в первом моём учебнике не была упомянута cap(), не сказано, что у append() может быть третий параметр.
Конечно, я загляну в документацию и сам прочитаю, но это же учебник, пусть обучает меня полностью.
Мои ближайшие цели в плане практики: конвертер картинок в webp с уменьшением в 2 раза (это для 4k), замена php в моей личной считалке расходов, а потом попробую ради интереса что-то позапускать на телефоне или в wasm.
А вы от учебника по математике тоже требуете перечисления всех возможных чисел?
Учебник на то и учебник, чтобы не разъяснять все буквально, но как минимум давать достоверную информацию. В случае с append достаточно было бы привести сигнатуру, чтобы учащийся мог понять, что возможен и третий, не обязательный, параметр, а не замалчивать о его существовании. Тот, кто учится, уже сам должен обратиться к спецификации и изучить для чего этот параметр нужен
В учебнике математики когда умножение проходят множитель не пропускают
Видимо, смотря какого уровня учебник. Наверное, я слишком многого жду, если хочу, чтобы одна книга сделала меня специалистом. Я готов даже на книгу в 2000 страниц, но таких не пишут.
Сейчас читаю Михалис Цукалос - «Golang для профи», на 50-й странице, качественно идёт, плотно.
Конечно, я загляну в документацию и сам прочитаю, но это же учебник, пусть обучает меня полностью
Учебник вообще это помощник учителю, не ученику.
Лучше прочтя первый учебник сразу ставить проектные цели и гуглить необходимые для их реализации функции / библиотеки.
Цели есть, но я жду, когда, прочитав другие учебники, узнаю, как решать их правильно. А то, в других комментах уже ругались на счёт того, что я для себя реализовал JS-овый .forEach у silce. Мол, тут так не принято. Хотя учебники пишут, что функциональный стиль в Go допусти́м.
Конечно, я некоторый код пишу, что-то пробую, чтобы разобраться, но есть стремление делать правильно. А то, я в первые годы писал только для себя, как мне было удобно и привычно, сейчас даже смотреть страшно. Когда я школе решил попробовать C после Pascal, я себе задефайнил фигурные скобки на begin и end, потому что так было привычно.
у append() может быть третий параметр.
https://pkg.go.dev/builtin#append
Ну может потому и не сказано, что его нет..?
доку читайте, там все есть
Тоже пописывал на питоне и тоже переполз в 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 цвета.
Понравилось сравнение языков, где в тесте есть чтение из БД. Надо было удалить остальные шаги теста, сравнить Питон с С++ и написать: вывод - Питон такой же быстрый, как С++!
часто функции передают дополнительный параметр
как будто бы хочется увидеть слово возвращают
В итоге решил довериться утверждению, что 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 так умеет, да), и используете ее из Питона.
Проблема в том, что:
Каждая гошная shared library содержит внутри себя собственную копию Go runtime
Два экземпляра Go runtime не могут ужиться в одном процессе.
Т.е., пока у вас такой модуль один, все будет ОК. Как только их появится два (причем второй может появиться не от вас, а откуда-нибудь еще), всё сломается. Причем возможно даже не упадёт, а будет глючить самым неожиданным образом.
Не советую так делать, если вы не эксперт во внутренностях Go.
Насколько часто в Go приходится писать boilerplate code?
до появления Generics - всегда. Изначально язык и позиционировался как замена скриптам, но как и в случае скриптов, на нем стали колбасить все, что можно наколбасить, и пришлось второпях эволюционировать.
Мда…. Они придумали C#.
Доброе утро!
Ну в Go как бы есть вывод типов. Указывать в каждом месте не обязательно.
Про какие-то конторы написали, что они используют go, а то что Docker так-то тоже на go написан, не написали.
Непорядок...
Как я начал учить Go и правда ли он похож на Python. Мой личный опыт