Я понимаю, почему вы в такой приоритет поднимаете low-level знания, но я не согласен. Для того, чтобы ребенок понял, что есть программирование, что есть язык программирования, как можно давать команды компьютеру, заинтересовался в конце концов и начал изучать дальше — не нужно учить ассемблер и устройство кешей процессора. Будет надобность — выучит и освоит (top-down), и будет у него «картина целостная», как и ваша.
Но, как заметили выше, не все дети станут программистами, а вот мышление им поставить и дать азы программирования — это важно.
То, о чём тут сейчас идет вялая дискуссия, называется top-down vs bottom-up design. Top-down подход (в контексте обучения) это вот то, что пишут и плюсуют выше — сначала дается общая картинка (big picture), понимание общего дизайна и структуры программы, а уже потом, по мере углубления в ту или иную тему, более детальное изучение «внутренностей». При bottom-up подходе, который вы рекомендуете — сначала даются детали всех составляющих кубиков (пазл про ассемблер, как там биты бегают и тд), из которых уже далее создаются более сложные конструкции.
У меня нет проблем принять тот факт, что некоторые люди очень болезненно отказываются от привычек и убеждений. Тоесть, когда человеку дают новый инструмент, а он говорит «он не похож на старый, значит он плох» — с этим можно смириться, люди такие люди. Но давайте и вы будете объективными, и если реальность такова, что этот инструмент, вне зависимости от того, нравится он вам или не нравится, в продакшене показывает свою крутость и тысячи людей, помимо вас, успешно этим пользуются — то хотя бы имейте смелость это не отрицать. Тогда хоть будет о чем говорить.
Я бы удивился, если бы кто-то написал «голова болит от указателей» )
На самом деле это очень интересная тема, и любой практический опыт ценен. Мне сейчас кажется, что детям важно сначала давать понимание базовой логики и блоков: условия, циклы, функции, вот это всё, и язык тут главное чтобы не был переусложнен. Понимание, как оно там бегает внутри на уровне байт — прийдет позднее, если понадобится, но имхо алгоритмическое мышление нужно ставить до того, как объяснять низкоуровневые абстракции.
Они ставятся на этапе 2, стандартным инсталлятором (в Linux — apt-get/yum/etc, Windows и Mac — стандартный инсталлер с тремя кнопочками «Next»).
Кстати, папки bin и pkg можно не создавать, они создадутся автоматически во время первого билда. Достаточно только src. Я вообще рекомендую GOPATH устанавливать в ~ и тогда достаточно все проекты ложить в ~/src.
Не уверен, что правильно понял. Ссылка на оригинал есть в каждом переводе на хабре (внизу поста), но в данном случае парсер хабра её не принимал, поэтому я указал ещё и в тексте.
Не сильно понял ваше удивление. Есть 4 горутины, которые в случае 1 ядра выполняются *по-факту* последовательно, в случае нескольких — разбрасываются шедулером на несколько ядер и выполняются параллельно. 4-х кратное ускорение вполне логично.
Вот не надо про исключения. Вы чистой воды теоретик, это ясно.
У меня были недавно споры по поводу исключений. Человек вот точно также доказывал, что исключение — единственный true метод обработки ошибок, и все обвинения в том, что исключения часто неправильно используются — это потому что «программисты плохие», язык тут не причём. В теории все звучало круто, пока не дошло до практики.
Код этого человека, с обработкой ошибок на исключениях, получил шанс пройти испытание практикой — нужно было изолировать бинарник в докер, и, по ходу, ошибок, выяснять, чего не хватает, порты, связи, файлы — вот это всё. И все эти аргументы разбились в пух и прах — практически ни одна из ошибок не была правильно отрепорчена, метод «выбросить исключение и забить» показал себя на ура — единственным спасение оказался strace. Вопрос — зачем тогда вообще обрабатывать ошибки исключениями, если даже человек, яростно их защищающий и «умеющий правильно их использовать» не может хорошо этим инструментом пользоваться.
Всё, простите, но предлагаю закончить этот спор теоретиков и практиков.
Хотите модных фишечек PLT — есть масса других языков. Go оставьте для продуктивности и практического применения. Точка.
Жду следующую статью «Почему Go и Rust не враги, а друзья» с главным посылом о том, что Rust помогает Go избавить мир от C++ в тех нишах, где нужен ручной контроль памяти :)
Именно. Познакомьтесь с системой типов в Go, станет понятно, и всё это гадание на кофейной гуще станет не нужным.
В Go, как уже выше писалось, типы различаются на «интерфейсный тип» и «конкретный тип», и любой конкретный тип может неявно удовлетворять «интерфейсный тип». Там используется смешанный подход early/late binding, concrete types чекаются компилятором, интерфейсные типы чекаются рантаймом.
А ресивер метода да, может быть определен только на «конкретный тип». В спеке это четко описано.
Давайте вы сначала пройдете Tour of Go, а потом будете пытаться «поломать язык»? :)
Вообще, специально для людей вот с таким подходом, в разных докладах по Go говорилась фраза «Don't fight the language». Решайте практические задачи способами языка, а не приносите старые паттерны и жалуйтесь, что они не так работают, как вы ожидаете.
Поверьте, Go писали далеко не дураки, и вот так, сгоряча, даже не почитав основ, пытаться «раскусить» и найти там глупость у вас не выйдет.
Ну, тоесть, себя вы может и сможете в этом убедить, но это же не интересно :)
А не поделитесь ссылкой (-ами)?
Но, как заметили выше, не все дети станут программистами, а вот мышление им поставить и дать азы программирования — это важно.
На самом деле это очень интересная тема, и любой практический опыт ценен. Мне сейчас кажется, что детям важно сначала давать понимание базовой логики и блоков: условия, циклы, функции, вот это всё, и язык тут главное чтобы не был переусложнен. Понимание, как оно там бегает внутри на уровне байт — прийдет позднее, если понадобится, но имхо алгоритмическое мышление нужно ставить до того, как объяснять низкоуровневые абстракции.
Кстати, папки bin и pkg можно не создавать, они создадутся автоматически во время первого билда. Достаточно только src. Я вообще рекомендую GOPATH устанавливать в ~ и тогда достаточно все проекты ложить в ~/src.
Статьи подобного рода — естественная реакция тех, кто попробовал что-то новое, остался доволен и хочет поделиться этим с миром.
UPD. Или я неверно понял, что именно удивляет?
У меня были недавно споры по поводу исключений. Человек вот точно также доказывал, что исключение — единственный true метод обработки ошибок, и все обвинения в том, что исключения часто неправильно используются — это потому что «программисты плохие», язык тут не причём. В теории все звучало круто, пока не дошло до практики.
Код этого человека, с обработкой ошибок на исключениях, получил шанс пройти испытание практикой — нужно было изолировать бинарник в докер, и, по ходу, ошибок, выяснять, чего не хватает, порты, связи, файлы — вот это всё. И все эти аргументы разбились в пух и прах — практически ни одна из ошибок не была правильно отрепорчена, метод «выбросить исключение и забить» показал себя на ура — единственным спасение оказался strace. Вопрос — зачем тогда вообще обрабатывать ошибки исключениями, если даже человек, яростно их защищающий и «умеющий правильно их использовать» не может хорошо этим инструментом пользоваться.
Всё, простите, но предлагаю закончить этот спор теоретиков и практиков.
Хотите модных фишечек PLT — есть масса других языков. Go оставьте для продуктивности и практического применения. Точка.
Или покажите, где я такое сказал или забирайте свое обвинение обратно )
В Go, как уже выше писалось, типы различаются на «интерфейсный тип» и «конкретный тип», и любой конкретный тип может неявно удовлетворять «интерфейсный тип». Там используется смешанный подход early/late binding, concrete types чекаются компилятором, интерфейсные типы чекаются рантаймом.
А ресивер метода да, может быть определен только на «конкретный тип». В спеке это четко описано.
Вообще, специально для людей вот с таким подходом, в разных докладах по Go говорилась фраза «Don't fight the language». Решайте практические задачи способами языка, а не приносите старые паттерны и жалуйтесь, что они не так работают, как вы ожидаете.
Поверьте, Go писали далеко не дураки, и вот так, сгоряча, даже не почитав основ, пытаться «раскусить» и найти там глупость у вас не выйдет.
Ну, тоесть, себя вы может и сможете в этом убедить, но это же не интересно :)
Ошибку не получите, потому что в случае двух разных пакаджей это будут две разных функции: packageA.RunInSandbox() и packageB.RunInSandbox().