Сразу обозначу в go недавно, а в этой группе и подавно. Учитывая философию и концепцию языка, в нем все минималистично и более не менее однозначно. Почти. Я вот не могу понять, почему не убрали аллокацию через new? ведь: new(Struct) и &Struct{} это одно и тоже, только второй вариант более гибкий и позволяет заодно же провести и инициализацию. Есть еще make, но он для слайсов контейнеров, его наличие я еще могу понять Если уже такое обсуждалось заранее сорри

Давно разжевано https://stackoverflow.com/questions/18420596/whats-the-difference-between-newstruct-and-struct-in-go

Коллеги, кто как, свои приложения в продакшен заводит?

Не сказать что это продакшен, пишу для себя любимого, но рабочая схема у меня на данный момент такая. Захожу на сервер, mkdir project cd project git init git add . git commit -m "first commit" Теперь создадим отдельную ветку production git checkout -b production На домашнем ПК git clone ssh://user@8.8.8.8/home/project Я могу такое позволить потому что я заранее сделал ключи для ssh. На сервере, переключаемся на master git checkout master Теперь, нужно создать скрипт, который при пуше смержит production с master и перезапустит мой проект cd project touch .git/hooks/post-receive nano .git/hooks/post-receive Вставляем туда #!/bin/sh cd .. env -i git merge production sudo systemctl stop app sudo systemctl start app Разумеется у нас есть конфиг systemd - /etc/systemd/system/app.service, через него происходит стоп и старт проекта. Как-то так.

Давно разжевано https://stackoverflow.com/questions/18420596/whats-the-difference-between-newstruct-and-struct-in-go

Это я читал и прекрасно понимаю, но &S{} короче и легче для рефакторига если вдруг решить добавить все таки поля в S

Вопрос стоял почему бы его не убрать?

Если одни приимущества на стороне этого варианта. Может кто то может привести реальные юзеркейсы?

Я не знаю. Я не академик, я просто делаю сайты и изучаю новое. Задайте вопрос создателям Го.

Сразу обозначу в go недавно, а в этой группе и подавно. Учитывая философию и концепцию языка, в нем все минималистично и более не менее однозначно. Почти. Я вот не могу понять, почему не убрали аллокацию через new? ведь: new(Struct) и &Struct{} это одно и тоже, только второй вариант более гибкий и позволяет заодно же провести и инициализацию. Есть еще make, но он для слайсов контейнеров, его наличие я еще могу понять Если уже такое обсуждалось заранее сорри

Единообразие, кмк

Единообразие, кмк

Ну если что я 10 лет программирую на всевозможных языках и даже писал на такой экзотике как Uno, а то, что здесь много неофитов именно на Go, то это логично, первая версия всего 6 лет назад релизнулась, а популярность стал набирать только года 3-4 назад.

Вопрос стоял почему бы его не убрать?

Я рад, что вы изучаете Го так досконально. Фразой - "Я не знаю. Я не академик, я просто делаю сайты и изучаю новое. Задайте вопрос создателям Го." я не хотел вас обидеть. Пошу прошения

*Прошу прощения

Вопрос стоял почему бы его не убрать?

Я не знаю, обсуждается ли вариант убрать его в Go 2, но в Go 1.x убрать new нельзя из-за вот этого:

It is intended that programs written to the Go 1 specification will continue to compile and run correctly, unchanged, over the lifetime of that specification. At some indefinite point, a Go 2 specification may arise, but until that time, Go programs that work today should continue to work even as future "point" releases of Go 1 arise (Go 1.1, Go 1.2, etc.).

https://golang.org/doc/go1compat

Второй философский вопрос: Зачем нужны указатели в Go без арифметики указателей (понятное дело из-за GC)? Если нужно передать объект именно по ссылке, то используем именно ссылку или вообще все это дело делаем неявно и оставляем на волю компилятора как в других языках. А указатели без арифметики не имеют смысла имхо. Только потому что так верно: func (self *Foo) Set(x int) { self.val = x } А так компилятор не позволяет - не довод: func (self &Foo) Set(x int) { self.val = x } Скорее всего это тоже вопрос к авторам компилятора

It is intended that programs written to the Go 1 specification will continue to compile and run correctly, unchanged, over the lifetime of that specification. At some indefinite point, a Go 2 specification may arise, but until that time, Go programs that work today should continue to work even as future "point" releases of Go 1 arise (Go 1.1, Go 1.2, etc.).

Спасибо! Я так примерно и думал, что исключительно для совместимости с минорной версией

Второй философский вопрос: Зачем нужны указатели в Go без арифметики указателей (понятное дело из-за GC)? Если нужно передать объект именно по ссылке, то используем именно ссылку или вообще все это дело делаем неявно и оставляем на волю компилятора как в других языках. А указатели без арифметики не имеют смысла имхо. Только потому что так верно: func (self *Foo) Set(x int) { self.val = x } А так компилятор не позволяет - не довод: func (self &Foo) Set(x int) { self.val = x } Скорее всего это тоже вопрос к авторам компилятора

& это получение указателя. А * это тип.

Второй философский вопрос: Зачем нужны указатели в Go без арифметики указателей (понятное дело из-за GC)? Если нужно передать объект именно по ссылке, то используем именно ссылку или вообще все это дело делаем неявно и оставляем на волю компилятора как в других языках. А указатели без арифметики не имеют смысла имхо. Только потому что так верно: func (self *Foo) Set(x int) { self.val = x } А так компилятор не позволяет - не довод: func (self &Foo) Set(x int) { self.val = x } Скорее всего это тоже вопрос к авторам компилятора

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

Это про одно и тоже.

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

& это получение указателя. А * это тип.

Если там так же как в C/С++, то это указатель на тип

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

Так же как и в С и C++, но в C++ можно еще пердавать и по ссылке, так же не будет никокого копирования

Это тип, означающий указатель на тип.

В С есть указатели и ссылки. В Го только указатели

(кстати, понимание указателей и ссылок, а также их отличие - это часто большая проблема для изучающих С/С++)

Например в C++: void set(Foo* x) { x->val = 1; } Или void set(Foo& x) { x.val = 1; }

В С есть указатели и ссылки. В Го только указатели

В С нет ссылок. Я кстати впервые сегодня услышал о существовании оных )))

В C++

В C да, их нету, только указатели

А вру. Я так понимаю в Питоне ссылки как раз

Да, я забыл. Давно на С ничего не писал. Ну так вот, в Го, можно считать, нет указателей, а есть только аналог ссылок из С++

приблизительный

Да, я забыл. Давно на С ничего не писал. Ну так вот, в Го, можно считать, нет указателей, а есть только аналог ссылок из С++

Неа. В go цифиря там. Её даже можно посмотреть

В Go как раз чисто указатели

А вру. Я так понимаю в Питоне ссылки как раз

В Python, Java, C#, JS и многих других языках только ссылки для объектов и при чем неявные

А вру. Я так понимаю в Питоне ссылки как раз

Нет

Нет

Ммм?

Все компиляторы у которых есть сборщик муссора оперируют исключительно с ссылками и запрещают манипуляции с указателями, оно и понятно

Но в Go тоже GC, а не скажем ARC

да даже не важно, как именно они реализованы. Я к тому, что работают они похоже на ссылки в С++. Указывают на переменную, арифметики нет, нужны для передачи изменяемых параметров в функции

Все компиляторы у которых есть сборщик муссора оперируют исключительно с ссылками и запрещают манипуляции с указателями, оно и понятно

Не знаю что там кому запрещено - в Go чисто указатели :)

да даже не важно, как именно они реализованы. Я к тому, что работают они похоже на ссылки в С++. Указывают на переменную, арифметики нет, нужны для передачи изменяемых параметров в функции

Так вопрос стоял, что разве только для этого? Это можно легко сделать и через ссылки как в других языках.

да даже не важно, как именно они реализованы. Я к тому, что работают они похоже на ссылки в С++. Указывают на переменную, арифметики нет, нужны для передачи изменяемых параметров в функции

А. Ну... Ну кстати неясно нет ли арифметики. Я вот не уверен. Я так понимаю тут никто низкоуровневого Go-то не знает

Я более чем уверен, что арифметика есть

А в чем смысл вопроса тогда? Почему назвали указателем, а не ссылкой? Потому что под капотом указатель.

Правда в C# для этого используют ref и out, но там просто ссылки неявные

Арифметика, вроде бы, есть в unsafe

Арифметика, вроде бы, есть в unsafe

Угу.

но лучше туда не лезть :)

Арифметика, вроде бы, есть в unsafe

Но на самом деле Go это и есть unsafe :)))))))

Ага, значит все таки в unsafe есть

но лучше туда не лезть :)

Да. Поэтому мы "считаем", что типа арифметики нет

Ага, значит все таки в unsafe есть

А как ты думаешь Go на Go написан?

Как кстати с маршаллингом у Go? Еще до этого не дошол

https://golang.org/pkg/unsafe/ - см. type Pointer

Надо кстати перейти со своего коронного "четверть века Golang" на "а как Go написан на Go?". Это ведь очень интересный вопрос

А что там про четверть века?

А что там про четверть века?

Ну мы же все знаем, что Go не 6 лет и это не новый язык придуманный google? Или подождите, не все?

э-э-э-э

ААААААААААААААААААААААААААААААААААААААА!!!!!!!!!!!!!!!!!!!

я ньюфаг. Расскажи

Ты хочешь поведать про Go! ?

Если да, то это тоже самое что говорить, что JavaScript унаследовался от Java

Это игрушка Пайка. Любимая игрушка Пайка. Не им написанная, о он влюбился в неё с первого взгляда с первого релиза в 1992 году, в котором он и участвовал сам. Были ещё там ветки, ещё что, но в итоге это стало его игрушкой на всю жизнь. Это язык Alef. С сильно переделанным рантаймом (с учетом того что не взлетел). Есть только две вещи, почему нельзя провести прямую линию - копирастия, google не может впрямую пиарить эту историю, и программы на Alef не будут компилиться на Go и наоборот - полная несовместимость

Ты хочешь поведать про Go! ?

Конечно нет

Я надеюсь, вы не думаете, что Go действительно кто-то портировал на Plan9? :)) Нет, просто наработки и уши Plan9 там вычистили чуть не к 1.5 только

Давно не смотрел - Go до сих пор точки с запятыми препроцессором расставляет?

А ну, так у Алефа он унаследовал только многопоточность и каналы

А ну, так у Алефа он унаследовал только многопоточность и каналы

Он всё унаследовал от него кроме рантайма

Это просто он и есть

Да Alef даже пофункциональнее выглядит: http://doc.cat-v.org/plan_9/2nd_edition/papers/alef/ref

Да. Если почитать артикли того же Пайка или там Ритчи тех лет - там понятно почему

Они там с Alef собственно зашились на работе с памятью. А с GC они не смогли придумать как реализовать часть функционала

Любопытно, да. Посмотрел сейчас на этот Alef - да, есть много параллелей с Go. Странно, что я про него ни разу раньше не слышал

Я на самом деле не к тому, что надо называть Go Alef'ом или там значки вешать и памятники ставить. Я только к тому, что надо понимать, что история этого языка совершенно откровенно не начинается в 2007 году. И нет, это не то чтобы "с него взяли". Это одна и та же команда разработчиков с одной и той же платформой.

Любопытно, да. Посмотрел сейчас на этот Alef - да, есть много параллелей с Go. Странно, что я про него ни разу раньше не слышал

Угу. Например список разработчиков очень удивительно пересекается :)))

Например при вое про дженерики надо помнить, что разработчики Go знали о дженериках, когда большинство нытиков ходило разве что в подгузники, а их любимого языка (Java) ещё не было в природе.

И использование дженериков с каналами - это не теория, а вполне себе практика. Разработчикам явно не понравившаяся

И синтаксис кстати придумывать не надо - он есть :))))))

Кстати Алеф еще получил развитие в виде Limbo

А Go и не скрывают, что одним из вдохновителей был как раз Limbo. Так что между Go и Алефом есть родственная связь, не пойму почему Google что то там отрицает

Кстати Алеф еще получил развитие в виде Limbo

limbo совсем не похож и он таки с опкодом и своей vm

А Go и не скрывают, что одним из вдохновителей был как раз Limbo. Так что между Go и Алефом есть родственная связь, не пойму почему Google что то там отрицает

Это кстати забавно, учитывая, что у Limbo синтаксис сильно отличается от Go. Рантайм - да, могли очень сильно на нём наработать. С учетом правда vm

А Go и не скрывают, что одним из вдохновителей был как раз Limbo. Так что между Go и Алефом есть родственная связь, не пойму почему Google что то там отрицает

Limbo не принадлежит крупной корпорации, которая жопу за лиценщию порвет :))

Сказал бы: https://www.ibm.com/developerworks/ru/library/l-inferno_plan9_3/index.html

Те же срезы, короткая запись для объявления переменных, туплеты, каналы и т д

Те же срезы, короткая запись для объявления переменных, туплеты, каналы и т д

Ну это да. Логично. Опять те же разработчики. Но там он совсем не похож. И я в третий раз говорю - там vm

А еще он поддерживает ARC с фоллбэком на GC для циклических указателей. Впервые такое вижу

Код type Config struct { Name string `json:"name"` } func GetFromConfig() string { file, err := os.Open("./config.json") if err != nil { log.Fatal(err) } defer file.Close() decoder := json.NewDecoder(file) cnf := Config{} err = decoder.Decode(&cnf) if err != nil { log.Panic(err) } return cnf.Name } Вопрос, как бы мне так извернуться что-бы через GetFromConfig() получать аргумент, и возвращать его? func GetFromConfig(s string) string { ... return cnf.s Как-то так. Или если есть какие получше варианты?

Код type Config struct { Name string `json:"name"` } func GetFromConfig() string { file, err := os.Open("./config.json") if err != nil { log.Fatal(err) } defer file.Close() decoder := json.NewDecoder(file) cnf := Config{} err = decoder.Decode(&cnf) if err != nil { log.Panic(err) } return cnf.Name } Вопрос, как бы мне так извернуться что-бы через GetFromConfig() получать аргумент, и возвращать его? func GetFromConfig(s string) string { ... return cnf.s Как-то так. Или если есть какие получше варианты?

Есть вариант получше. Зачем каждый раз насиловать диск, когда можно один раз считать конфиг при запуске? Таким образом на порядок быстрее будет работать.

Есть вариант получше. Зачем каждый раз насиловать диск, когда можно один раз считать конфиг при запуске? Таким образом на порядок быстрее будет работать.

Например?

Это запускается один раз при старте.

Получаю буквально три-четыре параметра из конфига.

Ок, второй вариант: func (config *MyConfig) GetName() string { return config.Name} Я бы завёл под конфиг свой тип, и для него бы реализовал методы, возвращающие нужные поля.

В том то и дело, что поля у структуры одинаковые, строка. То есть не вижу смысла писать кучу методов.

В том то и дело, что поля у структуры одинаковые, строка. То есть не вижу смысла писать кучу методов.

Сори, но в Go не дженериков, поэтому копипаст и кодогенерация тут - "эта норма".

Хотя мне есть что предложить. Если конфиг без вложенностей, можешь через reflect доставать нужное поле: func (c Config) GetField(fieldName string) string() {}

Но никто это не одобрит ))

Да при чём тут дженерики? Мне просто нужна функция, одна, которая распарсит джейсон и вернёт запрашиваемую строку из файла.

Да при чём тут дженерики? Мне просто нужна функция, одна, которая распарсит джейсон и вернёт запрашиваемую строку из файла.

Зачем json? Когда ты должен один раз загрузить json в структуру и уже запросы делать по структуре?