То чувство, когда думал, что Rust — про безопасный C++, а оказалось — про быстрый Haskell

12 строчек разделяют гибкость от безопасности и производительности. Разумная цена?

Подборка статей Филиппа Вадлера по аффинным типам

Однозначно в вишлист

Сурцы

Наткнулся на очень хорошую обзорную статью Rust vs. Haskell, благодаря которой поближе познакомился с Haskell. В целом мое первое впечатление от Rust как высокопроизводительном варианте функциональном языке ака Haskell оказался правдивым. Но Rust за свою эффективность заплатил отказом от части фич ML семейства:

Partial field accessors

Благодаря этой возможности в Haskell в конструктор типа-суммы можно передавать аргументы одного из типов, например:

data Croissant  = Plain {price :: Double}
  | WithFilling {filling :: String, price :: Double}

let plain = Plain 1.75

-- This is ok and works as expected:
print $ price plain
-- Prints: 1.75

Runtime and concurrency

Rust пошел по пути stackless корутин со всеми любимыми async/await, что нельзя сказать про Haskell с более приятным синтаксисом:

concurrentProgram :: Work -> IO Result
concurrentProgram work = do
  results <-
    timeout twoSeconds $
      mapConcurrently (doWork work) [ServiceA, ServiceB, ServiceC]
  pure $ case results of
    Just success -> Success success
    Nothing -> Timeout
 where
  twoSeconds = 1000 * 1000

-- Run the program
concurrentProgram someWork

Generators

В Rust толком нет ленивых вычислений, которые могут быть очень полезны для оптимизации памяти. Haskell напротив всегда лениво вычисляется.

Higher-order programming

В Haskell все построено на высоко-уровненных абстракциях как монады, функторы и т.д., которые делают язык более выразительным. Но с другой стороны, это все не бесплатно, а Rust предоставляют достаточную выразительность также

Добрался до новинки от Влада Хононова

Буду тут оставлять отрывки, под тегом #balancing_coupling

#balancing_coupling

Дедушки вспоминают пришествие микросервсивов:

Around 2014, yet another “decoupling salvation” came around — microservices. I even remember a slide saying “microservices is the architecture for decoupling” at some conference

В последнее время очень часто встречаю ссылки на эту книгу от Кент Бека до Влада Хононова. Однозначно в список на чтение Yourdon and Cosntantine 1975

#balancing_coupling

Coupling suggests a relationship between connected entities. If they are coupled, in some way, they can affect each other. That said, as there are different systems to build and different ways to design them, there are different ways to connect components.

#balancing_coupling

There are different types of knowledge that can be shared across the boundaries of coupled components. The more knowledge is shared, the higher the dependency between the components; thus, the more often the components will have to change together. Even if components are not sharing knowledge, they can be coupled through shared lifecycles.

#balancing_coupling

Позитивный настрой в книге по архитектуре программ

Charles Perrow conducts a detailed analysis of the causes for catastrophic accidents in complex systems, such as nuclear power plants, air traffic, and others. He concludes that, sooner or later, all complex systems are doomed to fail.

#balancing_coupling

Всем любителям оверинженерии и хайповых примочек посвящается

A system is plagued with accidental complexity: the team introduces tools and techniques because they are trendy, and not because they are really needed.

#balancing_coupling

Modular design aims to address a wider range of goals than a non-modular system can. It expands the system’s goal to accommodate requirements that are currently unknown, but may be needed in the future.

#balancing_coupling

The goal of an abstraction is to represent multiple things equally well

#balancing_coupling

An effective abstraction removes all extraneous information, retaining only what is absolutely necessary for effective communication

Один из лучших докладов по форме подачи и содержанию

https://youtu.be/wi6h9ox1wwM?si=uWWSmuuNx-eJ9MvX

В этом году вышла книга Building Multi-Tenant SaaS Architectures собственно про построение multi-tenant SaaS, как понял, это как раз то, что сейчас в разных командах называют «платформизацией» или «платформой», но явно не является PaaS.

Такая «платформизация» является трендам во многих командах последние годы.

В список на чтение, нужно разбираться с сабжем

Краткий ответ, почему для успеха ЯП недостаточно его хорошо спроектировать и дать базовые инструменты разработки. Экосистема играет огромную роль в завоевании успеха, и как кажется, инвестиции в неё могут позволить только большие компании