>как будто кроме написания небольшой функции больше ничего и нет в языке
Как не странно, это примерно так и есть - Джулия позволяет хорошо дробить сложные алгоритмы на небольшие под-алгоритмы и делать так чтобы они работали на максимально большой области типов и хорошо повторно использовались 🙂

Так, мне кажется, именно для этого и сделан getproperty что бы всяких геттеров не писать. Если не хочешь что бы get был через getfield - перегружаешь getproperty и всё ...

ИМХО это дискуссионно и далеко не всегда выглядит понятным. Ну возвращаясь к тому же length(). Теоретически его тоже можно через getproperty переопределить.

Если это простое и понятное свойство, то почему нет. А если это какой-нить массив nzval из SparseArray, то при перегрузка его через getproperty в другой реализации AbstractSparseArray меня лично на какое-то время поставит в тупик

А getproperty умеет разве хорошо диспатчить? Я об этом никогда не задумывался особо, но он же вроде бы должен быть type unstable.

а standalone приложения сейчас можно создавать на Джулии? а то вот человек например пишет (год назад):

Те, кто работает плотно с Julia, подскажите, ее уже можно использовать в небольших standalone скриптах?

Я год назад пробовал написать небольшой standalone скрипт, который запускается по таймеру, собирает из API json'ы, делает расчет, пишет в файл и завершает работу.

К моему удивлению этот скрипт работал каждый раз секунд около 20, тогда как «медленный» python работал какие-то миллисекунды. Я написал в форумы, мне посоветовали запускать мой код из REPL, который все время висит в памяти. Я тогда немного удивился и забил на julia.

Подскажите, сейчас это починили?

https://habr.com/ru/post/519930/#comment_22097222

Или они как-то хитро обошли это ограничение?

как я понимаю, когда a.b разворачивается в getproperty, то всегда срабатывает constant propagation внутри этой функции

и компиляция выдаёт всегда нужный тип, без нестабильностей

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

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

О, здорово, спасибо.

Хммм...
То есть это и с другими функцями должно сработать? 😊

если как-то убедиться, что всегда constant propagation будет, то должно :)

Ну да, логично.
Поэтому for name in fieldnames(x) работает медленно, а x.foo быстро.

про оверхед запуска: если скрипт лёгкий и не делает особых вычислений, то можно запускать julia --compile=min

ещё PackageCompiler есть, но я не пользовал

Интересно

function foo(x)
    if x == 1
        return 0
    elseif x == 2
        return -1.0
    elseif x == 3
        return "asdsad"
    elseif x == 4
        return 'a'
    end
end

@code_warntype foo(2)
julia> @code_warntype foo(2)
Variables
  #self#::Core.Const(foo)
  x::Int64

Body::Any
1 ─ %1  = (x == 1)::Bool
└──       goto #3 if not %1
2 ─       return 0
3 ─ %4  = (x == 2)::Bool
└──       goto #5 if not %4
4 ─       return -1.0
5 ─ %7  = (x == 3)::Bool
└──       goto #7 if not %7
6 ─       return "asdsad"
7 ─ %10 = (x == 4)::Bool
└──       goto #9 if not %10
8 ─       return 'a'
9 ─       return nothing

Но при этом

julia> @btime foo(2)
  0.019 ns (0 allocations: 0 bytes)
-1.0

```

То есть code_warntype обманывает немного.

@code_warntype это не ловит, да

он только тип аргумента учитывает, а не значение