Информация об изменениях

Сообщение Re: Сloud functions и ограничения по ЯП от 31.07.2023 13:53

Изменено 31.07.2023 13:57 vsb

Re: Сloud functions и ограничения по ЯП
Здравствуйте, Shmj, Вы писали:

S>AWS Lambda: Java, Go, PowerShell, Node.js, C#, Python, and Ruby.

S>Google Cloud Functions: Java, Python, Go, Node. js, and Rust.
S>Azure Functions: C#, JavaScript, Java, PowerShell, Python, TypeScript.

S>Т.е. в основном интерпретируемые языки или управляемые. Исключение — Rust для Google Functions — это же не управляемый язык, т.е. не выполняется в вирт. машине.


Go — компилируемый язык.

S>И вопрос у меня такой. Выбор языков чем-то принципиально ограничен?


Желанием компании поддерживать инфраструктуру для этого языка.

S> Не создается отдельная вирт. машина


С чего ты взял? Создаётся.

S> а изоляция достигается средствами ограничения API (как то стандартные функции записи в файл — не доступны или урезаны (как-то читать можно только из своей папки)).


API тут не при чём, любые ограничения API можно обойти, тем более на языках вроде Go или Rust, где ты можешь просто написать машинный код в память и выполнить его.

S>Т.е. С++, получается, особо нельзя применить, т.к. там придется запретить прямой доступ к памяти процесса, а это уже не проканает — без этого язык не может существовать?


Можно, просто это никому не нужно. И Go и Rust ничем принципиально от C++ не отличаются. На Java тоже можно в память писать, ежели умеючи. Конечно же там всё ограничено на уровне виртуальных машин, иначе никак.

S>С Rust, как я понял, удалось за счет того, что можно отключит unsafe и оставить только safe. С C# та же петрушка, по сути — там тоже unsafe. А вот с С++ это не проканает, т.к. нету концепции safe|unsafe. Правильно я понял?


Откуда ты это взял, что там только safe?

Ещё обычно есть опция — просто OCI-образ, который будет работать, как эта "функция". Если хочешь писать на C++, используй этот вариант. Думаю, что "под капотом" все языки в итоге и превращаются в какой-то образ и запускаются в виртуальных машинах. Иначе никак. Даже контейнеры не обеспечивают надёжной изоляции. А про "Shared hosting" даже смешно и думать, что в одном процессе рядом будут выполняться функции от банка и функции от шарашкиной конторы.

https://firecracker-microvm.github.io/ вот технология от амазона, которая используется для всего этого.
Re: Сloud functions и ограничения по ЯП
Здравствуйте, Shmj, Вы писали:

S>AWS Lambda: Java, Go, PowerShell, Node.js, C#, Python, and Ruby.

S>Google Cloud Functions: Java, Python, Go, Node. js, and Rust.
S>Azure Functions: C#, JavaScript, Java, PowerShell, Python, TypeScript.

S>Т.е. в основном интерпретируемые языки или управляемые. Исключение — Rust для Google Functions — это же не управляемый язык, т.е. не выполняется в вирт. машине.


Go — компилируемый язык.

S>И вопрос у меня такой. Выбор языков чем-то принципиально ограничен?


Желанием компании поддерживать инфраструктуру для этого языка.

S> Не создается отдельная вирт. машина


С чего ты взял? Создаётся.

S> а изоляция достигается средствами ограничения API (как то стандартные функции записи в файл — не доступны или урезаны (как-то читать можно только из своей папки)).


API тут не при чём, любые ограничения API можно обойти, тем более на языках вроде Go или Rust, где ты можешь просто написать машинный код в память и выполнить его.

S>Т.е. С++, получается, особо нельзя применить, т.к. там придется запретить прямой доступ к памяти процесса, а это уже не проканает — без этого язык не может существовать?


Можно, просто это никому не нужно. И Go и Rust ничем принципиально от C++ не отличаются. На Java тоже можно в память писать, ежели умеючи. Конечно же там всё ограничено на уровне виртуальных машин, иначе никак.

S>С Rust, как я понял, удалось за счет того, что можно отключит unsafe и оставить только safe. С C# та же петрушка, по сути — там тоже unsafe. А вот с С++ это не проканает, т.к. нету концепции safe|unsafe. Правильно я понял?


Откуда ты это взял, что там только safe?

Ещё обычно есть опция — просто OCI-образ, который будет работать, как эта "функция". Если хочешь писать на C++, используй этот вариант. Думаю, что "под капотом" все языки в итоге и превращаются в какой-то образ и запускаются в виртуальных машинах. Даже контейнеры не обеспечивают надёжной изоляции. А про "Shared hosting" даже смешно и думать, что в одном процессе рядом будут выполняться функции от банка и функции от шарашкиной конторы.

https://firecracker-microvm.github.io/ вот технология от амазона, которая используется для всего этого.