LINUX.ORG.RU

Релиз Go 1.1

 ,


2

7

Команда разработчиков рада сообщить о выходе новой версии языка программирования Go — 1.1.

Go — компилируемый многопоточный язык программирования, разработанный компанией Google. Первоначальная разработка Go началась в сентябре 2007 года, а его непосредственным проектированием занимались Роб Пайк и Кен Томпсон.

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

  • оптимизация компилятора и компоновщика;
  • улучшение работы сборщика мусора;
  • многочисленные улучшения в стандартной библиотеке.

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

Кроме того, есть некоторые изменения и в самом языке:

С момента выхода Go 1.0 было внесено 2600 изменений от 161 разработчика за пределами Google.

На данный момент поддержка Go осуществляется для операционных систем FreeBSD, OpenBSD, Linux, Mac OS X, Windows.

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

★★★★★

Проверено: maxcom ()
Последнее исправление: CYB3R (всего исправлений: 2)
Ответ на: комментарий от quantum-troll

Потому, что это и путь к тому же.

В сях это тоже путь. И?

Лишние типы не нужны.

Ага. Их переизобрели тут же во встроенных мапах и т.д. То что нормальные люди делают обобщенной библиотекой там закатали в компилятор. Можно мне реализацию мультимапы на Go? Ну пожалуста - я хочу посмеятся.

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

Это фейспалм полный. Как с точки зрения чтения так и с точки зрения execution flow. А уже оптимизатор наверное вообще вешается.

Тебя удивляет множественное присваивание?

Меня удивляет необзодимость стопицотпервого очередного синтаксиса присваивания.

Параметриков не сделали - зато решение детских проблем в полный рост.

Почему бы и нет?

Это лозунг го. Не «нужно потому что». А «почему бы и нет».

ну ты понял.

Ага. Главное таплов не изобретать. Лучше if и case поправить. Хочу видеть в цвете например аналог этого:

do
x <- might_return_error(1),
y <- might_return_error(x),
z <- might_return_error(y),
return z

Какой специальный синтаксис? Есть массивы, есть срезы, в чём проблема?

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

range в случае срезов и массивов — не более, чем синтаксический сахар.

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

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

Потому что главное было скобки вырезать и кейвордов напихать. Знаем.

С твоим узким восприятием только ЛСД и поможет.

Узким? что там воспринимать? ТАм же нет ничего. И тормозит как жаба.

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

Как с точки зрения чтения так и с точки зрения execution flow. А уже оптимизатор наверное вообще вешается.

С точки зрения чтения си++-утятами? Наверное.
А про трудности оптимизации расскажи.

Главное таплов не изобретать.

Кортежи есть в Limbo, предшественнике го, если ты не знал. Видимо, выпилили за ненадобность.

В том что я хочу мою собственную коллекцию с таким же синтаксисом вызова.
Как мне сделать range например по дереву моей собственной реализации?

http://research.swtch.com/generic
Давай ещё раз: генерики или их отсутствие или ТОРМОЗЯТ, или ТОРМОЗЯТ, или ТОРМОЗЯТ. Разница лишь в том, что именно.
И да, вопрос с генериками до сих пор открыт.

кейвордов напихать

В го кейвордов ещё меньше, чем в си, не говоря уже про другие языки.

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

С точки зрения чтения си++-утятами?

Нет не C++ утятами. А с точки зрения адеекватными людьми у которых голова действует адекватно - «куда показывают туда и поворачивают».

пример (псевда).

[code]
два named results.

result1 = 0
result2 = 0

if (condition1)
result1 = 1
if (codnition2)
result2 = 2

.....

if (codition3) return
.....

[/code]

Что будет в if(codition3) возвращено? И скажи мне что это - не наркоманство.

Видимо, выпилили за ненадобность.
ненадобность.

facepalm А что это чуть ли не в каждом if с ok?

Уже придумал эквивалент do notation?

А как мне передать результат функции f в функцию g если результат по количеству не соответствует сигнатуре? Никак?

Давай ещё раз: генерики или их отсутствие или ТОРМОЗЯТ, или ТОРМОЗЯТ, или ТОРМОЗЯТ

Бред сивой кобылы. Отсутствие генериков влияет только на статическую проверку. В условии отсутствие генериков ты получаешь или кастинг - что просто ошибки.

В го кейвордов ещё меньше, чем в си

НУ да. Сделаем new и make «системными функциями» и сделаем вид что это не кейворды.

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

Что будет в if(codition3) возвращено? И скажи мне что это - не наркоманство.

Замени присваивание сверху на определение, а return на return result1, result2, и получишь то же самое, но без использования named results. Полно подобного и в обычной сишке.

Отсутствие генериков влияет только на статическую проверку

Я не только про, читай статью же.

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

Полно подобного и в обычной сишке.

Не «полно» а только в случаях сбора некоего результата по частям. И в ретурне очевидно что он что-то возвращает.

И твой аргумент работает в сторону «не нужно». Это не короче не проще вообще никакого преймущества не имеет кроме обфускации кода вроде «это просто ретурн или там гдето таки что-то вернется»?

Зачем?!?

Я не только про, читай статью же.

Читал я эту статью. Они обвиняют генерики в боксинге - что вообще только косвенно связано. И еще пускай откроют для себя http://www.scala-notes.org/2011/04/specializing-for-primitive-types

Если тебе надо экстремально быстрая коллекция с примитивами - в язке с генериками не проблема такую написать. Если в языке нет генериков - это большая проблема.

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

В сях это тоже путь. И?

И в сях он тоже в кавычках. Ну или в скобках, да.

Можно мне реализацию мультимапы на Go? Ну пожалуста - я хочу посмеятся.

Мультимапы? Что-то типа map[int]map[string][]byte ? Или недостаточно смешно?

Это фейспалм полный.

Ну так не используй их - выше возможность не использовать 80% плюсов была представлена, как охренительное преимущество.

Меня удивляет необзодимость стопицотпервого очередного синтаксиса присваивания.

Простой и понятный синтаксис. Не можешь запомнить? Сложно набирать? Попей витаминчиков, авось полегчает.

Это лозунг го. Не «нужно потому что». А «почему бы и нет».

Как раз таки лозунг го - «почему бы не выкинуть ещё что-нибудь».

Хочу видеть в цвете например аналог этого:

func do() (int, error) {
	if x, err := might_return_error(1); err != nil {
		return 0, err
	}
	if y, err := might_return_error(x); err != nil {
		return 0, err
	}
	return might_return_error(y)
}

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

А потом пользователи сидят и думают, чего это обращение к элементу массива в базу лезет.

Как мне сделать range например по дереву моей собственной реализации? Писать на каком нибудь другом языке?

Специально для твоих деревьев gof придумали итератор, чтоб люди знали, с чем имеют дело. А то у некоторых вон побитовый сдвиг в файлы дует. Впрочем, range ещё и каналы умеет, так что если очень хочется, можно изобразить что-то подобное:

type MyItem int
type MyCollection []MyItem

func (m MyCollection) Items() chan MyItem {
	c := make(chan MyItem)
	go func() {
		for _, i := range m {
			c <- i
		}
	}()
	return c
}
Laz ★★★★★
()
Ответ на: комментарий от r

Это не короче не проще

На практике это именно что короче и проще, и в исходниках го используется часто.

это просто ретурн или там гдето таки что-то вернется

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

Eсли в языке нет генериков - это большая проблема.

Никто не спорит с этим, тема генериков довольно часто поднимается на golang-nuts. Рано или поздно, но их запилят, но пока что это открытый вопрос.

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

По твоей ссылке херня написана в части java. Коллекция байтов - это наркомания. Чем в рантаме коллекция ссылок на Object будет медленнее коллекции ссылок на MyObject - непонятно. Для примитивов есть специализированные коллекции полностью совместимые со стандартными, но без боксинга - fastutil. У java generic'ов единственный минус - типа в рантайме не знаешь, про скорость это из пальца высосано.

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

или ТОРМОЗЯТ, или ТОРМОЗЯТ, или ТОРМОЗЯТ

И программист может выбрать одно из трёх либо ничего. Но не в го.

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

И в сях он тоже в кавычках. Ну или в скобках, да.

Ну или в скобках, да.

Что-то типа map[int]map[string][]byte ? Или недостаточно смешно?

Нет.

Ну так не используй их

Мы про качество языка. Я го пользовать не буду точно. Потому что там ровно ничего _хорошего_ нет. Если придется пользоваться заменителем С++ - пока выигрывает rust.

Простой и понятный синтаксис.

Главное для такой мегафичи было язык создавать. Бенжамин Пирс и люди изобретающие разные effect systems и higher kinded types рвут на себе волосы. Одерский готовиться кончить житзнь самоубийством - ему надо было не HKT заниматься а очередной вариант присваивания изобрести.

func do() (int, error) {

во первых работать не будет потому что x, y, z вне скоупа - для этого эти инициализаторы и изобрели. Во вторых - спосибо поржал.

А потом пользователи сидят и думают, чего это обращение к элементу массива в базу лезет.

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

Впрочем, range ещё и каналы умеет, так что если очень хочется, можно изобразить что-то подобное:

«А потом пользователи сидят и думаю как это обход дерева пошел через CSP...» ага - чтобы жизнь малной не казалась...

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

На практике это именно что короче и проще, и в исходниках го используется часто.

Ну да return x сильно сложнее return.

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

Я го пользовать не буду точно.

Это обнадёживает.

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

Ну зачем же? Пусть изобретают на здоровье. А мы пока код писать будем.

во первых работать не будет потому что x, y, z вне скоупа - для этого эти инициализаторы и изобрели. Во вторых - спосибо поржал.

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

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

Пользователи библиотеки, читатели кода, ты сам через n дней.

«А потом пользователи сидят и думаю как это обход дерева пошел через CSP...»

Если что, синтаксис range для слайсов/массивов и для каналов различается, так что незаметно подменить одно другим таки не выйдет, не надейся.

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

А мы пока код писать будем.

Код можно писать на чем угодно. Мне нервов жалко.

где там скоупы, где инициализаторы, нипанятна.

Гошная часть работать не будет.

Пользователи библиотеки

Пользователи будут радоваться что они могут передать что массив что итератор по базе в одни и теже функции и все работает.

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

Я не про незаметно я про через одно место. Или думаешь обход структур через CSP совсем совсем не влияет на производительность?

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

Гошная часть работать не будет.

Действительно.

Пользователи будут радоваться что они могут передать что массив что итератор по базе в одни и теже функции и все работает.

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

что массив что итератор

А ничего, что массив и итератор - это принципиально разные вещи?

Я не про незаметно я про через одно место. Или думаешь обход структур через CSP совсем совсем не влияет на производительность?

Не знаю, не мерял. Если нужно обходить структуры, я использую итераторы, про которые и написал изначально. Но тебе же, помнится, хотелось range любой ценой.

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

Типа такого.

А массив и мапа с апи применемым к ним смотит на твой интерфейс....

А ничего, что массив и итератор - это принципиально разные вещи?

А куча фреймворков в других языках и не знает.

Но тебе же, помнится, хотелось range любой ценой.

Мне хотелось унификацию. Если ее нет - кто-то начнет изобретать буст - или будет колоться как ежик.

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