Интересная история о том, как пожилой программист воссоздал древний системный язык программирования SPITBOL, диалект языка SNOBOL, и сохранил его для истории благодаря GitHub.
Сам автор говорит о программировании на системном машинном уровне, как о потерянном искусстве (sad, but true), поэтому столь важно было сохранить разработанный им много лет назад и давно потерянный язык и его компилятор для истории на современных облачных носителях данных.
https://motherboard.vice.com/en_us/article/78x5ba/this-70-year-old-programmer-is-preserving-an-ancient-coding-language-on-github
Сам автор говорит о программировании на системном машинном уровне, как о потерянном искусстве (sad, but true), поэтому столь важно было сохранить разработанный им много лет назад и давно потерянный язык и его компилятор для истории на современных облачных носителях данных.
https://motherboard.vice.com/en_us/article/78x5ba/this-70-year-old-programmer-is-preserving-an-ancient-coding-language-on-github
SPITBOL is written at the assembly language level—low-level code that interfaces almost directly with hardware itself. Since most coding is now done at a higher level, Shields refers to SPITBOL as an important part of software history. "What's special about it is that it's the most elegant surviving example of coding at the machine level," Shields said. "The art of writing at the machine level is a lost art."
Motherboard
This 70-Year-Old Programmer Is Preserving an Ancient Coding Language on GitHub
"Everything else I’ve written, those were all on magnetic tapes and are lost to history.”
Янн ЛеКун, знаменитый исследователь методов разработки искусстенного интеллекта, разработавший модели свёрточных нейронных сетей (convolutional neural networks) для распознавания образов, ныне работающий директором по исследованиям проблем искусстенного интеллекта в Facebook AI Lab, с лекцией о возможностях, ограничениях и пределах границ в применении методов глубокого машинного обучения для анализа данных.
https://www.youtube.com/watch?v=0tEhw5t6rhc
https://www.youtube.com/watch?v=0tEhw5t6rhc
YouTube
Yann LeCun - Power & Limits of Deep Learning
Yann LeCun is Director of AI Research at Facebook, and Silver Professor of Dara Science, Computer Science, Neural Science, and Electrical Engineering at New York University, affiliated with the NYU Center for Data Science, the Courant Institute of Mathematical…
Technologique
Embedding Rust in Python. Статья годичной давности, но при этом не менее актуальная, об интересном опыте процесса оптимизации проекта Sentry на Rust. Критические части Python приложений можно переписывать на Си и С++ - но это давно всем известно, со времён…
Embedding Rust in Python. Next step.
Дело оптимизации и встраивания Rust в проекты написанные на Python развивается!
Недавно Армин Ронахер опубликовал библиотеку Milksnake для автоматизации встраивания бинарных блобов и автоматизации создания сборок подобных комбинированных проектов на Python, содержащих бинарные модули написанные на Rust (и используемые через CFFI) а также на других системных языках (C/C++) совместимых по ABI, при помощи инфраструктуры систем сборки пакетов PIP (Python Wheels) и EasyInstall/SetupTools (Python Eggs).
Для Python проектов не нужно сильно заботиться о кросс-платформенной переносимости программ, если вы не используете специфичные для платформы API интерфейсы (например библиотеки GLib в GNU/Linux или интерфейс WinAPI в Windows, хотя и они сейчас переносимы в большинстве случаев - GLib кросс-платформенная библиотека проекта GNOME, а для WinAPI под Linux есть WINE) - в идеале если вы полагаетесь на стандартную библиотеку, то межплатформенная переносимость будет зависеть только от наличия сборки интерпретатора CPython для целевой платформы и её особенностей, например полноты стандартной библиотеки (сборки CPython есть для большинства платформ, даже экзотических).
Но что если в проекте есть оптимизации критических участков кода при помощи модулей, написанных на системных статически компилируемых языках (таких как C, C++ и Rust, который начал входить в область оптимизации существующих проектов), как в проекте Sentry, и такие зависимости тоже нужно контролировать, и создавать воспроизводимые сборки (reproducible builds) таких проектов при непрерывном интеграционном тестировании, формировании поставки и развёртывании таких проектов в облачной инфраструктуре (continuous delivery, deployment, continuous integration).
Со статически компилируемыми языками дело обстоит иначе - для каждой целевой платформы/ОС и процессорной архитектуры нужна своя сборка/билд зависимых системных библиотек и компиляция исполняемых образов файлов под целевую платформу.
Идея состоит в том, чтобы из скриптов сборщиков пакетов Python вызывать сторонние системы сборки для внешних зависимостей проекта (в данном случае Cargo для сборки crate пакета/модуля, написанного на Rust) и статической компиляции бинарных исполняемых образов для целевой платформы — всё для создания переносимых кросс-платформенных сборок таких комбинированных компонентных проектов и их зависимостей.
Для этого и была создана библиотека Milksnake, для расширения функциональности систем сборки пакетов для Python. Она подходит для подключения не только Cargo в качестве внешнего сборщика, но и билд-систем сборки для других языков,
https://blog.sentry.io/2017/11/14/evolving-our-rust-with-milksnake
https://github.com/getsentry/milksnake
Дело оптимизации и встраивания Rust в проекты написанные на Python развивается!
Недавно Армин Ронахер опубликовал библиотеку Milksnake для автоматизации встраивания бинарных блобов и автоматизации создания сборок подобных комбинированных проектов на Python, содержащих бинарные модули написанные на Rust (и используемые через CFFI) а также на других системных языках (C/C++) совместимых по ABI, при помощи инфраструктуры систем сборки пакетов PIP (Python Wheels) и EasyInstall/SetupTools (Python Eggs).
Для Python проектов не нужно сильно заботиться о кросс-платформенной переносимости программ, если вы не используете специфичные для платформы API интерфейсы (например библиотеки GLib в GNU/Linux или интерфейс WinAPI в Windows, хотя и они сейчас переносимы в большинстве случаев - GLib кросс-платформенная библиотека проекта GNOME, а для WinAPI под Linux есть WINE) - в идеале если вы полагаетесь на стандартную библиотеку, то межплатформенная переносимость будет зависеть только от наличия сборки интерпретатора CPython для целевой платформы и её особенностей, например полноты стандартной библиотеки (сборки CPython есть для большинства платформ, даже экзотических).
Но что если в проекте есть оптимизации критических участков кода при помощи модулей, написанных на системных статически компилируемых языках (таких как C, C++ и Rust, который начал входить в область оптимизации существующих проектов), как в проекте Sentry, и такие зависимости тоже нужно контролировать, и создавать воспроизводимые сборки (reproducible builds) таких проектов при непрерывном интеграционном тестировании, формировании поставки и развёртывании таких проектов в облачной инфраструктуре (continuous delivery, deployment, continuous integration).
Со статически компилируемыми языками дело обстоит иначе - для каждой целевой платформы/ОС и процессорной архитектуры нужна своя сборка/билд зависимых системных библиотек и компиляция исполняемых образов файлов под целевую платформу.
Идея состоит в том, чтобы из скриптов сборщиков пакетов Python вызывать сторонние системы сборки для внешних зависимостей проекта (в данном случае Cargo для сборки crate пакета/модуля, написанного на Rust) и статической компиляции бинарных исполняемых образов для целевой платформы — всё для создания переносимых кросс-платформенных сборок таких комбинированных компонентных проектов и их зависимостей.
Для этого и была создана библиотека Milksnake, для расширения функциональности систем сборки пакетов для Python. Она подходит для подключения не только Cargo в качестве внешнего сборщика, но и билд-систем сборки для других языков,
https://blog.sentry.io/2017/11/14/evolving-our-rust-with-milksnake
https://github.com/getsentry/milksnake
Product Blog • Sentry
Evolving Our Rust With Milksnake
Sharing our new approach to using Rust in Python.
Technologique
Embedding Rust in Python. Next step. Дело оптимизации и встраивания Rust в проекты написанные на Python развивается! Недавно Армин Ронахер опубликовал библиотеку Milksnake для автоматизации встраивания бинарных блобов и автоматизации создания сборок подобных…
Так же для тех, кто интересуется темой воспроизводимых сборок (reproducible builds), в комбинированных проектах на скриптовых и статически компилируемых языках, советую посмотреть на билд-систему Meson, которая используется в проекте дистрибутива Debian, проекте GNOME, написана на Python и позволяет делать сборки проектов на Python, Rust, Vala, Genie, D, Си и C++.
http://mesonbuild.com
https://github.com/mesonbuild/meson
https://reproducible-builds.org
http://mesonbuild.com
https://github.com/mesonbuild/meson
https://reproducible-builds.org
GitHub
GitHub - mesonbuild/meson: The Meson Build System
The Meson Build System. Contribute to mesonbuild/meson development by creating an account on GitHub.
Technologique
Embedding Rust in Python. Next step. Дело оптимизации и встраивания Rust в проекты написанные на Python развивается! Недавно Армин Ронахер опубликовал библиотеку Milksnake для автоматизации встраивания бинарных блобов и автоматизации создания сборок подобных…
Ещё одна интересная статья из блога для разработчиков RedHat по этой же теме оптимизации критических участков программ на Python при помощи Rust и сборке таких проектов.
https://developers.redhat.com/blog/2017/11/16/speed-python-using-rust/
https://developers.redhat.com/blog/2017/11/16/speed-python-using-rust/
Red Hat Developer
Speed up your Python using Rust | Red Hat Developer
What is Rust? Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety. Featuring zero-cost abstractions move semantics guaranteed memory
Инициатива развития Nim в направлении GC free и raw pointer free программирования.
Автор языка Nim и его компилятора, Андреас Рампф (Andreas Rumpf), недавно написал о планах удаления механизма сборки мусора (GC) и перехода к ARC (atomic/automatic reference counting) модели управления памятью. Также планируется внедрить механизм контроля указателей подобный имеющемуся в Rust.
https://nim-lang.org/araq/destructors.html
https://nim-lang.org/docs/gc.html
В небольшой заметке я изложил своё отношение к данной инициативе и перечислил возможности, имеющиеся в Rust для работы с указателями, со ссылками на документацию Rust Book.
http://telegra.ph/GC-free-and-raw-pointer-free-programming-10-21
Автор планирует сделать boxed указатели c системой типов для контроля их владений и заимствований поверх ARC механизма LLVM с применением автоматических деструкторов (RAII) - всё как в Rust. Но зачем всем нам ещё один "Rust" со смесью синтаксиса Object Pascal (Free Pascal, если быть точным - на нём в среде Windows был написан первый компилятор языка Nimrod, позже язык был переименован в Nim) и Python, ещё и с последующей трансформацией синтаксического дерева фронт-энд компилятором в слаботипизированный Си (промежуточная транс-компиляция), пока не очень понятно и не только мне, так как для Nim есть другие, до сих пор в полной мере не реализованные пути его улучшения, в первую очередь это поддержка событийно-асинхронного кода (event loop, async/await), различных моделей thread safety многопоточности (continuations, coroutines, channels, actors) и доработка стандартной библиотеки в этих направлениях. Это было в планах, об этом просит сообщество разработчиков, но планы реализуются крайне медленно.
И сейчас не понятно сколько предложенная инициатива будет реализовываться по времени, т.к. другие инициативы автора — улучшения thread safety (thread safe, lock-free, race-free, null references free, and so on!) и модели многопоточности (сопрограммы, каналы, акторы), а также иммутабельности данных в памяти (системы типов на базе эффектов - читайте системы зависимых типов или даже реализации транзакционной памяти в Nim!) — до сих пор не реализованы в полной мере в языке и лишь частично покрыты в стандартной библиотеке языка, и это спустя уже несколько лет после самих статей автора!
https://nim-lang.org/araq/concurrency.html
https://nim-lang.org/araq/concurrency2.html
https://nim-lang.org/araq/writetracking.html
Автоматическое управление памятью и система типов в Rust.
Фактически ARC и RAII единственно приемлемые методы автоматического управления памятью для системных языков.
Rust как раз полагается на ARC в LLVM бэкэнд компиляторе.
Но, поверх ARC механизма построен сильный строгий контроль типов и использования boxed указателей, благодаря субструктурной системе типов.
Swift также использует ARC механизм LLVM, но только с контролем владений (ownership - owned, unowned, weak refereces), пока без механизма заимствований указателей (borrowed pointers) на сегменты памяти.
GC использует алгоритмы подсчёта указателей, обхода памяти и учёта времени жизни указателей.
Чисто системные языки не используют GC из-за STW задержек (stop-the-world latency) при обходе указателей в памяти (STW возникает в любом случае, даже в многопоточном GC, т.к. GC это дополнительный алгоритмический механизм поверх RC/ARC механизма подсчёта указателей), что не приемлемо для mission-critical и real-time задач, особенно для задач жёсткого реального времени (hard real-time) с гарантированным временем реакции/задержки.
Поэтому в Rust нет GC, т.е. вообще нет работающего GC в run-time, хотя есть сторонние proof-of-concept проекты реализующие GC для Rust:
http://dpzmick.com/2017/01/23/rust-arc-gc-realtime/
https://github.com/Manishearth/rust-gc
http://manishearth.github.io/blog/2015/09/01/designing-a-gc-in-rust/
http://manishearth.github.io/blog/2016/08/18/gc-support-in-rust-api-design/
Автор языка Nim и его компилятора, Андреас Рампф (Andreas Rumpf), недавно написал о планах удаления механизма сборки мусора (GC) и перехода к ARC (atomic/automatic reference counting) модели управления памятью. Также планируется внедрить механизм контроля указателей подобный имеющемуся в Rust.
https://nim-lang.org/araq/destructors.html
https://nim-lang.org/docs/gc.html
В небольшой заметке я изложил своё отношение к данной инициативе и перечислил возможности, имеющиеся в Rust для работы с указателями, со ссылками на документацию Rust Book.
http://telegra.ph/GC-free-and-raw-pointer-free-programming-10-21
Автор планирует сделать boxed указатели c системой типов для контроля их владений и заимствований поверх ARC механизма LLVM с применением автоматических деструкторов (RAII) - всё как в Rust. Но зачем всем нам ещё один "Rust" со смесью синтаксиса Object Pascal (Free Pascal, если быть точным - на нём в среде Windows был написан первый компилятор языка Nimrod, позже язык был переименован в Nim) и Python, ещё и с последующей трансформацией синтаксического дерева фронт-энд компилятором в слаботипизированный Си (промежуточная транс-компиляция), пока не очень понятно и не только мне, так как для Nim есть другие, до сих пор в полной мере не реализованные пути его улучшения, в первую очередь это поддержка событийно-асинхронного кода (event loop, async/await), различных моделей thread safety многопоточности (continuations, coroutines, channels, actors) и доработка стандартной библиотеки в этих направлениях. Это было в планах, об этом просит сообщество разработчиков, но планы реализуются крайне медленно.
И сейчас не понятно сколько предложенная инициатива будет реализовываться по времени, т.к. другие инициативы автора — улучшения thread safety (thread safe, lock-free, race-free, null references free, and so on!) и модели многопоточности (сопрограммы, каналы, акторы), а также иммутабельности данных в памяти (системы типов на базе эффектов - читайте системы зависимых типов или даже реализации транзакционной памяти в Nim!) — до сих пор не реализованы в полной мере в языке и лишь частично покрыты в стандартной библиотеке языка, и это спустя уже несколько лет после самих статей автора!
https://nim-lang.org/araq/concurrency.html
https://nim-lang.org/araq/concurrency2.html
https://nim-lang.org/araq/writetracking.html
Автоматическое управление памятью и система типов в Rust.
Фактически ARC и RAII единственно приемлемые методы автоматического управления памятью для системных языков.
Rust как раз полагается на ARC в LLVM бэкэнд компиляторе.
Но, поверх ARC механизма построен сильный строгий контроль типов и использования boxed указателей, благодаря субструктурной системе типов.
Swift также использует ARC механизм LLVM, но только с контролем владений (ownership - owned, unowned, weak refereces), пока без механизма заимствований указателей (borrowed pointers) на сегменты памяти.
GC использует алгоритмы подсчёта указателей, обхода памяти и учёта времени жизни указателей.
Чисто системные языки не используют GC из-за STW задержек (stop-the-world latency) при обходе указателей в памяти (STW возникает в любом случае, даже в многопоточном GC, т.к. GC это дополнительный алгоритмический механизм поверх RC/ARC механизма подсчёта указателей), что не приемлемо для mission-critical и real-time задач, особенно для задач жёсткого реального времени (hard real-time) с гарантированным временем реакции/задержки.
Поэтому в Rust нет GC, т.е. вообще нет работающего GC в run-time, хотя есть сторонние proof-of-concept проекты реализующие GC для Rust:
http://dpzmick.com/2017/01/23/rust-arc-gc-realtime/
https://github.com/Manishearth/rust-gc
http://manishearth.github.io/blog/2015/09/01/designing-a-gc-in-rust/
http://manishearth.github.io/blog/2016/08/18/gc-support-in-rust-api-design/
Telegraph
GC free and raw pointer free programming in Rust... and Nim.
Just want to give some response on the article and initiative by Andreas Rumpf, author of Nim programming language, about memory safe and thread safe future of Nim. https://nim-lang.org/araq/destructors.html I think that in #Rust ARC and RAII destructors…
В Rust нет динамизма времени исполнения, производится полный вывод типов в compile-time (CTTI, compile-time type inference), даже для полиморфных типов производится мономорфизация через субструктурную систему уникальных типов и в run-time при множественной диспетчеризации (multiple dispatch) типов срабатывает принцип автоматической подстановки экземпляра кода для обработки определённого заранее статически вычисленного типа выражения, но при этом выведенного в run-time (RTTI, run-time type inference) - столь сильная система типов необходима для строгой проверки выражений (eager/strict evaluation), для статических гарантий безопасности времени исполнения, безопасности типов данных и работы с ними, для безопасности и абсолютной предсказуемости поведения программы во время её исполнения (в run-time), статического анализа завершения/завершённости программы (escape analysis, termination analysis, totality checking) и гарантий полноты типов программы.
Именно на этих принципах, тотального/сильного функционального программирования (total/strong functional programming), использующего системы типов, основанные на типизированном лямбда-исчислении высших порядков, статическом анализе, анализе завершённости и полноты типов, основывается language based security, т.е. безопасность программ должна начинаться с языка и сильной системы типов для него.
Всё управление памятью Rust строится на субструктурной системе уникальных типов (substructural type system of uniqueness types) для контроля указателей поверх ARC механизма LLVM, плюс в Rust совместно с ARC механизмом используются автоматические деструкторы RAII.
В Nim (и других современных системных языках - Swift, Vala, Genie) нет uniqueness types, т.е. нет субструктурной системы уникальных типов, наподобие линейных типов (линейной логики), но ещё более сильной и строгой, для того чтобы обеспечить безопасность памяти и работы указателей так, как это сделано в Rust, а для внедрения такой системы типов нужно будет фундаментально переработать язык, компилятор и даже синтаксис, особенно синтаксис работы с boxed указателями, а указатели нужно будет обернуть (wrapped pointers, wrapping) в уникальные типы (boxing, box model) для контроля владений памяти и её заимствований указателями в различных потоках (при многопоточном программировании).
Для языков Vala и Genie фронт-энд компилятором производится синтаксический анализ (parsing) и трансформация абстрактного синтаксического дерева полученных лексем (AST, abstract syntax tree transformation) в язык Си, т.е. производится транс-компиляция в язык Си, так же как и во фронт-энд компиляторе Nim. Далее язык Си компилируется бэкэнд компилятором LLVM Clang. Библиотека Glib (набор системных библиотек проекта GNOME) используется как стандартная библиотека этих языков. Для автоматического управления памятью используются RAII и ARC механизм LLVM, но нет субструктурной системы типов, соответственно нет контроля указателей и не обеспечивается thread safety.
В целом - Nim (а тажке Swift, Vala, Genie) нельзя рассматривать как серьёзные системные языки и серьёзной конкуренции Rust и OCaml в области надёжного системного программирования в ближайшем будущем они составить не смогут, т.к. Rust и OCaml основываются на серьёзных фундаментальных исследованиях систем типов и изначально спроектированы для безопасного системного программирования и создания надёжных программ.
Rust и OCaml используют очень схожие системы уникальных типов (uniqueness types), основанные на λω (λ2 + λω_) исчислении, все проверки типов происходят в compile-time до фазы времени исполнения и с полным выводом типов в compile-time (CTTI). Достаточно сказать, что первая публичная версия компилятора Rust была написана Грейдоном Хоаром на OCaml - парсер был реализован с помощью макро-препроцессора Camlp4, код компилировался фронт-энд компилятором в LLVM IR/MIR представление.
Именно на этих принципах, тотального/сильного функционального программирования (total/strong functional programming), использующего системы типов, основанные на типизированном лямбда-исчислении высших порядков, статическом анализе, анализе завершённости и полноты типов, основывается language based security, т.е. безопасность программ должна начинаться с языка и сильной системы типов для него.
Всё управление памятью Rust строится на субструктурной системе уникальных типов (substructural type system of uniqueness types) для контроля указателей поверх ARC механизма LLVM, плюс в Rust совместно с ARC механизмом используются автоматические деструкторы RAII.
В Nim (и других современных системных языках - Swift, Vala, Genie) нет uniqueness types, т.е. нет субструктурной системы уникальных типов, наподобие линейных типов (линейной логики), но ещё более сильной и строгой, для того чтобы обеспечить безопасность памяти и работы указателей так, как это сделано в Rust, а для внедрения такой системы типов нужно будет фундаментально переработать язык, компилятор и даже синтаксис, особенно синтаксис работы с boxed указателями, а указатели нужно будет обернуть (wrapped pointers, wrapping) в уникальные типы (boxing, box model) для контроля владений памяти и её заимствований указателями в различных потоках (при многопоточном программировании).
Для языков Vala и Genie фронт-энд компилятором производится синтаксический анализ (parsing) и трансформация абстрактного синтаксического дерева полученных лексем (AST, abstract syntax tree transformation) в язык Си, т.е. производится транс-компиляция в язык Си, так же как и во фронт-энд компиляторе Nim. Далее язык Си компилируется бэкэнд компилятором LLVM Clang. Библиотека Glib (набор системных библиотек проекта GNOME) используется как стандартная библиотека этих языков. Для автоматического управления памятью используются RAII и ARC механизм LLVM, но нет субструктурной системы типов, соответственно нет контроля указателей и не обеспечивается thread safety.
В целом - Nim (а тажке Swift, Vala, Genie) нельзя рассматривать как серьёзные системные языки и серьёзной конкуренции Rust и OCaml в области надёжного системного программирования в ближайшем будущем они составить не смогут, т.к. Rust и OCaml основываются на серьёзных фундаментальных исследованиях систем типов и изначально спроектированы для безопасного системного программирования и создания надёжных программ.
Rust и OCaml используют очень схожие системы уникальных типов (uniqueness types), основанные на λω (λ2 + λω_) исчислении, все проверки типов происходят в compile-time до фазы времени исполнения и с полным выводом типов в compile-time (CTTI). Достаточно сказать, что первая публичная версия компилятора Rust была написана Грейдоном Хоаром на OCaml - парсер был реализован с помощью макро-препроцессора Camlp4, код компилировался фронт-энд компилятором в LLVM IR/MIR представление.
Ссылки:
Swift:
https://xn--r1a.website/technologique/1095
https://xn--r1a.website/technologique/1096
https://xn--r1a.website/technologique/1097
https://xn--r1a.website/technologique/1098
https://xn--r1a.website/technologique/1099
Scala:
https://xn--r1a.website/technologique/1131
https://xn--r1a.website/technologique/1132
https://xn--r1a.website/technologique/1133
#обзор
#viewpoint
#Nim
#Rust
#OCaml
Swift:
https://xn--r1a.website/technologique/1095
https://xn--r1a.website/technologique/1096
https://xn--r1a.website/technologique/1097
https://xn--r1a.website/technologique/1098
https://xn--r1a.website/technologique/1099
Scala:
https://xn--r1a.website/technologique/1131
https://xn--r1a.website/technologique/1132
https://xn--r1a.website/technologique/1133
#обзор
#viewpoint
#Nim
#Rust
#OCaml
Telegram
Technologique
Релиз Swift 4.
https://swift.org/blog/swift-4-0-released/
Проблему критических секций (shared mutable memory, shared mutable state) памяти потоков с общим доступом частично решили - https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce…
https://swift.org/blog/swift-4-0-released/
Проблему критических секций (shared mutable memory, shared mutable state) памяти потоков с общим доступом частично решили - https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce…
Доклады с недавнего Rust Hungary Meetup проходившего в столице Венгрии, Будапеште, 23 ноября.
https://www.meetup.com/Rust-Hungary-Meetup/events/244411460/
https://www.meetup.com/Rust-Hungary-Meetup/events/244411460/
Meetup
Rust Hungary 3rd edition
Rust Hungary returns again in November! Join us for a slice of pizza and a slice of the amazing Rust-i-verse, with talks about how Firefox and Rust became best friends and now reach hundreds of millio
Technologique
New Firefox: Firefox Quantum. Fast. For good. Mozilla выпустили релиз браузера Firefox 57 на новом движке рендеринга макетов страниц Quantum. https://www.youtube.com/watch?v=n6wiRyKkmKc https://www.mozilla.org/en-US/firefox/quantum/ О том какие компоненты…
Браузерные WebAssembly (WASM) модули на Rust.
https://www.youtube.com/watch?v=FJoYZUMOwM4
Ссылки по теме:
https://xn--r1a.website/technologique/1143
https://xn--r1a.website/technologique/1144
https://xn--r1a.website/technologique/1145
https://www.youtube.com/watch?v=FJoYZUMOwM4
Ссылки по теме:
https://xn--r1a.website/technologique/1143
https://xn--r1a.website/technologique/1144
https://xn--r1a.website/technologique/1145
YouTube
Jan-Erik Rediger - WebAssembly for the Rust of Us (Rust Hungary #3, 2017-11-23)
What if we take Rust, compile it to WebAssembly and it becomes the application language of the web? WebAssembly as a target for the web opens up new possibil...
Technologique
Embedding Rust in Python. Next step. Дело оптимизации и встраивания Rust в проекты написанные на Python развивается! Недавно Армин Ронахер опубликовал библиотеку Milksnake для автоматизации встраивания бинарных блобов и автоматизации создания сборок подобных…
Нативные бинарные модули на Rust для Node.js.
https://www.youtube.com/watch?v=zz1Gie9FkbI
Плюс статья:
https://blog.risingstack.com/node-js-native-modules-with-rust/
Оптимизация проектов, написанных на скриптовых языках при помощи бинарных статически скомпилированных модулей, написанных на Rust - это уже фактический тренд.
Ссылки по теме:
https://xn--r1a.website/technologique/1153
https://xn--r1a.website/technologique/1154
https://xn--r1a.website/technologique/1155
https://xn--r1a.website/technologique/1123
https://xn--r1a.website/technologique/1124
https://xn--r1a.website/technologique/1125
https://www.youtube.com/watch?v=zz1Gie9FkbI
Плюс статья:
https://blog.risingstack.com/node-js-native-modules-with-rust/
Оптимизация проектов, написанных на скриптовых языках при помощи бинарных статически скомпилированных модулей, написанных на Rust - это уже фактический тренд.
Ссылки по теме:
https://xn--r1a.website/technologique/1153
https://xn--r1a.website/technologique/1154
https://xn--r1a.website/technologique/1155
https://xn--r1a.website/technologique/1123
https://xn--r1a.website/technologique/1124
https://xn--r1a.website/technologique/1125
YouTube
Péter Czibik - Fast & Safe Native node.js Modules with Rust (Rust Hungary #3, 2017-11-23)
Fast and Safe native modules in a node.js application? Péter Czibik will show us how to achieve both with Rust and hand-rolled native node.js extensions, or by using the Rust NEON wrapper library.
Slides: https://docs.google.com/presentation/d/1QWJ_4H3N…
Slides: https://docs.google.com/presentation/d/1QWJ_4H3N…
Technologique
Инициатива развития Nim в направлении GC free и raw pointer free программирования. Автор языка Nim и его компилятора, Андреас Рампф (Andreas Rumpf), недавно написал о планах удаления механизма сборки мусора (GC) и перехода к ARC (atomic/automatic reference…
Nim safety.
На днях у нас с коллегой разгорелась интересная дискуссия о Nim safety, безопасен ли Nim и обеспечивает ли он безопасность (language based security) на уровне системы типов при написании программ.
В посте выше я утверждаю, что Nim не безопасен, поэтому автор языка и компилятора хочет сделать систему типов "как в Rust" для обеспечения безопасности работы с указателями, обернув их в типы (uniqueness types), с использованием субструктурной системы уникальных типов (на низком уровне в процессе статического анализа и компиляции программы) для контроля использования указателей и памяти, особенно в разных потоках при многопоточном программировании.
Для того, чтобы сделать Nim безопасным нужно в первую очередь переработать бэкэнд компилятор, чтобы он порождал LLVM IR/MIR код, имеющий проверки исключений, которые можно использовать в таком скомпилированном коде для реализации любой системы типов.
Существует также транс-компилятор Nim в JavaScript, который сейчас считается не иначе как языком "C-based language for web and mobile clients" или даже "web-based C" по своей семантике типов.
Но JS позволяет делать сложную проверку исключений на уровне самого языка и транс-компилятор в JS может генерировать шаблонный код всех проверок при AST трансформациях мета-языка (TypeScript, Dart, ReasonML), что позволяет реализовать любую систему типов поверх JS.
Поэтому транс-компиляция в JS - это ещё куда не шло, но код при этом не будет быстрее, т.к. базовый JS исполняется движком V8 который использует JIT компиляцию, но вывод, проверка, диспетчеризация и связывание типов происходят в run-time во время JIT компиляции, до полной компиляции проверок типов в машинный код, что и вызывает задержки по времени исполнения кода и V8 в этом плане уже оптимизирован до предела по скорости исполнения кода.
Но транс-компиляция, тем более в Си - это по определению небезопасно, т.к. Си слаботипизированный язык и транс-компиляция в него это архисложная задача и процесс автоматного программирования при транс-компиляции не позволяет точно описывать и проверять поведение встроенных типов Си (которые во многих реализациях ещё и машинно-зависимы от длины машинных слов и разрядности регистров), проверять все ситуации и всю работу с указателями и памятью, т.е. Си создан для прецизионного ручного кодирования, но не для автоматного программирования.
#Rust
#Nim
Ссылки:
https://news.ycombinator.com/item?id=9050999
https://www.reddit.com/r/programming/comments/3sa6lf/d_has_no_vision_go_is_out_of_its_depth_rust/cwvgh4k/
https://www.quora.com/Is-Nim-really-that-unsafe
https://github.com/nim-lang/Nim/wiki/Unofficial-FAQ#is-nim-unsafe
https://github.com/nim-lang/Nim/issues/3531
https://news.ycombinator.com/item?id=8936061
https://gradha.github.io/articles/2015/02/goodbye-nim-and-good-luck.html
А некоторые ещё и очень сильно обожглись в своих проектах, когда решили перейти с Rust на Nim:
https://news.ycombinator.com/item?id=9050114
https://news.ycombinator.com/item?id=10947761
https://xn--r1a.website/technologique/1157
На днях у нас с коллегой разгорелась интересная дискуссия о Nim safety, безопасен ли Nim и обеспечивает ли он безопасность (language based security) на уровне системы типов при написании программ.
В посте выше я утверждаю, что Nim не безопасен, поэтому автор языка и компилятора хочет сделать систему типов "как в Rust" для обеспечения безопасности работы с указателями, обернув их в типы (uniqueness types), с использованием субструктурной системы уникальных типов (на низком уровне в процессе статического анализа и компиляции программы) для контроля использования указателей и памяти, особенно в разных потоках при многопоточном программировании.
Для того, чтобы сделать Nim безопасным нужно в первую очередь переработать бэкэнд компилятор, чтобы он порождал LLVM IR/MIR код, имеющий проверки исключений, которые можно использовать в таком скомпилированном коде для реализации любой системы типов.
Существует также транс-компилятор Nim в JavaScript, который сейчас считается не иначе как языком "C-based language for web and mobile clients" или даже "web-based C" по своей семантике типов.
Но JS позволяет делать сложную проверку исключений на уровне самого языка и транс-компилятор в JS может генерировать шаблонный код всех проверок при AST трансформациях мета-языка (TypeScript, Dart, ReasonML), что позволяет реализовать любую систему типов поверх JS.
Поэтому транс-компиляция в JS - это ещё куда не шло, но код при этом не будет быстрее, т.к. базовый JS исполняется движком V8 который использует JIT компиляцию, но вывод, проверка, диспетчеризация и связывание типов происходят в run-time во время JIT компиляции, до полной компиляции проверок типов в машинный код, что и вызывает задержки по времени исполнения кода и V8 в этом плане уже оптимизирован до предела по скорости исполнения кода.
Но транс-компиляция, тем более в Си - это по определению небезопасно, т.к. Си слаботипизированный язык и транс-компиляция в него это архисложная задача и процесс автоматного программирования при транс-компиляции не позволяет точно описывать и проверять поведение встроенных типов Си (которые во многих реализациях ещё и машинно-зависимы от длины машинных слов и разрядности регистров), проверять все ситуации и всю работу с указателями и памятью, т.е. Си создан для прецизионного ручного кодирования, но не для автоматного программирования.
#Rust
#Nim
Ссылки:
https://news.ycombinator.com/item?id=9050999
https://www.reddit.com/r/programming/comments/3sa6lf/d_has_no_vision_go_is_out_of_its_depth_rust/cwvgh4k/
https://www.quora.com/Is-Nim-really-that-unsafe
https://github.com/nim-lang/Nim/wiki/Unofficial-FAQ#is-nim-unsafe
https://github.com/nim-lang/Nim/issues/3531
https://news.ycombinator.com/item?id=8936061
https://gradha.github.io/articles/2015/02/goodbye-nim-and-good-luck.html
А некоторые ещё и очень сильно обожглись в своих проектах, когда решили перейти с Rust на Nim:
https://news.ycombinator.com/item?id=9050114
https://news.ycombinator.com/item?id=10947761
https://xn--r1a.website/technologique/1157
reddit
r/programming - D has no vision. Go is out of its depth. Rust skipped leg day.
2,835 votes and 1,052 comments so far on Reddit
Technologique
Релиз Rust 1.21. https://blog.rust-lang.org/2017/10/12/Rust-1.21.html https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1210-2017-10-12 #Rust
Релиз Rust 1.22 и 1.22.1.
https://blog.rust-lang.org/2017/11/22/Rust-1.22.html
https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1220-2017-11-22
#Rust
https://blog.rust-lang.org/2017/11/22/Rust-1.22.html
https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1220-2017-11-22
#Rust
blog.rust-lang.org
Announcing Rust 1.22 (and 1.22.1) | Rust Blog
Empowering everyone to build reliable and efficient software.
Technologique
Нативные бинарные модули на Rust для Node.js. https://www.youtube.com/watch?v=zz1Gie9FkbI Плюс статья: https://blog.risingstack.com/node-js-native-modules-with-rust/ Оптимизация проектов, написанных на скриптовых языках при помощи бинарных статически скомпилированных…
Нативные бинарные модули на Rust для проектов написанных на Ruby.
Оптимизация производительности критических участков кода на Ruby с помощью бинарных модулей, написанных на Rust и используемых в проектах через Ruby-FFI.
https://blog.codeship.com/improving-ruby-performance-with-rust/
https://github.com/d-unseductable/ruru
https://usehelix.com
https://github.com/tildeio/helix
https://github.com/ffi/ffi
Оптимизация скорости/производительности исполнения кода скриптовых языков с использованием статически скомпилированных бинарных модулей, написанных на Rust - это действительно уже устойчивый тренд!
Ссылки по теме:
https://xn--r1a.website/technologique/1162
Оптимизация производительности критических участков кода на Ruby с помощью бинарных модулей, написанных на Rust и используемых в проектах через Ruby-FFI.
https://blog.codeship.com/improving-ruby-performance-with-rust/
https://github.com/d-unseductable/ruru
https://usehelix.com
https://github.com/tildeio/helix
https://github.com/ffi/ffi
Оптимизация скорости/производительности исполнения кода скриптовых языков с использованием статически скомпилированных бинарных модулей, написанных на Rust - это действительно уже устойчивый тренд!
Ссылки по теме:
https://xn--r1a.website/technologique/1162
CloudBees
Improving Ruby Performance with Rust
After rewriting just a few of the slow methods for my Rails site in Rust
Быстрое руководство разработчикам на Python для освоения и постижения Rust.
https://github.com/rochacbruno/py2rs
#Rust
#Python
https://github.com/rochacbruno/py2rs
#Rust
#Python
GitHub
GitHub - rochacbruno/py2rs: A quick reference guide for the Pythonista in the process of becoming a Rustacean
A quick reference guide for the Pythonista in the process of becoming a Rustacean - rochacbruno/py2rs
#ITSUBBOTNIK в Санкт-Петербурге
9 декабря в Санкт-Петербурге состоится пятый #ITsubbotnik
Это бесплатная конференция для опытных разработчиков и инженеров.
13 спикеров поделятся своим опытом и лайфхаками в реальных рабочих проектах. В этот раз доклады будут в следующих направлениях: Data Science, JavaScript & Mobile, DevOps и Java.
Также вас ждут стенды, гейм-зона и многое другое.
Приходите!
Регистрация здесь: https://epa.ms/itsubbotnik-winter
https://events.epam.com/events/itsubbotnik-winter-2017
9 декабря в Санкт-Петербурге состоится пятый #ITsubbotnik
Это бесплатная конференция для опытных разработчиков и инженеров.
13 спикеров поделятся своим опытом и лайфхаками в реальных рабочих проектах. В этот раз доклады будут в следующих направлениях: Data Science, JavaScript & Mobile, DevOps и Java.
Также вас ждут стенды, гейм-зона и многое другое.
Приходите!
Регистрация здесь: https://epa.ms/itsubbotnik-winter
https://events.epam.com/events/itsubbotnik-winter-2017
Go Garbage Collector — concurrent tri-color incremental mark & sweep algorithm.
Доклад Рика Хадсона на конференции GopherCon 2015 о том, как в Go 1.5 удалось радикально уменьшить STW (Stop-The-World) задержки исполнения потоков программы (до наносекундных/субмиллисекундных показателей в последующих версиях, вплоть до крайних Go 1.8 и 1.9) благодаря применению гибридных алгоритмов многопоточной сборки мусора (GC) для программ написанных на языке Go.
https://www.youtube.com/watch?v=aiv1JOfMjm0
https://blog.golang.org/go15gc
Слайды:
https://talks.golang.org/2015/go-gc.pdf
Roadmap - на пути к версии 1.5:
http://golang.org/s/go14gc (https://docs.google.com/document/d/16Y4IsnNRCN43Mx0NZc5YXZLovrHvvLhK_h0KN8woTO4/edit)
Метрики:
https://github.com/bmhatfield/go-runtime-metrics
https://twitter.com/brianhatfield/status/900473287750365184
Статья с оценкой производительности и метрик сервиса Twitch в их блоге:
https://blog.twitch.tv/gos-march-to-low-latency-gc-a6fa96f06eb7
В версии языка и компилятора Go 1.5 был кардинально переработан код сборщика мусора (GC), до этой версии он был полностью переписан на самом Go методами автоматного (транс-компиляция с языка Си), а после и ручного программирования (коррекция) и были внедрены новые (вернее старые, но давно забытые) улучшения в алгоритмы многопоточной сборки мусора, благодаря чему данный GC стал лучшей программой в своём классе (субмиллисекундные задержки при освобождении памяти даже для оперативных in-memory хранилищ данных с размером кучи в 256 ГиБ (heap-size) для каждой ноды кластера!).
Эта разработка стала исторической вехой не только для языка Go, укрепившей его позиции в серверной разработке облачных инфраструктур, сетевых сервисов и демонов сетевых протоколов (server-side cloud infrastructure software development), но и большим прецедентом для доказательства работоспособности концепций (proof-of-concept) алгоритмов сборки мусора, разработанных ещё в 1970-х годах (tri-color, quad-color, incremental, mark & sweep algorithms).
Алгоритм сборки мусора, применённый в GC для программ на Go - это многопоточный трёхцветный (по фазам пометки указателей с последующим перемещением и освобождением блоков памяти) алгоритм коллектора (concurrent tri-color incremental mark & sweep collector), концепция которого была разработана известным датским математиком и инженером Эдсгером Дейкстра в 1978 году.
https://www.cs.utexas.edu/users/EWD/transcriptions/EWD05xx/EWD520.html
Но run-time (фаза исполнения) программ на Go был не первым проектом где был применён подобный алгоритм для коллектора памяти (GC).
Ранее Майк Пэлл (Mike Pall), автор знаменитого оптимизированного JIT копилятора Lua, применил подобный алгоритм в LuaJIT версий 1.x/2.0 для run-time фазы исполнения программ на языке Lua.
В LuaJIT будущей версии 3.0 автор планирует реализовать ещё более продвинутый четырёх-цветный оптимизированный алгоритм коллектора (Quad-Color Optimized Incremental Mark & Sweep GC).
http://wiki.luajit.org/New-Garbage-Collector
В run-time фазе исполнения программ оригинальным интерпретатором Lua версий 5.1/5.2 также используется трёхцветный алгоритм коллектора (Tri-Color Incremental Mark & Sweep GC). В более ранней версии Lua 5.0 использовался стандартный двухцветный алгоритм для коллектора памяти (Two-Color Mark & Sweep GC).
Отличная статья в блоге Майка Хёрна (Mike Hearn) о Go GC и вызовах современной компьютерной индустрии при создании гибридных алгоритмов коллекторов памяти:
https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e
Визуализация различных алгоритмов сборки мусора - https://xn--r1a.website/technologique/958
#Go
#GC
#Lua
#ThrowbackTech
Ссылки:
https://xn--r1a.website/technologique/721
https://xn--r1a.website/technologique/722
https://xn--r1a.website/technologique/750
https://xn--r1a.website/technologique/1057
https://xn--r1a.website/technologique/732
https://xn--r1a.website/technologique/551
https://xn--r1a.website/technologique/423
https://xn--r1a.website/technologique/1157
Доклад Рика Хадсона на конференции GopherCon 2015 о том, как в Go 1.5 удалось радикально уменьшить STW (Stop-The-World) задержки исполнения потоков программы (до наносекундных/субмиллисекундных показателей в последующих версиях, вплоть до крайних Go 1.8 и 1.9) благодаря применению гибридных алгоритмов многопоточной сборки мусора (GC) для программ написанных на языке Go.
https://www.youtube.com/watch?v=aiv1JOfMjm0
https://blog.golang.org/go15gc
Слайды:
https://talks.golang.org/2015/go-gc.pdf
Roadmap - на пути к версии 1.5:
http://golang.org/s/go14gc (https://docs.google.com/document/d/16Y4IsnNRCN43Mx0NZc5YXZLovrHvvLhK_h0KN8woTO4/edit)
Метрики:
https://github.com/bmhatfield/go-runtime-metrics
https://twitter.com/brianhatfield/status/900473287750365184
Статья с оценкой производительности и метрик сервиса Twitch в их блоге:
https://blog.twitch.tv/gos-march-to-low-latency-gc-a6fa96f06eb7
В версии языка и компилятора Go 1.5 был кардинально переработан код сборщика мусора (GC), до этой версии он был полностью переписан на самом Go методами автоматного (транс-компиляция с языка Си), а после и ручного программирования (коррекция) и были внедрены новые (вернее старые, но давно забытые) улучшения в алгоритмы многопоточной сборки мусора, благодаря чему данный GC стал лучшей программой в своём классе (субмиллисекундные задержки при освобождении памяти даже для оперативных in-memory хранилищ данных с размером кучи в 256 ГиБ (heap-size) для каждой ноды кластера!).
Эта разработка стала исторической вехой не только для языка Go, укрепившей его позиции в серверной разработке облачных инфраструктур, сетевых сервисов и демонов сетевых протоколов (server-side cloud infrastructure software development), но и большим прецедентом для доказательства работоспособности концепций (proof-of-concept) алгоритмов сборки мусора, разработанных ещё в 1970-х годах (tri-color, quad-color, incremental, mark & sweep algorithms).
Алгоритм сборки мусора, применённый в GC для программ на Go - это многопоточный трёхцветный (по фазам пометки указателей с последующим перемещением и освобождением блоков памяти) алгоритм коллектора (concurrent tri-color incremental mark & sweep collector), концепция которого была разработана известным датским математиком и инженером Эдсгером Дейкстра в 1978 году.
https://www.cs.utexas.edu/users/EWD/transcriptions/EWD05xx/EWD520.html
Но run-time (фаза исполнения) программ на Go был не первым проектом где был применён подобный алгоритм для коллектора памяти (GC).
Ранее Майк Пэлл (Mike Pall), автор знаменитого оптимизированного JIT копилятора Lua, применил подобный алгоритм в LuaJIT версий 1.x/2.0 для run-time фазы исполнения программ на языке Lua.
В LuaJIT будущей версии 3.0 автор планирует реализовать ещё более продвинутый четырёх-цветный оптимизированный алгоритм коллектора (Quad-Color Optimized Incremental Mark & Sweep GC).
http://wiki.luajit.org/New-Garbage-Collector
В run-time фазе исполнения программ оригинальным интерпретатором Lua версий 5.1/5.2 также используется трёхцветный алгоритм коллектора (Tri-Color Incremental Mark & Sweep GC). В более ранней версии Lua 5.0 использовался стандартный двухцветный алгоритм для коллектора памяти (Two-Color Mark & Sweep GC).
Отличная статья в блоге Майка Хёрна (Mike Hearn) о Go GC и вызовах современной компьютерной индустрии при создании гибридных алгоритмов коллекторов памяти:
https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e
Визуализация различных алгоритмов сборки мусора - https://xn--r1a.website/technologique/958
#Go
#GC
#Lua
#ThrowbackTech
Ссылки:
https://xn--r1a.website/technologique/721
https://xn--r1a.website/technologique/722
https://xn--r1a.website/technologique/750
https://xn--r1a.website/technologique/1057
https://xn--r1a.website/technologique/732
https://xn--r1a.website/technologique/551
https://xn--r1a.website/technologique/423
https://xn--r1a.website/technologique/1157
YouTube
GopherCon 2015: Go GC: Solving the Latency Problem - Rick Hudson
Long garbage collection (GC) pauses stand directly in the way of Go’s growth. It is an important, and often times the only, technical reason practitioners give for not migrating to managed runtimes such as Go. If Go is to live up to its promise of providing…
IDE GoLand от JetBrains для языка программирования Go официально выпущена в релиз.
https://blog.jetbrains.com/go/2017/11/30/the-way-to-go-jetbrains-goland-ide-hits-the-market/
#Go
#Golang
Links:
https://www.jetbrains.com/go/
https://plugins.jetbrains.com/plugin/9568-go
https://twitter.com/GoLandIDE
https://xn--r1a.website/technologique/1142
https://blog.jetbrains.com/go/2017/11/30/the-way-to-go-jetbrains-goland-ide-hits-the-market/
#Go
#Golang
Links:
https://www.jetbrains.com/go/
https://plugins.jetbrains.com/plugin/9568-go
https://twitter.com/GoLandIDE
https://xn--r1a.website/technologique/1142
Technologique
Go Garbage Collector — concurrent tri-color incremental mark & sweep algorithm. Доклад Рика Хадсона на конференции GopherCon 2015 о том, как в Go 1.5 удалось радикально уменьшить STW (Stop-The-World) задержки исполнения потоков программы (до наносекундны…
Go CSP concurrency (cooperative/non-preemptive multithreading) versus actor model for multithreading.
Сравнение многопоточной производительности, реализаций очень близких моделей кооперативной многопоточности, Go CSP (goroutines+channels) и акторных фреймворков от Parallel Universe, Quasar для Java/Kotlin/Scala и Pulsar для Closure — скорости порождения новых программных потоков (green threads, user threads, fibers), их мапинга (M:N) во время исполнения на пул системных тредов (thread-pool) процесса приложения, предачи данных между потоками, задержек и оверхэда всех операций с потоками.
Quasar:
http://www.paralleluniverse.co/quasar/
http://blog.paralleluniverse.co/2014/08/12/noasync/
http://blog.paralleluniverse.co/2013/10/16/spaceships2/
Go 1.1:
http://blog.paralleluniverse.co/2013/05/02/quasar-pulsar/
Go 1.6.2:
http://blog.paralleluniverse.co/2016/05/03/skynet-go-quasar/
Skynet, бенчмарк для теста многопоточности:
https://github.com/atemerev/skynet
Сравнение многопоточной производительности, реализаций очень близких моделей кооперативной многопоточности, Go CSP (goroutines+channels) и акторных фреймворков от Parallel Universe, Quasar для Java/Kotlin/Scala и Pulsar для Closure — скорости порождения новых программных потоков (green threads, user threads, fibers), их мапинга (M:N) во время исполнения на пул системных тредов (thread-pool) процесса приложения, предачи данных между потоками, задержек и оверхэда всех операций с потоками.
Quasar:
http://www.paralleluniverse.co/quasar/
http://blog.paralleluniverse.co/2014/08/12/noasync/
http://blog.paralleluniverse.co/2013/10/16/spaceships2/
Go 1.1:
http://blog.paralleluniverse.co/2013/05/02/quasar-pulsar/
Go 1.6.2:
http://blog.paralleluniverse.co/2016/05/03/skynet-go-quasar/
Skynet, бенчмарк для теста многопоточности:
https://github.com/atemerev/skynet
Dependent Typing and Monads as type system extensions.
Интересная беседа со Стефани Вейрих по зависимым типам, монадам, как коллекциям типов для расширения базовой системы типов языка Haskell (системы типов Хиндли-Милнера, λω = λ2 + λω_) — применении теории категорий для создания струкурных (высокоуровневых) и субструктурных (низкоуровневых) систем типов, применении теории типов Мартина-Лёфа (Martin-Löf type theory) для создания систем зависимых типов (исчисление конструкций, CoC, λPω) для (структурного и субструктурного) вывода типов при статическом анализе программ.
https://www.infoq.com/interviews/weirich-haskell-dependent-types
#Haskell
Ссылки по теме:
https://xn--r1a.website/technologique/1051
https://xn--r1a.website/technologique/1052
https://xn--r1a.website/technologique/1054
Интересная беседа со Стефани Вейрих по зависимым типам, монадам, как коллекциям типов для расширения базовой системы типов языка Haskell (системы типов Хиндли-Милнера, λω = λ2 + λω_) — применении теории категорий для создания струкурных (высокоуровневых) и субструктурных (низкоуровневых) систем типов, применении теории типов Мартина-Лёфа (Martin-Löf type theory) для создания систем зависимых типов (исчисление конструкций, CoC, λPω) для (структурного и субструктурного) вывода типов при статическом анализе программ.
https://www.infoq.com/interviews/weirich-haskell-dependent-types
#Haskell
Ссылки по теме:
https://xn--r1a.website/technologique/1051
https://xn--r1a.website/technologique/1052
https://xn--r1a.website/technologique/1054
InfoQ
Stephanie Weirich on Dependent Typing, Extending Haskell, Type System Research
Stephanie Weirich gives an introduction to the ideas behind dependent typing, dependent typing in Haskell, extending Haskell, and the status and future of type theory.
Technologique
Dependent Typing and Monads as type system extensions. Интересная беседа со Стефани Вейрих по зависимым типам, монадам, как коллекциям типов для расширения базовой системы типов языка Haskell (системы типов Хиндли-Милнера, λω = λ2 + λω_) — применении теории…
This media is not supported in your browser
VIEW IN TELEGRAM