Популярные высокоуровневые ЯП с AOT компиляцией или транспайлингом в другие AOT компиляторы для системного программирования (например, CLI утилитки) с максимально широкой поддержкой таргетов (оси, архитектуры и т.п.)

Ты так пишешь как будто только что об этом задумался.

Я ж тебе говорил, не надо умничать всякими мутными аббревиатурами. Вот уже оказалось что ты её ещё и не к месту использовал (я вот почитал - hateWin прав, AOT это схема «скомпилируем и запустим», а вовсе не предкомпилированный бинарник как ты думаешь, да это похоже на JIT, но JIT компилирует куски кода по мере их использования, а тут вся прога сразу). А мог бы просто по-русски написать своими словами и никто бы не придирался.

И вообще, забей ты на эти девопсы и роадмапшы, они до добра не доведут.

И вообще, забей ты на эти девопсы и роадмапшы,

Какая связь между DevOps и обсуждаемой темой?

Ты же делаешь вид, что туп как валенок, потому что не отличаешь DevOps от системного программирования.

они до добра не доведут.

Тебя твои советы точно до добра не доведут, можешь быть уверен.

AOT это схема «скомпилируем и запустим»,

И чем же это отличается от следующего:

а вовсе не предкомпилированный бинарник как ты думаешь,

Я уже дважды давал линк на википедию про С++, но до альтернативно одарённых троллей типа вас с hateWin никак не доходит, потому что в качестве троллей других не принимают на такую службу типа вашей.

Ruby

https://www.reddit.com/r/ProgrammerHumor/comments/1ajmgrl/irrelevance/

Поправил заголовок: Популярные высокоуровневые ЯП

Понятнее не стало. Вопрос какой?

Понятнее не стало. Вопрос какой?

Популярные высокоуровневые ЯП с AOT компиляцией или транспайлингом в другие AOT компиляторы для системного программирования (например, CLI утилитки) с максимально широкой поддержкой таргетов (оси, архитектуры и т.п.) (комментарий)

какие существуют высокоуровневые ЯП - аналоги GoLang с точки зрения деплоя выхлопа (много таргетов, где можно запустить выхлоп), но с более приятным синтаксисом, чем у GoLang.

Ну ЛИСП же. Если хочешь модно-молодёжно, то zig и crystal. Ещё сейчас разная скриптота (и не только) поддерживает компиляцию в wasm. А уже wasm можно откомпилять нативно (или в Си).

Ну ЛИСП же.

Совсем не нравится, и Emacs тоже.

Если хочешь модно-молодёжно, то zig

Название так себе и поддержки классов вроде нет?

и crystal.

Что-то я не заметил у него особой кроссплатформенности как у Сишки - промежуточного таргета, например, для Nelua.

Ещё сейчас разная скриптота поддерживает компиляцию в wasm.

Вот это надо изучить подробнее.

Как только не изгаляются, лишь бы на плюсах не писать.

Как только не изгаляются, лишь бы на плюсах не писать.

А какие преимущества у плюсов по сравнению с Nelua?

и Ruby со своим Sorbet

Опять нейронка подсказала? Sorbet — это (gradual) static type checker, к теме он не относится никак.

Sorbet — это (gradual) static type checker, к теме он не относится никак.

На этот раз ценное замечание, благодарю (не сарказм)!

Ещё другие ошибки есть в моих сообщениях этой ветки?

Предкомпилированный бинарник - это когда его скомпилировал автор и раздаёт уже в нативном виде. АОТ это когда раздаётся исходник либо байткод, а в бинарник он превращается непосредственно перед выполнением. Разница тут такая: предкомпилированный бинарник будет только под те архитектуры, под которые его сделал автор, а во втором случае раздаётся что-то кроссплатформенное, но на компе где ты его запускаешь должен быть компилятор.

Предкомпилированный бинарник - это когда его скомпилировал автор и раздаёт уже в нативном виде. АОТ это когда раздаётся исходник либо байткод, а в бинарник он превращается непосредственно перед выполнением. Разница тут такая: предкомпилированный бинарник будет только под те архитектуры, под которые его сделал автор, а во втором случае раздаётся что-то кроссплатформенное, но на компе где ты его запускаешь должен быть компилятор.

Пруфы будут?

Тебе опровергающих линков накидать, где будет расписано, как можно распространять нативные сборки после AOT без сорцов и без промежуточного байт кода?

Нативные сборки после АОТ не будут АОТ, они будут нативными сборками.

Нативные сборки после АОТ не будут АОТ, они будут нативными сборками.

Как же ты достал своими тупыми придирками. На, почитай:

https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=net7%2Cwindows

Publishing your app as Native AOT produces an app that's self-contained and that has been ahead-of-time (AOT) compiled to native code. Native AOT apps have faster startup time and smaller memory footprints. These apps can run on machines that don't have the .NET runtime installed.

The Native AOT deployment model uses an ahead-of-time compiler to compile IL to native code at the time of publish. Native AOT apps don't use a just-in-time (JIT) compiler when the application runs. Native AOT apps can run in restricted environments where a JIT isn't allowed. Native AOT applications target a specific runtime environment, such as Linux x64 or Windows x64, just like publishing a self-contained app.

Я ж тебе говорил, не надо умничать всякими мутными аббревиатурами.

Мутные они только в твоём с hateWin замутнённых сознаниях.

Вот уже оказалось что ты её ещё и не к месту использовал (я вот почитал - hateWin прав, AOT это схема «скомпилируем и запустим», а вовсе не предкомпилированный бинарник как ты думаешь, да это похоже на JIT, но JIT компилирует куски кода по мере их использования, а тут вся прога сразу).

Почитал уже линк от Microsoft?

А мог бы просто по-русски написать своими словами

Мог бы, но зачем? Я пишу для общения с профи, а не с форумными троллями типа тебя с hateWin .

и никто бы не придирался.

Обрадовал, мне теперь подстраиваться под требования любого тролля или неуча, незнакомого со значениями используемых аббревиатур?

И вообще, забей ты на эти девопсы и роадмапшы

А ещё что сделать? Огласите весь список своих пожеланий, пожалуйста!

Меньше читай микрософтовских маркетологов. Найди более авторитетный источник.

Rust - это IMHO уже перебор,

Кхм. Поперхнулся. На нём как раз cli пишется с пол пинка.

• разбор аргументов,
• десериализация json/yaml/…,
• работа с сетью/USB/…,
• tui/цветная консолька/…,
• можно смело паниковать, только по человечески опиши почему.

А вот с полноценными приложениями…

Вероятно, наиболее портируемыми ЯП будут те, для которых есть транспайлер в С, Free Pascal или хотя бы Rust?

Сейчас «новые» языки чаще выползают на разные архитектуры за счёт LLVM. Только, как всегда, остаются НО. Т.к. в стандартную библиотеку пихают поддержку utf-8 для ввода/вывода и файловой подсистемы, и многие прочие фишки, которые далеко не кросплатформенные в Си без библиотек.

Т.е. основной проблемой является не поддержка архитектуры процессора, а поддержка ОС. И если писать транслятор в Си, то ещё нужны и кросплатформенные библиотеки. Как, например, делает Vala.

На нём как раз cli пишется с пол пинка.

На чём проще и быстрее писать простой и сравнимый по сложности CLI? На Ion shell (кстати написанный на Rust, походит на Bash, но IMHO более понятный и удобный синтаксис при работе с массивами и строками) или полностью только на Rust?

Ion shell, насколько я понял, позволяет дополнять его своими кастом плагинами на Rust.

Т.е. основной проблемой является не поддержка архитектуры процессора, а поддержка ОС. И если писать транслятор в Си, то ещё нужны и кросплатформенные библиотеки. Как, например, делает Vala.

Интересно, как с этим обстоят дела у Python+Nuitka?

IMHO очень мало инфы о запуске бинарников, скомпиленных в Nuitka, на редких архитектурах типа MIPS, PowerPC, SPARC и относительно редких осях типа OpenBSD, Illumos, etc.

Очень радует Free Pascal своей всеядностью осей и архитектур, если верить его описанию.

Можешь, пожалуйста, сравнить портируемость софта, разработанного на Free Pascal, Rust и Nelua (сишный транспайлер)?

Сейчас «новые» языки чаще выползают на разные архитектуры за счёт LLVM. Только, как всегда, остаются НО. Т.к. в стандартную библиотеку пихают поддержку utf-8 для ввода/вывода и файловой подсистемы, и многие прочие фишки, которые далеко не кросплатформенные в Си без библиотек.

Судя по https://www.reddit.com/r/openbsd/comments/c11mx3/the_state_of_obsd_ppc/?rdt=41445

5 лет назад сборки сорцов на Rust были не шибко-то портируемыми. За 5 лет что-то улучшилось в Rust для OpenBSD+PowerPC ?

Меньше читай микрософтовских маркетологов.

А причём тут маркетологи Microsoft?

Документация создаётся маркетологами или техническими писателями?

Найди более авторитетный источник.

https://nelua.io/

Nelua takes advantage of ahead-of-time compilation using powerful, optimized C compilers such as GCC or Clang, and thus generates very efficient native code. No interpreter is needed at runtime. 

Надеюсь себя на пару с hateWin ты не считаешь авторитетным источником? Так и не смогли даже привести линки с пруфами своей точки зрения и опровержения моей. Пустая брехня без пруфов c вашей стороны. Возможно вам ваши преподы мозги немного деформировали субстанцией сомнительного происхождения. Переучивайтесь пока не поздно.

В связи с тем, что я не любитель кодинга на Python, но при этом понимаю полезность обилия готовых либ на нём, то возник ещё и такой вопрос: насколько возможно, полезно, практично компилить питонолибы через Nuitka и задействовать их из ЯП с более приятным синтаксисом типа Nelua?

IMHO Nelua (с синтаксисом Lua) дополнительно с арсеналом готовых различных либ на С, да ещё и с питонячими либами намного интереснее просто Nelua.

Приглашаю в обсуждение LINUX-ORG-RU как одного из любителей языка программирования Lua :)

Остаётся вопрос в портабельности такой связки Nelua + Nuitka_for_libs.

https://openjdk.org/jeps/295

Там достаточно прямым текстом указывается, что AOT делается юзером, а не автором.

Там достаточно прямым текстом указывается, что AOT делается юзером, а не автором.

Пожалуйста, процитируй здесь соответствующую фразу из упомянутого тобой текста.

я хз, кто все это пони и об чем вообще речь, но, блин, тут разве нет ограничений на длину заголовка?
ТС, ты мне весь раздел "лолкс" порвал своей портянкой в три строки, негодяй ты эдакий!
и вообще, какого хрена ты на pony.org.ru приперся со своими АОТ с транслайтингами (что бы это ни значило)? и что вообще эта непонятная муть делает в лолксах?

и вообще, какого хрена ты на pony.org.ru приперся со своими АОТ с транслайтингами (что бы это ни значило)? и что вообще эта непонятная муть делает в лолксах?

This ?

Извини, говорят, программисты обычно ведут себя как дети, а у меня ещё и осложнение BS degree in CS, вообщем всё плохо в данном контексте …

Это какой-то кринж. Почитай, что такое ahead of time compilation

Дай линк на правильное с твоей точки зрения определение. Авторитетное (с) ессно LOL, чтобы firkax не возмущался.

я хз, кто все это пони

они даже до пони ещё не развились

epony из OpenBSD - это огого человечище!

и об чем вообще речь

Настоящие красивые цветные пони - это ночные (для РФ) агенты АНБ ? :)

ЩИТО? По-моему, AOT присходит, когда виртуальная машина заранее компилирует байт-код в нативный код и кеширует результат.

Ты опять перепутал AOT с кэширующим JIT?

JIT Caching

During the execution of an application, the JVM dumps the code generated to disk. It allows the JVM, at the next execution of the application, to only have to pick-up where it left off, loading the code previously generated from disk, and have a robust startup throughput. It differs from the AOT compiler in the requirement to run the application to generate the code, while the AOT compiler only involves parsing the application’s code.

This method requires persistent storage between runs of the application. It does require the same dependencies and environment between runs. Otherwise, you cannot always guarantee that the code generated on a previous run is compatible with the current one.

Two implementations are OpenJ9 Dynamic AOT and Azul Compile Stashing, available in Azul Zing.

Я думаю проблема в сложности такой задачи для языка с большим набором фич, например, Python, который в отличие от Lua, или даже JavaScript несоизмеримо больше. Даже улучшалка Python - Mojo, написанный под свежий MLIR, не всё поддерживает.

Во-первых, консольные утилиты это не системное программирование.

Во-вторых, Unix-way это прошлый век, и вообще, в целом он провалился.

В третьих, термин AOT имеет смысл как противопоставление JIT, на тех платформах, где он имеется, т.е. Java и .NET, например. Лиспы, несмотря на то, что практически все компилируются в нативный код, в рантайме, по большей части никакие не AOT, а просто компиляторы(в Clisp есть байткод и JIT, например, но нету AOT, вроде бы, но разве что и всё). Этот термин вообще говоря, не имеет отношения к «созданию бинарника».

Во-первых, консольные утилиты это не системное программирование.

https://www.geeksforgeeks.org/system-programs-in-operating-system/

Some of the System Programs are simply user interfaces, others are complex.

Here are the examples of System Programs : 

...

    Command Line Interface(CLI’s) : CLIs is the essential tool for user . It provide user facility to write commands directly to the system for performing any operation . It is a text-based way to interact with operating system. CLIs can perform many tasks like file manipulation,system configuration and etc.
    Device drivers :Device drivers work as a simple translator for OS and devices . Basically it act as an intermediatry between the OS and devices and provide facility to both OS and devices to understand each other’s language so that they can work together efficiently without interrupt.

...

И я интересуюсь в контексте разработки портабельного (на разные архитектуры и оси) CLI для S6 init, так что тем более system programming ;)

Кроме того многие системные программы не имеют отдельной консольной утилиты, полностью отсоединённой к примеру от daemon, и поэтому у них тоже есть CLI. Т.е. CLI содержится внутри бинарника daemon. Надеюсь, daemon - это системное программирование?

Во-вторых, Unix-way это прошлый век, и вообще, в целом он провалился.

В каком смысле провалился?

Ты опять перепутал AOT с кэширующим JIT?

И чем тогда в твоей интерпретации AOT отличается от обычной компиляции той же сишки?

И чем тогда в твоей интерпретации AOT отличается от обычной компиляции той же сишки?

AOT компилятор - это некий преобразователь кода из состояния S1 в состояние S2.

S1 - состояние кода на входе AOT компилятора.

S2 - состояние кода на выходе AOT компилятора, пригодное для запуска (обычно на bare-metal).

S1 может быть кодом в сорцах, P/byte/IL, etc.

S2 должно соответствовать рантайму, т.е. обычно native. Но например, для Angulare - это JavaScript :)

AOT provides better security. It compiles HTML components and templates into JavaScript files long before they are served into the client display. So, there are no templates to read and no risky client-side HTML or JavaScript evaluation. This will reduce the chances of injections attacks.

https://www.geeksforgeeks.org/what-is-aot-and-jit-compiler-in-angular/

Важно то, что AOT компилятор обычно работает на машине разработчика или DevOps пайплайне до запуска на возможно другой целевой машине.

Об AOT компиляторах действительно заговорили, когда стали добавлять его альтернативной к JIT компиляторам, потому что раньше для старинных Сишки, etc. AOT компилируемость подразумевалась по умолчанию, на этом не делали акцента модными словечками, потому что редко для какого ЯП была возможность генерить байт код (кстати это IMHO тоже своеобразный AOT из сорцов в P/byte код). Ну для Паскаля (не Турбо) вроде было возможно такое в теории Вирта и даже для Perl.

Из дискуссии в этой ветке вижу, что народ привык понимать AOT так, как это описано в доках IBM и других Java вендоров.

Но за пределами Java мирка AOT тоже существует, а то что OpenJ9 называет у себя AOT, другие привыкли называть JIT caching.

У Oracle кстати IMHO определения AOT в контексте GraalVM ближе к тому, что мы наблюдаем в .NET и т.п.?

Было бы очень интересно узнать, какие с твоей точки зрения преимущества у Сишки над Nelua и Vlang?

1. Существующий код написан на C/C++

2. Примеры написаны для C/C++, инструменты написаны для C/C++, банально для этой маргинальщины даже IDE нету

3. Я не нашел как из них вызвать расширения компилятора

4. Я увидел что типы там имеют фиксированный размер которого может не быть на платформе нативно integer=int64_t

1. Существующий код написан на C/C++

Vlang и Nelua умеют работать с существующим сишным кодом:

https://stackoverflow.com/questions/61946577/how-to-use-c-libraries-in-vlang-for-basic-statistics

а Vlang кроме того, если я правильно понял, даже может конвертировать его в свой синтаксис:

https://github.com/vlang/c2v

Кроме того Vlang и Nelua являются транспайлерами в сишный код, т.е. на выходе у них сишный выхлоп :)

2. Примеры написаны для C/C++, инструменты написаны для C/C++,

Там ведь тоже есть примеры, экосистема постепенно вырастает.

банально для этой маргинальщины даже IDE нету

VSCode (Codium) и другие, они же перечислены по крайне мере для Vlang. Nelua ещё моложе.

4. Я увидел что типы там имеют фиксированный размер которого может не быть на платформе нативно integer=int64_t

Что в этом плохого?

Vlang и Nelua умеют работать с существующим сишным кодом

Нужно еще этот код расширять, дорабатывать, это все очень сложно. Макросы хотя бы работают в них сишные?

Там ведь тоже есть примеры, экосистема постепенно вырастает.

Где примеры uefi приложения на vlang? Как там с библиотеками?

VSCode (Codium) и другие, они же перечислены по крайне мере для Vlang. Nelua ещё моложе.

Это редактор а не IDE, пруф на офф.сайте. Статических анализаторов наверное вообще нету.

Что в этом плохого?

Платформа может поддерживать только 40 битные числа, или только 80 битные. Ладно бы еще тип был least, fast, но просто фиксированный...

Как там с библиотеками?

https://vpm.vlang.io/

https://github.com/vlang/awesome-v

Сразу хочу тебя предупредить, что я о Vlang знаю чуть больше твоего (если ты не троллишь своими вопросами), просто потому что прочитал инфу на их сайте.

Я не пытаюсь рекламировать Vlang, а интересуюсь, подойдёт ли он мне, есть ли более хорошие варианты.

Это редактор а не IDE, пруф на офф.сайте.

Таки многие разрабатывают в VSCode. Это больше, чем nano, и т.п. Отладчик тоже есть, судя по описанию.

Нужно еще этот код расширять, дорабатывать, это все очень сложно.

https://github.com/vlang/v/blob/master/doc/docs.md#calling-c-from-v

Calling C from V

Example

#flag freebsd -I/usr/local/include -L/usr/local/lib
#flag -lsqlite3
#include "sqlite3.h"
// See also the example from https://www.sqlite.org/quickstart.html
pub struct C.sqlite3 {
}

pub struct C.sqlite3_stmt {
}

type FnSqlite3Callback = fn (voidptr, int, &&char, &&char) int

fn C.sqlite3_open(&char, &&C.sqlite3) int

...

fn C.sqlite3_free(voidptr)

fn my_callback(arg voidptr, howmany int, cvalues &&char, cnames &&char) int {
	unsafe {
		for i in 0 .. howmany {
			print('| ${cstring_to_vstring(cnames[i])}: ${cstring_to_vstring(cvalues[i]):20} ')
		}
	}
	println('|')
	return 0
}

fn main() {
	db := &C.sqlite3(unsafe { nil }) // this means `sqlite3* db = 0`
	// passing a string literal to a C function call results in a C string, not a V string
	C.sqlite3_open(c'users.db', &db)
	// C.sqlite3_open(db_path.str, &db)
	query := 'select count(*) from users'
	stmt := &C.sqlite3_stmt(unsafe { nil })

Как там с библиотеками?

Как там с библиотеками?

Для uefi их очевидно нету, модули ядра как на этом разрабатывать - непонятно.

Таки многие разрабатывают в VSCode. Это больше, чем nano, и т.п.

Но это не IDE все равно.

https://github.com/vlang/v/blob/master/doc/docs.md#calling-c-from-v

Там получается все еще хуже чем я думал, нужно вручную описывать структуры? И следить потом за этим описанием...

а интересуюсь, подойдёт ли он мне, есть ли более хорошие варианты

Я думаю сначала нужна четкая цель, а там будет зависеть уже например от библиотек. Возможно для CLI утилиты будет идеально подходить Go, потому что будет очень удобная для задачи библиотека, а возможно C, потому что ничего кроме C library там не будет, а писать свои биндинги это лишняя работа.

Для меня очень важен синтаксис ЯП.

Старые плюсы я знаю ещё со средней школы, но предпочитаю высокоуровневые ЯП типа VisualBasic.NET и C#.

К сожалению AOT компилятор даже в Mono предлагает таргеты только для X86 и ARM.

Так что Vlang для меня - пока IMHO самый оптимальный вариант относительно высокоуровнего синтаксиса с максимальным охватом таргетов (разные архитектуры и оси).

Мне проще один раз биндинги описать к нужным функциям Сишных либ, чем постоянно плавать в гошной субстанции.

Из твоего списка, для Linux наиболее адекватно только Python по моему выглядит, я правда не понимаю зачем его компилировать.

Ещё и конвертор есть кода Go в V:

https://github.com/vlang/go2v

Но IMHO готовые либы лучше юзать в оригинале через Сишные вызовы.

Из твоего списка, для Linux наиболее адекватно только Python по моему выглядит,

Отвратный синтаксис, чуть лучше Golang. Приходится терпеть его только потому что учусь на DevOps инженера.

В роли разработчика рассматриваю CPython только в качестве поставщика готовых либ. В .NET/Mono его легко заюзать через специальный шлюз почти без лишних усилий. Т.е. почти все либы CPython автоматически доступны в .NET и Mono. И работает такая связка в лучшем случае через JIT без AOT.

Но нужно учитывать, что такой Python - это куча зависимостей (сам CPython и охапка либ к нему), которую деплоить без контейнеров - то ещё удовольствие. Теоретически можно воспользоваться Nuitka, но я уже упоминал своё отношению к программированию на Python. Поэтому даже Nuitka для меня - это всего лишь источник готовых питонячих либ для использования их из Vlang.

Я правда не понимаю зачем его компилировать.

Системное программирование утилит подразумевает на выходе один бинарник. И чтобы при сборке можно было задать десятки разных таргетов (отдельный бинарник для каждого) типа OpenBSD on PowerPC, OpenBSD on SPARC, etc. А тут у Mono AOT и тем более у .NET AOT полнейший провал - нет поддержки таких экзотических таргетов.

Системное программирование утилит подразумевает на выходе один бинарник.

Нет конечно. Обычно все утилиты что то за собой да тянут, даже С тянет за собой обязательно пару сошек.

И чтобы при сборке можно было задать десятки разных таргетов (отдельный бинарник для каждого) типа OpenBSD on PowerPC, OpenBSD on SPARC, etc.

Этой сборкой занимаются мейнтеры, ты должен предоставить исходники.