LINUX.ORG.RU

Go 1.13

 


1

5

Вышел язык программирования Go 1.13, основные нововведения:

  • Язык Go теперь поддерживает более унифицированный и модернизированный набор префиксов числовых литералов, в том числе для двоичных, восьмеричных, шестнадцатеричных и мнимых литералов.
  • Совместимость с Android 10.
  • Поддержка TLS 1.3 включена по умолчанию в пакете crypto/tls.
  • Поддержка Error wrapping.
  • Unicode 11.0 теперь доступен из пакета Go Unicode.

Это последний выпуск, который будет работать на Native Client (NaCl).

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

★★

Проверено: Shaman007 ()

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

Они, наверное, имели в виду что-то типа

try {
} catch (Exception e) {
  // здесь ничего не делаем
}
кстати, вы будете смеяться, но у меня именно вот такой код сейчас на втором мониторе, из java проекта, который я починяю :)

Но ведь и в go так можно:

result, _ = foo()

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

Не понимаю откуда столько сарказма, так и есть - это явно говорит нам об ошибке в контракте и заставляет где-то ее обработать, или проигнорить со знанием дела, или добавить контекста ошибке. Зависит от нужд проекта. Что тут не так то?

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

Мне думается что они никогда вообще никаких программ не писали. Либо там с обработкой ошибок было всё плохо.

Но ты же понимаешь, что нередко бывает, что правильным в таких случаях будет просто убрать try-catch и дать исключению уйти вверх настолько насколько оно сможет. Далее либо попадет в твой же блок catch где-то чуть выше (и этот перехват гарантированно окажется осмысленным, т.к. это вытекает из самого дерева вызовов). Либо он уплывет до main() где ты своим кодом сделаешь exit(). Либо вообще выйдет за main() т.е. уронит программу без тебя - это опять же нередко наиболее корректный вариант со всех точек зрения.

Единственное, что джаве иногда нужно аналогично подталкивать исключеня выше вручную (например через throw RuntimeException(e)). Это маразм из-за checked-excpetions. Checked-excpetions - это совершенно глупая идея, это ошибка. Но выключить их в Java нельзя.

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

Но ты же понимаешь, что нередко бывает, что правильным в таких случаях будет просто убрать try-catch и дать исключению уйти вверх настолько насколько оно сможет

я-то понимаю, потому и говорю, что исключения - это нормально. А заменять их постоянным повторением молитвы «if err != nil return err» нет никакого смысла, ведь сейчас уже давно не меряют работу программиста в строках кода :)

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

Зависит от нужд проекта.

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

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

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

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

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

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

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

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

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

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

в какой-то момент тебе всё равно придётся её обработать

Это абсолютно не соответствует истине.

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

постоянным повторением молитвы «if err != nil return err»

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

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

Карьеру у нас никто с го не начинал

В этом-то всё и дело.

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

исключение никуда наверх не уплывёт, тем более до main. исключение без обработчика - это сразу terminate() без какой либо раскрутки с тека, т.е. аналогично сегфолту.

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

таких как ты к с++ подпускать вообще нельзя. к джаве ладно, там checked exceptions, но не к с++. дай угадаю, ты работаешь где-то в гос-секторе, да?

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

почему в некоторых проектах предпочитают коды ошибок вместо исключений. наверное потому что там crazy cost exceptions из-за трёх ассемблерных инструкций. да нет, это потому что вы программы пишете наугад.

весь itt этот тред - живое подтверждение того, что дизайн го корректен.

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

Пфф, в Perl 5.30 уже 12.1 юникод поддерживается.

Тыничонипонял. Перл мёртв. И си мертв, и си++. Посмотри на рейтинги на гитхабе: либа полная багов, поддерживающая 1/3 от общих фич на мейнстрим языках набирают тысячи звёзд. Обкатанное годами решение не на хайповых языках - пару десятков.

Тебе реально охота, чтоб эти люди пришли в перл?)

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

Ты очень тупой.

ты работаешь где-то в гос-секторе, да?

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

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

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

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

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

-

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

исключение никуда наверх не уплывёт, тем более до main

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

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

ну во-первых, как ты раскрутишь стек до main() если исключение произошло в другом потоке? во-вторых, кто тебя просил раскручивать стек до main() и отправлять в мусор всё приложение, ты вообще нормален?

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

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

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

кто тебя просил раскручивать стек до main() и отправлять в мусор всё приложение, ты вообще нормален?

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

И еще: прочитай внимательно, что я написал. Если не понял, прочитай 100 раз. Внимательно.

ну во-первых, как ты раскрутишь стек до main() если исключение произошло в другом потоке?

Не понял тебя. Просто ставишь руками try-catch в начале того треда и они прекрасно ловятся. Дальше или делаешь что-то по данному поводу. Или просто сохраняешь/ставшь флаг и т.д., а потом из заинтересованных тредов это читаешь. Да много вариантов. вопрос твой непонятен. Кроме того, если в стандартной библиотеке языка абстракции чуть выше, то они могут предоставить метод для проверки были ли там эксепшн. На обычных же тредах в джаве до запуска указывается обработчик. Вообще это уже вопрос вкуса - можно даже к футуре эту информацию приделать.

ты учись, студент. если ты чего-то не понимаешь, то это не значит. что идея глупая

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

Ты тупое наглое дно.

про гос-сектор я угадал, да? я только там такую дичь видел, люди вообще ноль на массу, что они делают, но деньги платят

дальше не читал. заткнить уже а

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

к джаве ладно, там checked exceptions

Checked Exceptions - это невероятная ужасная глупость.

Самая идея глупость и не имеет смысла.

Провал был осознан, но пока еще осознан только как «ну да она не работает на практике».

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

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

учись обрабатывать ошибки настоящим образом. приеду - проверю.

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

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

Даун, никто (кроме, очевидно, тебя вместе твоими «ноль на массу» быдло-друзьями) не роняет программ из-за recoverable исключений.

Как ты можешь быть настолько непроходимо тупым и самоуверенным?

Ты просто дно...

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

Не в оффтопике.

Там была проблема со стрипом до этого. Потом её поправили. Но она давняя, к 1.3 отношения не имеет. Вроде бы --strip-all делал исполняемый файл негодным ранее.

kostyarin_ ★★ ()
Ответ на: комментарий от den73
if err != nil {
    return nil, err
}

разумеется это – 100%-ый аналог отсутствия обработки ошибки вообще, никакой качественный сеньор такое не пропустит. Адекватная обработка в рамках задач для которых используется Go (сетевые сервисы, CLI-утилитки) будет выглядеть либо как

if err != nil {
    return nil, fmt.Errorf("doing something: %w", err) // эти дебилы не завезли errors.Wrap
}

либо

if err != nil {
    return nil, CustomError{Err: err}
}

В каких-то задачах этого может не хватать, но от этого нужно делать правильный вывод: Go нечего делать за пределами сетевых сервисов и CLI-утилит.

Joe_Bishop ()

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

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

Это маразм из-за checked-excpetions. Checked-excpetions - это совершенно глупая идея, это ошибка.

А в расте прекрасно работает. Может, в консерватории что-то подправить?

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

А в расте прекрасно работает. Может, в консерватории что-то подправить?

Я не видел rust и ничего сказать не могу про него.

Если ты такое пишешь про checked exceptions, то на Java ты ни дня не программировал.

Мой совокупный опыт Java - около трех месяцев. Но даже мне понятно, что checked exceptions это больная идея. Очень хорошо, что это постепенно начинают без лишнего шума признавать.

Эти checked exceptions, кстати, вступают в прямое противоречие с «официальной» доктриной по эксепшенам, изложенной кажется в effective java. Просто мало кто это замечает. (Или мало кто читал и официальную документацию, и книгу и пытался хоть минимально подумать головой).

Почему это бред в целом я описывать не буду. Это требует обстоятельного объяснения с примерами.

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

То есть ты или нездоров, или не знаешь, что такое checked exceptions в Java.

А про rust я ничего не знаю. Возможноб там что-то совсем и другое и иначе сделано. Кроме того, это всё же другой язык совсем с другими применениями. То есть нужно предметно что и там и как оно там получается. Но я rust не знаю.

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

Я в рот бодрил каждого неосилятора, который считает это 0o644, и 0b0110 говно чем-то стоящим. И тебя, кид, в частности.

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

nil это пустое поле типа?

  • указатель
  • интерфейс
  • хэш-таблица
  • канал
  • функция
  • отрезок

Это всё может быть nil.

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

Я в рот бодрил каждого неосилятора, который считает это 0o644, и 0b0110 говно чем-то стоящим. И тебя, кид, в частности.

Вот, еще один вскрылся диванный непрограммист-дебил.

Ну давай, не петушись, а поясни, почему 0b0110 это плохо и для неосиляторов.

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

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

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

0o644

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

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

А ты поясни что хорошего для начала

Так. Ты вскукарекнул, что это «всякое говно» и что это для неосиляторов.

Обоснуй свой вскукарек.

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

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

разумеется это – 100%-ый аналог отсутствия обработки ошибки вообще.

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

И тут выясняется, что, получив очередной err из какой-то функции, мы не можем получить список того, что же эта err может из себя представлять, потому что библиотеки об этом в своей документации не пишут (во всяком случае, те, которые мне попадались).

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

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

Слив засчитай. Приятного аппетита.

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

И тут выясняется, что, получив очередной err из какой-то функции, мы не можем получить список того, что же эта err может из себя представлять

  1. Go не предоставляет типобезопасного способа сделать это.

  2. На самом деле в стандартной либе появился инштрумент errors.As, который как раз для подобных ситуаций и предназначается. Хотя, на мой взгляд

    1. Он не должен был появляться до генериков, т.к. может давать паники из-за своего interface{} в сигнатуре
    2. Даже с генериками он не будет решать задачу так, как решала бы её система с АТД: нет гарантии полного перебора вариантов, прежде всего.
  3. В задачах с этим самым Go такая обработка ошибочных ситуаций обычно и не нужна. Самым «сложным» для типичных сетевых задач в моей практике был случай (*Result, error, Warning) – и здесь Warning на своём месте, т.к. мог соседствовать как с *Result-ом, так и с error-ом. Т.е. в расте было бы что-то в духе (Result<Res, error>, Warning). Это для случая, например, когда создан объект, но не получилось дать извещение: Warning в любом случае будет отлогирован, а в случае удачи ещё может быть поставлена, например, задача о повторной попытке извещения.

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

Там должно быть семантическое errors.As(err error, target *error), но Го так не умеет. Точнее смысл совсем другой.

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

Ну да. Но с контрактами (в дев-ветке они уже появились) и генериками будет можно так:

contract errorImpl(T) {
    T Error() string
}

func (type T errorImpl) (err error, target *T) bool
Joe_Bishop ()
Ответ на: комментарий от Joe_Bishop

Вопрс, что эта конструкция значит? Я просто совсем не знаю го.

if err != nil {
    return nil, fmt.Errorf("doing something: %w", err)
}
В го что, действительно конвертируют ошибки в строки рядом с местом возникновения и передают дальше по стеку?? При этом зачем-то выбрасывают информацию о типе?

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

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

Я как профессионал знаю, что такие литералы полезны.

Ну а ты, если б ты хоть хеловорлд один в жизни написал, то ты бы возможно тоже знал.

Короче обосрался ты, придурок.

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

Я как профессионал знаю, что такие литералы полезны.

Профессионал преподавания в детских садах для детей даунов?

Ну а ты, если б ты хоть хеловорлд один в жизни написал, то ты бы возможно тоже знал.

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

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

Т.е. ты настолько дно, что даже свое самое мелкое мнение обосновать не можешь?

Ты вообще программируешь хоть что-то?? Хочу понять на чем вообще основано твое мнение.

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

Т.е. ты настолько дно, что даже свое самое мелкое мнение обосновать не можешь?

Я не вижу смысла обосновывать неадеквату что-то. В этом просто нету смысла.

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

То есть получается, ты свое мнение обосновать не можешь и представления о вопросе не имеешь?

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

То есть получается, ты свое мнение обосновать не можешь и представления о вопросе не имеешь?

Потому что есть более удобные для этого способы. Если тебе это не понятно, то я роток тебя бодрю.

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

В го что, действительно конвертируют ошибки в строки рядом с местом возникновения и передают дальше по стеку?? При этом зачем-то выбрасывают информацию о типе?

Т.е. ты нихера о язычке не знаешь, но кукарекатьвысказывать свое веское мнение влез?

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

Потому что есть более удобные для этого способы. Если тебе это не понятно, то я роток тебя бодрю.

давай начнем издалека

покажи мне более удобный 0b10011101 и попробуй объяснить чем и почему он более удобен

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

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

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