Запросы к triple store (SPARQL) ещё более громоздкие, чем к полноценной графовой БД с произвольными атрибутами вершин и рёбер. 😔

Да, я видел этот доклад, он очень хороший. Идея простая — и это у него как раз мотивам алгоритмизации мат. нотации времен Fortress. Я был бы только рад такому ЯП, на котором бы выполнялся "код" из научных статей. Возможно, некоторых авторов это бы дисциплинировало :)

Fortress не вызвал интереса у DARPA. "Математиков" (кто бы это должен был быть, интересно?) никто не спрашивал.

А вот это интересный момент. По моему опыту (а я муз. программированием интересуюсь много лет) непрограммисты проявляют больший интерес, все-таки, к визуальному представлению. Причина здесь в том, как мне кажется, что близость к предметной области, к предметной нотации важнее, зачастую, всего остального. Электронные музыканты хорошо представляют, как работать с модульными аналоговыми синтезаторами. Это множество блоков с различными регуляторами, блоки соединяются между собой с помощью проводов. И "творческий метод тыка" здесь отлично работает — музыканту интересно пробовать различные идеи, экспериментировать. В текстовом представлении все уже не так наглядно и увлекательно. Любопытно, что приведенный по ссылке Sonic Pi это фасад к уже давно известному аудиоязыку SuperCollider. Сам по себе SC достаточно прост и довольно мощен, но музыканты им не очень заинтересовались. Путь упрощения синтаксиса (SonicPI) тут, скорее, погоды не изменит. При этом Max/MSP, Pd, Reaktor, Kyma и прочие продолжают музыкантами использоваться.

Это, опять же, вопрос специализации. В области компиляторов есть свои "графовые БД" и свои языки запросов. Моника Лэм целый раздел в последней книге дракона отвела на описание статического анализа средствами Datalog. При этом есть ряд работ по эффективной компиляции Datalog в императивные представления.

Ну так в своих областях они и "взлетели", и появление N графовых БД в последние годы говорит о том, что либо новые ниши возникли, либо повысился интерес к старым.
Но вопрос же был о "погружении" языка "общего назначения" в графовую БД (что бы это ни значило).

Именно. Вопрос требует доп. осмысления самим задающим, и пока все это мимо компиляторной тематики :)

Да, скорее всего. Хотя не совсем понятно, чем это от графа отличается

Граф - понятие растяжимое. Triple stores реализуют только один тип графов. "Полноценные" графовые БД обычно позволяют разметить рёбра и вершины произвольным набором атрибутов, вот и вся разница. Добавляет удобства.

https://christine.website/blog/compile-stress-test-2019-10-03 Тупо, но весело. 😂

"Meanwhile the same thing in Go took 5 minutes and I was able to run it on my desktop instead of having to rent a server from AWS.". Вот-вот. А ведь благородная цель авторов Go добиться высокой скорости компиляции оставила, к сожалению, широкие программистские массы равнодушными.

Вроде нет. Все гоферы в восторге от скорости компиляции, а взялись они не из воздуха - перешли с других языков.

угу, с JS ;)

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

Если в Rust нужна высокая скорость компиляции, то так же выполнимо. Делал когда то давно подобный тест, только там был Rust и AS и не 1.1 млн строк а 400 тыс что тоже неплохо. На моем стареньком макбуке 2013 года 7 минут в итоге:
https://github.com/MaxGraey/assemblyscript-compiler-bench#results-rust-rustc-1400-nightly-37538aa13-2019-09-25

Все дело в настройках компилятора и понимании того, как работают макросы в Rust

если быть достаточно упоротым, можно и С++ заставить быстро комплироваться (в том числе шаманя флаги)
но вот только пользователям нужно "сделать за%бись" по дефолту :)

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

Конечно, хороший тон — открыть информацию о том, что за алгоритмы в компиляторе имеют экспоненциальную сложность. Только я не уверен, что сообщество в том же Rust осведомлено обо всех деталях, особенно, если учитывать, как быстро код меняется :)

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