Опубликован выпуск «Learning Go» 0.3

> Ты разберись, нужно сервер написать или POSIX API освоить.

Речь сразу шла про SMTP-сервер. У него не очень фантастически сложная логика работы.

И что?

И в этом отличие от SMTP.

в С# нет RAII, так что сиди унылый и не гавкай

ну вот, скатились на оскорбления... и только потому что у меня ДРУГОЕ мнение, я например считаю что нельзя оценивать языки по наличию отсутствию каких бы то ни было фишек, в Java нет unsigned и нет properties, но это не значит что это сводит остальные плюсы к абсолютному нулю

> Речь сразу шла про SMTP-сервер. У него не очень фантастически сложная логика работы.

Правда? А sendmail - это не SMTP-сервер? Если же речь шла об _учебном_ SMTP-сервере, то это как раз хелловорлд.

The focus of the project is on integrity over performance. (c) Wikipedia

И что?

И в этом отличие от SMTP.

Сравнение сервера с протоколом, какая прелесть. Не говоря уже о том, что «integrity over performance» в Monotone относится к дизайну структур данных, а не ее сетевого сервера.

Это не удивительно. Приходи, когда узнаешь весь.

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

Это то как я понял. На самом деле избавляет от всех этих лишних implements BlahBlah, если и так понятно — все методы есть значит имплементирует.

Про duck typing они вроде бы это где-то писали, но я уже не помню где

О! Вспомнил ещё ултимэйт штуку!! Там нету явных спецификаторов доступа.

func MegaFunction(){ // это public функция, будет видна за пределами пакета
}

func notSoMega() { // это private функция
}

Компилятор решает public это или private в зависимости от того с большой буквы написано название переменной/функции/метода или нет.

> Компилятор решает public это или private в зависимости от того с большой буквы написано название переменной/функции/метода или нет.

Классный язык, чо.

public это или private в зависимости от того с большой буквы написано название

Вообще-то синтаксис go должен вызывать лютый баттхёрт, ещё почище питоновских отступов. Они убрали большинство тем для холиворов: открывающая скобка на той же строке и gofmt как единственно верный вариант написания кода — это вам не PEP8.

> ну вот, скатились на оскорбления... и только потому что у меня ДРУГОЕ мнение, я например считаю что нельзя оценивать языки по наличию отсутствию каких бы то ни было фишек, в Java нет unsigned и нет properties, но это не значит что это сводит остальные плюсы к абсолютному нулю

а я вот например щитаю что многие вещщи стОит сравнивать по отсутствию тех или иных возможностей :-)

...так как если какаято важная особенность отсутствует — то зачастую именно она и оказывается наиболее недостоющщей

тут как обычно всё сводится к: http://bit.ly/eeDLwY (wikipedia.org/Закон_ограничивающего_фактора)

возьмём простой пример:

например в Java (до версии 8) — отсутствовали замыкания [да, да, все мы помним про анонимные классы, но чтобы их оформить приходилось использовать кучу синтаксического мусора!] — думаю и именно отсутствие замыканий снизило популярность Явы в то время :-)

в то время как Javascript (jQuery) уже позвалял делать:

$('li').each(function(index) {
    alert(index + ': ' + $(this).text());
});

когда (в январе 2013 года) — вышла OpenJDK 8 — она уже так и не смогла набрать упущенную популярность! оно и ясно... :-)

> Компилятор решает public это или private в зависимости от того с большой буквы написано название переменной/функции/метода или нет.

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

:-/ :-)

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

> замыкания, от их наличия/отсутствия ни холодно ни жарко

дружочек, какую глупость ты пишешь!

> Правда? А sendmail - это не SMTP-сервер?

А что там сложного в логике, собсно? Там по-моему сложно понять «что хотел сказать автор». Пять уровней вложенности, функции по 700+ строк, произвольные гоуту и т.д. Да, я не уверен, что авторам sendmail поможет C++ или иной язык. Там всё плохо^W пид^W оптимально.

Если же речь шла об _учебном_ SMTP-сервере, то это как раз хелловорлд.

В учебных smtp-серверах у нас примерно всё тоже самое, только хуже, меньше и обычно понятнее. В них функции выделяют, например. И не делают свои map, в отличие от.

Сравнение сервера с протоколом, какая прелесть.

Мне просто надоело писать "-сервер", я полагаю это ясно из контекста.

> Компилятор решает public это или private в зависимости от того с большой буквы написано название переменной/функции/метода или нет.

ужасно.

Напыщенного быдла на ЛОР'е всегда валом.

>> Правда? А sendmail - это не SMTP-сервер?

А что там сложного в логике, собсно?

То есть с точки зрения программной логики там всё просто, я правильно понял? А сточки зрения структур данных - тоже?

Сравнение сервера с протоколом, какая прелесть.

Мне просто надоело писать "-сервер", я полагаю это ясно из контекста.

Не ясно и никак не вытекает. Процитирую себя же: «integrity over performance» в Monotone относится к дизайну структур данных, а не ее сетевого сервера.

замыкания, OpenJDK 8, 2013

Да вы, батенька, махровый оптимист.

дружочек, какую глупость ты пишешь!

это всего лишь удобство, некоторое сокращение кода, не более того - будешь с этим спорить? есть - хорошо, нет - жаль

это всего лишь удобство, некоторое сокращение кода, не более того

Ага, то-то жабисты табунами валят на груви и скалу.

Ага, то-то жабисты табунами валят на груви и скалу.

смотря какие проекты писать, кто спорит что это плюс языка? если такие конструкции встречаются на каждой десятой строчке то еще можно понять

Во! Вспомнил ещё одну офигительную штуку — оператор defer. Он позволяет указать код, который должен быть вызван в любом случае при выходе из функции. Пример:

func CopyFile(dstName, srcName string) (written int64, err os.Error) {
    src, err := os.Open(srcName, os.O_RDONLY, 0)
    if err != nil {
        return
    }
    defer src.Close()
 
    dst, err := os.Open(dstName, os.O_WRONLY|os.O_CREATE, 0644)
    if err != nil {
        return // тут будет вызван src.Close()
    }
    defer dst.Close()
 
    return io.Copy(dst, src) // Тут будут вызваны src.Close(), dst.Close() (именно в этом порядке)
}

смотря какие проекты писать,

Если отвлечься от реалий, связанных с работой, то java, как язык, сейчас может нравиться только очень недалёким людям.

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

Под «сложно» я всегда понимал что-то не проще «хитрых методов анализа КС-языков», типа Грахам сотоварищи. В sendmail местами в логике хочется немного убить автора, это мешает понять сложность логики. В теории она вся вытекает из RFCs и желания чтобы работало быстро и не было голодания. Я что-то радикально не понимаю?

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

А сточки зрения структур данных - тоже?

Структуры там, к счастью расписаны даже понятно, не вижу пока ничего чудовищного.

На текущий момент главное замеченное мною отличие сурсов монотона и сендмайла --- это «первые не боялись выделять функции», а не замена goto на try. ООП, для которого не достаточно было бы С, я вижу довольно эпизодически в монотоне.

Ну это ты как программист явно мыслишь, а не скажем HR. %))

оператор defer

Это всё от безисключительности go. Обработка ошибок в Си-стиле, возведённая до абсурда.

Мне в go нравится только реализация интерфейсов. Всё остальное вызывает WTF!!?? — пердуны реализовали свои юношеские мечты.

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

Если не обращать внимания на слово google, то язык в текущем своём виде и реализации совершенно не катит на замену существующих решений.

Ну это ты как программист явно мыслишь, а не скажем HR

Любитель микрософта явно не из последних.

> Вот Scala, например, мне интересна. Гибриды вообще рулят.

Мне Scala интересна тем, что на ней не так противно писать под Java-платформу, как на самой жабе.

ИМХО, большой минус гибридов, и Scala в частности, в том, что они излишне сложны.

http://harmful.cat-v.org/software/dynamic-linking/
Всё правильно сделали.

> А Go? ":=" - зачем?
Чтобы не писать ClassName classname = new(ClassName); // Classname Classname Classname
Очевидно же!

> Гибриды вообще рулят.
Ещё одни любители комбайнов?

Насчёт «не нужен»... Требуется императивный ЯП, который умеет:
- CSP
- Нормальную систему типов наподобие той, что есть в хаскеле, а не костыли вроде ООП и уж тем более не извращенские костыли вроде Си++ ООП
- Маленькая и достаточно быстрая реализация
- Компилируемость
Если вы знаете ещё один такой — скажите же!

Требуется императивный ЯП, который умеет:...

ocaml

Нормальную систему типов наподобие той, что есть в хаскеле

Причем здесь go непонятно совершенно.

Всё правильно сделали.

Чтобы не сделать динамическую линковку ничего делать не надо, внезапно. И да, я посмотрю на тебя, когда любой grep, cat или find будет весить по мегабайту с хвостом.

> Возможно, я храбрый после этого.

Пока что ты храбро уклоняешься от прямых ответов.

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

Мде. Для протокола - для любого ООП достаточно Си. Более того, на Си можно написать всё.

> я посмотрю на тебя, когда любой grep, cat или find будет весить по мегабайту с хвостом.

Аудитория cat-v.org такиъ вещей не страшится. У них большие... диски. И правильные libc.

> Требуется императивный ЯП, который умеет:...

Haskell - лучший императивный ЯП.

(c) Simon PJ

Ну еще бы SPJ сказал что-то другое.

1) Вы действительно вбросили
2) В Vala есть смысл и предназначение, в Go он отсутствует

2) В Vala есть смысл и предназначение, в Go он отсутствует

признаю что был не прав, почитал про Vala, все-таки язык очень мощный, только очень смущает его область применимости

например, в Mono подкупает факт независимости от ОС и архитектуры процессора (уж простите что с языка перешел на сравнение платформ), при мощном языке

но можно ли создавать ОС/процессоро-независимые бинарники, если пишешь на Vala? мне показалось это очень неприятным, что таким важным пунктом поступились и даже как я вижу не предусмотрели возможность доразвития этих «способностей» в будущем - я ошибаюсь?

> почитал про Vala, все-таки язык очень мощный

Это ты еще о нормальных языках не читал...

но можно ли создавать ОС/процессоро-независимые бинарники, если пишешь на Vala?

...но, с другой стороны, ты и о Vala читал как-то странно. Ответ на твой вопрос - «нет».

>IDisposable и using

Неудобно же очень

>но можно ли создавать ОС/процессоро-независимые бинарники, если пишешь на C#?

fixed.

>но можно ли создавать ОС/процессоро-независимые бинарники, если пишешь на C#? fixed.

Мой личный опыт показывает что ДА.

>>IDisposable и using

>Неудобно же очень

Напротив, RAII по сравнению с этим выглядит как костыль, завязанный на особенности работы плюсовых конструкторов и деструкторов. Подмена одного другим.

>Мой личный опыт показывает что ДА.

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

>Напротив, RAII по сравнению с этим выглядит как костыль, завязанный на особенности работы плюсовых конструкторов и деструкторов. Подмена одного другим.

И как тебе про ocaml после такого верить. Если ты решишь какой-нибудь тип сделать IDisposable, то тебе придется _все_ типы, которые включают данный, тоже делать IDisposable и в каждом писать однообразные простынки Dispose. Тоже самое для всех типов, включающих в себя любой из данных типов. Лавинообразные правки по всему проекту. Куда уж тут костылям плюсов, до такого coupling'а. Потом надо просмотреть все вхождения поправленных типов и при необходимости вкорячивать using. Заодно возникает вопрос, зачем нужен GC, если кругом ручные using, а забудешь где-нибудь using - получишь утечку ресурсов. Ну и то, что Dispose не завязан на уничтожение объекта и, следовательно, вполне возможен доступ к disposed-объектам со всеми вытекающими - это выглядит логическим завершением всего предыдущего беспредела.

Мне кажется, что ты выдумываешь. На практике не встречал огромных вложенных объектов, реализующих IDisposable. Не припомню такого. Все обычно ограничивается небольшим набором классов. Чаще всего, стандартных. Хотя, если увлекаться ООП... Да, еще в WinForms через чур увлекались использованием IDisposable. Но в WPF и Silverlight этого наследия старого строя уже нет.

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

>Мне кажется, что ты выдумываешь.

Мне кажется ты просто с этим не сталкивался в реальности - отсюда этот восторг. Это страшная история из жизни. При портировании на 64 бита выяснилось, что шарповые массивы ограничены 2Gb. Пришлось написать LongArray< T >, который юзал VirtualAlloc, и, естественно был IDisposable. По интерфейсу он практически не отличался от обычного массива и в плюсах бы все на этом закончилось, а в шарпе только началось. Grid, разнообразные кубы данных - и понеслось.

Хотя, если увлекаться ООП

При чем тут ООП, я про включение, а не наследование.

Не совсем хорошо, но все же лучше, чем реальная утечка памяти в си или плюсах.

Иллюзия. В C++ у тебя тоже память отдастся системе после завершения процесса. Вообще, если у тебя 8Гб вовремя не отдалось или нужный файл не отпустился - это ничем не лучше.

Где и когда он устоялся??? Правда и будущее за Си-подобными языками... Их юзает большинство.

Хотя язык Go мне и не нравится, но ваша позиция мне не нравится существенно больше. Вот неандертальцы тоже утверждали, что «будущее за каменными топорами, так как ими пользуется большинство», но неожиданно вымерли.

И да, как замена C D или vala подходят существенно лучше, как по концепции, так и по дизайну и реализации, не говоря о наборе библиотек (но это дело наживное).