Комментарии 48
Сейчас тоже занимаюсь изучением, но я пришёл со стороны 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 наверное лучший вариант.
О, а вот в контейнеризацию ещё не погружался, посмотрю. Спасибо за направление!
Плюсы у го конечно есть. Сборка в один файл, статическая типизация, большая скорость работы, горутины.
Но и минусы тоже есть. Меньше библиотек, чем на питоне. На питоне можно писать гораздо больше всего.
Мне понравился го, но я вернулся на питон.
А для чего в Go не найти библиотеку?
GUI либы разве что - так себе... но в плане бекенда там всего в достатке и есть из чего выбрать обычно.
В плане бакенда неплохо, то тоже меньше чем в питоне. На питоне можно и десктоп приложение написать и даже для мобил (хотя возможно это и того не стоит). Ну просто больше всего - ML, анализ данных, комьютерное зрение. Питон разноплановый язык на нем много чего можно писать, а на гошке только бэк. Вот написали например бэк на го, а потом понадобилось какую-то модель заюзать. И чего теперь? Отдельный бэк на питоне делать? Лучше уж сразу тогда на питоне.
ML и в Go не так и сложно подключить. И питон как прослойка для этого не сильно нужен.
Не я не спорю в питоне больше всякого. Но это и минус - понаписано столько что муки выбора в некоторых вопросах зашкаливают.
А что касается поддержки версий - это тоже в питоне немного через задний проход сделано в отличии от Go.
Ну, логично, что с Numba код на питоне будет выполняться по скорости сопоставимо с Go - вы ж его скомпилировали в бинарник.
У Go есть киллер-фича - стандартная библиотека Go написана на Go :-) Это значит, что вы у каждой функции или метода стандартной библиотеки можете код посмотреть. Это очень полезно для изучения.
имхо, 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?
Мда…. Они придумали C#.
Доброе утро!
Ну в Go как бы есть вывод типов. Указывать в каждом месте не обязательно.
Про какие-то конторы написали, что они используют go, а то что Docker так-то тоже на go написан, не написали.
Непорядок...
Долгое время моим основным языком был R. Я все ещё с нежностью вспоминаю "векторизирование" всего что можно, иначе тормоза. Но в какой-то момент настало время выбирать новый стэк. Метался между python, rust и go. Хотел было взять python, но оказалось я устал от динамической типизации, ну правда: сейчас строка, через 10 строчек число... Потом был rust - и вроде все неплохо, безопасность, скорость, си "образность", но требует смены восприятия, а мне уже не 20, мозг грубеет. Лайф таймы там всякие. Так вот, короче, go реально стал оптимальной серединой. Скорость, простота, структуры вместо ООП, пусть немного излишняя многословность, но зато как бы сказать, однозначность, что ли, до введения дженириков. Все ещё остаюсь на нем, жду все нововведения с опаской, но совместимость у него отличная и ими можно просто не пользоваться.
Как я начал учить Go и правда ли он похож на Python. Мой личный опыт