Здравствуйте, Kswapd, Вы писали:

K>Не совсем так. Go — обычный язык программирования, который может быть реализован несколькими компиляторами и даже интерпретаторами. FAQ на оф. сайте говорит, что на данный момент развивается и поддерживается три "официальных" компилятора: gc (основной), gccgo (использующий бэкенд от gcc) и gollvm (использующий соответственно LLVM). Видимо, вопрос того, какой подход победит, остаётся открытым.

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

K>Хотя лично мне нравится идея трансляции Go в промежуточный абстрактный ассемблер. Есть в этом безуминка гения .

Это есть в официальном Go, просто "правильное", с играми и девочками, а не какой-то там LLVM.

the compiler operates on a kind of semi-abstract instruction set, and instruction selection occurs partly after code generation

Авторы Go большие поклонники Plan 9 и не могли себе позволить такую ересь как использование готового бекэнда для компиляторя:

Although the assembler takes its guidance from the Plan 9 assemblers, it is a distinct program, so there are some differences.

Здравствуйте, kaa.python, Вы писали:

KP>Официальный и реально годный для использования в продуктовой разработки только gc, остальные не более чем игрушки небольшого количества энтузиастов.
gccgo — полноценно работающий. Я его использую для финальной сборки, код существенно быстрее получается.

Здравствуйте, Kswapd, Вы писали:

K>Раз уж упомянули Rust, будет нелишне вспомнить заметку Эрика Рэймонда, широко известного как ESR
Он банальный дилетант в обоих языках. Можно почитать его посты на golang-dev и rust-internals.

Здравствуйте, kaa.python, Вы писали:

KP>В основном из за очень-очень плохого оптимизатора. В Go можно понять всё, кроме религиозных заморочек авторов не позволивших им взять LLVM.
В требованиях к Go, когда он проектировался в 2006-м году, была скорость компилятора. В то время LLVM была ещё маленькой и clang только-только появлялся. Так что Go сделали свой кодогенератор и альтернативную полноценную реализацию для gcc (которая и сейчас развивается). Получилось очень неплохо — скорость компиляции в первой версии зашкаливала.

Здравствуйте, Cyberax, Вы писали:

C> Получилось очень неплохо — скорость компиляции в первой версии зашкаливала.

А потом компилятор переписали на Го, и скорость просела безвозвратно.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, kaa.python, Вы писали:

KP>>Официальный и реально годный для использования в продуктовой разработки только gc, остальные не более чем игрушки небольшого количества энтузиастов.
C>gccgo — полноценно работающий. Я его использую для финальной сборки, код существенно быстрее получается.

Похоже что, gccgo решение, но он отстает от основной ветки:

The GCC 7 releases include a complete implementation of the Go 1.8.1 user libraries

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

Здравствуйте, kaa.python, Вы писали:

KP>Шумиха вокруг Go вызвана тем, что он позволяет использовать откровенных жопоруков, коих в огромных корпорациях очень много. Так что я бы сильно не радовался соскочив с C++ на Go, так как Go — язык для мартышек и по насыщению рынка их ждёт судьба PHP программистов.

После того, как в проекте заменил C++ на Go (95%) и Rust (5%), появилось куда больше времени на прокачку навыков помимо "C++ граблеобходитель". Наконец-то можно плотно заняться расширением кругозора, архитектурой и софт скиллами
А если у кого-то профессионализм измеряется исключительно языком — это его печаль и беда

Здравствуйте, ct0r, Вы писали:

C>После того, как в проекте заменил C++ на Go (95%) и Rust (5%), появилось куда больше времени на прокачку навыков помимо "C++ граблеобходитель". Наконец-то можно плотно заняться расширением кругозора, архитектурой и софт скиллами

Я уверен что ты тут сильно недоговариваешь, так как вместо грабель C++ (каких, кстати?) ты получаешь модель памяти Rust, которая те же грабли, но вид с боку. А вот Go, да, это как раз то, о чем я говорил. Любой посредственный разработчик не сумевших осилить более сложный и выразительный инструмент превращается в обезьянку способную если не Войну и мир написать, но что-то не сразу падающее точно. Правда потом более опытным дядям всяко приходится смотреть на поделие осиливших хотя бы Go и продумывать как это расчищать

C>А если у кого-то профессионализм измеряется исключительно языком — это его печаль и беда

Одна из составляющих профессионализма — знание своего рабочего инструмента. Язык программирования — один из основных рабочих инструментов. Так что разработчик не осиливший языка не может считаться профессионалом. Вторым сопоставимым по важности элементом будет домeнная область.

Здравствуйте, kaa.python, Вы писали:

C>>gccgo — полноценно работающий. Я его использую для финальной сборки, код существенно быстрее получается.
KP>Похоже что, gccgo решение, но он отстает от основной ветки:
KP>

The GCC 7 releases include a complete implementation of the Go 1.8.1 user libraries

В GCC 8 образца лета прошлого года — уже версия 1.10.

Тут основная проблема с тем, что циклы релиза и стабилизации у gcc слишком долгие. Гопники портируют всё в GCC всё достаточно быстро, а потом оно там год лежит.

Здравствуйте, Cyberax, Вы писали:

C>В GCC 8 образца лета прошлого года — уже версия 1.10.

C>Тут основная проблема с тем, что циклы релиза и стабилизации у gcc слишком долгие. Гопники портируют всё в GCC всё достаточно быстро, а потом оно там год лежит.

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

Здравствуйте, D. Mon, Вы писали:

C>> Получилось очень неплохо — скорость компиляции в первой версии зашкаливала.
DM>А потом компилятор переписали на Го, и скорость просела безвозвратно.
Зато компьютеры побыстрее стали Они его сейчас немного параллелизуют, а тут ещё generic'и подтянутся. Глядишь, и догонит по скорости.

KP>Одна из составляющих профессионализма — знание своего рабочего инструмента. Язык программирования — один из основных рабочих инструментов. Так что разработчик не осиливший языка не может считаться профессионалом. Вторым сопоставимым по важности элементом будет домeнная область.

Доменная область это главное. И голова и время не бесконечно, чем меньше тратится усилий на инструменты тем лучше.

Здравствуйте, gardener, Вы писали:

G>Доменная область это главное. И голова и время не бесконечно, чем меньше тратится усилий на инструменты тем лучше.

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

G>>Доменная область это главное. И голова и время не бесконечно, чем меньше тратится усилий на инструменты тем лучше.

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

Ну тут сложно возразить.

Здравствуйте, kaa.python, Вы писали:

KP>грабель C++ (каких, кстати?)
Мы будем вести дискуссию на тему того, есть ли в С++ грабли? Серьезно?

KP>модель памяти Rust, которая те же грабли, но вид с боку.
А шаблоны С++ — те же interface{} в Go, только сбоку. Ну и так далее.

KP>Любой посредственный разработчик не сумевших осилить более сложный и выразительный инструмент превращается в обезьянку способную если не Войну и мир написать, но что-то не сразу падающее точно.
Отлично. Что плохого? И что плохого в том, если хороший разработчик начнет на Go писать?

KP>Правда потом более опытным дядям всяко приходится смотреть на поделие осиливших хотя бы Go и продумывать как это расчищать
А теперь давай подумаем о количестве тех, кто не осилил C++, но пишет на нем. И подумаем, за кем именно опытным дядям будет проще расчищать.

KP>Одна из составляющих профессионализма — знание своего рабочего инструмента. Язык программирования — один из основных рабочих инструментов. Так что разработчик не осиливший языка не может считаться профессионалом. Вторым сопоставимым по важности элементом будет домeнная область.
Основных элементов чем выше по карьерной лестнице, тем больше. Далее, это не противоречит ничему из того, что я сказал. Если человек перестал писать на C++, но начал на Go, то что, он становится от этого менее профессионалом? Конечно нет.

Здравствуйте, kaa.python, Вы писали:

KP>Тут есть один тонкий момент. Разные инструменты за счет разной базовой сложности могут давать различные результаты в плане скорости разработки и простоты поддержки решения.
Согласен, в моем проекте лучший результат — это когда в одних местах вместо C++ — Go, а в других вместо C++ — Rust.

Здравствуйте, iZEN, Вы писали:

ZEN>Go используется примерно в 300 различных проектаов, связанных с разработкой ПО:
ZEN>https://www.freshports.org/lang/go/

Там половина либы для него самого.

Здравствуйте, kaa.python, Вы писали:

KP>С генераторами жить скорее приходится, особого удовольствия это не доставляет.

Нет, ничего, получается довольно изящно, выглядит немногим хуже плюсовых шаблонов. И можно сразу писать generic-тесты:

//go:generate genny -in=queue.go -out=intqueue.go gen "<T>=int"
//go:generate genny -in=queue.go -out=stringqueue.go gen "<T>=string"

import "github.com/cheekybits/genny/generic"

type <T> generic.Type

type <T>Queue []<T>

func New<T>Queue() *<T>Queue {
    return &<T>Queue{}
}

func (q *<T>Queue) Put(val <T>) {
    q = append(q, val)
}

...

func Test<T>Queue(t *testing.T) {
    ...
}

Здесь угловые скобки — юникодные символы с похожим начертанием, можно вместо <T> взять любое другое валидное имя.

Обобщённый код пишется в своём файле (queue.go), после go generate появляется столько дополнительных файлов, сколько было заказано типов. Конечный эффект точно такой же, как от шаблонов, оверхед — три-четыре строки и дополнительный этап трансляции.

Здравствуйте, Kswapd, Вы писали:

K>Нет, ничего, получается довольно изящно, выглядит немногим хуже плюсовых шаблонов. И можно сразу писать generic-тесты:

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

Здравствуйте, e.thrash, Вы писали:

ET>Казалось, что Python пришел надолго.
ET>Но вот что-то стал часто слышать, что Go вытеснит Питон.
ET>Что думаете?
А вы как думаете?
Пока у go не будет PSF (grants, infrastructure, annual gathering support)
Врядли он кого вытеснит.