LINUX.ORG.RU

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

 ,


0

3

Язык Go ещё очень молод и динамично развивается. Несмотря на то, что язык отлично документирован на golang.org, чувствуется недостаток книг.

На сегодняшний день «Learning Go» — наиболее объёмная книга по этому перспективному языку программирования, хотя, как пишет автор, Miek Gieben, это скорее слепок текущего состояния, чем её финальная версия.

Скачать

>>> Подробности



Проверено: JB ()
Последнее исправление: Dendy (всего исправлений: 2)

Ответ на: комментарий от tailgunner

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

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

И что?

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

sv75 ★★★★★
()
Ответ на: комментарий от ckotinko

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

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

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от sv75

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

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

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

И что?

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от sv75

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

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

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

mors
()
Ответ на: комментарий от pevzi

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

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

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

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

mors
()
Ответ на: комментарий от mors

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от mors

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

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

baverman ★★★
()
Ответ на: комментарий от I-Love-Microsoft

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

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

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

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

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

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

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

$('li').each(function(index) {
    alert(index + ': ' + $(this).text());
});
-- можно только представить — сколькобы аналогичная Java-конструкция заняла-бы синтаксического мусора в коде :-D

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

user_id_68054 ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

:-/ :-)

user_id_68054 ★★★★★
()
Ответ на: комментарий от user_id_68054

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

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

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

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

anonymous
()
Ответ на: комментарий от tailgunner

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

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

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

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

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

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

sv75 ★★★★★
()
Ответ на: комментарий от mors

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

ужасно.

sv75 ★★★★★
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от sv75

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

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

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

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от user_id_68054

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

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

baverman ★★★
()
Ответ на: комментарий от anonymous

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

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

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

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

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

baverman ★★★
()
Ответ на: комментарий от baverman

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

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

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от baverman

Во! Вспомнил ещё одну офигительную штуку — оператор 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() (именно в этом порядке)
}

mors
()
Ответ на: комментарий от I-Love-Microsoft

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

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

baverman ★★★
()
Ответ на: комментарий от tailgunner

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

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

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

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

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

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

sv75 ★★★★★
()
Ответ на: комментарий от mors

оператор defer

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

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

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

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

baverman ★★★
()
Ответ на: комментарий от sv75

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

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

baverman ★★★
()
Ответ на: комментарий от Zenom

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

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

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

pitekantrop ★★★
()
Ответ на: комментарий от I-Love-Microsoft

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

quantum-troll ★★★★★
()

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

quantum-troll ★★★★★
()
Ответ на: комментарий от quantum-troll

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

ocaml

baverman ★★★
()
Ответ на: комментарий от quantum-troll

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

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

baverman ★★★
()
Ответ на: комментарий от quantum-troll

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

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

baverman ★★★
()
Ответ на: комментарий от sv75

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

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от baverman

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от X-Pilot

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

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

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

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

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

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

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

>>IDisposable и using

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

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

dave ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

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

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

anonymous
()
Ответ на: комментарий от dave

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

dave ★★★★★
()
Ответ на: комментарий от dave

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от I-Love-Microsoft

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

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

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

Vudod ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.