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

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

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

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

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

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

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

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

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

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

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

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

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

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

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