Комментарии: 16
🦾
Залез поизучать всякие технологии стриминга / процессинга, и наткнулся там на Yomo
Не до конца понимаю что именно это за технология, кажется, что это framework + infra для запуска serverless функций, в которую вшит транспорт, роутер, деплой и среда запуска
Меня зацепило то, что они позволяют писать serverless функции на Go, Rust, C и даже Zig (уффф кайф), после чего вы конвертируете их в WASM и движок Yomo запускает эти функции...
И вот я не понимаю: это гениально или тупо?
Что меня смущает: все эти языки компилируются в бинарники, которые можно запускать даже на условном тостере, вопрос в том зачем для этого WASM? Способно ли 1 WASM приложение вызывать функции из разных языков или под каждое придется раскрывать свое приложение? А что происходит с "рантаймом" самих этих языков, например, конкурентность, IO или GC, в случае go?
Теоритические плюсы:
+ WASM работает одинаково на любых платформах, а значит билдишь на любой и запускаешь на любой, да, это удобно
+ Если сравнивать с docker, то WASM образ намного меньше весит, намного быстрее запускается и намного меньше требует ресурсов
+ Можно настраивать политики доступов во внешнюю сренду (особенно удобно для PaaS вендоров)
Исходя из плюсов, могу предположить, что WASM – это может быть удобной технологией для построения serverless PaaS с конкретными ограничениями на конкретные задачи (например, ETL)
P.S.
С праздниками вас, мои замечательные качки и качессы 💪
Не до конца понимаю что именно это за технология, кажется, что это framework + infra для запуска serverless функций, в которую вшит транспорт, роутер, деплой и среда запуска
Меня зацепило то, что они позволяют писать serverless функции на Go, Rust, C и даже Zig (уффф кайф), после чего вы конвертируете их в WASM и движок Yomo запускает эти функции...
И вот я не понимаю: это гениально или тупо?
Что меня смущает: все эти языки компилируются в бинарники, которые можно запускать даже на условном тостере, вопрос в том зачем для этого WASM? Способно ли 1 WASM приложение вызывать функции из разных языков или под каждое придется раскрывать свое приложение? А что происходит с "рантаймом" самих этих языков, например, конкурентность, IO или GC, в случае go?
Теоритические плюсы:
+ WASM работает одинаково на любых платформах, а значит билдишь на любой и запускаешь на любой, да, это удобно
+ Если сравнивать с docker, то WASM образ намного меньше весит, намного быстрее запускается и намного меньше требует ресурсов
+ Можно настраивать политики доступов во внешнюю сренду (особенно удобно для PaaS вендоров)
Исходя из плюсов, могу предположить, что WASM – это может быть удобной технологией для построения serverless PaaS с конкретными ограничениями на конкретные задачи (например, ETL)
P.S.
С праздниками вас, мои замечательные качки и качессы 💪
V
A
Моё мнение.
Это определенно гениально (wasi). Не понятно только приживеться ли.
Основной плюс — wasi контейнер не имеет доступа к окружению, только к тому к чему прокинули зависимости явно. Соответственно, тут выигрыш в производительности и утилизации ресурсов.
Можно разный код от разных клиентов запускать на одной железке и это очень быстро. Нету холодного старта.
Как правило там нету рантайма от языка, как и управления памятью. Много чего нету. 😁
Такой подход требует изменения мышления. 🥸 По сути, весь прикладной код не должен иметь побочных эффектов. 😌
Раньше были на слуху:
https://www.fermyon.com
Это определенно гениально (wasi). Не понятно только приживеться ли.
Основной плюс — wasi контейнер не имеет доступа к окружению, только к тому к чему прокинули зависимости явно. Соответственно, тут выигрыш в производительности и утилизации ресурсов.
Можно разный код от разных клиентов запускать на одной железке и это очень быстро. Нету холодного старта.
Как правило там нету рантайма от языка, как и управления памятью. Много чего нету. 😁
Такой подход требует изменения мышления. 🥸 По сути, весь прикладной код не должен иметь побочных эффектов. 😌
Раньше были на слуху:
https://www.fermyon.com
V
A
V
A
V
Похоже ты прав, есть пропозал на интеграцию большого WASM GC https://chromestatus.com/feature/6062715726462976 с GO, но по https://github.com/WebAssembly/gc/issues/59 в MVP этого нет, а так gc они включили в хроме уже
🦾
A
🦾
Сейчас читаю про WasmGC и понимаю, что Dart хоть где-то оказался реально полезен: благодаря тому, что Google пытается его хоть куда-то просунуть, они активно начали развивать Dart + WASM, чтобы более человечно внедрять его в браузер и это приводит к появлению WasmGC, который дает путь другим языкам))
A
🦾
A
Firestore по такому принципу может работать. Только там свой язык, вместо любимого. 🥶
service cloud.firestore {
match /databases/{database}/documents {
// Assign roles to all users and refine access based on user roles
match /some_collection/{document} {
allow read: if request.auth != null && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Reader"
allow write: if request.auth != null && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Writer"
// Note: Checking for roles in your database using `get` (as in the code
// above) or `exists` carry standard charges for read operations.
}
}
}
https://firebase.google.com/docs/firestore/security/get-started
service cloud.firestore {
match /databases/{database}/documents {
// Assign roles to all users and refine access based on user roles
match /some_collection/{document} {
allow read: if request.auth != null && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Reader"
allow write: if request.auth != null && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Writer"
// Note: Checking for roles in your database using `get` (as in the code
// above) or `exists` carry standard charges for read operations.
}
}
}
https://firebase.google.com/docs/firestore/security/get-started
🦾