Comment by salt-licker | Hacker News Reader

Comment by salt-licker | Hacker News Reader

Julia’s type system is not particularly user-friendly. For example, it has both a “String” and a “SubString” type which cannot always be interchanged. Their language design seem to be much more concerned with execution speed than programmer productivity — Python has the balance in the opposite direction, but they’ve been gradually improving performance for years, and this is much easier to improve after the language design is set in stone, especially as more and more people add typing info to their programs.

Also, 1-indexed arrays are a major turn-off.

I’ve generally found they can be interchanged in the way you would expect as a Python user: duck typing. I have more experience using SubArrays, but I think the underlying machinery in the language is basically the same.

Adding performance after the fact is not easy. This is why most numerical Python projects depend on C extensions rather improvements to the Python runtime. Writing C extensions or jamming your algorithm into the shape of existing C accelerated APIs is often not very time efficient.

IMO, array indices are a matter of taste which inspire feelings of religious intensity.

You can change it if you prefer 0 or -14 or whatever number you like. Non zero effort is required, but if you otherwise like the language it can be changed AFAIK

https://docs.julialang.org/en/v1/devdocs/offset-arrays/

    julia> supertype(String) == supertype(SubString) == AbstractString
    true

If you insist just use f(s::AbstractString)

Reply on news.ycombinator.com