LINUX.ORG.RU
Форум — Talks  

Что ждёт Go в 2017? Упячка, попячтса: берём пример с Rust.

 , , ,


2

4

Russ Cox, один из главных разработчиков ЯП Go, написал заметку о том, чем он будет заниматься в 2017 году.

  1. Type aliases. Попытка добавить в ЯП «общие псевдонимы» для того, чтобы облегчить рефакторинг внутри Г Корп, была встречена не очень тепло в сообществе. Не смотря на фекалии, фичу запилили, чтобы позже выпилить из-за обнаружившихся проблем. Вместо них, в 1.9 будут реализованы «псевдонимы типов».

  2. Package management. «Группа контрибьюторов» решила реализовать лучший p.m., централизованный. В стиле Rust:

    We’re now iterating on tool implementation, with gps as the engine. We’re learning and tweaking as we go, and plan to open up the repository publicly in early January

    A central packaging registry (a la npm)

    Напомню, ранее в соседнем треде уже упоминали, как выглядел процесс дизайна пакетного менеджера в ЯП Rust. Выглядело всё где-то так же: сначало реализовали без всякой обратной связи, потом дали сообществу и попросили жрать, что дают.
    Впрочем, обещать не значит жениться, пилят всё это какие-то левые лоси, а Russ лишь обещает убедиться, что идеи хорошо лягут на стандартный тулчейн Go.

  3. Build improvements. Недостаточно агрессивное кеширование приводит порой к медленной компиляции. Из этого вытекает и проблема медленного прогона тестов. Помимо этого, go build должен поддерживать и проекты вне GOPATH.

  4. go vet, указывающий на ошибки в корректности кода, возможно, должен запускаться параллельно с компиляцией / прогоном тестов. Кроме того, в него должны быть включены наиболее часто встречающиеся ошибки из 100 самых популярных проектов на Github'е по количеству звёзд / форков.

  5. Улучшение сообщений ошибок. Большая часть кода в Go проектах сейчас выглядит так:
    if err != nil {
    	return err
    }
    
    В результате - отсутствие контекста ошибки, её непонятность, что не айс. В 2017 Russ будет раскидывать мыслю по этому поводу.

  6. Формулирование лучших практик pkg/context. В 1.7 запилили этот костыль, сформулировали правила использования и нарушили их при реализации стандартной библиотеки database/sql. Теперь нужно таки опять решить, когда context уместен.

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

  8. Immutability. В долгосрочной перспективе go race для обнаружения гонок должен стать бесполезен в виду реализации reference immutability. Хотя, «вполне вероятно, что это лишь влажные фантазии и ничего такого не случится». В одном можно быть уверенным, в 2017 автор познакомится с проблемой ближе.

  9. Generics. Самый горячий аргумент. Между тем, цитата:

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

    4 предложения (proposals) по реализации этой фичи не взлетело, протухнув после обсуждений. Сейчас подошло время заново глянуть на проблему, учтя опыт Dart, Midori, Rust и Swift. Но в этом году дженериков не будет, год пройдёт под знаком лучшего понимания.


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

Большая часть кода в Go проектах сейчас выглядит так

Одна из вещей, которые меня в Go категорически бесят :)

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

Было обсуждение про сахарок к конструкции выше в стиле:

f, return := os.Open("file.txt")
вместо:
f, err := os.Open("file.txt")
if err != nil {
	return err
}
Но как-то не пошло: не нашли универсального варианта, да и не сильно хотели, видимо. Правда, проблему контекста ошибки это бы не решило.

MadDeer
() автор топика

Но в этом году дженериков не будет, год пройдёт под знаком лучшего понимания.
нет нормального централизованного пакетного менеджера
if err != nil {
return err
}

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

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

нет «нормального» централизованного пакетного менеджера

Надеюсь и не появится такого «нормального». Ещё не хватало гуглу анус подставлять при пользовании ЯП.

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

Вы уже его подставляете. Причем это гэнгбэнг с вами на главной роли.

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

Пример такой взрослой платформы в студию и чтобы перекрывала все плюсы Го.

Deleted
()

раскидывать мыслю по этому поводу.

Хорошо что не мысью по древу.

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

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

Deleted
()

5. Улучшение сообщений ошибок.

…

В 2017 Russ будет раскидывать мыслю по этому поводу.

Кто в курсе — запилить монаду Maybe ему не предлагали?

Deleted
()
Последнее исправление: Deleted (всего исправлений: 2)
Ответ на: комментарий от joy4eg

Здравствуй древние годы

Рrogram Writing;
Var
  FileName : string; {строка, содержащая имя файла}
  FVar : file of char; {переменная файлового типа}
  Index : integer; 
  Letter : char; {читаемый из файла символ}
Begin
  write('Enter filename: '); {предложение ввести имя файла}
  readln (FileName); {ввод имени файла}
  assign (FVar,FileName); {связь имени файла и переменной}
  {$I-} {отключен контроль ввода/вывода}
  reset (FVar); {открытие файла для чтения и записи}
  {$I+} {включен контроль ввода/вывода}
  if IOResult <> 0 {выход, если файл не открыт}
    then
      begin
        writeln ('Не открыт файл ', FileName);
        Halt
      end;
  while not EOF (FVar) do {цикл до конца файла}
    begin
      read (FVar, Letter); {чтение символа из файла}
      Letter:=Upcase(Letter); {преобразование букв}
      Seek(FVar,FilePos(FVar)-1); {перемещение указателя назад на 1 позицию}
      write(FVar,Letter); {запись преобразованной буквы}
    end; {конец цикла}
  close(FVar) {закрыть файл}
End.
dmxrand ★
()
Ответ на: комментарий от KRoN73

В общем случае это решается простым

val, err := f()
if err != nil {
    return nil, fmt.Errorf("Whatever description, got %v", err)
}
или использованием logrus и подобного или написанием своего велосипеда, под свои нужды.

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

Сравни то, что написано выше:

val, err := f()
if err != nil {
    return nil, fmt.Errorf("Whatever description, got %v", err)
}

И то, что написал я

{$I-} {отключен контроль ввода/вывода}
  reset (FVar); {открытие файла для чтения и записи}
  {$I+} {включен контроль ввода/вывода}
  if IOResult <> 0 {выход, если файл не открыт}
dmxrand ★
()
Ответ на: комментарий от Deleted

Хорошо. В общем то, как в Haskell с Maybe — было бы спасением в Go.

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

Дык большой разницы нет. Локальная переменная, глобальная переменная. Переменная она и есть переменная.

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

f, return := os.Open(«file.txt»)

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

bread ☆
()
Ответ на: комментарий от dmxrand

Дык большой разницы нет. Локальная переменная, глобальная переменная.

А... ну окей.

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

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

dmxrand ★
()

Нда, не густо.

Они бы еще заинтересовались нормальным тулчейном для тестирования в stdlib. Сейчас если нормально покрывать код тестами, то этих тестовых loc будет раз в 6-12 больше, чем самого кода.

BigAlex ★★★
()

p.m., централизованный.

Не прошло и сколько там, 8 лет? С самого начала говорили что нужен полноценный менеджер с поддержкой в языке и тулзах, но нет, мол давайте лучше отдадим это коммунити, которые напилили десятка два несовместимых недоменеджеров. Хорошо показывает основной минус Го - консерватизм и медленное принятие идей/фейлов. И ладно бы там дженерики, которые они не знают как нормально реализовать, но вот такие мелочи уж могли бы постараться.

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

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

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

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

Да, в некоторых зрелых языках лютые проблемы вроде GIL уже язык не повернется назвать ни детскими болячками, ни старческим маразмом

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

я сейчас зашел в наш проект и построил граф зависимостей. Сто шестьдесят две. Дальше сам думай, что не так с го гет.

stevejobs ★★★★☆
()
Ответ на: комментарий от stevejobs
# gb vendor list | wc -l
176

Дальше сам думай, что не так с го гет.

Что? Да, без gb/godeps на большом количестве зависимостей никуда, но 1) это не причина делать централизованное говно 2) это прекрасно и удобно для небольших утилит и либ 3) а вот работать внутри GOPATH совсем неудобно, да, но я так понял, что они это признали

derlafff ★★★★★
()

Го
    для
          гопников
                         быдло-кодеров.

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

Не сказал бы что пакетный менеджер для ЯП такой уж сложный момент. Их десяток написан, даже пришлось завести отдельную страничку (https://github.com/golang/go/wiki/PackageManagementTools) в вики. Gpm вон вообще на баше.

Это скорее пример инопланетного мышления. Вроде no warning policy, когда каждая ошибка - критическая ошибка, выбивающая из компиляции. Или геморрой с неиспользуемыми переменными, когда ты дебажишь, забываешь заюзать или удалить перменную, а компилятор тебя посылает куда подальше - https://golang.org/doc/faq#unused_variables_and_imports

entefeed ☆☆☆
()
Ответ на: комментарий от stevejobs

имхо всё просто - в гугле не хотят тратить бабки. Хотят чтобы хомяки всё им сделали

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

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

Это проблемы сообщества, что оно ниче родить не может

Десяток родило, смотри коммент прямо над твоим. Проблема в том что при выборе ПМ нет единства. Зоопарк, как с этими вашими луниксами, но тут хоть внутри дистра один пакетный менеджер, а там их дохрена.

entefeed ☆☆☆
()
Ответ на: комментарий от derlafff

С go get все прекрасно

Прекрасно для хелловорлдов. Не умеет в версионность, не умеет в нормальные зависимости и конфликты.

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

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

я смотрел парочку, имхо проблема в том, что у подавляющего большинства гошников квадратно-гнездовое мышление и извращенное понимание простоты в смысле «примитивизм». На все вопросы они отвечают в стиле: «а мы не будем делать проекты с тысячью зависимостей» или «я хочу всегда знать всё, что происходит с моими зависимостями». Объяснить им, что простота - это не когда у тебя 2 файла лежат в папке либ, а когда ты дирижируешь миллионами файлов так же просто как одним - совершенно нереально.. И это не проблема самого го, это проблема культуры анскиледов, которая вокруг него начала клубиться.. так же как вокруг джавы клубится культура индусятины, например

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

Десяток родило, смотри коммент прямо над твоим. Проблема в том что при выборе ПМ нет единства.

Вот и я говорю - проблема. Пора как то опредляться уже.

bread ☆
()
Ответ на: комментарий от entefeed

Всему своё место. В дистрах есть всякие dpkg/rpm — уровень go get, и есть apt/yum/прочих — уровень gb/godeps

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

Иди пиши свои хелловорлды микросервисы из пяти строк, не отвлекайся на взрослых людей.

Аргументы кончились?

на взрослых людей.

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

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

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

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

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

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

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

Да, на такие аргументы у меня контраргументы кончились.

entefeed ☆☆☆
()
Ответ на: комментарий от BigAlex

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

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