А есть ли ЯП, которые умеют обходиться без системы сборки?

БД, скорее всего, будет на сервере

нет, она будет на компе разработчика - она же не боевая

По теме: в контексте твоих запросов - любой ЯП, умеющий вычислять в момент компиляции. Лиспы, Perl, Haskell, Scala и вроде C++ (про последний не очень уверен, т.к. там не так всё просто).

Нет, совсем нет. Вопрос не в том, чтобы вычислять во время компиляции, а вопрос в том, чтобы

1) удобно вычислять во время компиляции, интегрированно и статически типизированно (ну или аннотации там расставлять, как в питоне)

2) вызывать прямо во время компиляции произвольные функции из собственных библиотек, в тех же плюсах возможно вызвать constexpr функцию, но нельзя вызвать функцию, которая сделает запись в файл, например

Кстати, а что у питона с аннотациями типов в ORM -ах ?

Фичи из пункта 1 очень сложно совместно реализовать.

К примеру, в хаскеле и скале некоторые либы-фреймворки позволяют определять разные схемы для парсинга с помощью EDSL. Но я бы не сказал, что это удобно.

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

базы данных)

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

т.е., это всё-таки, возможно, и в отдельных языках, даже на практике реализовано

А по 2 пункту - зачем тебе писать в файл при компиляции? Если надо писать в файл - пиши в рантайме. Наоборот, разработчики ЯП стремятся ограничить код, выразимый при компиляции. Что бы тебе не сделали rm -rf при каком-нибудь perl -c Модуль.pm (в перле это можно, не знаю, как в других динамических ЯП).

зачем тебе писать в файл при компиляции?

например, сгенерировать из xml *h и *cpp, любая gui рисовалка такое умеет, но не изнутри языка, что неудобно

Rust мощный язык, которого я не знаю, но всё же, подозреваю что эта ORM работает как движок регекспов в большинстве языков - вспомогательные структуры данных формируются при (первом) использовании того или иного регекспа, а движок по сути интерпретирует их.

Интерпретатор тебе не возбраняется написать практически с любым ЯП.

движки регекспов во многих языках, кстати, тоже зачастую формируют вспомогательные структуры данных именно на этапе компиляции

«не возбраняется» и удобство вещи разные

Во-первых, ты взял из воздуха маловероятный и довольно бредойвый кейс. Во-вторых, можно просто сдампить запросы, генеряемые алхимией. Проблемы?

Нет. Там всё на этапе компиляции. В том числе и базовая валидация запросов.

Главная ORM в Rust - https://github.com/diesel-rs/diesel

Там compile-time генерация финального кода через макросы и аттрибуты

#[derive(Queryable)]
pub struct Post {
    pub id: i32,
    pub title: String,
    pub body: String,
    pub published: bool,
}

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

http://diesel.rs/guides/getting-started/

Сам фреймворк немного нарушает DRY принцип, определяешь одно и то же по много раз, так что что-то мне он не очень уже на уровне getting started нравится

Во-первых, ты взял из воздуха маловероятный и довольно бредойвый кейс

Не более бредовый, чем миграция на другую СУБД, про которую часто поют адепты ORM. По факту я сталкивался с переходом на другой ЯП чаще.

Во-вторых, можно просто сдампить запросы, генеряемые алхимией.

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

круто! Т.е. в rust тоже полноценные compile-time тюринг-полные макросы?

А есть ли ЯП, которые умеют обходиться без системы сборки?

Red - язык, рантайм и нативная кросскомпиляция под несколько платформ в 1мб бинарнике.

Только он пока еще из альфы не вылез, так что можно сказать не считается.

Хибер это обычная либа.

Но мне уже нравится.

Да.

https://doc.rust-lang.org/book/ch19-06-macros.html#procedural-macros-for-gene...

Forth