Comments 34
Выбирал, имея уже 15 лет опыта в программировании.
Выбирал для следующих своих проектов чего посовершеннее.
Java — много лишнего писать
Scala — куда лучше, все равно Ява машина требует по минимуму много оперативки.
Python, Ruby — медленные. Да и статическая типизация — это ж вещь.
Выбирал как
«а что у нас есть со статической типизацией, сборкой мусора и компиляцией».
Выбирал для следующих своих проектов чего посовершеннее.
Java — много лишнего писать
Scala — куда лучше, все равно Ява машина требует по минимуму много оперативки.
Python, Ruby — медленные. Да и статическая типизация — это ж вещь.
Выбирал как
«а что у нас есть со статической типизацией, сборкой мусора и компиляцией».
В Go привлекла богатая стандартная библиотека, статическая компиляция, быстрота, ну и gofmt.
Написал несколько приложений реализующих простое API. Последнее это сервис для управления системой из нескольких розеток на ESP8266.
Начинал учить по http://golang-book.ru/.
А вообще в нише простеньких web-сервисов golang просто великолепен.
Написал несколько приложений реализующих простое API. Последнее это сервис для управления системой из нескольких розеток на ESP8266.
Начинал учить по http://golang-book.ru/.
А вообще в нише простеньких web-сервисов golang просто великолепен.
мне вот очень интересен go, но не могу перебороть отвращение, когда смотрю ближе. )
скажем, упомянутую статью про 50 оттенков открыл с большим интересом, но первый же пункт вызвал полное непонимание, " Открывающую фигурную скобку нельзя размещать в отдельной строке" — издеваетесь? а второй пункт сразу же как бы отвечает — «да издеваемся и гордимся этим»)
это не критика, я понимаю, что кому-то идет нормально и у него множество плюсов. но лично я, после си-подобной свободы синтаксиса, содрогаюсь от мысли писать с такими нелогичными трюками.
скажем, упомянутую статью про 50 оттенков открыл с большим интересом, но первый же пункт вызвал полное непонимание, " Открывающую фигурную скобку нельзя размещать в отдельной строке" — издеваетесь? а второй пункт сразу же как бы отвечает — «да издеваемся и гордимся этим»)
это не критика, я понимаю, что кому-то идет нормально и у него множество плюсов. но лично я, после си-подобной свободы синтаксиса, содрогаюсь от мысли писать с такими нелогичными трюками.
Когда вам нужно будет за полгода написать 30 000 строк кода и не сгореть, то Go очень подходит. Особенно после C/C++.
Тут все абсолютно логично.
Легко ПИСАТЬ код. Сложно ЧИТАТЬ чужой код.
Пока вы работаете один — можете хоть отрицательные отступы использовать. Всем наплевать на ваш код. Интересует только то, что ваш код делает.
Когда вы начинаете работать в КОМАНДЕ над ОДНОЙ кодовой базой, то использование единого стиля оформления решает сразу 2 проблемы:
1. Вы быстрее вникаете в код ваших коллег.
Чужой стиль вас не раздражает КАЖДЫЙ раз. Потому что он выглядет так же как и ваш код.
А это — очень важно: посмотрите на себя, вас уже ЗАОЧНО начала раздражать скобка, что же будет когда вам придется ежедневно читать тонны чужого кода.
Таким образом, вы сосредоточены на основной цели — на смысле программы, а не на том, как она выглядит.
2. При использовании git и т.п. (а куда без них сейчас) вы видите в коммитах только то, что НА САМОМ ДЕЛЕ изменено. Вы не видете в коммитах, что кто то прогнал код через автоформатер и ПРОСТО изменил отступы на свой вкус — и коммит на 1000 строк получился из-за этого.
Таким образом, вы сосредоточены на основной цели — на смысле программы, а не на том, как она выглядит.
В других языках эти вещи все равно в крупных конторах делаются через внешние инструменты — линтеры, code style guide. В golang часть этого добра просто встроена в инструменты «из коробки» и подтягивает даже мелкие конторы под уровень наведения порядка в коде как в больших конторах.
Можно было долго рассуждать какие отступы лучше, где лучше ставить скобку. Каждый бы решал по своему и в результате мы бы получили лишние затраты времени на написание code style guide по 100 разных версий в 100 разных конторах, да зоопарк оформления кода…
Авторы языка просто директивным путем сказали — будет так. И единым махом сняли кучу проблем. Нечто подобное сделано было и при создании Python — там ведь не сделаешь отступы если, то не получишь работающей программы.
Как ни удивительно — но даже опытнейшие программисты нередко оформляют код весьма погано, бывает.
Унификация — позволяет работать более продуктивно, легче разбираться с чужим кодом.
Легко ПИСАТЬ код. Сложно ЧИТАТЬ чужой код.
Пока вы работаете один — можете хоть отрицательные отступы использовать. Всем наплевать на ваш код. Интересует только то, что ваш код делает.
Когда вы начинаете работать в КОМАНДЕ над ОДНОЙ кодовой базой, то использование единого стиля оформления решает сразу 2 проблемы:
1. Вы быстрее вникаете в код ваших коллег.
Чужой стиль вас не раздражает КАЖДЫЙ раз. Потому что он выглядет так же как и ваш код.
А это — очень важно: посмотрите на себя, вас уже ЗАОЧНО начала раздражать скобка, что же будет когда вам придется ежедневно читать тонны чужого кода.
Таким образом, вы сосредоточены на основной цели — на смысле программы, а не на том, как она выглядит.
2. При использовании git и т.п. (а куда без них сейчас) вы видите в коммитах только то, что НА САМОМ ДЕЛЕ изменено. Вы не видете в коммитах, что кто то прогнал код через автоформатер и ПРОСТО изменил отступы на свой вкус — и коммит на 1000 строк получился из-за этого.
Таким образом, вы сосредоточены на основной цели — на смысле программы, а не на том, как она выглядит.
В других языках эти вещи все равно в крупных конторах делаются через внешние инструменты — линтеры, code style guide. В golang часть этого добра просто встроена в инструменты «из коробки» и подтягивает даже мелкие конторы под уровень наведения порядка в коде как в больших конторах.
Можно было долго рассуждать какие отступы лучше, где лучше ставить скобку. Каждый бы решал по своему и в результате мы бы получили лишние затраты времени на написание code style guide по 100 разных версий в 100 разных конторах, да зоопарк оформления кода…
Авторы языка просто директивным путем сказали — будет так. И единым махом сняли кучу проблем. Нечто подобное сделано было и при создании Python — там ведь не сделаешь отступы если, то не получишь работающей программы.
Как ни удивительно — но даже опытнейшие программисты нередко оформляют код весьма погано, бывает.
Унификация — позволяет работать более продуктивно, легче разбираться с чужим кодом.
Унификация — это интересно, но людей смущает не она сама по себе, а невозможность ее отключить, хотя бы частично
gofmt запускать вовсе не обязательно. это настоятельно рекомендуется — и только.
Я имел ввиду немного другое. Например, компилятор ругается на неиспользуемую библиотеку (ему-то что?). Если подобные фичи тоже отключаются — тогда все в порядке, но я во время экспериментов такой возможности не нашел
Как только появляется возможность это отключать — в релиз билдят с отключенной проверкой.
Вы никогда не видели в релизе программ, скопилированных с debug-информацией? Мне регулярно встречаются. Такова природа человека — человек ленив.
Импорты — такая уж и не проблема. Нормальные редакторы/IDE для Go сами добавляют/удаляют импорты.
Вы никогда не видели в релизе программ, скопилированных с debug-информацией? Мне регулярно встречаются. Такова природа человека — человек ленив.
Импорты — такая уж и не проблема. Нормальные редакторы/IDE для Go сами добавляют/удаляют импорты.
> но лично я, после си-подобной свободы синтаксиса
Да, я понимаю, свобода синтаксиса позволяет писать упопомрачительные конструкции, которые удивляют коллег. Однако конечная цель программиста — решение задачи, а вовсе не жонглирование инструментом.
Парадокс: слишком большая свобода С — это его недостаток, вовсе не достоинство. Из-за нее чаще получается неожиданное поведение компилятора.
Да, я понимаю, свобода синтаксиса позволяет писать упопомрачительные конструкции, которые удивляют коллег. Однако конечная цель программиста — решение задачи, а вовсе не жонглирование инструментом.
Парадокс: слишком большая свобода С — это его недостаток, вовсе не достоинство. Из-за нее чаще получается неожиданное поведение компилятора.
вы платите скобочками за скорость компиляции ))
Так Go потому и востребован (одно из), что в нем заставляют писать код единообразно. Вам может в чем-то не нравиться какой-то ЯП, но деньги платят заказчики / владельцы конторы. Хотите у них работать — подстраивайтесь, но хотите — ищите другие ниши, где есть «Ваши» ЯП. Конфликт интересов надо правильно решать.
До Go основным языком был perl, для перехода с perl выбирал между 15 языками, долго выбирал..., так как натыкался на огромные слабости во всех языках, они все не доросли до perl.
Обратил внимание на Go, он сразу понравился и стандартной библиотекой и github был аналогом CPAN и много чего, сделал ставку на него! Спустя 7 лет он остаётся лучшим, пишу на нем и буду продолжать писать!
Обратил внимание на Go, он сразу понравился и стандартной библиотекой и github был аналогом CPAN и много чего, сделал ставку на него! Спустя 7 лет он остаётся лучшим, пишу на нем и буду продолжать писать!
Когда заинтересовался этим Go, у меня был всего один вопрос: как на нём делать пользовательский интерфейс. Я обратился с вопросом к народу, и народ мне ответил, что я дурак, что время десктопов ушло, а все интерфейсы должны быть через Хром.
Так что я себе решил: ну её, эту хипстерскую приблуду.
UFO just landed and posted this here
Ну чтобы никуда не прыгать, есть Питон и Ява. Могут всё, работают везде. Нет, С++ круто, но по моему его главная проблема — слишком много устаревших практик в готовом коде и в головах самих программистов. Когда в 2016 году в совершенно не критичном коде видишь сдвиг указателя вправо на значение, взятое из указателя на указатель, или ручное написание Makefile с тучей условий, это хочется не рефакторить, а форматнуть вместе с диском и самим автором.
https://github.com/avelino/awesome-go#gui
Ваша логика такова: язык похож синтаксисом на С — поэтому на нем можно делать десктопные приложения, подобные тем, что делают на С++?
Делать так же как это делают с другими языками — библиотеки для создания GUI для Go есть
http://eax.me/go-gkt-gui/
https://habrahabr.ru/post/253519/
Есть альтернативный путь — например LiteIDE написан с использование Go и QT и еще одного языка ;)
Но, возможно, Вы путаете язык и и нативный дизайнер интерфейсов для него.
Полноценный развитый нативный дизайнер интерфейсов для Go писать уже вряд ли кто будет, как и для любого другого нового языка. Тут ваши советчики правы — например, С# имеет лучшую заточенность на работу с GUI десктопа.
Ваша логика такова: язык похож синтаксисом на С — поэтому на нем можно делать десктопные приложения, подобные тем, что делают на С++?
Делать так же как это делают с другими языками — библиотеки для создания GUI для Go есть
http://eax.me/go-gkt-gui/
https://habrahabr.ru/post/253519/
Есть альтернативный путь — например LiteIDE написан с использование Go и QT и еще одного языка ;)
Но, возможно, Вы путаете язык и и нативный дизайнер интерфейсов для него.
Полноценный развитый нативный дизайнер интерфейсов для Go писать уже вряд ли кто будет, как и для любого другого нового языка. Тут ваши советчики правы — например, С# имеет лучшую заточенность на работу с GUI десктопа.
ну тогда вопрос какой фреймворк быстрый использовать для веб разработки BPM платформы, все таки когда завезут IDE ??
Для веба у Go нет острой необходимости в фреймворках. Не переносите стереотипы с других языков.
Для многих случаев вполне достаточно стандартной библиотеки а также не полных фреймворков, а отдельных модулей библиотек, например, из Gorilla Toolkit.
BPM, вероятно, имеет смысл делать на микросервисах — тогда поглядите на Go-Micro.
Для многих случаев вполне достаточно стандартной библиотеки а также не полных фреймворков, а отдельных модулей библиотек, например, из Gorilla Toolkit.
BPM, вероятно, имеет смысл делать на микросервисах — тогда поглядите на Go-Micro.
Для программистов, кто хочет научиться писать на Go — это можно сделать за два вечера, пройдя тур на оф. сайте. Дальше читать Effective Go. Да и собственно, кроме Effective Go (а это даже не маленькая книжка, а небольшой буклетик, размером тянет на статью) вам ничего не надо.
Для программистов, которые не хотят учиться программировать на Go, тоже есть плюшки:
1. В Go до сих пор нет нормальной полностью работающей экосистемы. Во-первых, нет IDE. Всё, что заскриптовано (плагины для всяких редакторов) — опирается на стандартную парадигму Go, то есть один GOPATH, в нём /src /pkg и /bin.
2. Когда дело доходит до вендоринга (как без него вообще жить?) — половина этих плагинов уже отваливается, т.к. структура папок не by default.
3. Когда дело доходит до нормального вендоринга (не просто положить зависимость в папку проекта, а положить зависимость конкретной версии из конкретной ветки) — то отваливается ещё половина плагинов. Тут же отваливаются половина стандартных тулзов самой go — например, go type, go vet и т.д. Эти тулзы, почему-то, читают бинарники, а не исходники, и читают их их GOPATH/pkg. Поэтому, если у тебя два проекта с одной зависимостью, но разных версий, то это всё начинает ругаться матом и т.п. Более того, go types вообще перестал работать в Go 1.7 из-за смены формата архивных файлов, выдаваемых компилятором.
Ну и, в общем, смысл вы поняли. Костыли для создания подобия IDE, костыли для вендоринга и т.д. Подвижки в этом плане есть, недавно всё коммьюнити заставили пройти большой опрос по поводу выбора вендоринга. Надеюсь, устаканится.
Для программистов, которые не хотят учиться программировать на Go, тоже есть плюшки:
1. В Go до сих пор нет нормальной полностью работающей экосистемы. Во-первых, нет IDE. Всё, что заскриптовано (плагины для всяких редакторов) — опирается на стандартную парадигму Go, то есть один GOPATH, в нём /src /pkg и /bin.
2. Когда дело доходит до вендоринга (как без него вообще жить?) — половина этих плагинов уже отваливается, т.к. структура папок не by default.
3. Когда дело доходит до нормального вендоринга (не просто положить зависимость в папку проекта, а положить зависимость конкретной версии из конкретной ветки) — то отваливается ещё половина плагинов. Тут же отваливаются половина стандартных тулзов самой go — например, go type, go vet и т.д. Эти тулзы, почему-то, читают бинарники, а не исходники, и читают их их GOPATH/pkg. Поэтому, если у тебя два проекта с одной зависимостью, но разных версий, то это всё начинает ругаться матом и т.п. Более того, go types вообще перестал работать в Go 1.7 из-за смены формата архивных файлов, выдаваемых компилятором.
Ну и, в общем, смысл вы поняли. Костыли для создания подобия IDE, костыли для вендоринга и т.д. Подвижки в этом плане есть, недавно всё коммьюнити заставили пройти большой опрос по поводу выбора вендоринга. Надеюсь, устаканится.
1. IDE в Go есть уже очень давно:
а) LiteIDE (кстати, написано с использованием самого Go)
б) Jetbrains IntelliJ (а также Android Studio и любые другие на базе IDE Jetbrains, например, PyCharm) — это универсальная IDE, адаптация под любой язык, в том числе и под Go — делается плагином. https://plugins.jetbrains.com/plugin/5047
Этот плагин активно развивается.
в) Есть развитые плагины для основных программистких редакторов, которые превращают эти редакторы практически в IDE — vim-go для vim, есть для Sublime, Emacs, Atom и пр.
2. Если вы используете какую то нестандартную систему вендоринга — извольте подстроить под нее свою IDE. Хотя бы пути укажите вручную.
3. Похоже, вы просто не осилили вендоринг. Принимал участие в больших проектах. Ничего у нас не отваливалось.
Конечно, инфраструктура не такая развитая как для Java или C#, но вполне сравнима с костылями, которые приходится делать для С++.
а) LiteIDE (кстати, написано с использованием самого Go)
б) Jetbrains IntelliJ (а также Android Studio и любые другие на базе IDE Jetbrains, например, PyCharm) — это универсальная IDE, адаптация под любой язык, в том числе и под Go — делается плагином. https://plugins.jetbrains.com/plugin/5047
Этот плагин активно развивается.
в) Есть развитые плагины для основных программистких редакторов, которые превращают эти редакторы практически в IDE — vim-go для vim, есть для Sublime, Emacs, Atom и пр.
2. Если вы используете какую то нестандартную систему вендоринга — извольте подстроить под нее свою IDE. Хотя бы пути укажите вручную.
3. Похоже, вы просто не осилили вендоринг. Принимал участие в больших проектах. Ничего у нас не отваливалось.
Конечно, инфраструктура не такая развитая как для Java или C#, но вполне сравнима с костылями, которые приходится делать для С++.
Дропбокс уже перешел на Go,
Докер и сопутствующие утилиты написаны на Go,
Хашимото (DevOps — Consul, Nomad и пр) поднял миллионы с использование Go,
Kubernetes — самая перспективная на сегодня система управления микросервисными контейнерами написана на Go
На Go переписаны нагруженные куски кода в Twitter и Youtube.
CloudFlare в значительной части быстро работает благодаря тому, что код там на Go.
eBay, Bitbucket и пр.
А вы все еще стесняетесь использовать Go?
К чему это я? Я утверждаю, что все эти ребята решили для себя ваши надуманные проблемы.
А вы так и продолжайте ждать пока для Go сделают всё, пока сделают универсальную кнопку, нажав на которую вы сможете решить любую проблему в ИТ — или может лучше самому написать такую кнопку, под свою конкретную задачу?
Докер и сопутствующие утилиты написаны на Go,
Хашимото (DevOps — Consul, Nomad и пр) поднял миллионы с использование Go,
Kubernetes — самая перспективная на сегодня система управления микросервисными контейнерами написана на Go
На Go переписаны нагруженные куски кода в Twitter и Youtube.
CloudFlare в значительной части быстро работает благодаря тому, что код там на Go.
eBay, Bitbucket и пр.
А вы все еще стесняетесь использовать Go?
К чему это я? Я утверждаю, что все эти ребята решили для себя ваши надуманные проблемы.
А вы так и продолжайте ждать пока для Go сделают всё, пока сделают универсальную кнопку, нажав на которую вы сможете решить любую проблему в ИТ — или может лучше самому написать такую кнопку, под свою конкретную задачу?
1. IDE. Что они есть, это не значит, что они хорошо работают. А они все работают плохо, по большей части из-за вендоринга. Просто скажите мне, каким вендорингом вы пользовались, учавствуя в больших проектах?
2. То, что много кто пишет на Go я не сомневаюсь, это не значит, что они не испытывают боль такую же, как я, когда пишу на Go.
Вы утверждаете, что они решили для себя мои «надуманные» проблемы. Ключевое слово здесь — «решили». Да, я их тоже решил, спокойно сижу и програмирую на Go, но чтобы этого добиться, мне приходилось «решать» какие-то простейшие проблемы.
Вот вам задача, которую я поставил перед собой — хочу работать попроектно (вендоринг), что в каждом проекте был repeatable build (нестандартный вендоринг), чтобы я мог спокойно форкнуть какую-нибудь популярную либ, изменить её и использовать мой форк вместо оригинальной во всех проектах, при этом не меняя импорты в куче файлов во всех проектах (опять нестандартный вендоринг). Плюс хочу, чтобы мой код был чистым и автоматом проверялся на code style (плагины-линтеры, плагины-форматтеры, govet, gotype и т.д.). При этом хочу, чтобы моя IDE не была на Java и работала быстро. Ещё хочу не только билдить локально, но и деплоить на тестовый сервер по нажатию кнопки в IDE.
Вопрос — я много хочу? Вроде бы стандартный набор разработчика, но почему каждая из этих фич заставляет меня писать костыли??? Вы правильно заметили, костыли сродни плюсовым. Но позиционирование у Go абсолютно противоположное плюсам — easy to learn, easy to use, easy to solve your problems.
Жду описания вашего воркфлоу и как вы его уместили в стандартную экосистему golang.
2. То, что много кто пишет на Go я не сомневаюсь, это не значит, что они не испытывают боль такую же, как я, когда пишу на Go.
Вы утверждаете, что они решили для себя мои «надуманные» проблемы. Ключевое слово здесь — «решили». Да, я их тоже решил, спокойно сижу и програмирую на Go, но чтобы этого добиться, мне приходилось «решать» какие-то простейшие проблемы.
Вот вам задача, которую я поставил перед собой — хочу работать попроектно (вендоринг), что в каждом проекте был repeatable build (нестандартный вендоринг), чтобы я мог спокойно форкнуть какую-нибудь популярную либ, изменить её и использовать мой форк вместо оригинальной во всех проектах, при этом не меняя импорты в куче файлов во всех проектах (опять нестандартный вендоринг). Плюс хочу, чтобы мой код был чистым и автоматом проверялся на code style (плагины-линтеры, плагины-форматтеры, govet, gotype и т.д.). При этом хочу, чтобы моя IDE не была на Java и работала быстро. Ещё хочу не только билдить локально, но и деплоить на тестовый сервер по нажатию кнопки в IDE.
Вопрос — я много хочу? Вроде бы стандартный набор разработчика, но почему каждая из этих фич заставляет меня писать костыли??? Вы правильно заметили, костыли сродни плюсовым. Но позиционирование у Go абсолютно противоположное плюсам — easy to learn, easy to use, easy to solve your problems.
Жду описания вашего воркфлоу и как вы его уместили в стандартную экосистему golang.
У меня к вендорингу есть свои претензии, но похоже, что вы называете этим слово что-то такое, что не относится к обычному, появившимся еще в версии 1.5. С этим вендорингом все IDE и продвинутые редакторы работают как должно. Вопрос «каким вендорингом вы пользовались» заставил меня даже посмотреть на дату сообщения — сейчас есть единый и неповторимый vendor, который понимают все тулзы и все IDE и который не требует переписывания импортов.
Эту часть «хочу работать попроектно (вендоринг), что в каждом проекте был repeatable build (нестандартный вендоринг)» я не понял вообще. Как попроектно относится к вендорингу? Если речь идет о том, что вы хотите все свои зависимости завендорить — ну так они ничем не отличаются от внешних зависимостей и положив их в vendor вы добьетесь repeatable build без всяких плясок и усилий. И «форкнуть какую-нибудь популярную либ, изменить её и использовать мой форк» тоже не проблема. Форкаем, меняем, кладем в vendor.
«хочу, чтобы моя IDE не была на Java и работала быстро» — и чтоб синенького цвета? Если надо именно IDE то выбора особого нет, только на java. Если надо продвинутый редактор с пониманием Go – то таких есть штук пять.
«ещё хочу не только билдить локально, но и деплоить на тестовый сервер по нажатию кнопки в IDE» — а это для Go делается каким-то особым и сложным способом? Я не знаю, какой уровень волшебства вы ожидаете, но у меня вообще ничего не надо нажимать и все это делается по коммиту. Ну и в IDE как и в редакторах это делается десятком разным плагинов, на любой вкус.
Для всего этого, что перечислено, никаких костылей не надо. В принципе, для этого вообще ничего не надо, оно уже там есть и оно работает.
Эту часть «хочу работать попроектно (вендоринг), что в каждом проекте был repeatable build (нестандартный вендоринг)» я не понял вообще. Как попроектно относится к вендорингу? Если речь идет о том, что вы хотите все свои зависимости завендорить — ну так они ничем не отличаются от внешних зависимостей и положив их в vendor вы добьетесь repeatable build без всяких плясок и усилий. И «форкнуть какую-нибудь популярную либ, изменить её и использовать мой форк» тоже не проблема. Форкаем, меняем, кладем в vendor.
«хочу, чтобы моя IDE не была на Java и работала быстро» — и чтоб синенького цвета? Если надо именно IDE то выбора особого нет, только на java. Если надо продвинутый редактор с пониманием Go – то таких есть штук пять.
«ещё хочу не только билдить локально, но и деплоить на тестовый сервер по нажатию кнопки в IDE» — а это для Go делается каким-то особым и сложным способом? Я не знаю, какой уровень волшебства вы ожидаете, но у меня вообще ничего не надо нажимать и все это делается по коммиту. Ну и в IDE как и в редакторах это делается десятком разным плагинов, на любой вкус.
Для всего этого, что перечислено, никаких костылей не надо. В принципе, для этого вообще ничего не надо, оно уже там есть и оно работает.
А почему именно сегодня день рождения?
Если отбросить странные коммиты Brian Kernighan от 1972, 1974 и 1988 года (o_O; это тот самый? пасхалка?), то получаем
Т.е. 2 марта день рождения.
git log --reverse
Если отбросить странные коммиты Brian Kernighan от 1972, 1974 и 1988 года (o_O; это тот самый? пасхалка?), то получаем
commit 18c5b488a3b2e218c0e0cf2a7d4820d9da93a554
Author: Robert Griesemer <gri@golang.org>
Date: Sun Mar 2 20:47:34 2008 -0800
Go spec starting point.
SVN=111041
Т.е. 2 марта день рождения.
Ага, нашел.
Оттуда:
Тогда 21 сентября. Сейчас ноябрь.
Robert Griesemer, Rob Pike and Ken Thompson started sketching the goals for a new language on the white board on September 21, 2007.
Тогда 21 сентября. Сейчас ноябрь.
Мало ли.
Например, к ноябрью они уже поняли, что это не просто упражнения для ума… — уже точно будет язык. Может имя придумали…
Например, к ноябрью они уже поняли, что это не просто упражнения для ума… — уже точно будет язык. Может имя придумали…
Новость о релизе была именно 10 ноября. Эту дату и приняли. Собственно, пруф в этом году https://blog.golang.org/7years, а самой первой новости видимо уже не сохранилось.
Как банально это не звучит, но я купил книгу The Go Programming Language и начал читать, а главное делать задания, которые там даются. Кому интересно, здесь некоторые из них, которые я уже выполнил.
Sign up to leave a comment.
Языку программирования Go — семь лет