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

Можно конечно же.
Проблема в том, что это нужно делать всегда и везде, где идёт обработка текста.
Самое ужасное, что я когда начал смотреть библиотеки, то выяснилось, что каждый свои собственные велосипеды пилит.
Например CSV парсеры.
Сколько есть CSV парсеров, столько и контейнеров, которые строки оборачивают.

Имхо, это безобразие.

там есть ещё  iterate и collect(eachindex(str))

вариант над collect(eachindex(str)), думаю, что быстрее, чем nextind

Просто авторы сразу не подумали. Это надо было брать под контроль и выдавать рекомендации

str = "abываcdf"
@btime collect(eachindex($str))   # 72.807 ns (2 allocations: 160 bytes)
@btime collect($str)                        # 52.985 ns (1 allocation: 112 bytes)

Если речь идёт о десятках тысяч строчек, то разница уже существенная получается.

Ну и дополнительно

str = "abываcdf"
str2 = collect("abываcdf")

@btime $str[9] # 2.389 ns (0 allocations: 0 bytes)
@btime $str2[6] # 1.339 ns (0 allocations: 0 bytes)

В полтора раза медленнее коллект, почти в два раза меньше скорость обращения.

Неудобно всё это.
Нельзя этим пользоваться, если производительный код нужен.

str = "abываcdf"
str2 = collect("abываcdf")

@btime $str[9] # 2.389 ns (0 allocations: 0 bytes)
@btime $str2[6] # 1.339 ns (0 allocations: 0 bytes)

а это странно…. Надо разбираться, что же они там сделали

А, я смотрел.
Они не просто возвращают значение по индексу.
Они заходят в строчку, а потом начинают по ней двигаться, до тех пор пока не упрутся в конец символа.
После этого они собирают байты и конвертят их в UInt32, который уже и возвращают.

тогда понятно

А как они в bio Julia строки хранят, или у них только 4 буквы и нет проблем таких

Смотреть надо.
Но вроде бы, где-то я видел, что они какой-то аналог bitarray используют.

По два бита на букву.

То есть у них там вроде совсем не строки.

Но могу ошибаться, разумеется.

Я не знаю, честно говоря, что в Ruby, но насколько я понимаю, текущая концепция метапрограммирования в Julia целиком взята из Clojure и других LISP образных языков. Там управление AST выглядит довольно органично, более того, это вообще чуть ли не их базовая концепция. По крайней мере девиз кложуры "code is data, data is code".

Но в Джулии это всё выглядит не таким родным. Одна из причин имхо - это то, что между кодом и выполнением стоит компилятор, который своей жизнью живёт, из-за чего всё это метапрограммирование становится довольно непредсказуемым. Ну и к тому же оно ортогонально к базовым принципам, типа multiple dispatch.

RSpec.describe Game do
  describe "#score" do
    it "returns 0 for an all gutter game" do
      game = Game.new
      20.times { game.roll(0) }
      expect(game.score).to eq(0)
    end
  end
end

Рубийный вариант DSeL в виде теста RSpec. Ключевыми синтаксическими особенностями тут являются опциональные скобки и do/end в том же понимании, что и у Julia. + динамические методы, которые можно навешивать на класс или на экземпляр. У Julia в этом смысле есть multiple dispatch