Комментарии 72
Сейчас реально истерия пройдет и фанбои сдуются. По факту имеем очень ущербный язык, разработчики которого поставили крест на всех наработках в области языков программирования. На фоне Go даже такие упоротые проекты как Nim смотрятся свежо и актуально.
Сейчас гоферы Go-вна понапишут и потом придется кучу времени потратить, чтобы это на нормальные языки переписать.
Даже Python на фоне Go смотрится как ракета.
Я думаю, в Гугле люди знают, как реализовывать всякие LINQ-подобные API, имплиситы, дженерики, зависимые типы, higher kinded типы, и другое. И Гуглерам было ой, как не просто, спроектировать проестое API Go, на котором сможет любой general разработчик прочитать и написать код.
Мне нравится синтаксис Go. Но «нравится / не нравится» — это субъективщина. Мне например не нравится отсутствие скобочек в Python. Но я и не пишу на Python, так что тут всё сходится.
Но мне интересно, что конкретно по-твоему не так с синтаксисом Go. Расскажешь или это тайна?
Я вот не хочу такое здесь читать, хоть на Го и не пишу. Поэтому внёс свою лепту, чтобы вы пореже могли писать.
Стиль кода
Тут мы выяснили, что комментариев как таковых в Go нет и не будет.
Окей, есть хоть вообще какие-то причины писать на языке без комментариев, нормальной обработки ошибок, дженериков, нормального менеджмента зависимостей и системы пакетов в 2018 году?
Ответ на ваш комментарий вы найдете в практически любом посте про Go, где вы писали.
А почему язык такой странный?
1. Потому что это portable C
2. Потому что старались сделать язык на котором единообразно будут писать сотрудники любой квалификации
и отсюда растут все его недостатки.
Единственно я не понял, что значит нет комментариев?
Единственно я не понял, что значит нет комментариев?
Комментарии, по определению, не должны никак влиять на код. Если же вы используете комментарии для того, что бы изменять код или его поведение — это уже нельзя назвать комментариями.
Следовательно, это можно назвать метаинформацией и при ее написании вам стоит помнить, как ее можно безопасно оформлять, а как — нет.
Ну вот, а мне казалось, я сам это заметил.
И в чем это утверждение неправильное, в том что комментарии не должны влиять на код или в том, что в go они влияют на код?
Например `//go:noescape` директива функции, она учитывается компилятором.
В тоже время `// go:noescape` — просто комментарий (пробел есть).
Тоже самое в CGO:
// #include <stdio.h>
// #include <errno.h>
import "C"
А вот просто комментарий:
// #include <stdio.h>
// #include <errno.h>
import "C"
Дальше ж, разработчики начали такое же использовать, например, для генерации кода. В статье упоминается easyjson — он генерит код для cериализация/десериализация json. Ну и там используются комменты (но без пробела), где держат метаинформацию для генератора.
/me плачет
Ну кроме вот тех случаев с CGO и директивами.
Если посмотреть на более экзотические языки — думаю можно ещё найти
Хм… а можно примеры из С++ и JavaScript? Ну, исключая доки, в javascript у них такой же формат, как и в java и на код вроде не влияют, если я не ошибаюсь.
В Java через комментарии в старых версия работали, сейчас там появились аттрибуты (вроде в версии 1.5).
В любом случае псевдокомментации — вещь достаточно распространённая, только из-за них отказываться от языка глупо.
2. статический бинарник
3. производительность (в зависимости с чем сравнивать, конечно)
4. concurrency
5. тулсет (go fmt/imports/guru/vet/rename, go/ast (что очень важно, что бы свои тулзы проще писать было), vgo)
6. стандартная библиотека (конечно же не все идеально), но все равно помогает решать очень много задач
7. простота кода (да да, я перешел на Go с java и код на Go читать намного проще)
8. ошибки — намного удобнее чем исключения (но может быть это уже вкусовщина)
2. Который вы с большой вероятностью все равно положите в docker?
4. А что нет? Почти любой язык так может, даже python.
5. А что нет? Так же, я бы добавил, что тот же vgo не официальная часть тулсета, а «high experimental not ready for production» и его опять же легко могут выкинуть как dep.
6. А у кого нет нормальной стандартной библиотеки?
7. Субъективно, лично я считаю, что автоматический экспорт всех файлов в папке в общий namespace — это просто безумный ад для чтения кода.
8. Мне всегда было интересно, чем?
2. image будет небольшого размера, билдинг такого image будет самым быстрым
3. А что нет?
4. А что нет? Вы на какой пункт отвечали? vgo уже в go 1.1 (да, пока под флагом). Если бы вы чуть больше интересовались Go, вы бы знали про обсуждения dep в Go команде и какие к нему были претензии. Его хотели включить в Go тулсет, после редизайнинга (почитайте твиттер тред от Russ Cox, на хакерньюс еще был).
5. А что нет?
6. Субъективно
7. Я уже писал об этом (даже в посте, где вы бегали и кричали про ошибки в Go). Опять тоже обсуждение начинать не хочу, тем более с вами.
> 4. concurrency
> 4. А что нет? Почти любой язык так может, даже python.
даже python? серьезно? Умеет как Go?
лучше бы уже новый написали, чем старый коммент изменять.
Я по дурости включил Markdown и он переиначил мне нумерацию :( Простите
даже python? серьезно? Умеет как Go?
Практически, только вместо тредов у вас будут процессы. Или модель корутин в python чем-то принципиально хуже, чем схема с горутинами в go, исключая тот факт, что python не может в потоки?
1. Каналы есть в python? Это все таки часть concurrency в Go.
2. Так же удобно работать с корутинами? Создавать (одно ключевое слово `go`), управлять (`sync.WaitGroup`, `sync.Once`, etc, `context`, select и range для каналов).
3. Как работает планировщик корутин в python? Мне вот нравится идея с work-stealing планировщиком.
Небольшая поправка на все, что я напишу ниже — в силу того, что в python нет нормальных потоков, у вас есть различие между корутиной внутри одного процесса и корутинами между.
- Внутри процесса есть Queue, для общения между процессами есть Pipe. Но я бы предложил просто навернуть zeromq сверху для унификации.
- В целом, для синхронизации корутин есть большая куча доступных примитивов,
waitс гибкими возможностями настройки (отвалится после первого провала, после всех или просто подождать первый результат), gather, wait_for и так далее.selectнет, так как в python вообще нет case, обычно это эмулируется определенным образом. + Еще сторонние библиотеки для всяких timeout и прочей мути. В целом, вполне удобно, на мой взгляд. - Как-то так + возможность реализовать свой.
Не будет ли вам сложно придумать довольно простой пример приложения, которому нужно такое взаимодействие между корутинами и я попробую его запустить на этой схеме, что бы проверить, в самом деле это все будут костыли или нет?
А то я не могу придумать какого-то быстро примера :)
Создается 10 goroutine, которые читают с одного канала и обрабатывают сообщение. Есть рутина, которая пишет в канал (не важно как, например, читает с файла и пишет в канал). Обработка сообщений затратный процесс (потому один пишет и много читают). Самый обычный кейс.
При этом, после Ctrl+C завершается работа всех goroutine и после этого приложение останавливается.
(набросал быстро, к качеству можно не придраться)
package main
import (
"context"
"os"
"os/signal"
"sync"
"syscall"
)
func main() {
queue := make(chan message)
ctx, cancel := context.WithCancel(context.Background())
w := &worker{
queue: queue,
}
var wg sync.WaitGroup
wg.Add(1)
go func() {
produce(ctx, queue)
wg.Done()
}()
wg.Add(10)
for i := 0; i < 10; i++ {
go func() {
w.work(ctx)
wg.Done()
}()
}
stop := make(chan os.Signal, 1)
go func() {
signal.Notify(stop, syscall.SIGTERM, syscall.SIGINT)
defer signal.Stop(stop)
}()
<-stop
cancel()
wg.Wait()
}
type message struct{}
func produce(ctx context.Context, queue chan message) {
// допустим тут мы прочитали строку с файла и создали message
msg := message{}
select {
case queue <- msg:
case <-ctx.Done():
return
}
}
type worker struct {
queue chan message
}
func (w *worker) work(ctx context.Context) {
for {
select {
case msg := <-w.queue:
process(msg)
case <-ctx.Done():
return
}
}
}
func process(msg message) {
// omit
}
У меня получилось как-то так.
В целом, немного ручного шедулинга у меня есть. По желанию можно переписать так, что бы main_message_processer вместо того, что бы создавало просто три корутины запускало только одну, которая каждый раз при получении задачи запускала бы еще одну в фоне.
2. Легковесные goroutine vs. процессы — костыли.
Стоит заметить, что все происходит опять же из-за того, что в python я не могу одновременно выполнять задачи в нескольких тредах, потому что у нас есть GIL.
Но я бы сказал, что:
- Общение через каналы (общую память между тредами) vs. IPC — костыли (?).
Легковесные goroutineтреды vs. процессы — костыли.
Так как в go в пределах одного треда вы тоже не можете выполнять больше одной задачи одновременно. То есть, больше одной корутины можно (так же, как и в python), но именно работать будет все равно только одна. Разве нет?
Стоит заметить, что все происходит опять же из-за того, что в python я не могу одновременно выполнять задачи в нескольких тредах, потому что у нас есть GIL.
Ну вот именно, потому костыли. В Go все изначально по другому, потому python и рядом не стоит.
Так как в go в пределах одного треда вы тоже не можете выполнять больше одной задачи одновременно. То есть, больше одной корутины можно (так же, как и в python), но именно работать будет все равно только одна. Разве нет?
Вы же помните, мы говорим про concurrency?
В Go есть планировщик, который ранит горутины на тредах. В один момент времени на одном треде будет раниться одна горутина. Да. Точно так же, как на одном ядре будет выполняться один процесс в одновременно.
А теперь давайте посмотрим реальный мир — точно так же как и процесс, горутина может быть в состоянии blocked, running, waiting. Blocked — например горутина выполняет системный вызов, планировщик припарковывает эту горутину и освобождает тред, тред берет следующие горутину из очереди и выполняет ее. Как только горутина получила ответ, она попадает в очередь и как только будет свободный тред — продолжит свое выполнение. И это все в рамках одного процесса. Потому можно на одной машине запускать десятки тысяч горутин.
В данном случае треды не простаивают и полностью утилизированы, в отличии от любого другого языка с тредами (в java, например, когда тред будет выполнять блокирующий вызов — тред будет заблокирован).
В целом, почитайте про планировщик и в целом про райтайм в Go, что бы потом не писать тут глупости.
В целом, почитайте про планировщик и в целом про райтайм в Go, что бы потом не писать тут глупости.
Ну, python может работать аналогично с go +GOMAXPROCS=1, а дальше ему мешает фатальный недостаток. Простите. В целом, еще 2-3 года и скорее всего, python таки избавится от него и заживем, а пока да, немного страданий.
А возвращаясь к реальному миру, у вас так часто бывают задачи, в которых нужно вам необходимо утилизировать правильно ядра?
А еще обратно к реальному миру, мне кажется, вместо каналов вы чаще будете использовать какие-то другие MQ, например nats.
Ну, python может работать аналогично с go +GOMAXPROCS=1, а дальше ему мешает фатальный недостаток. Простите. В целом, еще 2-3 года и скорее всего, python таки избавится от него и заживем, а пока да, немного страданий.
Да вы товарищь троль.
А возвращаясь к реальному миру, у вас так часто бывают задачи, в которых нужно вам необходимо утилизировать правильно ядра?
Я же пример привел — в java тред будет заблокирован, в Go будет выполнять горутину. Тредов мало, горутин много.
А еще обратно к реальному миру, мне кажется, вместо каналов вы чаще будете использовать какие-то другие MQ, например nats.
Какая чушь.
А NATS, о господи, использует каналы. Видно, что вы никогда не программировали но Go и потому говорите такие глупости.
Зачем вы реагируете на тролинг? Ну не нравятся кому-то go пусть пишут на том что нравится, это их проблемы, зачем в сообществе go говнокодеры? Пусть пишут на питоне на php и не в коем случае не трогают язык go!
Им не дано, и заставлять или что-то доказывать нет никакого смысла! Тем более спорить.
Отправляй тролям статью https://divan.github.io/posts/go_complain_howto/ именно для них она и написана. Пусть добавляют свои варианты и радуются.
А сообщество go будет избавлено от говнокодеров которые не понимая язык начинают писать так же как на php писали и в результате получать сами знаете что...
Очевидно, потому что ответы, которые состоят из "сторонний инструмент" и "вам это не нужно" — это так себе ответы.
Ну и еще потому, что мне приходится пользоваться инструментами, написанными на go, которые по хорошему стоило бы написать на том же python, потому что требования по производительности у него нет, зато python позволяет концентрироваться на логике кода, вместо всякого boilerplate.
Я просто жду, что однажды мне скажут "vgo теперь включити в официальный toolchain и он стабильный, а еще добавили процедурные макросы и специальный синтаксис для метаинфомации и так далее". Но пока все нет и нет.
Вы же про этот vgo?
Который "https://github.com/golang/vgo"?
И про который написано тут, что "For any production workloads, use dep, or migrate to it if you have not done so already."?
* Ничего не поделаешь, нам всём придётся пользоваться инструментами на go периодически. И как бы вы ни были правы в том, что Go плох, ситуация не сдвинется ни на грамм.
Или вам до сих пор никто не ответил потому что модно и потому что Google?
Краткий спойлер — такое утверждение как минимум сомнительно потому, что go в том числе не предпринимает попыток избавится от тех же runtime errors.
Я не отрицаю, что на golang можно писать нормальный софт, это было бы глупо. Но утверждение о том, что «на golang даже не профессионалы могут писать качественный софт», которое на мой взгляд подразумевает, что на остальных то языках нельзя — требует хоть каких-то доказательств или исследований, потому что я предпосылок для этого не вижу.
Но почему светлая тема по умолчанию так обделена разнообразием подсветки?
Отключается где-то в драйвере, я толком до сих пор не понимаю где, т.к. переодически оно само слетает. И хотя все галки остаются, яркость начинает гулять.
Т.е. переключение между тёмным Sublime и светлым браузером — это несколько секунд гуляния подсветки.
А так как все галки остались на месте, то приходится снимать-сохранять-выставлять-сохранять все галки снова.
Хотя в остальном меня Intel видюхи вполне устраивают, даже выдают неплохой fps в майнкрафте в разрешение 4k. Прогресс не остановить! =)
В таком случае тёмная тема позволяет снизить негативные ощущения, но причину не убирает и проблему не решает. Если вы работаете с тёмной темой не из эстетических предпочтений, а из-за в глазах, затылке и т.п., то это звоночек, что дело хреново и надо начинать следить за собой, заставлять моргать часто, делать перерывы, меньше пить кофе (т.е. вообще не пить) и так далее.
Это непросто, но надо.
Потому что уже второй раз (до этого — при обновлении на одну из промежуточных 2018.1, сейчас — при обновлении на 2018.2) при предложении обновиться меня предупреждают о том, что плагин для поддержки Less превратится в тыкву.
Насколько понимаю, его тупо не пересобрали под обновленную версию.
Перешел на GoLand в связи с эпичной смертью плагина GoClipse под эклипс. Покойся с миром!
Хочу рассказать что меня "покоробило" в GoLand, если вдруг не в тему и надо где-то задачи завести, дайте пожалуйста ссылки, я заведу задачи, так как это важные вещи.
У разработчиков GoLand нет понимания того что комментарии в коде Go это не только комментарии! Подход описанный в пункте "Add leading space to comments" выглядит как косяк заклеенный скотчем. Важно разделять "комментарии" хотя бы на три группы:
1.1. Управляющие директивы — Пример: // +build ignore
1.2. Комментарии/документация к экспортируемым переменным, константам, функциям
В настоящий момент они игнорируются и даже не отображаются в подсказках
1.3. Директивы управления работой сторонних библиотек, используемые в go generate, упомянуты в статье, в главе "Стиль кода" на примере библиотеки easyjson
При наличии достаточно подробного и расширенного по сравнению с GoClipse инструмента раскраски синтаксиса, был сильно удивлён тем что GoLand не делает различий между строкой и многострочной строкой.
""и``соответственно. Хотелось бы чтобы появилась возможность покрасить код с такими строками в разные цвета.
Нет возможности изменить цвет у файлов, скины меняются, все цвета изменяются, кроме цветов в именах файлов во вкладке "проект" и в табах открытых файлов. Почему?
Это же портит механизм смены скина. И из за того что имена файлов только либо красные, чёрные или голубые весь внешний вид портится. Хотелось бы иметь возможность и этим элементам задать цвета.
А в целом получился у вас редактор очень хороший, вы уже на пол шажка обогнали плагин GoClipse для эклипса. Так что так держать!
Надеюсь на достигнутом вы не остановитесь, будите прислушиваться к пожеланиям разработчиков и сделаете идеальный IDE!
www.material-theme.com
P.S. В контесте подсветки Go я не проверял, но проект однозначно достойный. Многое из того, что там реализовано и отсутсвует из коробки — вызывает у меня недоумение.
- Все так и работает, комментарии разделяются на эти три типа: директивы IDE знает сама, вторая группа от третьей отделяется введенной настройкой.
- Заведите, пожалуйста, реквест в нашем баг-трекере.
- Объясните, пожалуйста, какой смысл вы вкладываете в слово «скин».
И да, на данный момент UI элементы (в том числе табики) нельзя кастомизировать. Но, можно как раз воспользоваться вышеупомянутым плагином: Preferences | Plugins | Material Theme UI.
Что нового в GoLand 2018.2