Основная причина, почему Vercel выбрала Rust, а не Go (и написала эту статью) — им удалось купить мейнтейнеров SWC и получить полный контроль над проектом.
Аналог на Go (esbuild) не уступает по скорости и функциональности, а где-то даже превосходит решение на Rust. Единственная проблема — его пишет технический директор Figma, поэтому купить его затруднительно, а это противоречит бизнес-модели Vercel.
Раньше был Scaleway, который предоставлял dedicated ARM64, но они отказались из-за низкой надёжности. Где хостинги а ля Hetzner/Scaleway для ARM? Apple M1 даже найти уже намного легче (тот же Hetzner), чем Linux/aarch64.
В итоге остаётся только Amazon с их собственными Graviton, которые не сильно отличаются от того, что предлагает AMD, ну ещё и Oracle Cloud. Ещё есть куча китайских облаков, но там причина движения в сторону арма понятна, это отвязка от интела.
Для меня отсутствие предложений является хорошим индикатором, что нужно это мало кому. Даже на гитхабе приходится делать self-hosted раннеры, чтобы тестировать код на ARM64. На днях вот специально поднимал в оракловом облаке для опенсорс проектов.
Описание API будет чуть позже, я как раз разбираюсь с тем, как правильно работать с обновлениями.
Будет отдельная статья про это, в том числе про повторную отправку, систему диспетчеризации обновлений, ack-и, пинги, параллельные соединения их их пулинг, скачивание и загрузку файлов, соединения к CDN и т.д.
Чем дальше, тем больше будет упор на описание специфики Telegram.
Первоначально я действительно не тестировал на tmpfs, полагая, что файл целиком уместился в кеше. Сейчас специально сделал на tmpfs, результаты аналогичные:
$ time ./wc /tmp/space/test.txt
15000001 44774631 1841822210 /tmp/space/test.txt
real 0m2,842s
user 0m2,784s
sys 0m0,395s
$ time LANG=C LC_ALL=C wc /tmp/space/test.txt
15000000 44774631 1871822210 /tmp/space/test.txt
real 0m4,447s
user 0m4,226s
sys 0m0,209s
$ df -h | grep /tmp
tmpfs 3,0G 1,8G 1,3G 59% /tmp/space
А еще я сейчас заметил, что у моего варианта отличается и количество characters от вывода wc, наверное, где-то у меня ошибка или это те самые непечатные символы.
Я успел прочитать сообщение до редактирования и поэтому отвечу: я запускал тесты несколько раз, убедившись, что файл в кеше и программы находятся хотя бы примерно в одинаковых условиях.
Ну и я не ставил себе целью произвести абсолютно точные измерения, очевидно, что wc делает больше работы, да и ресурсов потребляет меньше (гошный рантайм ест несколько мегабайт + bufio.Scanner имеет довольно большой максимальный буфер). Ни в коем случае не хочу сказать что-то вроде "го побеждает си в 20 строчек".
Даже очень наивная реализация на го оказывается быстрее wc (скорее всего из-за буферизации или еще каких срезанных углов):
package main
import (
"bufio"
"fmt"
"os"
"flag"
"strings"
)
func main() {
flag.Parse()
file, err := os.Open(flag.Arg(0))
if err != nil {
panic(err)
}
scanner := bufio.NewScanner(file)
var lines, words, characters int
for scanner.Scan() {
lines++
line := scanner.Text()
characters += len(line)
words += len(strings.Split(line, " "))
}
fmt.Printf("%10d %10d %10d %s\n", lines, words, characters, file.Name())
}
$ time ./wc test.txt
15000001 44774631 1841822210 test.txt
real 0m2,897s
user 0m2,873s
sys 0m0,492s
$ time LANG=C LC_ALL=C wc test.txt
15000000 44774631 1871822210 test.txt
real 0m4,419s
user 0m4,196s
sys 0m0,213s
Откуда-то взялась лишняя строчка, но мне не интересно в этом разбираться, как и дальше оптимизировать этот код.
При этом мы честно поддерживаем юникод, программа переносима и кросс-компилируется в нативные статические бинари на все поддерживаемые платформы одной командой.
Прокси сохраняет значение в sum.golang.org, который по сути дерево Меркла, и сейчас там изменить хеш версии невозможно. Зато можно криптографически проверить все изменения версий :) Кстати, это всё работает по умолчанию в гошном тулинге начиная с версии 1.13, дополнительно устанавливать ничего не нужно.
удалить пакет из прокси
В общем случае невозможно, только если вручную мейнтейнером прокси в очень исключительных случаях.
UPD: забыл сказать, сам пакет прокси тоже хранит вечно, т.е. если даже удалить репо из гитхаба, пакет останется.
Не получится, там всё очень жестко.
Т.е. если вы задеплоили пакет v1.0.1 (по сути сделав git tag v1.0.1), то изменить или удалить его невозможно. Да и деплой происходит не явно, никто в прокси ничего не пушит, просто тегают новую версию в системе контроля версий и всё автоматически подтягивается при первой загрузке.
Вывезет, если это будет просто signaling, а трафик станет ходить по WebRTC. Сейчас ничего не мешает сделать эффектный peer-to-peer хостинг, все технологии есть, нужно просто правильно их собрать.
И чем больше людей одновременно смотрят одно видео, тем эффективнее эта система работает – да пусть хоть миллиард человек смотрит, будут просто тянуть кусочки видео друг от друга.
Но если такая альтернатива появится и станет сколько нибудь популярной, гугл начнет саботировать её, ведь он владеет самым популярным браузером на планете – достаточно всего лишь тихо испортить ICE механизм для этой платформы и всё. Даже если это обнаружат, гугл просто скажет "ой, это был баг" и выпустит новый "баг" через пару недель.
И даже https://github.com/diesel-rs/diesel подсвечивается? Ничего себе!
А можете, пожалуйста, показать?
Что это делает в хабе Go и зачем тут тег "rust is faster than go"?
Анимированные эмодзи отключаются. Стикеры нет, но их можно вежливо попросить не использовать.
Я, например, не хочу видеть голосовые сообщения :)
Oracle как раз сдаёт ARM vCPU, но на рынке он да амазон.
Scaleway давал ARM в сегменте Hetzner (вроде бы и dedicated, и vCPU, но насчет последнего не уверен), но потом отказался от затеи.
Ну да, esbuild не только транспайлер, но и бандлер. Поэтому я и написал, что "где-то даже превосходит".
Основная причина, почему Vercel выбрала Rust, а не Go (и написала эту статью) — им удалось купить мейнтейнеров SWC и получить полный контроль над проектом.
Аналог на Go (esbuild) не уступает по скорости и функциональности, а где-то даже превосходит решение на Rust. Единственная проблема — его пишет технический директор Figma, поэтому купить его затруднительно, а это противоречит бизнес-модели Vercel.
А где можно найти эти сервера и виртуалки?
Раньше был Scaleway, который предоставлял dedicated ARM64, но они отказались из-за низкой надёжности. Где хостинги а ля Hetzner/Scaleway для ARM? Apple M1 даже найти уже намного легче (тот же Hetzner), чем Linux/aarch64.
В итоге остаётся только Amazon с их собственными Graviton, которые не сильно отличаются от того, что предлагает AMD, ну ещё и Oracle Cloud. Ещё есть куча китайских облаков, но там причина движения в сторону арма понятна, это отвязка от интела.
Для меня отсутствие предложений является хорошим индикатором, что нужно это мало кому. Даже на гитхабе приходится делать self-hosted раннеры, чтобы тестировать код на ARM64. На днях вот специально поднимал в оракловом облаке для опенсорс проектов.
Нет, только лишь библиотека на go, самый близкий аналог это tdlib.
Но на основе этой библиотеки можно будет сделать и графический интерфейс.
Описание API будет чуть позже, я как раз разбираюсь с тем, как правильно работать с обновлениями.
Будет отдельная статья про это, в том числе про повторную отправку, систему диспетчеризации обновлений, ack-и, пинги, параллельные соединения их их пулинг, скачивание и загрузку файлов, соединения к CDN и т.д.
Чем дальше, тем больше будет упор на описание специфики Telegram.
Спасибо, завёл issue.
Попробуем не раздувать бинарники там, где в этом нет необходимости.
Первоначально я действительно не тестировал на tmpfs, полагая, что файл целиком уместился в кеше. Сейчас специально сделал на tmpfs, результаты аналогичные:
А еще я сейчас заметил, что у моего варианта отличается и количество characters от вывода wc, наверное, где-то у меня ошибка или это те самые непечатные символы.
Я успел прочитать сообщение до редактирования и поэтому отвечу: я запускал тесты несколько раз, убедившись, что файл в кеше и программы находятся хотя бы примерно в одинаковых условиях.
Ну и я не ставил себе целью произвести абсолютно точные измерения, очевидно, что wc делает больше работы, да и ресурсов потребляет меньше (гошный рантайм ест несколько мегабайт + bufio.Scanner имеет довольно большой максимальный буфер). Ни в коем случае не хочу сказать что-то вроде "го побеждает си в 20 строчек".
Полностью с вами согласен, добавил свой вариант, чтобы сделать абсурдность сравнения еще более очевидной :)
Даже очень наивная реализация на го оказывается быстрее wc (скорее всего из-за буферизации или еще каких срезанных углов):
Откуда-то взялась лишняя строчка, но мне не интересно в этом разбираться, как и дальше оптимизировать этот код.
При этом мы честно поддерживаем юникод, программа переносима и кросс-компилируется в нативные статические бинари на все поддерживаемые платформы одной командой.
Было бы забавно тут увидеть ещё и статью Дуров не имеет никакого отношения к TON
:)
Прокси сохраняет значение в sum.golang.org, который по сути дерево Меркла, и сейчас там изменить хеш версии невозможно. Зато можно криптографически проверить все изменения версий :) Кстати, это всё работает по умолчанию в гошном тулинге начиная с версии 1.13, дополнительно устанавливать ничего не нужно.
В общем случае невозможно, только если вручную мейнтейнером прокси в очень исключительных случаях.
UPD: забыл сказать, сам пакет прокси тоже хранит вечно, т.е. если даже удалить репо из гитхаба, пакет останется.
Не получится, там всё очень жестко.
Т.е. если вы задеплоили пакет
v1.0.1(по сути сделавgit tag v1.0.1), то изменить или удалить его невозможно. Да и деплой происходит не явно, никто в прокси ничего не пушит, просто тегают новую версию в системе контроля версий и всё автоматически подтягивается при первой загрузке.Есть sum.golang.org, можно почитать описание, если кратко, это проверяемый прозрачный лог хешей для модулей.
Уже есть https://proxy.golang.org/, а для зеркал https://github.com/gomods/athens. Добро пожаловать в 2100!
Go вполне удобно кросс-компилируется под поддерживаемые платформы, например.
Вывезет, если это будет просто signaling, а трафик станет ходить по WebRTC. Сейчас ничего не мешает сделать эффектный peer-to-peer хостинг, все технологии есть, нужно просто правильно их собрать.
И чем больше людей одновременно смотрят одно видео, тем эффективнее эта система работает – да пусть хоть миллиард человек смотрит, будут просто тянуть кусочки видео друг от друга.
Но если такая альтернатива появится и станет сколько нибудь популярной, гугл начнет саботировать её, ведь он владеет самым популярным браузером на планете – достаточно всего лишь тихо испортить ICE механизм для этой платформы и всё. Даже если это обнаружат, гугл просто скажет "ой, это был баг" и выпустит новый "баг" через пару недель.