Forwarded from igrishaev
Когда неподготовленный человек видит Лисп, он как-то реагирует: хихикает, лепит эмодзи, вовлекает других, словом — переживает. В такую минуту он напоминает школьника, который принес эротический журнал: смотрит на груди и попы, конфузится, краснеет, показывает другим под партой. Вроде бы интересно, но что с этим делать — не понятно.
Хорошо, если бы программистам объяснили: Лисп — лучший способ записать код. Любой язык можно улучшить хотя бы тем, что сделать синтаксис лиспо-подобным. Пусть даже парадигма останется прежней.
У скобочной записи есть преимущество: каждое выражение имеет начало и конец. Убедитесь, что прочли последнее предложение вдумчиво. В Лиспе каждая форма имеет начало и конец. В других языках — нет.
Предположим, я вижу выражение
Значит ли это, что выражение закончено? Конечно нет. За
Кроме того, что выражение определяется "на глазок", сюда вкрадывается приоритет операторов:
В то время на Лиспе первое выражение будет таким:
Скобки задают границы. Если скобка закрылась, то выражение закончилось, точка. Все, что следует дальше, относится ко внешнему выражению. Второе выражение сводит на нет котовасию с приоритетом операторов:
Все задано явно, вопросов быть не может. Вы, конечно, скажете, что приоритет умножения известен каждому школьнику? Тогда счастливой отладки дебажить что-то такое:
Из сказанного следует, что в Лиспе удобно работать с выражениями. Например, я могу выделить текущую форму. Обратите внимание — форму! Не метод, не сложение чисел, не класс, а именно форму! Потому что в Лиспе все это — форма. Мне не нужны хоткеи "Select method", "Select class", "Select whatever". Мне достаточно одной клавиши, чтобы покрыть все случаи.
Формы в Лиспе можно разбивать и объединять. Стоит нажать кнопку, и выражение
Форма может поглощать другие формы. Например, у меня есть код:
Теперь нужно, чтобы форма была внутри условия. Прямо над ней я пишу:
Далее, находясь внутри
Разумеется, есть другая кнопка, чтобы "выплюнуть" форму, и я получу то, что было до поглощения.
Каждый думает, что к нему это не относится, ведь он же пишет не на Лиспе. Но вот реальный пример на Джаве с цепочкой футур:
Каждый видит в меру своей испорченности, но я вижу здесь Лисп. Ему немного не повезло: нужно только переставить скобки, и получится нормально. Но вот курьез: Джава-человек в упор этого не видит. Для него это по-прежнему код на Джаве, а переставишь скобки — и все, ржака.
Теперь нужно изменить код так, чтобы
Хорошо, если бы программистам объяснили: Лисп — лучший способ записать код. Любой язык можно улучшить хотя бы тем, что сделать синтаксис лиспо-подобным. Пусть даже парадигма останется прежней.
У скобочной записи есть преимущество: каждое выражение имеет начало и конец. Убедитесь, что прочли последнее предложение вдумчиво. В Лиспе каждая форма имеет начало и конец. В других языках — нет.
Предположим, я вижу выражение
x = foo + barЗначит ли это, что выражение закончено? Конечно нет. За
bar вполне может быть продолжение:x = foo + bar * kek + lolКроме того, что выражение определяется "на глазок", сюда вкрадывается приоритет операторов:
bar * kek нельзя разорвать.В то время на Лиспе первое выражение будет таким:
(define x (+ foo bar))Скобки задают границы. Если скобка закрылась, то выражение закончилось, точка. Все, что следует дальше, относится ко внешнему выражению. Второе выражение сводит на нет котовасию с приоритетом операторов:
(define x (+ foo (* bar kek) lol))Все задано явно, вопросов быть не может. Вы, конечно, скажете, что приоритет умножения известен каждому школьнику? Тогда счастливой отладки дебажить что-то такое:
Some shit = foo && bar || test ^ foo;Из сказанного следует, что в Лиспе удобно работать с выражениями. Например, я могу выделить текущую форму. Обратите внимание — форму! Не метод, не сложение чисел, не класс, а именно форму! Потому что в Лиспе все это — форма. Мне не нужны хоткеи "Select method", "Select class", "Select whatever". Мне достаточно одной клавиши, чтобы покрыть все случаи.
Формы в Лиспе можно разбивать и объединять. Стоит нажать кнопку, и выражение
(+ foo bar) становится просто + foo bar. Далее я могу что-то сделать с его элементами. Форму можно двигать выше, ниже по текущему уровню вложенности. Можно втолкнуть ее внутрь. Можно вытолкнуть наверх из-под условия.Форма может поглощать другие формы. Например, у меня есть код:
(do-some-stuff x y z)Теперь нужно, чтобы форма была внутри условия. Прямо над ней я пишу:
(when some-condition)
(do-some-stuff x y z)Далее, находясь внутри
when, я жму кнопку, и форма втягивает в себя следующую за ней форму, и получается:(when some-condition
(do-some-stuff x y z))Разумеется, есть другая кнопка, чтобы "выплюнуть" форму, и я получу то, что было до поглощения.
Каждый думает, что к нему это не относится, ведь он же пишет не на Лиспе. Но вот реальный пример на Джаве с цепочкой футур:
return prepare(sql, executeParams)
.thenCompose((PreparedStatement stmt) -> sendBind(portal, stmt, executeParams))
.thenCompose((Integer ignored) -> sendDescribePortal(portal))
.thenCompose((Integer ignored) -> sendExecute(portal, executeParams.maxRows()))
.thenCompose((Integer ignored) -> sendClosePortal(portal))
.thenCompose((Integer ignored) -> sendCloseStatement(stmt))
.thenCompose((Integer ignored) -> sendSync())
.thenCompose((Integer ignored) -> sendFlush())
.thenCompose((Integer ignored) -> interact(executeParams))
.thenCompose((Result res) -> CompletableFuture.completedFuture(res.getResult()));Каждый видит в меру своей испорченности, но я вижу здесь Лисп. Ему немного не повезло: нужно только переставить скобки, и получится нормально. Но вот курьез: Джава-человек в упор этого не видит. Для него это по-прежнему код на Джаве, а переставишь скобки — и все, ржака.
Теперь нужно изменить код так, чтобы
stmt оставался в поле видимости на большее число шагов. Получится вот так:👍4❤🔥1🤨1 1
Малюткам DeFi-dev'ам. Часть 1.
Я успел немного копнуть в разработку DeFi. До этого я попрогал в целом для блокчейнов - смарт контакты, децентрализованное хранение (IPFS) и прочее всякое около. И был достаточно погружен в само явление DeFi как пользователь, холдер, ну и как многие пытался здесь навариться (лудка дело такое).
И если вы, как и я когда-то, заинтересовались программированием для DeFi и не знаете куда копать и с чего начать, то я надеюсь дать вам какую-то базу.
Первое, что стоит помнить и всегда держать в голове - в крипте очень много скама. Это благодатная почва как для лудоманов, так и для мошенников разных мастей (иногда они даже не осознают всю скам-природу их проекта). Идти сюда в надежде залутать шальные деньги - по сути тоже самое, что крутить слоты в надежде на драконий куш. Также слушать блогеров и прочих крипто-чуваков не стоит. Многие из них выезжают только за счет ставок против аудитории и инсайдов. Да и "большой" трейдинг в крипте держится на очень зыбких субстанциях.
Зато, на почве все еще зарождающегося рынка без внятного регулирования, находящейся до сих пор в серой зоне, каждый программист, которому интересна область финансов, может попробовать себя в деле и не прикасаться к реальным банкам с кучей бюрократии и сложностей.
По своей природе DeFi очень интересная область с точки зрения разработки. В ней сперва нашли себя шифропанки, затем стартаперы средней руки, а теперь и выросшие крипто-компании с десятками тысяч сотрудников. Если сейчас посмотреть сверху на рынок того, что тут делается, то за верхушкой айсберга крупных бирж скрывается много чего поменьше, и более интересного.
Вот такой список популярных видов проектов я накидал: AMM (автоматические маркет мейкеры), разного рода MEV автоматизация, анти-скам системы, лаунчпады, кредитование, управление активами, разные страховые системы, DEX'ы, DAO, Yield Farming, кроссчейн протоколы, NFT и прочие стартапчики использующие крипту как платежный шлюз.
В следующих частях обязательно рассмотрим каждый компонент DeFi с точки зрения потребителя и разработки в EVM и Solana сетях (может еще и Ton немного затронем, хотя тут пока с реальными DeFi проектами не густо).
Примерный список ключевых тем (на мой скромный взгляд) по DeFi: чем отличаются сети и чейны, обернутые токены, как запускаются токены, стейбл коины, пулл ликвидности, централизованные и децентрализованные платформы, автоматические маркет мейкеры, феномен Uniswap V3 и почему это круто, мемпулл, валидаторы, арбитраж, снайп и прочие боты (+ разные виды атак).
Что из того, что я перечислил выше вам знакомо? Что интересно в первую очередь?
Ну, и как мне кажется этих тем должно быть достаточно для старта DeFi-dev малютки. И, конечно, буду рад если мощные ребята докинут тем и помогут их разобрать.
Я успел немного копнуть в разработку DeFi. До этого я попрогал в целом для блокчейнов - смарт контакты, децентрализованное хранение (IPFS) и прочее всякое около. И был достаточно погружен в само явление DeFi как пользователь, холдер, ну и как многие пытался здесь навариться (лудка дело такое).
И если вы, как и я когда-то, заинтересовались программированием для DeFi и не знаете куда копать и с чего начать, то я надеюсь дать вам какую-то базу.
Первое, что стоит помнить и всегда держать в голове - в крипте очень много скама. Это благодатная почва как для лудоманов, так и для мошенников разных мастей (иногда они даже не осознают всю скам-природу их проекта). Идти сюда в надежде залутать шальные деньги - по сути тоже самое, что крутить слоты в надежде на драконий куш. Также слушать блогеров и прочих крипто-чуваков не стоит. Многие из них выезжают только за счет ставок против аудитории и инсайдов. Да и "большой" трейдинг в крипте держится на очень зыбких субстанциях.
Зато, на почве все еще зарождающегося рынка без внятного регулирования, находящейся до сих пор в серой зоне, каждый программист, которому интересна область финансов, может попробовать себя в деле и не прикасаться к реальным банкам с кучей бюрократии и сложностей.
По своей природе DeFi очень интересная область с точки зрения разработки. В ней сперва нашли себя шифропанки, затем стартаперы средней руки, а теперь и выросшие крипто-компании с десятками тысяч сотрудников. Если сейчас посмотреть сверху на рынок того, что тут делается, то за верхушкой айсберга крупных бирж скрывается много чего поменьше, и более интересного.
Вот такой список популярных видов проектов я накидал: AMM (автоматические маркет мейкеры), разного рода MEV автоматизация, анти-скам системы, лаунчпады, кредитование, управление активами, разные страховые системы, DEX'ы, DAO, Yield Farming, кроссчейн протоколы, NFT и прочие стартапчики использующие крипту как платежный шлюз.
В следующих частях обязательно рассмотрим каждый компонент DeFi с точки зрения потребителя и разработки в EVM и Solana сетях (может еще и Ton немного затронем, хотя тут пока с реальными DeFi проектами не густо).
Примерный список ключевых тем (на мой скромный взгляд) по DeFi: чем отличаются сети и чейны, обернутые токены, как запускаются токены, стейбл коины, пулл ликвидности, централизованные и децентрализованные платформы, автоматические маркет мейкеры, феномен Uniswap V3 и почему это круто, мемпулл, валидаторы, арбитраж, снайп и прочие боты (+ разные виды атак).
Что из того, что я перечислил выше вам знакомо? Что интересно в первую очередь?
Ну, и как мне кажется этих тем должно быть достаточно для старта DeFi-dev малютки. И, конечно, буду рад если мощные ребята докинут тем и помогут их разобрать.
👍7🔥6🦄2 2
Малюткам DeFi-dev'ам. Часть 2.
С майна первого Биткоина по текущий 2024 год успели родиться стони блокчейнов. Тысячи умерли еще в зачатке. И только десятки дожили до наших дней, и буквально парочка действительно окрепла и расправила крылья над полем децентрализованных финансов.
Сам феномен BTC, как валюты - потрясающий, как и идеи стоящие за блочейном Bitcoin, который по сути был создан ради нее. В отличии от классических финансов, где "хост" валюты - государство у Биткоина хостом служит множество нод, образующих сеть Bitcoin.
Чтобы обеспечить существование самого капитализированного токена без устали работают более 55к узлов сети (на август 2024). Они блок-за-блоком проверяют и передают другим узлам сети данные, которые вносят в них пользователи.
Если вы сталкивались с децентрализованным хранилищем (или хотя бы задавались вопросом), то вы скорее всего слышали о задаче двух генералов и CAP теореме. Если нет, то про первое обязательно прочитайте в Вики, а вот про CAP давайте поговорим.
CAP, где C - Согласованность, А - Доступность, P - устойчивость к разделению. Подумайте или вспомните, что предлагает вам ваша любимая база данных или брокер сообщений. Вспомнили? Как правило, просто достигаются два из трех правил, хотя сейчас с оговорками есть базы удовлетворяющие всем трем. С оговорками потому что достаточно немного поразмыслить, чтобы прийти логически к противоречивости наличия третьего. А теперь вернемся к блокчейн сетям.
Когда проектировалась сеть Биткоина, то она сразу задумывалась как децентрализованная сеть, по которой будут проходить финансовые операции. Потому нет ничего хуже отказа в обслуживании и невозможности обеспечить эту самую децентрализацию (все это с поправкой на реальность). А вот над согласованностью нужно поработать. И результатом работы стал механизм консенсуса PoW (Proof Of Work). Дорогой с точки зрения требуемых мощностей компьютеров и потребляемых энергоресурсов. И как показало время надежный и стабильный.
Еще в годы в университете я разрабатывал клиент для торрента. И вся эта возня с блокченами мне дико напоминала то, как работает этот самый торрент-протокол. Хотя, здесь идеи p2p сетей дошли до совершенно другого уровня.
У нас уже есть сети, объединяющие миллионы компьютеров (интернет). И даже есть те, кто готовы платить за электричество, чтобы хранить наши данные и держать их согласованными. В замен они получают придуманную нами награду. А давайте теперь будем выполнять на них какие-нибудь еще программы. С такими идеями в наш мир ворвался Ethereum.
EVM (Ethereum Virtual Machine) - децентрализованная виртуальная машина, сердце всего Ethereum. Для нее сперва пишется контакт на Solidity, который компилируется (с помощью компилятора solc) в специализированный байт код и выполняется на множестве нод. После компиляции полученную программу нужно также развернуть в сети. Если вам интересно все это пощупать, то возьмите Remix в качестве IDE, Hardhat для тестирования и Truffle для развертывания, ну и обязательно попробуйте развернуть стандартной либой ethers.js. Там все просто берем полученную после компиляции abi'шку (файл с содержащий информацию о внешнем интерфейсе вашей программы), бинарник (файл
С Эфиром работать приятнее всего (в следующих темах постараюсь вас в этом убедить). Пока обращусь к большинству: множество токенов и dapps запущенных на нем - подтверждение моих слов. Комьюнити взрослое, в DeFi понимающее, экосистема самая богатая (но и от нее иногда полыхает мое кресло), так что если решите делать проект - однозначно выбирайте Эфир.
Резюмируя, хоть Биткоин и стал ключевой фигурой в мире, однако, для DeFi это больше историческая фигура, а не что-то, чем сейчас дышит разработка в этой области. Так что его больше мы касаться не будем.
А вот с устройством EVM, нод, токенами на Эфире и вообще всем вокруг EVM-подобных сетей нам предстоит познакомиться далее.
С майна первого Биткоина по текущий 2024 год успели родиться стони блокчейнов. Тысячи умерли еще в зачатке. И только десятки дожили до наших дней, и буквально парочка действительно окрепла и расправила крылья над полем децентрализованных финансов.
Сам феномен BTC, как валюты - потрясающий, как и идеи стоящие за блочейном Bitcoin, который по сути был создан ради нее. В отличии от классических финансов, где "хост" валюты - государство у Биткоина хостом служит множество нод, образующих сеть Bitcoin.
Чтобы обеспечить существование самого капитализированного токена без устали работают более 55к узлов сети (на август 2024). Они блок-за-блоком проверяют и передают другим узлам сети данные, которые вносят в них пользователи.
Если вы сталкивались с децентрализованным хранилищем (или хотя бы задавались вопросом), то вы скорее всего слышали о задаче двух генералов и CAP теореме. Если нет, то про первое обязательно прочитайте в Вики, а вот про CAP давайте поговорим.
CAP, где C - Согласованность, А - Доступность, P - устойчивость к разделению. Подумайте или вспомните, что предлагает вам ваша любимая база данных или брокер сообщений. Вспомнили? Как правило, просто достигаются два из трех правил, хотя сейчас с оговорками есть базы удовлетворяющие всем трем. С оговорками потому что достаточно немного поразмыслить, чтобы прийти логически к противоречивости наличия третьего. А теперь вернемся к блокчейн сетям.
Когда проектировалась сеть Биткоина, то она сразу задумывалась как децентрализованная сеть, по которой будут проходить финансовые операции. Потому нет ничего хуже отказа в обслуживании и невозможности обеспечить эту самую децентрализацию (все это с поправкой на реальность). А вот над согласованностью нужно поработать. И результатом работы стал механизм консенсуса PoW (Proof Of Work). Дорогой с точки зрения требуемых мощностей компьютеров и потребляемых энергоресурсов. И как показало время надежный и стабильный.
Еще в годы в университете я разрабатывал клиент для торрента. И вся эта возня с блокченами мне дико напоминала то, как работает этот самый торрент-протокол. Хотя, здесь идеи p2p сетей дошли до совершенно другого уровня.
У нас уже есть сети, объединяющие миллионы компьютеров (интернет). И даже есть те, кто готовы платить за электричество, чтобы хранить наши данные и держать их согласованными. В замен они получают придуманную нами награду. А давайте теперь будем выполнять на них какие-нибудь еще программы. С такими идеями в наш мир ворвался Ethereum.
EVM (Ethereum Virtual Machine) - децентрализованная виртуальная машина, сердце всего Ethereum. Для нее сперва пишется контакт на Solidity, который компилируется (с помощью компилятора solc) в специализированный байт код и выполняется на множестве нод. После компиляции полученную программу нужно также развернуть в сети. Если вам интересно все это пощупать, то возьмите Remix в качестве IDE, Hardhat для тестирования и Truffle для развертывания, ну и обязательно попробуйте развернуть стандартной либой ethers.js. Там все просто берем полученную после компиляции abi'шку (файл с содержащий информацию о внешнем интерфейсе вашей программы), бинарник (файл
.bin, содержащий вашу програму), рассчитываем нужный газ (берем пока наугад с запасом) и делаем contract.deploy({ data: '0x' + bytecode }).send({}). С Эфиром работать приятнее всего (в следующих темах постараюсь вас в этом убедить). Пока обращусь к большинству: множество токенов и dapps запущенных на нем - подтверждение моих слов. Комьюнити взрослое, в DeFi понимающее, экосистема самая богатая (но и от нее иногда полыхает мое кресло), так что если решите делать проект - однозначно выбирайте Эфир.
Резюмируя, хоть Биткоин и стал ключевой фигурой в мире, однако, для DeFi это больше историческая фигура, а не что-то, чем сейчас дышит разработка в этой области. Так что его больше мы касаться не будем.
А вот с устройством EVM, нод, токенами на Эфире и вообще всем вокруг EVM-подобных сетей нам предстоит познакомиться далее.
🔥6❤🔥3 3🦄1
Малюткам DeFi-dev'ам. Часть 3.
И так, у нас есть какой-то байткод для EVM. Этот байткод мы будем выполнять сразу на всех нодах в сети Ethereum, тем самым никакой отдельный узел не может цензурировать наш контракт и исключает мухлеж со стороны держателей конкретной ноды (а уязвимости типа 51% решаются другими механиками).
Вообще каждой ноде не обязательно выполнять контракты, так в Ethereum сети есть три типа нод: полные, облегченные, архивные. Код смарт контрактов выполняют только полные и архивные узлы, а облегченные полагаются на них при валидации транзакций.
Так, а что же значит выполнить транзакцию?
Начнем с отправителя и получателя. Это два адреса. Адрес представляет собой 20-байтовое значения и начинаются с
И так мы - пользователь, отправитель. Наш получатель - контакт
Вот мы зашли на Eatherscan, нашли наш контракт (например, гляньте на контракт Uniswap V2, но далеко не все контракты открытые и есть тулзы для реверса из байткода) и увидели два метода
При вызове
И вот наша транзакция начала распространяться по сети и попадает в mempool (пул неподтвержденных транзакций).
Узлы начинают проверять достаточно ли у отправителя средств для выполнения транзакции, корректность подписи (можете почитать про алгоритм ECDSA) и верно ли указан Gas Limit. Валидаторы (или майнеры в случае с PoW) выбирают транзакции из mempool и включают их в блоки. Каждый блок имеет заголовок, который включает хеш предыдущего блока, временную метку, nonce и другие метаданные.
Когда уже одна из нод получит наше сообщение через вызов provider'а она начнет считать газ: ~700 газа за вызов функции (операция
Стоимость каждой операции в байткоде EVM хорошо задокументирована в спецификации и в нашем простом случае мы смогли легко сами посчитать значение, но так как контакты могут взаимодействовать с другими контрактами не вариант всегда вручную расчитывать цену.
Когда наконец транзакция включена в блок, узлы сети выполняют байткод транзакции на EVM: декодируют данные, вызывается функция, обновляется состояние.
И вот наконец происходит запись изменений в блокчейн, обновляя хранилище контракта. В дальнейшем это состояние будет доступно вызовом функции
И так, у нас есть какой-то байткод для EVM. Этот байткод мы будем выполнять сразу на всех нодах в сети Ethereum, тем самым никакой отдельный узел не может цензурировать наш контракт и исключает мухлеж со стороны держателей конкретной ноды (а уязвимости типа 51% решаются другими механиками).
Вообще каждой ноде не обязательно выполнять контракты, так в Ethereum сети есть три типа нод: полные, облегченные, архивные. Код смарт контрактов выполняют только полные и архивные узлы, а облегченные полагаются на них при валидации транзакций.
Так, а что же значит выполнить транзакцию?
Начнем с отправителя и получателя. Это два адреса. Адрес представляет собой 20-байтовое значения и начинаются с
Ox. Это может быть либо аккаунт пользователя (Externally Owned Accounts aka EOA), либо контракт, адрес которого генерируется при деплое.И так мы - пользователь, отправитель. Наш получатель - контакт
MessageStore который просто сохраняет наши сообщения на блокчейне. И да, помимо выполнения кода контакты могут записывать данные в блокчейн и хранить свое состояние.Вот мы зашли на Eatherscan, нашли наш контракт (например, гляньте на контракт Uniswap V2, но далеко не все контракты открытые и есть тулзы для реверса из байткода) и увидели два метода
setMessage(string memory newMessage и getMessage() public view returns (string memory). Чтож, пора его вызвать. Берем либу ethers тяп ляп и получаем что-то такое:
import { ethers } from "ethers";
const provider = new ethers.providers.InfuraProvider();
const privateKey = '...';
const wallet = new ethers.Wallet(privateKey, provider);
const abi = [
"function setMessage(string memory newMessage) public",
"function getMessage() public view returns (string memory)"
];
const contract = new ethers.Contract(contractAddress, abi, wallet);
const gasPrice = ethers.utils.parseUnits('20', 'gwei');
// Вызываем
const tx = await contract.setMessage("Запись от DeFi малюток!", { gasLimit: 21000, gasPrice });
// Ожидаем подтверждения транзакции
await tx.wait();
При вызове
contract.setMessage мы стартанули транзакцию от отправителя (wallet) в контракт. И вот наша транзакция начала распространяться по сети и попадает в mempool (пул неподтвержденных транзакций).
Узлы начинают проверять достаточно ли у отправителя средств для выполнения транзакции, корректность подписи (можете почитать про алгоритм ECDSA) и верно ли указан Gas Limit. Валидаторы (или майнеры в случае с PoW) выбирают транзакции из mempool и включают их в блоки. Каждый блок имеет заголовок, который включает хеш предыдущего блока, временную метку, nonce и другие метаданные.
Когда уже одна из нод получит наше сообщение через вызов provider'а она начнет считать газ: ~700 газа за вызов функции (операция
CALL),~20к газа за изменение (SSTORE),и 0 за RETURN. Тогда мы легко пройдем наш лимит (мы взяли чутка с излишком) и заплатим за это ~21000 газа * 20 Gwei = 420000 Gwei (0.00042 ETH). Если не указать явно gasLimit either за нас вызовет метод estimateGas - метод выполняет симуляцию транзакции и возвращает приблизительное количество газа, которое потребуется для её выполнения. В зависимости от состояния сети метод может ошибиться и переоценить (юзер заплатит больше) или недооценить стоимость (тогда транзакция упадет с out of gas). За 20 gwei за газ может случиться такое, что никто из валидаторв не возмет нашу транзакцию в обработку (либо ооч долго не будет брать) и если не указать gasPrice - either также может посчитать значение на основе условий сети. Стоимость каждой операции в байткоде EVM хорошо задокументирована в спецификации и в нашем простом случае мы смогли легко сами посчитать значение, но так как контакты могут взаимодействовать с другими контрактами не вариант всегда вручную расчитывать цену.
Когда наконец транзакция включена в блок, узлы сети выполняют байткод транзакции на EVM: декодируют данные, вызывается функция, обновляется состояние.
И вот наконец происходит запись изменений в блокчейн, обновляя хранилище контракта. В дальнейшем это состояние будет доступно вызовом функции
getMessage.Ethereum (ETH) Blockchain Explorer
Uniswap V2: Router 2 | Address: 0x7a250d56...659f2488d | Etherscan
Contract: Verified | Balance: $663,766.19 across 16 Chains | Transactions: 85,721,692 | As at Dec-25-2025 07:43:39 PM (UTC)
🔥2🦄2🌚1
Малюткам DeFi-dev'ам. Часть 4. MEV
И нет, мы не будем мяукать. MEV (aka Maximal Extractable Value) - такая мера прибыли, которую можно получить за счет включения, исключения или переупорядочивания транзакций внутри одного блока. Будем рассматривать на примере Ethereum. Напомню, что блок может включать в себя целый список транзакций и на этапе формирования мы все еще можем добавлять транзакции пока валидаторы (в PoS) не сформируют этот блок и не отправят в чейн (от сюда и БЛОКчейн если че). Тогда все, процесс необратим и включенные блоки иммутабельны.
В MEV'е есть три основные практики:
1. Фронтраннинг. Мы можем легально "подкупить" валидаторов назначив более высокую цену за газ и засунуть нашу транзакцию вперед других.
2. Бэкраннинг. Мы можем отправить транзакцию сразу после ожидаемой трнзакции, чтобы извлечь прыбыль из ее результатов
3. Сендвичинг. Тут мы отправляем две транзакции: одна перед и одна после, чтобы манипулировать ценой промежуточной транзакции.
Звучит как изи мани. Так оно и бывало особенно когда транзакции никак от этого не защищены. И тут надо понять что же нужно для такой атаки.
Перво-наперво нужен быстрый доступ к мемпулу - месту, где транзакции ожидают включения в блок. Это нам нужно, чтобы увидеть потенциальнуб транзакцию-жертву.
Дальше нам нужно научиться определить какую атаку мы хотим совершить. Например, это может быть арбитраж - покупка актива на одной бирже и продажи на другой, ликвидация на платформах кредитования или "фронтран", где мы может "опередить" транзакцию и получить с этого профит.
Понятное дело, что вручную это никто не делает. Для этого ребята пишут MEV ботов которые сразу и мониторят мемпулл, и определяют выгодную транзакцию, и совершают весь этот "атакующий" процесс, ну, и продают токены, приносят прибыль авторам.
Конечно, если бы все так было просто... Ребята из Эфира давно познали дзен и придумали несколько способов защиты от такой атаки (но есть чейны, где такая защита фундаментально невозможна, либо очень сложна и там пытаются вывезти на других механизмах, привет, Solana).
Эфир изменил механизм оплаты комиссии за транзакции (EIP-1559). Разделив комиссию на Base Fee (автоматически регулируется в зависимости от нагрузки на сеть) и Tip Fee (пользователи могут добавить чаевые валидаторам, но это все еще не гарантирует включение в блок). Это усложнило, не исключило возможности для MEV атак (подсчет рисков и прочая математика делает свое дело). Потому еще и появились отдельные проекты защищающие транзакции от MEV атак.
Тут можно выделить несколько проектов такой защиты.
- Flashbot и MEV-Geth - проект создает прозрачный рынок для MEV (не можешь победить - возглавь!). Во первых они устраивают аукцион и создают приватный пул, где майнеры/валидаторы могут выбирать их без риска фронтраннинга.
- Order Matching Protocols - протокол сопоставления ордеров. Также минимизирует ущерб от MEV. RFQ (Request For Quote) - сделки проходят оффчейн и только окончательная транзакция записывается на блокчейн, Batch Auctions - делаем ставки и ваша транзакция одновременно с другими (вместо поочередного выполнения)
- Time-locked Transactions - механизм на некоторых платформах, который откладывает включение транзакции в блок до поры-до времени.
- Privacy Enhancements - обеспечение приватности транзакций, скрывая их детали до включения блок. Тут популярны два протокола - zk-SNARKs и zk-Rollups.
- Decentralized Sequencers - похоже на RFQ, только децентрализованно (использую тн sequencers). Тут популярны проект Arbitrum и Optimism.
- Commit-Reveal Schemes - тут система такая: пользователь сперва отправляет commit (хеш транзакции), а затем раскрывает ее детали. Это предотвращает фронтраннинг, так как детали транзакции известны только после коммита.
В целом, все это не убило полностью, но сильно усложнило MEV-атаки. Вы всегда можете попробовать поискать другие уязвимости и более изощренные схемы. А я думаю, что пора перейти к расмотрению других блокчейнов.
И нет, мы не будем мяукать. MEV (aka Maximal Extractable Value) - такая мера прибыли, которую можно получить за счет включения, исключения или переупорядочивания транзакций внутри одного блока. Будем рассматривать на примере Ethereum. Напомню, что блок может включать в себя целый список транзакций и на этапе формирования мы все еще можем добавлять транзакции пока валидаторы (в PoS) не сформируют этот блок и не отправят в чейн (от сюда и БЛОКчейн если че). Тогда все, процесс необратим и включенные блоки иммутабельны.
В MEV'е есть три основные практики:
1. Фронтраннинг. Мы можем легально "подкупить" валидаторов назначив более высокую цену за газ и засунуть нашу транзакцию вперед других.
2. Бэкраннинг. Мы можем отправить транзакцию сразу после ожидаемой трнзакции, чтобы извлечь прыбыль из ее результатов
3. Сендвичинг. Тут мы отправляем две транзакции: одна перед и одна после, чтобы манипулировать ценой промежуточной транзакции.
Звучит как изи мани. Так оно и бывало особенно когда транзакции никак от этого не защищены. И тут надо понять что же нужно для такой атаки.
Перво-наперво нужен быстрый доступ к мемпулу - месту, где транзакции ожидают включения в блок. Это нам нужно, чтобы увидеть потенциальнуб транзакцию-жертву.
Дальше нам нужно научиться определить какую атаку мы хотим совершить. Например, это может быть арбитраж - покупка актива на одной бирже и продажи на другой, ликвидация на платформах кредитования или "фронтран", где мы может "опередить" транзакцию и получить с этого профит.
Понятное дело, что вручную это никто не делает. Для этого ребята пишут MEV ботов которые сразу и мониторят мемпулл, и определяют выгодную транзакцию, и совершают весь этот "атакующий" процесс, ну, и продают токены, приносят прибыль авторам.
Конечно, если бы все так было просто... Ребята из Эфира давно познали дзен и придумали несколько способов защиты от такой атаки (но есть чейны, где такая защита фундаментально невозможна, либо очень сложна и там пытаются вывезти на других механизмах, привет, Solana).
Эфир изменил механизм оплаты комиссии за транзакции (EIP-1559). Разделив комиссию на Base Fee (автоматически регулируется в зависимости от нагрузки на сеть) и Tip Fee (пользователи могут добавить чаевые валидаторам, но это все еще не гарантирует включение в блок). Это усложнило, не исключило возможности для MEV атак (подсчет рисков и прочая математика делает свое дело). Потому еще и появились отдельные проекты защищающие транзакции от MEV атак.
Тут можно выделить несколько проектов такой защиты.
- Flashbot и MEV-Geth - проект создает прозрачный рынок для MEV (не можешь победить - возглавь!). Во первых они устраивают аукцион и создают приватный пул, где майнеры/валидаторы могут выбирать их без риска фронтраннинга.
- Order Matching Protocols - протокол сопоставления ордеров. Также минимизирует ущерб от MEV. RFQ (Request For Quote) - сделки проходят оффчейн и только окончательная транзакция записывается на блокчейн, Batch Auctions - делаем ставки и ваша транзакция одновременно с другими (вместо поочередного выполнения)
- Time-locked Transactions - механизм на некоторых платформах, который откладывает включение транзакции в блок до поры-до времени.
- Privacy Enhancements - обеспечение приватности транзакций, скрывая их детали до включения блок. Тут популярны два протокола - zk-SNARKs и zk-Rollups.
- Decentralized Sequencers - похоже на RFQ, только децентрализованно (использую тн sequencers). Тут популярны проект Arbitrum и Optimism.
- Commit-Reveal Schemes - тут система такая: пользователь сперва отправляет commit (хеш транзакции), а затем раскрывает ее детали. Это предотвращает фронтраннинг, так как детали транзакции известны только после коммита.
В целом, все это не убило полностью, но сильно усложнило MEV-атаки. Вы всегда можете попробовать поискать другие уязвимости и более изощренные схемы. А я думаю, что пора перейти к расмотрению других блокчейнов.
Flashbots
A research and development organization mitigating the negative externalities posed by MEV.
1🔥3🦄2
Learn Clojure
Впервые о Clojure я услышал еще когда учился на Хекслете лет 8-9 назад. Тогда я еще не понимал всех прелестей, которые нам может принести LISP и реального применения функциональной парадигмы. Тогда я сосредоточился на JS и экосистеме вокруг. Трогая LISP'ы только в рамках первых трех глав СИКПа.
Года 4 назад я снова заинтересовался Clojure - посмотрел множество докладов, почитал первые книжки, порешал задачки и снова отложил, чтобы через полтора года вернуться.
И так я начал углубляться в Clojure 2.5 года назад. За это время я прошел несколько курсов, прочел 4 книги, посмотрел уйму докладов, сделал 3 проекта маленького-среднего размера и еще кучу забросил. Впечатления все еще самые позитивные, и разработка на нем все еще приносит самое большое удовольствие (а языков я успел попробовать множество) и на сколько же на нем приятнее работать с джавовыми либами, чем на самой Java. Теперь немного хотелось бы поделиться ресурсами, которыми стоит воспользоваться для изучения: доклады, курсы, книжки.
Пункт ноль - больше проникнуться. Я советую начать с простых материалов: подкстов (1, 2), ставшим классикой доклад Simple Made Easy, ответить еще себе на вопрос "почему", посмотреть что дает Clojure (и Datomic) в банкинге, да и такого оч много - сильные, крутые доклады про интересные вам прикладные области (например, активно развивается DS направление).
Впервые о Clojure я услышал еще когда учился на Хекслете лет 8-9 назад. Тогда я еще не понимал всех прелестей, которые нам может принести LISP и реального применения функциональной парадигмы. Тогда я сосредоточился на JS и экосистеме вокруг. Трогая LISP'ы только в рамках первых трех глав СИКПа.
Года 4 назад я снова заинтересовался Clojure - посмотрел множество докладов, почитал первые книжки, порешал задачки и снова отложил, чтобы через полтора года вернуться.
И так я начал углубляться в Clojure 2.5 года назад. За это время я прошел несколько курсов, прочел 4 книги, посмотрел уйму докладов, сделал 3 проекта маленького-среднего размера и еще кучу забросил. Впечатления все еще самые позитивные, и разработка на нем все еще приносит самое большое удовольствие (а языков я успел попробовать множество) и на сколько же на нем приятнее работать с джавовыми либами, чем на самой Java. Теперь немного хотелось бы поделиться ресурсами, которыми стоит воспользоваться для изучения: доклады, курсы, книжки.
Пункт ноль - больше проникнуться. Я советую начать с простых материалов: подкстов (1, 2), ставшим классикой доклад Simple Made Easy, ответить еще себе на вопрос "почему", посмотреть что дает Clojure (и Datomic) в банкинге, да и такого оч много - сильные, крутые доклады про интересные вам прикладные области (например, активно развивается DS направление).
YouTube
САМЫЙ ЖЕЛАННЫЙ ЯЗЫК ПРОГРАММИРОВАНИЯ / Отношение Яндекса к войне / Интервью с Clojure Developer
Гость сегодняшнего выпуска - Clojure-разработчик Андрей Руденко. Я узнал про Андрея из видео, в котором он дает лекцию про Clojure из автозака - "наш парень", подумал я :)
Первые два часа мы плотно поговорили про устройство языка и его экосистему, про списки…
Первые два часа мы плотно поговорили про устройство языка и его экосистему, про списки…
❤🔥3🔥2👍1
Для старта стоит пройти курс на code-basics. В нем есть весь необходимый материал, чтобы начать что-то делать. Однако, чтобы начать локально разрабатывать вам будет нужно проникнуться одним из отличий LISP'ов от других языков - интрактивным программированием. Немного схожий опыт разработки можно получить используя Quokka с JS'ом, но возможности REPL'а запущенного для Node.js программы довольно ограничены, да и синтаксис с мутабельностью мешают всему этому процессу.
Так что второе, что нужно будет научиться делать - работать с REPL'ом из вашего редактора (я за лучшим опытом также нырнул в emacs и для лиспов так на нем и остался). Тут выбор широкий - Clava для Vscode, Cursive для IDEA, CIDER для Emacs. По ссылкам туториалы по каждому варианту. И обязательно посмотреть как разные люди работают с REPL Driven Development (Show me your REPL). Также стоит настроить окружения (я продолжаю использовать Lein).
Теперь уже можно брать книжку. Первой книжкой по Clojure я рекомендую Clojure for the Brave and True.
Тут вы будеет в зоне серьезных знаний. И нужно будет еще больше разобраться в идиомах Clojure: Data Driven подход и DSL, Иммутабельность, Персистентные структуры и Ленивые Коллекции, в многопоточности.
Дальше еще немного докладиков и воршопов. Clojure для Java'истов (1, 2), для LISP'еров (1, 2), послушать про структуры данных (1, 2).
И уже можно переходить к более специфичной литературе. На русском есть две книжки от Ивана Гришаева: Clojure на производстве первый и второй том.
В ходе прочтения и закрепления тем на практике вы уже должны освоиться в clojure.core - основной стандартной библиотеке, в clojure.spec - мощной библиотекой для валидации (и даже генерации), с тестами, многопоточкой и немного с макросами.
По ходу дела для практики обязательно решать задачки на Exercism. И как они там закончатся (или раньше) уже приступать пилить свои проектики☺️ .
И если вы собираетесь писать web, то обязательно посмотрите про архитектуру web-приложений.
Также в Clojure нет полновесного фреймворка и люди сами собирают из библиотек свой мини-фреймворк. Есть более коробочные решения - biff и kit. Их однозначно стоит посмотреть. Мой выбор библиотек такой: integrant для клея всей системы, aero для конфигов, jetty+ring для сервера, роутинг с compojure, next-jdbc для бд и honeysql для построения sql, migratus для миграций, slingshot для исключений (кстати, вот крутой доклад почему в Clojure не прижилась Maybe монада), логгер - timbre, clj-http как http-клиент, cheshire для сериализации JSON'а.
А дальше путь бесконечный. Экосистема языка богатая, интересных концепций, помимо тех что вы изучите, еще много. Я еще не затронул ClojureScript - диалекта компилируемого в JS для Node.js и браузера для написания фронтенда. Если вас заинтересовало, и хотите стартануть - пишите мне, я обязательно помогу!
Так что второе, что нужно будет научиться делать - работать с REPL'ом из вашего редактора (я за лучшим опытом также нырнул в emacs и для лиспов так на нем и остался). Тут выбор широкий - Clava для Vscode, Cursive для IDEA, CIDER для Emacs. По ссылкам туториалы по каждому варианту. И обязательно посмотреть как разные люди работают с REPL Driven Development (Show me your REPL). Также стоит настроить окружения (я продолжаю использовать Lein).
Теперь уже можно брать книжку. Первой книжкой по Clojure я рекомендую Clojure for the Brave and True.
Тут вы будеет в зоне серьезных знаний. И нужно будет еще больше разобраться в идиомах Clojure: Data Driven подход и DSL, Иммутабельность, Персистентные структуры и Ленивые Коллекции, в многопоточности.
Дальше еще немного докладиков и воршопов. Clojure для Java'истов (1, 2), для LISP'еров (1, 2), послушать про структуры данных (1, 2).
И уже можно переходить к более специфичной литературе. На русском есть две книжки от Ивана Гришаева: Clojure на производстве первый и второй том.
В ходе прочтения и закрепления тем на практике вы уже должны освоиться в clojure.core - основной стандартной библиотеке, в clojure.spec - мощной библиотекой для валидации (и даже генерации), с тестами, многопоточкой и немного с макросами.
По ходу дела для практики обязательно решать задачки на Exercism. И как они там закончатся (или раньше) уже приступать пилить свои проектики
И если вы собираетесь писать web, то обязательно посмотрите про архитектуру web-приложений.
Также в Clojure нет полновесного фреймворка и люди сами собирают из библиотек свой мини-фреймворк. Есть более коробочные решения - biff и kit. Их однозначно стоит посмотреть. Мой выбор библиотек такой: integrant для клея всей системы, aero для конфигов, jetty+ring для сервера, роутинг с compojure, next-jdbc для бд и honeysql для построения sql, migratus для миграций, slingshot для исключений (кстати, вот крутой доклад почему в Clojure не прижилась Maybe монада), логгер - timbre, clj-http как http-клиент, cheshire для сериализации JSON'а.
А дальше путь бесконечный. Экосистема языка богатая, интересных концепций, помимо тех что вы изучите, еще много. Я еще не затронул ClojureScript - диалекта компилируемого в JS для Node.js и браузера для написания фронтенда. Если вас заинтересовало, и хотите стартануть - пишите мне, я обязательно помогу!
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
САМЫЙ ЖЕЛАННЫЙ ЯЗЫК ПРОГРАММИРОВАНИЯ / Отношение Яндекса к войне / Интервью с Clojure Developer
Гость сегодняшнего выпуска - Clojure-разработчик Андрей Руденко. Я узнал про Андрея из видео, в котором он дает лекцию про Clojure из автозака - "наш парень", подумал я :)
Первые два часа мы плотно поговорили про устройство языка и его экосистему, про списки…
Первые два часа мы плотно поговорили про устройство языка и его экосистему, про списки…
👍3🔥3 3😱2
Малюткам DeFi-dev'ам. Часть 5. Solana
Ничто не вечно под луной. Вот и блокчены рождаются и умирают. Кто-то сгорает ярко, а кто-то еще и заставляет обозлится на всю сферу после своего провала. Но новые блокчейны, как и другие программные продукты, всегда вдохновляются (воруют фичи) у своих конкурентов и толкают на развитие существующие решения. Каждый блокчейн пытался дать что-то уникальное, привлечь разработчиков, чтобы те пилили приложения для них, поднимали раунды и сливали деньги инвесторов (а иногда даже устраивали голландский штурвал инвестиций в проекты). Кто-то остается после бурного хайпа, а кто-то уходит, освобождая пространство для нового или старого. Так Solana пережила несколько взлетов, падений и снова взлетов. Давайте поговорим что же она предложила и почему привлекла к себе не только энтузиастов, но и трейдеров, скамеров и обычных программистов.
1. Пропускная способность. За все время Solana смогла на практике отстоять это заявление. Куча крупных запусков с жесткими буллранами без падений сети. Во многом этом работает благодаря механизму Proof of History. В целом реальный показатель - около 3k транзакций в секунду при комиссии менее $0.05, для сравнения на Эфире просто ~50 TPS с комиссией в бакс-два.
2. Низкие комиссии. По сути высокая пропускная способность также позволяет поддерживать низкие комиссии за транзакции. Что делает ее привлекательной для пользователей
3. Множество интересных архитектурных решений. Об этом поговорим еще далее, но Tower BFT (мод над PBFT), Gulf Stream (протокол пересылки транзакций), Sealevel (параллельная обработка смарт-контрактов) - также как дары, так и проклятие, но решения оказались рабочими, что скорее радует.
4. Экосистема и инструменты. При том, что Solana не совместима с EVM, для нее есть достаточно зрелая экосистема инструментов для разработчиков, чтобы реализовывать многие свои задумки или переносить проекты с EVM-like сетей. Контракты можно писать с использованием SDK на C или Rust (обычно выбирают Rust🤠 ), что тоже немного упрощает перекат в написание смарт-контрактов.
5. Развитая экосистема для DeFi. Что вам и надо, если вы хотите в инди-DeFi сегмент.
Минусы рассмотрим позже, а пока давайте о хорошем🙂 . Посмотрим на проекты, которые в экосистеме Solana достаточно стабильные и прибыльные, чтобы примерно понять, что на этом блокчейне можно сделать:
👉 AMM (Automatic Market Maker) проекты: Raydium, Orca, Meteora и самый популярный jupiter роутер
👉 JITO, Neon и подобные проекты расширяющие инфраструктуру экосистемы. JITO занимается оптимизацией транзакций в сети, а Neon интеграцией с EVM
👉 Переживающий новую волну хайпа Pumpfun, где запускают токены и стримят всякую дичь, тем самым ловят волну хайпа мем-коинов (как развлекаловка прикольный проект)
👉 Любые другие проекты, улучшающие жизнь трейдерам и авторам мем-коинов вроде @buybot
👉 Всякие кросс чейн проекты, типа Wormhole
👉 NFT и игровые проекты (более редкие гости, но тоже есть)
И мнооого чего еще, где благодаря своим сильным сторонам Solana привлекает, как разработчиков, так и пользователей.
Ничто не вечно под луной. Вот и блокчены рождаются и умирают. Кто-то сгорает ярко, а кто-то еще и заставляет обозлится на всю сферу после своего провала. Но новые блокчейны, как и другие программные продукты, всегда вдохновляются (воруют фичи) у своих конкурентов и толкают на развитие существующие решения. Каждый блокчейн пытался дать что-то уникальное, привлечь разработчиков, чтобы те пилили приложения для них, поднимали раунды и сливали деньги инвесторов (а иногда даже устраивали голландский штурвал инвестиций в проекты). Кто-то остается после бурного хайпа, а кто-то уходит, освобождая пространство для нового или старого. Так Solana пережила несколько взлетов, падений и снова взлетов. Давайте поговорим что же она предложила и почему привлекла к себе не только энтузиастов, но и трейдеров, скамеров и обычных программистов.
1. Пропускная способность. За все время Solana смогла на практике отстоять это заявление. Куча крупных запусков с жесткими буллранами без падений сети. Во многом этом работает благодаря механизму Proof of History. В целом реальный показатель - около 3k транзакций в секунду при комиссии менее $0.05, для сравнения на Эфире просто ~50 TPS с комиссией в бакс-два.
2. Низкие комиссии. По сути высокая пропускная способность также позволяет поддерживать низкие комиссии за транзакции. Что делает ее привлекательной для пользователей
3. Множество интересных архитектурных решений. Об этом поговорим еще далее, но Tower BFT (мод над PBFT), Gulf Stream (протокол пересылки транзакций), Sealevel (параллельная обработка смарт-контрактов) - также как дары, так и проклятие, но решения оказались рабочими, что скорее радует.
4. Экосистема и инструменты. При том, что Solana не совместима с EVM, для нее есть достаточно зрелая экосистема инструментов для разработчиков, чтобы реализовывать многие свои задумки или переносить проекты с EVM-like сетей. Контракты можно писать с использованием SDK на C или Rust (обычно выбирают Rust
5. Развитая экосистема для DeFi. Что вам и надо, если вы хотите в инди-DeFi сегмент.
Минусы рассмотрим позже, а пока давайте о хорошем
И мнооого чего еще, где благодаря своим сильным сторонам Solana привлекает, как разработчиков, так и пользователей.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥5💯2🦄2👍1
Forwarded from Мир Fastify
Во первых, вы попали на канал про Node.js, где основной темой обсуждения будет этот самый хост для JavaScript'а. Во вторых, я думаю, что вы уже имеете общее представление о Fastify, как минимум знаете, что это фреймворк для Node.js. По смыслу схож с Express, но во много другой. В течении следующих постов я постараюсь раскрыть, в чем же отличия, почему я последние 4 года выбираю именно его для всех своих серверных проектов, посмотрим на его составные части, а также экосистему вокруг него.
В 2016 году Маттео Коллина (Matteo Collina), в тот момент уже один из активных членов Node.js сообщества, недовольный состоянием популярных на тот момент Express и Koa приступил к написанию собсвеного решения. Прежде, он уже был известен, как один из авторов pino - быстрого логгера для Node.js и своим выступлением The Cost of Logging.
Теперь пришло время ускорять и web-сервер. После обсуждения был найден "убийца перформенса" -
JSON.stringify, с помощью которого осуществлялась сериализация и десереализация. Так, Мануэль Спиголон (Manuel Spigolon) начал реализацию первого важного компонента Fastify fast-json-stringify. В конечном итоге получилось решение превосходящее по скорости JSON.stringify в два раза. В тоже время на вооружение было взято быстрое решение для HTTP роутинга find-my-way от Томаса Ведова (Tomas Della Vedova), реализующее быструю маршутизацию по строкам вида
'/example/near/:lat-:lng/radius/:r' при помощи сжатого префиксного дерева. Томас, будучи одним из первых ментейнеров, собрал и внедрил все важные кусочки во фреймворк: мощную систему плагинов avvio (по верх которой можно было переиспользовать мидлвары из Express), pino в качестве логгера и fast-json-stringify как сериализатор.И доведя все части до ума в 2018 году, команда выкатила v1.0.0 и статью "Fastify goes LTS with 1.0.0!". Основным заявлением было наличие большого количества готовых плагинов, простота и скорость. Что актуально и по сей день.
На самом деле каждый кусочек Fastify заслуживает отдельного разбора. Что, я и планирую покрыть в следующих постах. А также делать небольшие обзоры и новости новых версий интересных мне пакетов Node.js.
Какая часть Fastify вам интереснее всего? С какими проблемами при изучении и использовании вы сталкивались? Буду рад комментариям и раскрыть интересные топики в следующих постах!
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
The Cost of Logging - Matteo Collina, nearForm
The Cost of Logging - Matteo Collina, nearForm
Sunday morning and your phone rings: production is down. After two hours, you manage to solve it: you could have fixed it in one minute if you had the right information from the start. First thing in the morning…
Sunday morning and your phone rings: production is down. After two hours, you manage to solve it: you could have fixed it in one minute if you had the right information from the start. First thing in the morning…
🔥4❤🔥2👍1🦄1
Yet Another Advent
Десятый год программисты спасают рождество на Advent of Code Это оказалось классным форматом попробовать новый язык и расширить горизонт своих знаний за пределы типичных рабочих задачек. Сам AoC достаточно требовательный к навыкам, но как способ обучения оказался офигенно полезным и многие переняли этот формат, превратив его в "декабрьские мини-курсы".
В этом году этих адвентов наплодилось как минимум с пяток, который я вам и принес. И пусть уже 16тый день, но все еще не поздно начать или скрасить свое времяпровождение на новогодних праздниках.
🖇 Adventjs - не сложные задачки, которые можно решать на JS, TS и Python
🖇 Advent of Property Based Testing - задачки на тестирование через тестирование свойств, сам узнал об этом авденте из поста Khraks'а
🖇 Advent Of Typenoscript - участвую уже второй год, отличная возможность поупражняться в TS'е и попрограмировать на типах
📥 Advent Of Rust 🦀 - еще один адвент, в котором принимаю участие. В целом, не сложные задачки на повторение и местами углубление знаний по Rust'у
🖇 Advent Of Go - задачки на углубление знаний о Golang. Тоже прорешал первые дни, но пока отложил
Участвуете ли вы в каких-нибудь программерских адвентах? Или может открываете коробочки? Я вот открыл по Гарри Поттеру и Фанки Поп по вселенной DС🤪️️️️️️
Десятый год программисты спасают рождество на Advent of Code Это оказалось классным форматом попробовать новый язык и расширить горизонт своих знаний за пределы типичных рабочих задачек. Сам AoC достаточно требовательный к навыкам, но как способ обучения оказался офигенно полезным и многие переняли этот формат, превратив его в "декабрьские мини-курсы".
В этом году этих адвентов наплодилось как минимум с пяток, который я вам и принес. И пусть уже 16тый день, но все еще не поздно начать или скрасить свое времяпровождение на новогодних праздниках.
Участвуете ли вы в каких-нибудь программерских адвентах? Или может открываете коробочки? Я вот открыл по Гарри Поттеру и Фанки Поп по вселенной DС
Please open Telegram to view this post
VIEW IN TELEGRAM
AdventJS
AdventJS - JavaScript, TypeScript and Python coding challenges every day of December
JavaScript, TypeScript and Python coding challenges every day of December. Learn and have fun with AdventJS coding challenges!
🔥8
Ого, уже 100+ подписчиков на канале к концу года! Всем читающим: с наступающим! 🥳
Изначально тут были все с кем я был знаком лично, потом добавлялись те, кому я был ментором, потом те, кто меня узнал по какой-то публичной онлайн деятельности и с кем я уже не мог познакомиться.
Так что немного про меня и планы на канал в новом году.
Привет👋 Я Вася. Родом из Казахстана. Пожил-поучился в Китае, пожил-поработал-поучился в Новосибирске, перебрался поработать-пожить в Питер и перекочевал в Алмату. Готовил и помогал организовать конференции Podlodka Crew, TechTrain, немного подсобил на разных оффлайн конфах помельче. Сильно люблю Хекслет: написал туда курс по тайпскрипту, взял несколько интервью на канал. Долгое время занимался в основном фронтендом, чуть меньше всегда занимался всем программированием подряд на всем подряд. Ушёл с концами в Node.js разработку, собрал и разобрал Node.js отдел. Попутно где-то руководил командами, строил какие-то процессы. Консалтил, менторил, разматывал инженерные проблемы мелких компаний и побольше, вел лекции. Сейчас плотно оказался в web3, за что спасибо тем, кто мне показал, чем интересным тут можно заниматься.
Про меня пока все, вот и познакопились🙏 . Теперь про уголок.
В этом году я уже начал серию постов про DeFi и в отдельном канале про Fastify (сюда тоже буду что-тот репостить, но авторские обзоры на новости только там). В планах еще начать цикл постов про Rust и разбавлять постами про хобби - НРИ, в которое я средне-активно вкатываюсь, и, конечно, периодически продолжать выкладывать общие мысли около или про разработку.
Посмотрим, что в итоге выйдет.
Изначально тут были все с кем я был знаком лично, потом добавлялись те, кому я был ментором, потом те, кто меня узнал по какой-то публичной онлайн деятельности и с кем я уже не мог познакомиться.
Так что немного про меня и планы на канал в новом году.
Привет
Про меня пока все, вот и познакопились
В этом году я уже начал серию постов про DeFi и в отдельном канале про Fastify (сюда тоже буду что-тот репостить, но авторские обзоры на новости только там). В планах еще начать цикл постов про Rust и разбавлять постами про хобби - НРИ, в которое я средне-активно вкатываюсь, и, конечно, периодически продолжать выкладывать общие мысли около или про разработку.
Посмотрим, что в итоге выйдет.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥21👍4
Воспоминания о Китае
Станция НЛО. Специальный выпуск #1
Станция НЛО. Специальный выпуск #1
Тема: Воспоминания о Китае
Гость: Василий Кузенков, персональный канал @webcorner
Содержание
00:00:26 Знакомство с гостем
00:13:45 Вход в китайский язык
00:17:58 Языковые особенности, слэнг
00:22:34 Китайский интернет
00:30:48 Компьютерные клубы
00:33:10 Строгий/анонимный доступ в интернет
00:36:54 Интернет-сервисы (аналоги gmail, youtube, steam)
00:44:02 Разработчики в Китае
00:46:44 Как появляются разрабы
00:53:07 Китайский IT рынок
00:58:24 Известные китайские продукты
01:00:55 Рынок стартапов в Китае
01:03:27 Желание уехать из Китая
01:07:53 Можно ли выйти из IT
01:09:14 Участие государства в жизни частных компаний
01:12:31 Слежка за постами в сети
01:14:08 Work life balance, работа 6 дней в неделю и выгорания
01:19:53 Уровень линейного разработчика
01:21:54 Если захотелось в Китай
Материалы к выпуску
— Маг на полную ставку, новелла с участием в переводе Василия
— Путешествие на Запад, один из классических романов
— Искусство войны, Сунь-цзы, древнейший трактат
— Троецарствие, исторический роман XIV века
— Tencent, известная компания
@xufostation, канал про разработку и информационные технологии
Тема: Воспоминания о Китае
Гость: Василий Кузенков, персональный канал @webcorner
Содержание
00:00:26 Знакомство с гостем
00:13:45 Вход в китайский язык
00:17:58 Языковые особенности, слэнг
00:22:34 Китайский интернет
00:30:48 Компьютерные клубы
00:33:10 Строгий/анонимный доступ в интернет
00:36:54 Интернет-сервисы (аналоги gmail, youtube, steam)
00:44:02 Разработчики в Китае
00:46:44 Как появляются разрабы
00:53:07 Китайский IT рынок
00:58:24 Известные китайские продукты
01:00:55 Рынок стартапов в Китае
01:03:27 Желание уехать из Китая
01:07:53 Можно ли выйти из IT
01:09:14 Участие государства в жизни частных компаний
01:12:31 Слежка за постами в сети
01:14:08 Work life balance, работа 6 дней в неделю и выгорания
01:19:53 Уровень линейного разработчика
01:21:54 Если захотелось в Китай
Материалы к выпуску
— Маг на полную ставку, новелла с участием в переводе Василия
— Путешествие на Запад, один из классических романов
— Искусство войны, Сунь-цзы, древнейший трактат
— Троецарствие, исторический роман XIV века
— Tencent, известная компания
@xufostation, канал про разработку и информационные технологии
❤🔥9👍3
Мое введение в Rust 🦀
Прежде чем продолжать писать о Солане очень хочется рассказать о языке, на котором она написанна. Да и вместе с ней многие современные блокчейны.
Rust выбирают за счет отсуствия сборщика мусора (вместо него тут borrow чекер и подход RAII), возможности писать высокоуровневые абстракции и выразительный код (хоть и синтаксис местами токсичен).
За моими плечами года 4 Раста, но низкоуровневых штук я на нем не писал, да и в целом долгое время просто изучал из праздного интереса. К текущему моменту получилось написать на нем парочку сервисов (даже не в стол), несколько cli утилит, потрогал плагины для SWC, немного L2 блокчейнов и смарт контрактов. Опенсорснул утилиту для aws, переписанную с Ruby на Rust, и парсер для TMA переписал с Golang'а🦀 .
В целом, как мне кажется, так довольно мало, чтобы считать, что я знаю Rust отлично, но достаточно, чтобы на нем очень даже сносно писать.
Начал я его изучение, как и вам советую с Книги📓. Попутно подкрепляя упражнениями и плейлистом от CSC Программирование на Rust (он все еще не устарел). Сейчас бы я вам еще порекомендовал прочесть и прорешать книгу Rust в действии - там много полезных и наглядных примеров + опускаются достаточно низко, что в дальнейшем вам поможет.
Вот этого материала, в целом, достаточно, чтобы вы уже чувствовали себя достаточно уверенно для написания прикладных программ. В языке много разных концепций, которые, возможно, покажутся вам новыми, особенно если вы переходите с языков вроде JS/TS. Из-за чего кривая обучения перед стартом получается довольно высокой.
Ставьте лайки, если ждете обзоры на другие полезные материалы по Rust'у, пишите про какую сферу применения Rust'а вам интересно было бы узнать!
ЗЫ. Ну и напоследок, главным бичом Rust я считаю паттерн билдер. Сделать современный язык, в котором нет опциональных аргументов - ало, парни в чулочках💅 , у вас там все хорошо? Ладно хоть за макросом все это безобразие скрыть можно... благодаря им я и написал этот пост... и вот, все собралось! я пошел!😳 Удачи вам!
Прежде чем продолжать писать о Солане очень хочется рассказать о языке, на котором она написанна. Да и вместе с ней многие современные блокчейны.
Rust выбирают за счет отсуствия сборщика мусора (вместо него тут borrow чекер и подход RAII), возможности писать высокоуровневые абстракции и выразительный код (хоть и синтаксис местами токсичен).
За моими плечами года 4 Раста, но низкоуровневых штук я на нем не писал, да и в целом долгое время просто изучал из праздного интереса. К текущему моменту получилось написать на нем парочку сервисов (даже не в стол), несколько cli утилит, потрогал плагины для SWC, немного L2 блокчейнов и смарт контрактов. Опенсорснул утилиту для aws, переписанную с Ruby на Rust, и парсер для TMA переписал с Golang'а
В целом, как мне кажется, так довольно мало, чтобы считать, что я знаю Rust отлично, но достаточно, чтобы на нем очень даже сносно писать.
Начал я его изучение, как и вам советую с Книги📓. Попутно подкрепляя упражнениями и плейлистом от CSC Программирование на Rust (он все еще не устарел). Сейчас бы я вам еще порекомендовал прочесть и прорешать книгу Rust в действии - там много полезных и наглядных примеров + опускаются достаточно низко, что в дальнейшем вам поможет.
Вот этого материала, в целом, достаточно, чтобы вы уже чувствовали себя достаточно уверенно для написания прикладных программ. В языке много разных концепций, которые, возможно, покажутся вам новыми, особенно если вы переходите с языков вроде JS/TS. Из-за чего кривая обучения перед стартом получается довольно высокой.
Ставьте лайки, если ждете обзоры на другие полезные материалы по Rust'у, пишите про какую сферу применения Rust'а вам интересно было бы узнать!
ЗЫ. Ну и напоследок, главным бичом Rust я считаю паттерн билдер. Сделать современный язык, в котором нет опциональных аргументов - ало, парни в чулочках
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Так ли токсичен синтаксис Rust?
fn main() { println!("Hello, Rust!"); println!("... Goodbye!"); } Синтаксис — это первое, на что обращают внимание разработчики, впервые столкнувшись с кодом на Rust. И сложно...
❤🔥11👍10🔥3🦄2
REST API на Rust'е🦀
Конечно, Rust не идеален и кроме макросов и вариадиков в нем достаточно неоднозначных решений. Как упоминали в комментах, одно из них - реализация
Rust эволюционировал и даже знаменитый borrow checker в нем появился не сразу и когда я учился в универе: был знакомый чел, который писал на Rust'е со сборщиком мусора. И одним из витков эволюции стал тренд на уменьшение рантайма. Желательно, чтобы работало в условиях полного отключения рантайма - так появился
И с позиции минимализации рантайма из коробки они и реализовали асинхронность. Для того, чтобы запустить что-то асинхронное вам понадобится что-то, что будет из синхронного Rust'а хитро парковать выполнение когда вы вызываете
У рантайма Tokio довольно богатая экосистема. И одной из core частей является Tower - это такая система мидлвар для http клиентов/серверов. И пока Tokio окончательно не стал тир-1 решением асинк рантайма была масса вариантов что бы выбирать для http сервер. Теперь же есть смысл выбирать только то, что построенно поверх Tower'а - tonik для grpc и axum для всего остального.
PS. Есть также прикольные попытки вроде https://loco.rs/ сделать полноценный RoR-like фреймворк, но это просто интересный проект, в котором надежностью и стабильностью пока не пахнет.
axum дает реализацию роутинга и набор модулей для более простой разработки (что-то вроде express'а). Для написания json api нам точно понадобится openapi и набор для валидации входящих запросов. Для open-api + макросов для роутинга я беру utoipa, а axum-valid в качестве обертки для валидации.
Для всяких крон и других видов фоновых задач меня устроил apalis(ощущается как давно знакомый мне Bull). А sqlx закрыл для меня вопрос взаимодействия с бд (Rust и ORM - это можно, но хочется больше контроля).
В целом вот такой вот набор вам понадобится для написания API на Rust'е. Для старта в асинхронщину на Rust'е рекомендую разобраться в синхронном коде, многопоточности и переходить к async-book (автор похоже начал ее переписывать и возможно даже наконец допишет). С utopia получается делать достаточно декларативный роутинг, а axum state позволяет обернуть все это дело в приятный DI. Успехов!
Конечно, Rust не идеален и кроме макросов и вариадиков в нем достаточно неоднозначных решений. Как упоминали в комментах, одно из них - реализация
async. Но дело тут даже не в Pin/Unpin и прочих сложных типах.Rust эволюционировал и даже знаменитый borrow checker в нем появился не сразу и когда я учился в универе: был знакомый чел, который писал на Rust'е со сборщиком мусора. И одним из витков эволюции стал тренд на уменьшение рантайма. Желательно, чтобы работало в условиях полного отключения рантайма - так появился
no_std в котором по-умолчанию нет аллокатора.И с позиции минимализации рантайма из коробки они и реализовали асинхронность. Для того, чтобы запустить что-то асинхронное вам понадобится что-то, что будет из синхронного Rust'а хитро парковать выполнение когда вы вызываете
.await и продолжать выполнение, как что-то будет готово. Это тот самый рантайм. https://tokio.rs/ сейчас самое популярное решение и так как оно не коробочное - раскол сообщества успешно произошел, но не вылился во что-то очень крупное.Альтернативные рантаймы выбирают редко и когда уже понимают, что нужно где-то выжать доп производительность или, например, жить конкурентно в одном потоке.У рантайма Tokio довольно богатая экосистема. И одной из core частей является Tower - это такая система мидлвар для http клиентов/серверов. И пока Tokio окончательно не стал тир-1 решением асинк рантайма была масса вариантов что бы выбирать для http сервер. Теперь же есть смысл выбирать только то, что построенно поверх Tower'а - tonik для grpc и axum для всего остального.
PS. Есть также прикольные попытки вроде https://loco.rs/ сделать полноценный RoR-like фреймворк, но это просто интересный проект, в котором надежностью и стабильностью пока не пахнет.
axum дает реализацию роутинга и набор модулей для более простой разработки (что-то вроде express'а). Для написания json api нам точно понадобится openapi и набор для валидации входящих запросов. Для open-api + макросов для роутинга я беру utoipa, а axum-valid в качестве обертки для валидации.
Для всяких крон и других видов фоновых задач меня устроил apalis(ощущается как давно знакомый мне Bull). А sqlx закрыл для меня вопрос взаимодействия с бд (Rust и ORM - это можно, но хочется больше контроля).
В целом вот такой вот набор вам понадобится для написания API на Rust'е. Для старта в асинхронщину на Rust'е рекомендую разобраться в синхронном коде, многопоточности и переходить к async-book (автор похоже начал ее переписывать и возможно даже наконец допишет). С utopia получается делать достаточно декларативный роутинг, а axum state позволяет обернуть все это дело в приятный DI. Успехов!
Please open Telegram to view this post
VIEW IN TELEGRAM
tokio.rs
Tokio - An asynchronous Rust runtime
Tokio is a runtime for writing reliable asynchronous applications with Rust. It provides async I/O, networking, scheduling, timers, and more.
👍14🔥4🌚2❤🔥1
Не только подземелья и Не столько драконы
Вчера доиграл свою первую большую компанию в DnD. Буря эмоций и долго не мог заснуть. Всем сопартийцам огромная благодартность и респект.
С текстовыми ролевками меня познакомили форумы по Наруто😌 . Сперва я там был игроком, но очень быстро стал модератором и начал развивать вселенную: придумывать новые задания, отыгрывать НИПов (так тут обычно называют персонажей мастеров). Ну и конечно всей этой терминологии в то время не существовало. Зато уже приходилось подпиливать неповоротливый Ucoz под себя, делать простую верстку и кайфовать с мелких интерактивных приколюх.
Свою первую партию в DnD я отодвигал как мог - совершенно не был уверен понравится ли мне. Я очень люблю фентази, запутанный ЛОР (историю, бестиарий и прочие атрибуты вымышленного мира) и ролевую составляющую. Куча пройденных RPG игр уже знакомили меня с основной вселенной DnD - Забытыми Королевствами. И вот я решился и сыграл свой первый ваншот - короткое приключение на одну сессию. И понял, что это мое - то самое, что отлично скрасит мои будни, вывернет из тревоги и типичных будней. Тут, конечно, могу выразить огромный респект талантливому мастеру, который провел мою первую игру и у которого я продолжил играть. Но пока затишье и ожидание.
До моей большой компании еще пара месяцев. А я перебивался мелким😕 - играл у нескольких мастеров, подмечал фишки и разбирался, что мне нравится в играх, а что нет. Я сразу понимал, что только играть мне будет мало - нужно и водить. Так я отвел для друзей свой первый ваншотик (для кого-то это была первая игровая сессия, а кто-то уже играл), потом водил парные сессии, и еще и еще для друзей-знакомых, мы начинали компании и забрасывали их. Также познакомился с другими НРИ (настольно-ролевыми играми): Вампиры Маскарад, Пасфайндер, Блэксэд. Каждая система НРИ давит на разные эмоции, дает разные инструменты, чтобы игроки могли почувствовать себя творцами или всего причастными к истории. Играя и наблюдая, ты замечаешь, как какие-то мастера не дают сделать шага за "рельсы", а какие-то в самые линейные истории вносят элемент песочницы. Стиль вождения, готовность к импровизации, подготовка и множество еще мелких элементов делают игры в НРИ крутейшим игровым опытом для многих.
И вот я дождался и ворвался посреди приключения - битвы за Боровию в лапах Страда Фон Заровича☠️ . Врыв мой оказался чутка смазанным, но компания и мастер сгладили оч много огрехов. И мой персонаж оказался в гуще событий и членом отличной партии, которая в итоге вырвала Боровию из злостных лап. Интриги от мастера, неожиданные развития персонажей игроков, ламповые истории и посиделки по вечерам после работы. Пять или шесть месяцев встреч, море эмоций и просто детский восторг почти каждую партию.
Если вы сами хотите поиграть - у крутейшего мастера Никиты периодически случаются наборы. Я уже занял слотик :D.
Сам процесс "записаться-прийти-поиграть" - только одна часть этого хобби. Тут есть очень много всякого, где можно проявить себя еще больше. Миниатюры, написание историй, разные геймплейные улучшения (правила достаточно гибкие и за каждым столом я встречал что-то новое в них), рисование, даже программисткое "улучшение автоматизации" имеет место быть. В общем дополнительные развлечения на любой вкус.
Могу еще много чего рассказывать и нахваливать, но лучше вам самим попробовать🕺 (конечно у Шефа Никиты).
Вчера доиграл свою первую большую компанию в DnD. Буря эмоций и долго не мог заснуть. Всем сопартийцам огромная благодартность и респект.
С текстовыми ролевками меня познакомили форумы по Наруто
Свою первую партию в DnD я отодвигал как мог - совершенно не был уверен понравится ли мне. Я очень люблю фентази, запутанный ЛОР (историю, бестиарий и прочие атрибуты вымышленного мира) и ролевую составляющую. Куча пройденных RPG игр уже знакомили меня с основной вселенной DnD - Забытыми Королевствами. И вот я решился и сыграл свой первый ваншот - короткое приключение на одну сессию. И понял, что это мое - то самое, что отлично скрасит мои будни, вывернет из тревоги и типичных будней. Тут, конечно, могу выразить огромный респект талантливому мастеру, который провел мою первую игру и у которого я продолжил играть. Но пока затишье и ожидание.
До моей большой компании еще пара месяцев. А я перебивался мелким
И вот я дождался и ворвался посреди приключения - битвы за Боровию в лапах Страда Фон Заровича
Если вы сами хотите поиграть - у крутейшего мастера Никиты периодически случаются наборы. Я уже занял слотик :D.
Сам процесс "записаться-прийти-поиграть" - только одна часть этого хобби. Тут есть очень много всякого, где можно проявить себя еще больше. Миниатюры, написание историй, разные геймплейные улучшения (правила достаточно гибкие и за каждым столом я встречал что-то новое в них), рисование, даже программисткое "улучшение автоматизации" имеет место быть. В общем дополнительные развлечения на любой вкус.
Могу еще много чего рассказывать и нахваливать, но лучше вам самим попробовать
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥11👍4
И снова о типчиках
Изначально я хотел поныть про переписывание компилятора TypeScript’а на Go, как уже ныл в комментах под новостью, но вместо решил чуть более рационально подойти к вопросу «Что вам дает типизация?». И если в случае с JavaScript’ом все понятно: надежда только на дисциплину разработчиков, вместо помощи от типов, привела к печальному состоянию многие кодовые базы (прикиньте, полное отсутствие комментов и доки в легаси - т.е. нет вообще какой-либо мета инфы, и типчики тут лучше, чем ничего). То вот зачем другим экосистемам и языкам типы? Что они дают нам, разрабам?
Оговорюсь сразу, что дальше речь только про типы, доступные на этапе работы с кодом или компиляции, и пока не про рантайм типы.
Так что дает типизация? Надежность? Сама по себе нет. Перформанс в рантайме? Не совсем. Подерживаемость кода? Без дисциплины все равно ситуация не сильно лучше. Это все спорные вопросы.
Но вот с чем сложно поспорить:
➡️ Улучшение Developer Experience в виде помощи IDE, LSP и иногда хоть какой-то документации, хотя бы для LLM’ок
➡️ Как инструмент для дизайна. Иногда просто круто начать с типчаков, принести их команде на обсуждение, обложиться тестами и потом уже имплементировать.
➡️ Как доказательство корректности. Тема очень интересная и перспективная для некоторых областей, но не доступная для большинства мейнстримных «статически типизированных» языков
В замен мы платим большим кол-вом кода (иногда), не возможностью сделать какие-то выкрутасы (назовем это гибкостью), сложностью инструментария.
🔔 С этими в голове у появилась очевидная мысль, что не все системы типов себя стоят и иногда ваш компилятор просто тупой или ленивый. И обычно тупость компилятора историческая (раньше вывод по ХМ был чисто игрушкой теоретиков), либо скрывается за попытками авторов ускорить компилятор за счет вашего удобства.
Типы действительно имеют эти преимущества, когда вы: дизайните с их помощью (ADT, либо костыли вокруг классов), функции пишите почти без описания типов (есть система вывода типов), на основании типов действительно можно верить в корректность программы во время испольнения (лайфтаймы в расте против висящих указателей, отсутствие NPE, даже деление на ноль или док-ва, что массив не пустой). И это не какой-то идеальный мир. Это реальность: плодотворная работа теоретиков и практиков над языками программирования.
И от компилятора TypeScript'а хотелось бы таких же гарантий. И чтобы TypeScript сам был написан с использованием этих гарантий. А не на криво-косо сделанной системе типов Go с
Да и в целом, вокруг получающих системы типов, других, ранее чисто динамических языков программирования, строятся интересные научные работы. И постепенное типизирование с gradual typing, например, Elixir’а - выглядит многообещающе, правда там это не приоритет. Да и то, что входит в мейнстрим (PHP, Python) все равно выглядит криво-косо. Но оно пока в процессе - дальше может будет получше.
Ну и в коменты скинул пару достаточно свежих папир с исследованиями, которыми я на эту тему вдохновился😊 .
Изначально я хотел поныть про переписывание компилятора TypeScript’а на Go, как уже ныл в комментах под новостью, но вместо решил чуть более рационально подойти к вопросу «Что вам дает типизация?». И если в случае с JavaScript’ом все понятно: надежда только на дисциплину разработчиков, вместо помощи от типов, привела к печальному состоянию многие кодовые базы (прикиньте, полное отсутствие комментов и доки в легаси - т.е. нет вообще какой-либо мета инфы, и типчики тут лучше, чем ничего). То вот зачем другим экосистемам и языкам типы? Что они дают нам, разрабам?
Оговорюсь сразу, что дальше речь только про типы, доступные на этапе работы с кодом или компиляции, и пока не про рантайм типы.
Так что дает типизация? Надежность? Сама по себе нет. Перформанс в рантайме? Не совсем. Подерживаемость кода? Без дисциплины все равно ситуация не сильно лучше. Это все спорные вопросы.
Но вот с чем сложно поспорить:
В замен мы платим большим кол-вом кода (иногда), не возможностью сделать какие-то выкрутасы (назовем это гибкостью), сложностью инструментария.
Типы действительно имеют эти преимущества, когда вы: дизайните с их помощью (ADT, либо костыли вокруг классов), функции пишите почти без описания типов (есть система вывода типов), на основании типов действительно можно верить в корректность программы во время испольнения (лайфтаймы в расте против висящих указателей, отсутствие NPE, даже деление на ноль или док-ва, что массив не пустой). И это не какой-то идеальный мир. Это реальность: плодотворная работа теоретиков и практиков над языками программирования.
И от компилятора TypeScript'а хотелось бы таких же гарантий. И чтобы TypeScript сам был написан с использованием этих гарантий. А не на криво-косо сделанной системе типов Go с
interface{}, на котором половина стандартной библиотеки зиждится. И чтобы TS спеку получил в одном из мажоров и чтобы соблюдение этой спеки тоже выводилась системой типов. Но мы уже знаем, что команде TypeScript'а важно другое. А кто хочет этого - пишите на чем-нибудь другом.Да и в целом, вокруг получающих системы типов, других, ранее чисто динамических языков программирования, строятся интересные научные работы. И постепенное типизирование с gradual typing, например, Elixir’а - выглядит многообещающе, правда там это не приоритет. Да и то, что входит в мейнстрим (PHP, Python) все равно выглядит криво-косо. Но оно пока в процессе - дальше может будет получше.
Ну и в коменты скинул пару достаточно свежих папир с исследованиями, которыми я на эту тему вдохновился
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13 3❤🔥2
Если бы я хотел стать разработчиком на Rust в 2025, с чего бы я начал?
Позвали написать статью в соавторстве про вкат в Rust на tproger. В итоге получился скорее краткий гайд по фичам языка.
https://tproger.ru/articles/esli-by-ya-hotel-stat-razrabotchikom-na-rust-v-2025--s-chego-by-ya-nachal-
Позвали написать статью в соавторстве про вкат в Rust на tproger. В итоге получился скорее краткий гайд по фичам языка.
https://tproger.ru/articles/esli-by-ya-hotel-stat-razrabotchikom-na-rust-v-2025--s-chego-by-ya-nachal-
Tproger
Гайд по Rust - Как научиться языку Раст с нуля - Tproger
Гайд по Rust. Показываем, что нужно знать, чтобы научиться языку программирования Раст. Рассматриваем пошаговую инструкцию и практические примеры ✔ Tproger
1🔥11👍5😱3