Читал. Для себя я получил достаточно данных, чтобы с уверенностью сказать, что TON и Telegram связаны напрямую, и что Telegram Systems LLP точно занимается разработкой TON, особенно после релиза на гитхабе — достаточно просто внимательно присмотреться. К чему конкретно — говорить не буду, зато скажу, что из репозитория можно даже узнать, на какой платформе скорее всего ведется основная разработка :)
Забавно, что упомянутая "техническая статья" Бородача теперь недоступна на медиуме.
Могли взять за базу другой блок-чейн о котором никто не знает и затереть исходных авторов
Вы бы хотя бы репозиторий посмотрели.
Ради бабла конечно! найти кучу наивных дурачков и впарить им эти койны, так и работают современные криптоаферы.
А можете подсказать, как мне на ton.org закинуть деньги и поучаствовать в этой замечательной афере? Обычно у криптоаферы красивый лендинг, а ton.org даже не резолвится. Какая-то странная афера получается. Можно сказать, конечно, что нужно подождать релиза, но опять же: столько стараний ради того, чтобы быть перечеркнутыми одним твитом Дурова, серьезно?
Так в этом и дело, что дуров его не PR-ит.
Мало смысла пиарить невышедший проект. Денег на разработку до релиза у них более, чем достаточно.
Мне на это все (дуров, телега, тоны) вообще пофиг
Именно поэтому вы пришли в статью и оставили комментарий. Прикольно будет, когда состоится релиз.
хотя примеров аферных криптовалют за последние годы было предостаточно.
Так как мне деньги кинуть в TON? Дайте уже ссылку на лендинг для хомячков.
Тогда 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.
Ну я же про корневой домен:
Читал. Для себя я получил достаточно данных, чтобы с уверенностью сказать, что TON и Telegram связаны напрямую, и что Telegram Systems LLP точно занимается разработкой TON, особенно после релиза на гитхабе — достаточно просто внимательно присмотреться. К чему конкретно — говорить не буду, зато скажу, что из репозитория можно даже узнать, на какой платформе скорее всего ведется основная разработка :)
Забавно, что упомянутая "техническая статья" Бородача теперь недоступна на медиуме.
Вы бы хотя бы репозиторий посмотрели.
А можете подсказать, как мне на ton.org закинуть деньги и поучаствовать в этой замечательной афере? Обычно у криптоаферы красивый лендинг, а ton.org даже не резолвится. Какая-то странная афера получается. Можно сказать, конечно, что нужно подождать релиза, но опять же: столько стараний ради того, чтобы быть перечеркнутыми одним твитом Дурова, серьезно?
Мало смысла пиарить невышедший проект. Денег на разработку до релиза у них более, чем достаточно.
Именно поэтому вы пришли в статью и оставили комментарий. Прикольно будет, когда состоится релиз.
Так как мне деньги кинуть в TON? Дайте уже ссылку на лендинг для хомячков.
Тогда 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 вкладывается и в докер.