я имею ввиду, что коммиты не зеркалируются, vgo — это go mod в отдельном репозитории. Сделано это для go 1.10 пользователей. Не думаю, что будут как-то отдельно развивать vgo, смысла нету две код базы поддерживать.
путем не сложных поисков, можно найти, что Soultan работал «Head of Digital Marketing Squad», а потом «Chief Digital Officer». Soultan маркетолог, а не технарь.
А вот от это «Digital» прям несет некомпетентностью, тем более в тех компании.
Ну, python может работать аналогично с go +GOMAXPROCS=1, а дальше ему мешает фатальный недостаток. Простите. В целом, еще 2-3 года и скорее всего, python таки избавится от него и заживем, а пока да, немного страданий.
Да вы товарищь троль.
А возвращаясь к реальному миру, у вас так часто бывают задачи, в которых нужно вам необходимо утилизировать правильно ядра?
Я же пример привел — в java тред будет заблокирован, в Go будет выполнять горутину. Тредов мало, горутин много.
А еще обратно к реальному миру, мне кажется, вместо каналов вы чаще будете использовать какие-то другие MQ, например nats.
Какая чушь.
А NATS, о господи, использует каналы. Видно, что вы никогда не программировали но Go и потому говорите такие глупости.
Стоит заметить, что все происходит опять же из-за того, что в python я не могу одновременно выполнять задачи в нескольких тредах, потому что у нас есть GIL.
Ну вот именно, потому костыли. В Go все изначально по другому, потому python и рядом не стоит.
Так как в go в пределах одного треда вы тоже не можете выполнять больше одной задачи одновременно. То есть, больше одной корутины можно (так же, как и в python), но именно работать будет все равно только одна. Разве нет?
Вы же помните, мы говорим про concurrency?
В Go есть планировщик, который ранит горутины на тредах. В один момент времени на одном треде будет раниться одна горутина. Да. Точно так же, как на одном ядре будет выполняться один процесс в одновременно.
А теперь давайте посмотрим реальный мир — точно так же как и процесс, горутина может быть в состоянии blocked, running, waiting. Blocked — например горутина выполняет системный вызов, планировщик припарковывает эту горутину и освобождает тред, тред берет следующие горутину из очереди и выполняет ее. Как только горутина получила ответ, она попадает в очередь и как только будет свободный тред — продолжит свое выполнение. И это все в рамках одного процесса. Потому можно на одной машине запускать десятки тысяч горутин.
В данном случае треды не простаивают и полностью утилизированы, в отличии от любого другого языка с тредами (в java, например, когда тред будет выполнять блокирующий вызов — тред будет заблокирован).
В целом, почитайте про планировщик и в целом про райтайм в Go, что бы потом не писать тут глупости.
оо, мне даже интересно как будет выглядеть на python, например, вот такое:
Создается 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
}
скажем так, в любом языке вы можете такое сделать (как easyjson). Для компилятора все это будут комментарии.
Ну кроме вот тех случаев с CGO и директивами.
В Go есть такие вещи как директивы и CGO.
Например `//go:noescape` директива функции, она учитывается компилятором.
В тоже время `// go:noescape` — просто комментарий (пробел есть).
Дальше ж, разработчики начали такое же использовать, например, для генерации кода. В статье упоминается easyjson — он генерит код для cериализация/десериализация json. Ну и там используются комменты (но без пробела), где держат метаинформацию для генератора.
Я даже не знаю с чего начать, тем более не использовал корутины в python. Давайте уточню:
1. Каналы есть в python? Это все таки часть concurrency в Go.
2. Так же удобно работать с корутинами? Создавать (одно ключевое слово `go`), управлять (`sync.WaitGroup`, `sync.Once`, etc, `context`, select и range для каналов).
3. Как работает планировщик корутин в python? Мне вот нравится идея с work-stealing планировщиком.
1. А что нет?
2. image будет небольшого размера, билдинг такого image будет самым быстрым
3. А что нет?
4. А что нет? Вы на какой пункт отвечали? vgo уже в go 1.1 (да, пока под флагом). Если бы вы чуть больше интересовались Go, вы бы знали про обсуждения dep в Go команде и какие к нему были претензии. Его хотели включить в Go тулсет, после редизайнинга (почитайте твиттер тред от Russ Cox, на хакерньюс еще был).
5. А что нет?
6. Субъективно
7. Я уже писал об этом (даже в посте, где вы бегали и кричали про ошибки в Go). Опять тоже обсуждение начинать не хочу, тем более с вами.
я имею ввиду, что коммиты не зеркалируются, vgo — это
go modв отдельном репозитории. Сделано это для go 1.10 пользователей. Не думаю, что будут как-то отдельно развивать vgo, смысла нету две код базы поддерживать.Изменения не зеркалируют
Нет, vgo это прототип от Russ Cox.
Так модули в Go это и есть vgo — его Расс сделал и предложил включить в Go.
Не путайте людей.
А вот от это «Digital» прям несет некомпетентностью, тем более в тех компании.
А NATS, о господи, использует каналы. Видно, что вы никогда не программировали но Go и потому говорите такие глупости.
Даже так — вы что никогда не писали многопоточный код, что бы сравнивать это с очередями?
Да вы товарищь троль.
Я же пример привел — в java тред будет заблокирован, в Go будет выполнять горутину. Тредов мало, горутин много.
Какая чушь.
А NATS, о господи, использует каналы. Видно, что вы никогда не программировали но Go и потому говорите такие глупости.
Ну вот именно, потому костыли. В Go все изначально по другому, потому python и рядом не стоит.
Вы же помните, мы говорим про concurrency?
В Go есть планировщик, который ранит горутины на тредах. В один момент времени на одном треде будет раниться одна горутина. Да. Точно так же, как на одном ядре будет выполняться один процесс в одновременно.
А теперь давайте посмотрим реальный мир — точно так же как и процесс, горутина может быть в состоянии blocked, running, waiting. Blocked — например горутина выполняет системный вызов, планировщик припарковывает эту горутину и освобождает тред, тред берет следующие горутину из очереди и выполняет ее. Как только горутина получила ответ, она попадает в очередь и как только будет свободный тред — продолжит свое выполнение. И это все в рамках одного процесса. Потому можно на одной машине запускать десятки тысяч горутин.
В данном случае треды не простаивают и полностью утилизированы, в отличии от любого другого языка с тредами (в java, например, когда тред будет выполнять блокирующий вызов — тред будет заблокирован).
В целом, почитайте про планировщик и в целом про райтайм в Go, что бы потом не писать тут глупости.
для vgo с vim делаю так — проект в GOPATH и делаю
vgo mod -vendor.Уверен что скоро будет поддержка vgo. Goland вон уже умеет.
2. Легковесные goroutine vs. процессы — костыли.
Создается 10 goroutine, которые читают с одного канала и обрабатывают сообщение. Есть рутина, которая пишет в канал (не важно как, например, читает с файла и пишет в канал). Обработка сообщений затратный процесс (потому один пишет и много читают). Самый обычный кейс.
При этом, после Ctrl+C завершается работа всех goroutine и после этого приложение останавливается.
(набросал быстро, к качеству можно не придраться)
Ну кроме вот тех случаев с CGO и директивами.
Например `//go:noescape` директива функции, она учитывается компилятором.
В тоже время `// go:noescape` — просто комментарий (пробел есть).
Тоже самое в CGO:
А вот просто комментарий:
Дальше ж, разработчики начали такое же использовать, например, для генерации кода. В статье упоминается easyjson — он генерит код для cериализация/десериализация json. Ну и там используются комменты (но без пробела), где держат метаинформацию для генератора.
1. Каналы есть в python? Это все таки часть concurrency в Go.
2. Так же удобно работать с корутинами? Создавать (одно ключевое слово `go`), управлять (`sync.WaitGroup`, `sync.Once`, etc, `context`, select и range для каналов).
3. Как работает планировщик корутин в python? Мне вот нравится идея с work-stealing планировщиком.
> 4. concurrency
> 4. А что нет? Почти любой язык так может, даже python.
даже python? серьезно? Умеет как Go?
2. image будет небольшого размера, билдинг такого image будет самым быстрым
3. А что нет?
4. А что нет? Вы на какой пункт отвечали? vgo уже в go 1.1 (да, пока под флагом). Если бы вы чуть больше интересовались Go, вы бы знали про обсуждения dep в Go команде и какие к нему были претензии. Его хотели включить в Go тулсет, после редизайнинга (почитайте твиттер тред от Russ Cox, на хакерньюс еще был).
5. А что нет?
6. Субъективно
7. Я уже писал об этом (даже в посте, где вы бегали и кричали про ошибки в Go). Опять тоже обсуждение начинать не хочу, тем более с вами.