так а с другой стороны тебе нужно держать этот сервер и заботиться чтоб он не лежал и справлялся с запросами

зато естественно выглядит модель подписки вместо однократного платежа - сейчас это любят...

как пользователю мне конечно это тоже не нравится

покажи мне человека, который это любит?

Точка зрения пользователя мало волнует маркетологов. Продвигать же технологическое средство на платформу, которая борется с альтернативными вариантами её использования - довольно бессмысленное занятие

разве что те, у кого з.п. с кучей нулей и деньги некуда тратить

всмысле бизнес любит, не пользователи

хотя как обычно всё сводится к сумме: например, я бы выбрал $5/год вместо $20 разово практически для всего софта
другое дело, что лично мне вообще платным ПО не приходится пользоваться

проблема подписки в том, что пока она у тебя одна, то всё нормально. А когда ты подписываешься сразу на 5+ таких денежных пылесосов, то приходит понимание...

Как бы то ни было, не думаю, что Julia сейчас готова для экспансии на мобильные платформы. Для настольных приложений ситуация немного иная, поскольку размер приложения для скачивания в полгига сейчас никого не пугает. Особенно, если это приложение упаковано в контейнер как у macos

netflix + spotify + блогохостинг + какой-нибудь фитнес + airtable/seatable/аналог - хопа, а у тебя уже 50 евро в месяц выходит.

а можно ли каким-то образом уменьшить бинари жулии (путём вырезания неиспользуемых частей) для экспорта под десктоп?

или лучше просто просить юзера ставить жулиа рантайм самостоятельно если такого в системе нет

В теории, можно. Но сейчас этим никто не занимается. Кроме того, надо помнить о том, что код Julia - не 100% код типизированного языка. Даже в случае системного образа, код для обработки методов, в которых появились новые типы, всё равно сохраняется

Проще использовать подход с изолированным системным окружением. Те самые dmg-пакеты. Локальные зависимости по Julia приведут к потенциальным конфликтам библиотек. Зависимостей там много.

мб можно пакеты сделать самостоятельнее путём "заморозки" их зависимостей в один большой файл, содержащий код пакетов-зависимостей, который поставляется вместе с пакетом?

Если говорим о прекомпилированном варианте, то там уже нет пакетов. Но есть зависимости по бинарникам. Если поставлять с пакетами Julia, то время компиляции будет довольно большим. Все хотят, чтобы приложение устанавливалось быстро.

Вариант с бинарниками работает только тогда, когда есть централизованный репозиторий. Тогда будет чёткий граф зависимостей. И тогда, любое приложение, собранное с использованием системных бинарников, гарантированно будет запускаемым на этом системном окружении. В линуксах сделать это можно. В остальных случаях - нет. Для macOS оптимальный вариант - изолированный контейнер. В виндовс - традиционно анархия.

Я немного не это имел в виду.

Скорее то, что в python библиотеки обычно предоставляют объекты, с фиксированным набором методов. И в принципе сразу более-менее понятно, что с ними можно делать, а чего нельзя.

В Джулии же всё выглядит как лего - отдельные части можно стыковать друг с другом, но если ты не знаешь про существование этих частей, то ты ничего не сделаешь. И даже если знаешь, нужен некоторый опыт, чтобы научиться собирать их вместе.

Из примеров можно привести допустим то,  что говорил Ракаукас: можно использовать вместе Measurments.jl и DifferentialEquations.jl и получать решения диффуров сразу с интервалами допустимости. Это конечно очень круто, что так можно делать, но если ты не знаешь об этом, то об этом очень сложно догадаться, так как ни в документации Measurments ни в DifferentialEquations даже намека на это нет.

Да, необычно )