Тогда MTProxy тоже скам, потому что пересекаются по коммитерам. И вообще, стиль ведения репозиториев у ton и у телеграмовских уж слишком похож.
Допустим, что кто-то настолько заморочился, что создал дизайн документы на сотни страниц, написал кучу работающего кода, но ради чего? Достаточно Дурову сказать прямо, что он не имеет отношения к TON, и вся "афера" разрушится. Я профита никакого не вижу, зато до официального полного запуска вполне логично сохранять молчание и снижать множество рисков, особенно если проект сложный и есть вероятность факапов.
Отсутствие generics не помешало Kubernetes развиться до текущего состояния.
А так конечно необходимость преувеличивают.
Не все пишут проекты уровня Kubernetes, да и проблема обычно решается другим подходом к проектированию, без попыток писать на Go как на C#, Rust или Python.
Я не погружался в то, что сделали в кодовой базе Kubernetes, так что не могу ничего сказать по этому поводу, но предполагаю, что проблему можно было решить иначе. Судя по последним изменениям в k8s.io/apimachinery, наблюдается движения к более строгой типизации.
Пятилетний опыт коммерческой разработки на Go показал, что дженерики не нужны для большинства решаемых задач (но это не значит, что с ними в некоторых местах было бы удобнее и проще). Но вам, конечно, виднее.
Я скорее не про себя, а про команду го и её мнение на этот счёт, да и про сообщество.
Дженерики нужны, но не настолько, чтобы бежать их пилить сломя голову – позиция, которая была очень давно и которой придерживалось большинство. "Мы не знаем, как их сейчас сделать правильно" и вот это вот всё.
Я как раз 5 лет на го и пишу, так что с моей точки зрения всё происходило примерно так, и данный пропозал – логичное продолжение работы над языком.
Может быть со стороны это действительно воспринимается иначе, особенно если быть предвзятым к этому языку.
Необходимость дженериков была понятна изначально.
Было несколько итераций с большими паузами.
Просто в го не хотят бездумно запиливать новые фичи, было желание сделать правильно и не наступить на грабли. Необходимость дженериков часто преувеличивают, действительно нужны они в довольно редких случаях, поэтому фокус был на другое и с ними не спешили, стараясь отполировать решение.
Кубернетис с докером прекрасно написали без дженериков, да.
Простота парсера и сохранение привычного для го синтаксиса это не религиозные соображения.
Для человека, который достаточно долго пишет на го, параметризация через скобки выглядит привычнее.
Просто так делать "как в других языках" не получится.
Юнит тесты позволяют быстрее изменять существующий код, этот эффект в расчетах не учтен.
Кроме того, тестируемый код приходится писать менее связанным с другими частями проекта, что косвенно улучшает архитектуру.
Уменьшение вероятности ошибки далеко не единственный результат юнит-тестирования, строить выводы о миллиардных убытках на выбранной модели весело, конечно, но не совсем корректно.
Я потом попробовал наивно распараллелить — получилось медленнее (~770ms), оверхед на рантайм высокий (в основном это блокировки и шедулинг горутин), ну и сложность решения выше даже при наивном подходе.
Этот оверхед можно смягчать, вводя нетривиальную модель воркеров как в fasthttp, но это уже сильно сложнее и в ~200 строчек кода не влезает.
total debtors: 2
total time: 559.910525ms
Первая коллекторская, Рога и копыта, Шестерочка:
123, 2128506, 234, 456, 788, 789
910000000
Казачий спас, Святой престол:
234567, 345678, 666
433200000
Для сравнения: предыдущая версия на Go показала 2.40s, ваша версия на Rust: 1.51s.
Код можно упростить и структурировать, но основная идея — если парсить потоково и сразу агрегировать, то получается быстро.
Не команда, а система матч-мейкинга. Команды формируются автоматически на основании некоторого рейтинга, который отображает (теоретически) умение играть. У бустануого аккаунта рейтинг искусственно завышен (отображает не акрлл владельца аккаунта, а "бустера"), что ломает всю систему подбора и балансировки рейтинга.
Я сейчас посмотрел, и мне кажется, что RFC в IETF, IAB и ISOC не пересекаются, и RFC однозначно можно было найти по номеру (до тех пор, пока не появились ржавые RFC, которые уже пересекаются).
Я скорее про ссылки в коде и документации. Ссылаются ли в коде на RFC из Rust'a?
Допустим, когда я вижу что-то типа RFC 5389 Section 15.2, я понимаю, что это ссылка на описание STUN, аттрибут XOR-MAPPED-ADDRESS.
Не волнуйтесь, по косвенным данным вас уже спокойно можно вычислить и без какой либо биометрии ;)
Пользуетесь мобильной связью, интернетом, оплачиваете покупки карточкой? На вас уже давно собран достаточный массив данных, чтобы ничего интегрировать и не пришлось. Везде стоят камеры, сопоставить данные не то, чтобы трудно.
Тогда MTProxy тоже скам, потому что пересекаются по коммитерам. И вообще, стиль ведения репозиториев у ton и у телеграмовских уж слишком похож.
Допустим, что кто-то настолько заморочился, что создал дизайн документы на сотни страниц, написал кучу работающего кода, но ради чего? Достаточно Дурову сказать прямо, что он не имеет отношения к TON, и вся "афера" разрушится. Я профита никакого не вижу, зато до официального полного запуска вполне логично сохранять молчание и снижать множество рисков, особенно если проект сложный и есть вероятность факапов.
Для чего Дурову пиарить невышедший проект — ради звездочек на гитхабе?
Тогда уж можно так:
:D
А с этим случайно не помогут контракты из недавно предложенного варианта дженериков для го?
Отсутствие generics не помешало Kubernetes развиться до текущего состояния.
Не все пишут проекты уровня Kubernetes, да и проблема обычно решается другим подходом к проектированию, без попыток писать на Go как на C#, Rust или Python.
Я не погружался в то, что сделали в кодовой базе Kubernetes, так что не могу ничего сказать по этому поводу, но предполагаю, что проблему можно было решить иначе. Судя по последним изменениям в
k8s.io/apimachinery, наблюдается движения к более строгой типизации.Пятилетний опыт коммерческой разработки на Go показал, что дженерики не нужны для большинства решаемых задач (но это не значит, что с ними в некоторых местах было бы удобнее и проще). Но вам, конечно, виднее.
Вроде бы обсуждался вариант с go fix для подобных вещей, когда можно заменить код на эквивалентный автоматически.
Я скорее не про себя, а про команду го и её мнение на этот счёт, да и про сообщество.
Дженерики нужны, но не настолько, чтобы бежать их пилить сломя голову – позиция, которая была очень давно и которой придерживалось большинство. "Мы не знаем, как их сейчас сделать правильно" и вот это вот всё.
Я как раз 5 лет на го и пишу, так что с моей точки зрения всё происходило примерно так, и данный пропозал – логичное продолжение работы над языком.
Может быть со стороны это действительно воспринимается иначе, особенно если быть предвзятым к этому языку.
Необходимость дженериков была понятна изначально.
Было несколько итераций с большими паузами.
Просто в го не хотят бездумно запиливать новые фичи, было желание сделать правильно и не наступить на грабли. Необходимость дженериков часто преувеличивают, действительно нужны они в довольно редких случаях, поэтому фокус был на другое и с ними не спешили, стараясь отполировать решение.
Кубернетис с докером прекрасно написали без дженериков, да.
Простота парсера и сохранение привычного для го синтаксиса это не религиозные соображения.
Для человека, который достаточно долго пишет на го, параметризация через скобки выглядит привычнее.
Просто так делать "как в других языках" не получится.
Юнит тесты позволяют быстрее изменять существующий код, этот эффект в расчетах не учтен.
Кроме того, тестируемый код приходится писать менее связанным с другими частями проекта, что косвенно улучшает архитектуру.
Уменьшение вероятности ошибки далеко не единственный результат юнит-тестирования, строить выводы о миллиардных убытках на выбранной модели весело, конечно, но не совсем корректно.
Вот мне интересно, почему именно "убийца"? Настолько убийственный Tupperware, что без Kubernetes в заголовке на статью не кликают что ли?
Я потом попробовал наивно распараллелить — получилось медленнее (~770ms), оверхед на рантайм высокий (в основном это блокировки и шедулинг горутин), ну и сложность решения выше даже при наивном подходе.
Этот оверхед можно смягчать, вводя нетривиальную модель воркеров как в fasthttp, но это уже сильно сложнее и в ~200 строчек кода не влезает.
Наткнулся на статью, удалось написать на go без рефлексии и относительно типобезопасно (156 строк), получилось 559ms.
https://gist.github.com/ernado/9d6bb51ab91887cc02a9540df4fb535d
Для сравнения: предыдущая версия на Go показала 2.40s, ваша версия на Rust: 1.51s.
Код можно упростить и структурировать, но основная идея — если парсить потоково и сразу агрегировать, то получается быстро.
Может быть проблема в том, что безопасность в бесплатный эластик не завезли, пока Амазон не вынудил?
Не команда, а система матч-мейкинга. Команды формируются автоматически на основании некоторого рейтинга, который отображает (теоретически) умение играть. У бустануого аккаунта рейтинг искусственно завышен (отображает не акрлл владельца аккаунта, а "бустера"), что ломает всю систему подбора и балансировки рейтинга.
Я сейчас посмотрел, и мне кажется, что RFC в IETF, IAB и ISOC не пересекаются, и RFC однозначно можно было найти по номеру (до тех пор, пока не появились ржавые RFC, которые уже пересекаются).
Может я чего-то не понимаю?
О, спасибо! С таким форматом документации проблем не должно быть, удобно.
Я скорее про ссылки в коде и документации. Ссылаются ли в коде на RFC из Rust'a?
Допустим, когда я вижу что-то типа RFC 5389 Section 15.2, я понимаю, что это ссылка на описание STUN, аттрибут XOR-MAPPED-ADDRESS.
Вот мне интересно, как внутри раста различают RFC которые IETF и свои?
Да, только на Windows. Мне кажется, что вполне логично сделать их доступными, раз уж Microsoft вкладывается и в докер.
Есть докер и для винды, я собираю и тестирую в докере под Windows несколько проектов на go.
Нужно только выбрать windows containers.
Или проблема в тулинге, который сложно использовать внутри контейнера?
Не волнуйтесь, по косвенным данным вас уже спокойно можно вычислить и без какой либо биометрии ;)
Пользуетесь мобильной связью, интернетом, оплачиваете покупки карточкой? На вас уже давно собран достаточный массив данных, чтобы ничего интегрировать и не пришлось. Везде стоят камеры, сопоставить данные не то, чтобы трудно.