LINUX.ORG.RU

Go 1.9

 


1

6

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

Наиболее важным изменением языка является введение псевдонимов типов. Объявление псевдонима типа выглядит следующим образом:

type T1 = T2

Это объявление вводит псевдоним Т1 для типа Т2, таким же образом, как byte всегда был псевдонимом для uint8. Дизайн-документ псевдонимов типов и статья о рефакторинге объясняют это дополнение более детально.

Новый пакет math/bits предоставляет функции подсчета и обработки битов для целых беззнаковых чисел, которые, когда это возможно, реализуются специальными инструкциями CPU. Например, в системах x86-64 bits.TrailingZeros(x) использует инструкцию BSF.

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

В пакет testing также добавлено дополнение. Новый метод Helper, добавленный к testing.T и testing.B, отмечает вызывающую функцию в качестве тестовой вспомогательной функции. Когда тестовый пакет печатает информацию о файле и строке, он показывает местоположение вызова вспомогательной функции вместо строки в самой вспомогательной функции.

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

Наконец, в рамках усилий, направленных на ускорение работы компилятора, Go 1.9 компилирует функции в пакете одновременно.

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

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

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



Проверено: Klymedy ()
Последнее исправление: Klymedy (всего исправлений: 3)

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

что бы примитивные формы жизни

Ясно.

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

что бы примитивные формы жизни смогли его осилить

ты переоцениваешь сложность дженериков. Их в Го нет, потому что уже хватает сущностей которые заменяют их. Цель языка в том чтобы убрать все лишнее. На примитивных форм больше походят нытики, которые без дженериков программировать не могут,фантазии не хватает

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

Ну так и есть языки для таких задач, в которых наследование есть. Я же про опыт в общем и целом.

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

Не я, а разработчики Go, если я конечно не наткнулся на какую-то ложь, чему в общем то не удивлюсь. А я вот что-то подумал о сущностях заменяющих дженерики... В Go же возможно унаследовать один _интерфейс_ от нескольких других? Если да, то я тогда могу понять отсутствие дженериков.

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

унаследовать

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

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

Я не о том наследовании. Да, композиция - это то что я подразумевал. То есть если у меня есть интерфейсы A, B, а так же «пустой» C: A, B, то все структуры, которые имплементируют A и B, автоматически имплементируют C? Если так, то это объясняет отсутствие дженериков.

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

А болезные всё о любимой теме. Казалось бы, каким образом Го соотносится с геями в воспалённом мозгу шизика.

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

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

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

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

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

NoviceNIX
()

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

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

Все нормально там с обработкой ошибок. То есть не хорошо и не плохо. Как и в других языках. Есть плюсы, есть минусы. Честно, не знаю языков с ОЧЕНЬ КЛАССНОЙ обработкой ошибок.

Поищи статью Пайка про обработку ошибок в го. Этого достаточно, чтоб понять, насколько всё плохо. Если автор языка объясняет, как, написав совсем немного кода, заменить идиоматическую обработку ошибок на старый добрый errno, то это прямо таки чистосердечное признание.

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

c := erc.Run(MyFunc, a, b)
или
c :=
erc.Run(() => MyFunc(a, b)) 

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

Ошибки нужно обрабатывать там, где они возникают

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

Я цитирую «Совершенный код». Что цитируешь ты?

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

А своя голова на плечах есть? Почему какой-то совершенный код должен её заменить? Ошибку можно обработать только там, где есть некий разумный способ на неё отреагировать. Вот ошибка выхода индекса за пределы массива где возникает? Очевидно, в операции индексации. Как вы её обработаете?

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

Как раз таки Try/Result не нужен. Что нужно:

1. Стектрейс. 2. Нормальный базовый класс ошибки с возможностью формирования цепочки ошибок.

В принципе основные проблемы решены в https://github.com/pkg/errors но проблема в том, что это не официальная библиотека, которая не может автоматически добавить те же стектрейсы в ошибки из стандартной библиотеки.

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

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

Если сравнивать с исключениями, то писать код дольше, зато runtime ошибок намного меньше.

Runtime ошибок не может быть меньше. Их столько, сколько возникает. Если их меньше, значит какие-то заметают метлой под полку. Это просто делать в Go, согласен, но это не решение проблемы.

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

А в Go если забудут обработать ошибку, трейс читать не придётся, его же нет и ошибки нет. Просто что-то не так работает. :)

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

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

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

Все нормально там с обработкой ошибок. То есть не хорошо и не плохо. Как и в других языках. Есть плюсы, есть минусы. Честно, не знаю языков с ОЧЕНЬ КЛАССНОЙ обработкой ошибок.

Очень классная обработка ошибок это unchecked исключения. Python, Java без checked исключений. Это пик развития компьютерной науки. А коды ошибок в любом виде это откат назад.

Что это ещё за утверждение такое? Какие ещё ошибки в каждой строчке? Если писать код как обезьяна, то в любом языке в каждой строчке будут ошибки.

А ты точно на Go писал? Вот тебе фрагмент реального кода:

	data, err := ioutil.ReadAll(os.Stdin)
	if err != nil {
		return errors.Wrap(err, "read stdin")
	}
	block, _ := pem.Decode(data)
	if block == nil {
		return errors.New("PEM block not found in stdin")
	}
	crt, err := x509.ParseCertificate(block.Bytes)
	if err != nil {
		return errors.Wrap(err, "parse X.509 certificate")
	}

На 3 строчки кода 9 строчек мусорного кода, не добавляющего никакого функционала.

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

А своя голова на плечах есть?

Переход на личности? Плохая идея.

В моей голове только мой опыт.

Почему какой-то совершенный код должен её заменить?

Автор аккумулировал опыт сотен экспертов по программированию.

Очевидно, они лучше меня и тебя разбираются в этом.

Вот ошибка выхода индекса за пределы массива где возникает?

Там, где длина массива не проверяется.

Повторюсь, чем раньше будет обработана ошибка, тем лучше.

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

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

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

Runtime ошибок может быть меньше, если компилятор проверяет compile time. А это именно тот случай. Никто ничего не заметает.

Если функция что-то возвращает, то обычно можно только сознательно проигнорировать ошибку, но не забыть. Если возвращает только error, то go vet и компания умеет сообщать, что забыли проверить ошибку.

Кстати, стектрейсы в go тоже есть, но большинство ошибок отлавливается на стадии компиляции.

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

Davidov ★★★★
()
Последнее исправление: Davidov (всего исправлений: 1)
Ответ на: комментарий от Dred

На примитивных форм больше походят нытики, которые без дженериков программировать не могут,фантазии не хватает

Нет, просто нытикам страшно представить, как они пишут что-то вроде:

collection SomeUsableCollection
GetNumbers(collection)

sum := 0
for i := 0; i < collection.size(); i++ {
    a, ok := collection.get(i).(int)
    if (!ok) {
        return
    }
    sum += a
}
Esper
()
Ответ на: комментарий от Legioner

Не так уж часто они и нужны, а когда нужны, можно что-нибудь придумать

Стокгольмский синдром?

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

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

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

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

Runtime ошибок может быть меньше, если компилятор проверяет compile time. А это именно тот случай. Никто ничего не заметает.

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

Если функция что-то возвращает, то можно только сознательно проигнорировать ошибку, но не забыть. Если возвращает только error, то go vet и компания умеет сообщать, что забыли проверить ошибку.

Ну-да, ну-да.

% cat main.go
package main

import (
	"fmt"
)

func main() {
	fmt.Println("Hello, World!")
}
% go vet main.go
% 

func Println(a ...interface{}) (n int, err error) Println formats using the default formats for its operands and writes to standard output. Spaces are always added between operands and a newline is appended. It returns the number of bytes written and any write error encountered.

Кстати, стектрейсы в go тоже есть, но большинство ошибок отлавливается на стадии компиляции.

У ошибок нет привязанного стектрейса.

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

Поигрался, говорю исходя их опыта. Про плюсы не спорю, плюсов хватает. Минусов тоже.

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

Все нормально там с обработкой ошибок. То есть не хорошо и не плохо. Как и в других языках. Есть плюсы, есть минусы. Честно, не знаю языков с ОЧЕНЬ КЛАССНОЙ обработкой ошибок.

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

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

Самое внезапное, что в стандартной библиотеке они есть, но больше их нигде нет.

NextGenenration ★★
()
Последнее исправление: NextGenenration (всего исправлений: 1)
Ответ на: комментарий от Dred

простенький без подводных камней в виде сахара

О_О

учится за неделю

Что означает что код гуру go будет не намного лучше того кто выучил его неделю назад

не надо возиться чтобы завести многопоточность

А где надо возится? Что на C#, что на rust, что на ... для многопоточности не нужно кучу букв

Отлично подходит для домашних задач для которых окажется мало питона

Заменим одно уг другим уг

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

дженерики просят те, кто не может придумать как придраться к Го (а могли бы к рантайму например), обычно они не знают что там даже классов нету

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

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

ты переоцениваешь сложность дженериков. Их в Го нет, потому что уже хватает сущностей которые заменяют их. Цель языка в том чтобы убрать все лишнее. На примитивных форм больше походят нытики, которые без дженериков программировать не могут,фантазии не хватает

Любишь копипастить код и заменять типы?

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

Ошибки нужно обрабатывать там, где они возникают

Я цитирую «Совершенный код»

Возникла ошибка в библиотеке, от того что её вызвали с неверными параметрами. Где нужно обрабатывать эту ошибку?

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

Для таких редких случаев существует уже несколько генераторов кода на замену дженерикам

Да здравствует препроцессор для go!

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

Если функция что-то возвращает, то обычно можно только сознательно проигнорировать ошибку, но не забыть

f, err := os.Open()
if err != nil {
	fmt.Println(err)
}
f.DoSomething()

Это когда обнаружится - во время выполнения или компиляции?

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

Какие это ошибки компилятор в Go проверяет в отличие от других языков?

Multiple-value in single-value context и unused variable. То есть если функция возвращает что-то важное и err, то забыть про ошибку практически невозможно.

Ну-да, ну-да.

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

У ошибок нет привязанного стектрейса

Вроде panic выдает трейс, всякие проблемы с тредами вроде тоже. Если error нормально обработался, трейс ему и не нужен.

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

Если уж так говорить, то в Go скорее больше ошибок, чем меньше,

нет, в 15-ом году у меня было 0 опыта в жабе и го. Ошибок в го коде было на порядок меньше чем в джаве, как раз за счёт обработки их на месте (в основном NPE).

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

Это подтверждается практикой использования: несмотря на примитивность системы типов правильный Го-код содержит меньшее число ошибок чем популярные языки прошлого поколения: Java, C#, D и т.д.

ЗЫ доставляют «программисты» боящиеся пары лишних строчек. Советую подумать о выборе профессии.

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

Joe_Bishop
()
Последнее исправление: Joe_Bishop (всего исправлений: 1)
Ответ на: комментарий от MLP_Fan

все равно куча народу обходится без дженериков

А куда они денутся? Язык неизбежно накладывает отпечаток на то как будут писать код.

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

@makoven

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

Например? Как я полагаю, наследование не нужно в принципе.

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

ЗЫ доставляют «программисты» боящиеся пары лишних строчек. Советую подумать о выборе профессии.

Они не устраивались наборщиками текста. или тебе за количество строк платят?

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

Не умеешь пользоваться наследованием?

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

разверни мысль, @Joe_Bishop

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

anonymous
()

Наиболее важным изменением языка является введение псевдонимов типов

Через сколько лет догонит по сложности кресты?

Это объявление вводит псевдоним Т1 для типа Т2, таким же образом, как byte всегда был псевдонимом для uint8

Зачем? Неужели так трудно запомнить что uint8 это и есть беззнаковая переменная длиной в один байт?

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

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

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

То что даже крайне кривым инструментом можно зарабатывать деньги

Окей. Тут все поняли, что кривым инструментом назван Го. Чем не предпосылка для холивара? Но мне как-то лень. Не сегодня, а.

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