Comments / Profile of divan0 / Habr

Пользователь

ProfileArticles82PostsNewsComments1.6K

Эволюция Go

divan0 Jul 14 2015 at 16:53

какая реализация будет вызвана?

Будет вызывана реализация «RunInSandbox redeclared».
В Go нет оверлоада функций.

Вы продолжаете мыслить классами и другими языками, но записывать это на Go и изобретать код, который не только далек от практической реальности, но и невалидный вообще.

+3

Эволюция Go

divan0 Jul 14 2015 at 14:45

Ну про «ломать язык» точно речь не идет. Но да, как же сложно class-based ООП-mindset выпрямлять )

0

Эволюция Go

divan0 Jul 14 2015 at 14:43

И всё же, читая «вы создаете класс», понятно, что вы пытаетесь создать уже знакомые вам ситуации там, где они не создаются просто потому, что задачи решаются иначе. В Go очень простая и понятная модель — структуры (классы, по вашему) — описывают свойства, а интерфейсы — описывают поведение. Это очень мощная модель, если ей не сопротивляться.

Ваши примеры вроде методов интерфейса iAmHuman() — нонсенс в Go, потому что интерфейс не определяет свойство, человек ты или обезъяна. Примите же это, наконец :)

+1

Эволюция Go

divan0 Jul 14 2015 at 14:34

На самом деле интересный пример, спасибо. В реальном мире, конечно, подобный код очень вряд ли встретиться, ещё и с «ой, где-то ошиблись», отсутствием доступа к оригинальным исходникам, описывающим интерфейсы и невозможностью адекватно переименовать.

Тоесть да, признаю, что в этом примере есть коллизия имен, которая приводит только к тому, что если вы ошиблись, то компилятор это не словит. Но, повторюсь, такой код можно либо сочинить очень старательно намеренно, либо это последствия -измов и кальки с других языков (как в вашем изначальном примере с сериалзайзерами).

Поэтому давайте объективно — если уж и произошел такой костыль, который нельзя исправить, то нужно искать workaround, если всё же хочется обезопасить себя на этапе компиляции. И workaround тут я вижу следующий — вместо Human использовать другой интерфейс-wrapper, отличный от Human. Вот как-то так (embedding наше все):

type MyHuman interface {
	Human
	MyRun()
}

func (c *Person) MyRun() {
	c.Run()
}

// ну и соответственно в playInFunnyGames использовать не Human, а MyHuman
func playInFunnyGames(h1 MyHuman, h2 MyHuman) {
	h1.Run()
	h2.Run()
	fmt.Println("Innocent game complete")
}

play.golang.org/p/EZrgR74HGd

+3

Сборщик мусора в Go: решение проблемы отзывчивости в Go 1.5

divan0 Jul 14 2015 at 07:47

Статья же об этом ) До 1.5 — влияет, после 1.5 — практически нет (есть небольшая корелляция, которую устранят к 1.6)

0

Сборщик мусора в Go: решение проблемы отзывчивости в Go 1.5

divan0 Jul 14 2015 at 07:46

На самом деле там были обсуждения и до Go 1.0 даже были в stdlib функции runtime.Alloc() и runtime.Free(), но их убрали. Надо мейллисты искать для подробностей.

0

Эволюция Go

divan0 Jul 13 2015 at 16:21

Смотрите, есть ситуация — Google, Dropbox, Docker, StackOverflow и куча других компаний, плюс еще тысячи людей успешно пишут проекты на Go, и говорят, что Go давным давно прошел стадию «нехватки библиотек».
У вас есть юз-кейс, где для одной спорной технологии вам не хватает одной библиотеки. Вы приплетаете сюда ещё вторую библиотеку для тоже весьма спорной по популярности задачи, в которой вам не нравится отсутствие примеров, и называете это «в Go нет библиотек»?

Давай быть объективными. Конечно, в Perl-е больше библиотек для устаревших или устаревающих технологий и задач. Но в Go их больше для новых и современных, для работы в облаке, для работы с современными форматами и протоколами, клиентов для новых серверных технологий и решений.

Я с огромным удовольствием помог бы найти подходящее решение, но, кажется, ваша задача — не понять объективную картину, а притянуть что-нибудь за уши, чтобы заявить, что в «Go нет библиотек».

PS. Я не хочу спорить про SOAP. Но я уверен, что Google Trends не врут (и это совпадает с моим пониманием востребованности), и что, будь SOAP так популярен — выбор библиотек был у вас такой же, как для других современных протоколов/технологий.

+2

Эволюция Go

divan0 Jul 13 2015 at 13:07

Структурно же они идентичны, что вводит компилятор в заблуждение об их эквивалентности.

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

+1

Эволюция Go

divan0 Jul 13 2015 at 08:36

Конечно, количество библиотек будет расти.

Но я считаю неадекватной оценку «Не имея библиотек» из-за того, что человеку нужно работать с устаревшими и непопулярными вещами. Здесь всё решает спрос, в конце концов, и для всего, что сейчас в современной экосистеме сетевого/облачного софта востребовано, в Go великолепная поддержка.

Ну и я уже не говорю, что Go — это язык программирования, в конце концов, и библиотеки пишутся такими же людьми, у которых возникла надобность в том или ином решении. Если msgpack востребован, то под него и куча решений, а разбор Maildir — вероятно не такая частая задача в наши дни, и, если вам не подошла библиотека («где примеры?») — всегда можно написать свою, с примерами.

+3

Эволюция Go

divan0 Jul 13 2015 at 08:21

Постарайтесь абстрагироваться от конкретных интерфейсов, каждый из которых может быть описан в отдельном модуле и вообще не знать о существовании друг друга.

Боюсь, что вы сейчас пытаетесь загнать себя (и меня) в логическую ловушку. Этой проблемы нет в Go by design, и вы просите решения несуществующей проблемы.

В спеке Go четко написано:

Two interface types are identical if they have the same set of methods with the same names and identical function types. Lower-case method names from different packages are always different. The order of the methods is irrelevant.

В Go, интерфейс это буквально «описание поведения», и если два интерфейса содержат одинаковые методы, то это одинаковые интерфейсы.

Взяв кальку с вашего примера:

type XMLSerializer interface {
    serialize()
}
type JSONSerializer interface {
    serialize()
}

Это два одинаковых интерфейса.
Любой тип, который реализует serialize() будет удовлетворять оба интерфейса, но это бессмысленно в Go, потому что интерфейс описывает поведение («сериализовать»), а не конкретную реализацию. Нужен JSON — создаете type Json struct{} и определяете serialize() для него. Нужен XML — создаете новый тип type XML struct{} и пишете свой serialize(). Создавать два интерфейса в этом примере бессмысленно. Тогда уже больше подойдет единый type Serializer interface.

+3

Эволюция Go

divan0 Jul 13 2015 at 08:09

Ну да, аж целых два use-кейса:

item := <- myChannel

и

myChannel <- item

Действительно, мозговзрывающе и контринтуитивно. В других языках такой сложности нет.

0

Сборщик мусора в Go: решение проблемы отзывчивости в Go 1.5

divan0 Jul 13 2015 at 07:56

Проблема в понимании причинности проблем. Мне звучит нелогичным утверждение «GC — зло, потому что, если собрать адскую хрень из 3-х языков, то начинаются проблемы». Это как взгромоздить велосипед на автомобиль, а автомобиль на самолёт и утверждать, что «колёса — зло, потому что из-за них начинаются проблемы».

+2

Эволюция Go

divan0 Jul 13 2015 at 07:29

Подобные статьи общего плана можно написать и про brainfuck. Без конкретных примеров, где были бы видны преимущества, такие маркетинговые статьи «для привлечения внимания» ничего не стоят.

Есть в ваших словах доля правды. Мое изначальное побуждение переводить и писать для хабра основано на том, что и я про Go узнал случайно, наткнувшись на какой-то блог-пост. Но сейчас вспоминаю, что это был, действительно, технический пост — точнее ссылка на видео доклада про advanced concurrency patterns в Go.

Ваш пример, наверное, не самый удачный, потому что эта задача (сериализации) в Go красиво решается с помощью тегов структур и стандартной библиотеки.
В пакетах encoding/json и encoding/xml есть интерфейсы Marshaller — json.Marshaller и xml.Marshaller соответственно. Но у них разные сигнатуры, MarshalJSON и MarshalXML. Любой тип, который хочет переопределить сериализацию в JSON или в XML — просто добавляет методы MarshalJSON и MarshalXML соответственно.
Вместо:

type Human struct {
    Name string `json:"name"`
}

h := Human{Name:"Jim"}
data, err := json.Marshal(h)

play.golang.org/p/RzO2LWI8dV

делается что-то вроде

// MarshalJSON implements Marshaller for Human
func (h Human) MarshalJSON() ([]byte, error) {
	return []byte(`{"human name": "` + h.Name + `"}`), nil
}

play.golang.org/p/tKxJ2OlEYj

Но, опять же, в реальной практике в этом обычно нет нужды. К примеру, данный сниппет легко решается изменением тэга json (или xml) для соответствующего поля структуры:

type Human struct {
	Name string `json:"human name", xml:"HumanName"`
}

play.golang.org/p/L-zHKlQEJs

+1

Эволюция Go

divan0 Jul 13 2015 at 06:03

Меня одного напрягает обилие восхваляющих Go статей, без единой строчки кода?

Цель этих статей — обратить внимание людей, не знакомых с Go, показать что такой язык есть, его плюсы и минусы. Более технических статей полно в англоязычном сегменте интернета, и пока что при выборе «что переводить» приоритет больше на статьи общего плана.

Как в Go решена проблема структурной типизации вида: есть два различных интерфейса с похожими с точностью до сигнатуры методами, как реализовать оба интерфейса, если реализации их должны быть различны?

В Go нет «проблемы структурной типизации». Интерфейс — это описание поведения, а не реализации. Если два интерфейса содержат идентичные методы, то это два одинаковых интерфейса.
Но, возможно, я не совсем верно понял ваш вопрос, тогда приведите практический пример, постараюсь ответить точнее.

+2

Эволюция Go

divan0 Jul 13 2015 at 05:38

Согласен. но Go всё таки в равной степени детище как Google, так и open-source сообщества, и если SOAP так востребован, важен и популярен, то нелогично, что нет достойных реализаций. Под любые другие протоколы, технологии и экосистемы, востребованные и популярные в это время — всё есть, если не в стандартной библиотеке, то third party. Тут же спрос решает в конце-концов.
Так что, либо я не так уж заблуждаюсь насчёт SOAP, либо есть иное объяснение. Но интересно, спасибо за мнение, постараюсь углубиться в тему чуть глубже.

0

Эволюция Go

divan0 Jul 13 2015 at 05:32

Мешанина значков, которые никак не могу запомнить как работают.

Ровно два значка:
<- = стрелочка «данные идут справа налево»
[] = это квадратные скобочки

Какой именно из этих целых двух значков вам тут рвёт мозг?

0

Эволюция Go

divan0 Jul 13 2015 at 05:29

Вы вправду не знаете крупные компании и проекты, которые написаны на Go или просто троллите?
Вот тут есть попытка собрать крупные компании, которые описывают свой опыт, но, как вы догадываетесь, большая часть компаний не рассказывает на публику про свой опыт в блог постах.
Но посмотрите, может быть знакомые компании увидите.

Currently using Go

Google — the core Go team work at Google. Most uses of Go at Google are confidential

+5

Эволюция Go

divan0 Jul 12 2015 at 19:44

Ну протобаф в Go по понятным причинам поддерживается великолепно, Cap'n'Proto для Go есть на офсайте.

+1

Эволюция Go

divan0 Jul 12 2015 at 19:41

У меня всегда было ощущение, что SOAP хорошо живет только в proprietary-системах, причем в экосистеме Microsoft, и это была одна из причин, почему REST победил. Я заблуждаюсь?

-1

Эволюция Go

divan0 Jul 12 2015 at 16:01

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

Можно. Но SOAP и «реальные сервера» это не синонимы, как может показаться из вашего ответа.

PS. readwrite.com/2011/05/26/soap-is-not-dead---its-undead

-1

1 2 ...

51

52 53 ...