Знакомство с сабжеязыком оставило двоякие впечатления. С одной стороны определенно что-то хорошее в нем есть. С другой - тот же пистон, вид с боку^W^Wс гугла Так что он меня не вдохновил на нем писать.

>>11927
Категорически не разделяю. Питон с Go имеет куда меньше общего, чем даже с джавой, джаваскриптом и сишкой, и чем у сишки и джавы между собой. Но в то же время, Go достаточно прост, чтобы начать на нём фигариться прямо сразу же. Я немножко пробовал, но сейчас времени нет.

Большие вещи на нем писать нет смысла, т.к. обобщенного программирования нема.

Очевидно, почему. Go is desined for fast little суслики.

Интерфейсы позволяют создавать относительно универсальные алгоритмы, не зная о том, какого типа будут данные. Конечно, они не работают на уровне примитивных типов. Придется создать структуру с методами, которые будут всё же выдавать значения одинаковых типов для разных реализаций (или другие интерфейсы). В общем, универсально писать на нём можно. По производительности правда должно бить наверняка, не проверял.

Самое странное, что в Go нет слова implements. Т.е. если я сделал интерфейс с определенными методами, а затем объявил структуру с этими методами, то она реализует интерфейс автоматически.
http://jordanorelli.com/post/32665860244/how-to-use-interfaces-in-go

Возьмем следующий пример:
package main

import "fmt"

type Animal interface {
Speak() string
}

type Dog struct {
}

func (d Dog) Speak() string {
return "Woof!"
}

func main() {
var x Animal = Dog{};
fmt.Println(x.Speak());
}

Закоментируйте функцию "func (d Dog) Speak() string". В этом случае команда "go build myprog.go" выдаст сообщение "cannot use Dog literal (type Dog) as type Animal in assignment: Dog does not implement Animal (missing Speak method)".

Я просто о том, что проверки выполняются на этапе компиляции, а ругается компилятор уже на приведение типа (assignment-строчка), а не на выполнение методов. Т.е. вещь вполне достойная практического применения.

Расскажу о вопросе, который волнует всех.
Допустимо ли писать на Go действительно маленькие программы, как 64k intro и трехбайтные кейгены. Ответ - нет, не допустимо. Размер binaries для Go - не приоритет. Возьмем для примера тот код, который я написал выше. Его размер в собранном виде - 1,89 Мб. Соберем его релизную версию, обрезав все debug-символы линкером (strip all).
go build -ldflags "-s" interfaceTest.go
Размер уменьшился до 1,36 Мб. Теперь возьмем получившееся и...
upx -oupxed.exe -9 interfaceTest.exe
Размер: 364 Кб. А ведь программа фактически ничего не делает.

Большую часть этого занимает Go runtime. Я так думаю, ведь у меня другой пример, который побольше, и использует внешнюю библиотеку, "github.com/hamstah/imaging". Кода там значительно больше, а бинарники занимают 3.19, 2.24 и 0.58 Мб соответственно. То есть вся эта библиотека из ~15 файлов + мой код в сжатом виде прибавляют к 364 всего лишь около 200 Кб.

Go позволяет из коробки работать сразу на всех ядрах процессора, делая параллельные циклы. Это чем-то напоминает OpenMP по своей сути, сделанное через асинхронный вызов процедур, как в JS, но с возможностью затормозить основной поток и подождать, пока все процедуры завершатся (модуль sync). Процедуры эти называются горутинами. Старт горутины делается ключевым словом go.
Пример: https://github.com/disintegration/imaging/blob/6429426f3023241bfed5045533f98542cd8732c0/parallel.go
32 строчка - WaitGroup будет ждать numGoroutines вызовов
36 строчка - запуск и объявление горутины.
37 строчка - ключевое слово defer означает, что wg.Done() будет вызвано прямо перед тем как функция (в данном случае горутина) завершится.
52 строчка - WaitGroup ждет, пока его счетчик не дойдет до нуля.

Еще, не знаю, как будет в будущем, но сейчас чтобы задействовать все ядра процессора, нужно в самом начале функции main, например, написать такую строчку.
runtime.GOMAXPROCS(runtime.NumCPU())

TCO - НЕТ
паттерн-матчинга - НЕТ
убить горутину извне - НЕЛЬЗЯ
иммутабельности - НЕТ

Для языка созданного в 2007 году всего этого не иметь... ну даже не знаю что сказать. Эрланг куда лучше подходит для той области, куда пытаются всунуть го.

>>11941

внезапно удваиваю этого стива.

>>11941
статической типизации - НЕТ
функциональной чистоты - НЕТ
компиляции - НЕТ
гарды - УБОГИЕ
let it crash - BULLSHIT

Ну даже не знаю что сказать. Хаскель куда лучше подходит для той области, куда пытаются всунуть Erlang.

t. erlang programmer

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

>>11943
Хаскель не подходит. У него сборщик мусора не один на каждую зеленую нить, а общий. Может в любой момент встать колом, чтобы мусор начать собирать, гигабайт так 20. А с таким сбором мусора даже жава не всегда справляется без того чтобы не задуматься на пару секунд, и это с ее-то вылизанной виртуальной машиной. Плюс нет шедулинга процессов по редукциям, что исключает блокировку одним процессом других. Плюс передача сообщений в Cloud Haskel медленнее, чем в медленном Erlang OTP. Плюс Cloud Haskel так пока и не зарелизили. Плюс сам язык сильно переусложнен, требует осиляторства. Плюс проблемы с деплоем и несовместимостью версий, а Erlang собирается везде, даже на mips и arduino. Плюс невозможность интроспекции - там где в Erlang можно присоединиться к живой нагруженной ноде и посмотреть, что там творится внутри каждого процесса и куда это ушло 20 гигабайт памяти, в хаскеле остается только задумчиво чесать бороду.

А Let it crash - просто чудо!

>>11944
Go и близко не c14. То есть совсем, обя языка используются для совершенно разных непересекающихся задач. Go это нечто среднее между NodeJS и Erlang.

>>11949
Может быть. Наверно. Возможно он задумывался как Эрланг, но он хорошо подходит для задач c14.

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

Я не знаю, как было, но предполагаю, что так и есть.

>>11948
> А Let it crash - просто чудо!
К сожалению, NDA не позволяет мне поделиться всей гаммой эмоций, которую я испытываю по поводу этой парадигмы. Но, скажем так, мне довелось близко познакомиться с проектом, откуда она пошла. Если абстрагироваться от деталей, её назначение в основном состоит в усложнении тестирования и превращении простых багов в сложные. На практике эти ваши хвалёные супервайзоры склонны распространять ошибки, а вовсе не изолировать их.
> У него сборщик мусора не один на каждую зеленую нить, а общий.
Как-то мы потратили два месяца на поиск и воспроизведение бага, когда гц иногда включался в одной нити, из-за чего начинали ехать уже все тайминги и, в конечном итоге, целая подсистема начинала жить своей жизнью. Так что это, возможно, и не самая хорошая идея. В хацкеле гц хоть и не конкуррентный, но параллельный.
> Плюс сам язык сильно переусложнен, требует осиляторства.
Высокий порог вхождения -- большой плюс, на самом деле.

>>11953
P.S. И да, хаскель вовсе не "переусложнён", а скорее наоборот.

>>11948
> У него сборщик мусора не один на каждую зеленую нить, а общий.
Это из спецификации языка следует? Или это особенность шотландского майкрософтовского компилятора?

Ну давайте еще об алгебраических типах поговорим.

>>11953
Тащемта я без всякого NDA могу сказать, что зарабатываю деньги эрлангом в качестве одновременно и владельца бизнеса и программиста, и подход let it crash мне очень нравится. Надо только понимать, что может упасть и как восстанавливать состояние после падения.
Супервизоры и не должны изолировать ошибки. Их задача - поднять упавший процесс, чтобы восстановить последнее неошибочное состояние. Если непонятно как восстанавливать - то значит и поднимать нечего, надо упасть и пусть этим разбирается вышестоящий супервизор. При падении каждого процесса пишется лог. Вообще ошибки изолироваться не должны, они должны откатыватся или игнорироваться, а если это невозможно - ронять систему.

Насчет GC - это известная тема для долгоживущих процессов с известными способами ее решения. В том числе при создании такого процесса средствами OTP можно явно указать как часто вызывать сборщик мусора. Можно хоть на каждое сообщение. А вот для короткоживущих процессов такой сборщик мусора имеет огромные преимущества, не имея при этом недостатков.

Насчет порога вхождения. С точки зрения бизнеса - категорическое нет. Язык с высоким порогом вхождения для бизнеса не подходит и массовым никогда не станет - слишком дорого и слишком долго. Для программиста тоже нет - язык должен упрощать работу, а не усложнять. Усложнять можно развлечение, получая удовольствие от красивого преодоления трудностей. Для подавляющего числа программистов на хаскеле хаскель - это именно красивая игрушка для развлечения. На работе они пишут на других языках. Хаскель хорош, когда программа самоценна сама по себе (компьютер саенс и т.п.). В коммерческой разработке программа не важна, важны результаты и характеристики ее работы.

Хаскель не "наоборот", он очень сильно переусложнен как на уровне количества конструкций, так и на уровне их семантики. Только вот если в другом языке, знаменитом своей сложностью - в С++ - можно начать писать не зная и не понимая большей части возможностей, то на хаскеле так уже не попишешь, там надо слишком многое знать и понимать сразу.

>>11956
Это следует из каноничной реализации существующего сборщика мусора хаскеля на всех платформах. Или будем вести разговор на уровне "можно зделать"?


>>11957
А что о них говорить, это же очень простая и удобная идея комбинирования типов, которая есть и в эрланге и в хаскеле, и которой нет в go. Только в хаскеле есть статическая проверка типов, которая работает с алгебраическими типами, а в динамическом эрланге можно или писать аннотации для диалайзера, или проверять типизацию гардами и кейсами, если вдруг хочется. Второе как правило получается само собой в процессе разработки.
На границе с i/o все равно и там и там приходится все проверять ручками, никакой статический анализ с i/o не поможет.

>>11959
> или проверять типизацию гардами и кейсами
> проверять типизацию гардами и кейсами

>>11964
Ну, местами Go действительно fail.

>>11959
> в качестве одновременно и владельца бизнеса и программиста
То есть с большими объёмами кода, которые пишутся непонятно кем, ты не работаешь. Вся суть динамиколюбов.

Я так понял, все сошлись, что Java норм, и не надо выносить друг другу мозг.

Джава деплоится долго.

Хорош тот инструмент, который кормит тебя.
Да благословенны будут друпаломаги вместе с SEO-блудницами.

>>11919
Пишу на нем убийцу фейсбука. Мне нравится.

>>11941
>убить горутину извне - НЕЛЬЗЯ
Можно послать ей сообщение, чтобы она самоубилась.

>>11989
или сохранить резултат, вернуться вв прошлое и не создавать ее

>>11993
Это очень мощный аргумент, кстати. Но я, проходящий мимо, вижу в Го только аналог сишки, поэтому не вижу проблем. На сишке путешествия во времени разрешены.

>>12004
Кстати пик - пруф

А давайте пилить интры 64кБ на яве. Я тут пытаюсь завести хелловорлд, но почему-то не рисуется ничего. Надо сообразить, как в drawElements. Требования такие: из зависимостей только опенгл+опенал (т.е. lwjgl, т.е. в pom.xml не добавлять ничего). Результат должен быть либо размер исходника не более 64 килобайт, либо получившаяся джарка не больше 64 килобайт (т.е. без учета lwjgl), что, как мне кажется, проще сделать. Исходники публиковать обязательно. https://github.com/georgy7/intro1%%

Есть хорошая статья о том, как делаются интры.
http://www.demoscene.ru/info/article.php3?03211

Давайте на раби писать, Балмеры. Я уже всё приготовил. Tk Там же лежит. 4k intro FTW Logo FTW Черепахи FTW Win FTW

>>12009
>интро на жабе
Но зачем?.jpg

>>12050
1. Потому что писать интры прикольно.
2. Потому что писать на Си обычно значит заведомо писать в стол.

3. Писать на Си компактно и переносимо почти нереально.

4. Пункт 3 может быть немного и неправда, но сборка под вендой - сорт бубеноводства. Если бы была хотя бы одна и та же IDE у всех. Но такого не будет никогда. А предварительно собранные exe всё равно никто качать не будет же: одни параноики сейчас. Вот и получается, что "только опенсорц", только джава, только раби, только джаваскрипт. Go не подходит из соображений невозможности 4k, 64k и так далее.

Выбирая между ковырянием в носу и бесплатным обмазыванем жабой, разумные люди выбирают первое.
>Если бы была хотя бы одна и та же IDE у всех
>Сборка проекта
>IDE
Лол.
>Потому что писать на Си обычно значит заведомо писать в стол
А на жабе получается не в стол? Почему?

> >Сборка проекта
> >IDE
> Лол.
Ладно.

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

Лол, я ответил на чужой пост через 4 минуты. Надо получить жизнь.

>>12055
Я пропущу мимо глаз глупость про мертвость сишки в сравнении с жабкой.
Где можно переиспользовать код демок на джаве и нельзя на сишке?

>>12057
Я просто хочу сказать, что код на чем угодно современном можно хоть где-то использовать, а код на сишке... ну это код на сишке. Крестов уж касаться не будем, они вообще не для 4к-демок.

Сишка-код тоже можно, причем везде, но стоит ли.

>>12058
Удивительные истории вы рассказываете, молодой человек! И что джава - современный язык и что у большинства языков, оказывается, нет FFI с сишкой. Епта, даже в жабе он есть. Уродливый, как и положено.
Может вы из паралелльной вселенной? Надеюсь на это, потому как иначе вы обыкновенный дилетант, слабо разбирающийся в предмете, но strong opinion имеющий. Фу таким быть.

Алсо байтоебствовать на жабе - очень плохая идея. Серьезно.

>FFI с сишкой
Я знаю. Но обычно FFI - это боль. Да, особенно в джаве.
>дилетант
Нет, но если говорить про сишку, может быть немного.
>strong opinion имеющий
Да я так, рассуждаю.
>байтоебствовать на жабе - очень плохая идея
Я знаю. На раби тоже. Особенно в силу того, что там нет ни опенджеля, ни работы со звуком из коробки. Некоторые гемы (glfw3 или даже просто opengl), как я понял требуют mingw на венде просто для установки, а применения других (как rubygame) можно расценивать разве что как читерство, ведь в них куча всего уже готового.

Жизнь - тлен.

>>11939
Хеловорд 1.89 Мб! 1.89 Мб, Карл!

7 лет прошло, сколько микросервисов уже написали?