LINUX.ORG.RU

Бета-выпуск языка программирования Mojo 1.0

 mojo


0

1

Представлен первый бета выпуск языка программирования Mojo 1.0, который ознаменовал стабилизацию языка и реализацию всех базовых возможностей. Выпуск оценивается как почти готовый к повсеместному использованию. Финальный релиз Mojo 1.0 ожидается в начале осени. Использование данной ветки позволит начать разрабатывать крупные проекты, не опасаясь появления в языке изменений, нарушающих совместимость.

В состав платформы включены компоненты, необходимые для разработки приложений на языке Mojo, включая компилятор, runtime, интерактивную REPL-оболочку для сборки и запуска программ, отладчик, дополнение к редактору кода Visual Studio Code (VS Code) с поддержкой автодополнения ввода, форматирования кода и подсветки синтаксиса, модуль для интеграции с Jupyter для сборки и запуска Mojo notebook. Исходный код стандартной библиотеки Mojo открыты под лицензией Apache 2.0 c исключениями от проекта LLVM, допускающими смешивание с кодом под лицензией GPLv2. Исходный код компилятора планируют открыть после завершения стабилизации внутренней архитектуры.

Язык Mojo развивается под руководством Криса Латнера (Chris Lattner), основателя и главного архитектора проекта LLVM и создателя языка программирования Swift. Синтаксис Mojo основан на языке Python, а система типов близка к C/C++. Проект преподносится как язык общего назначения, расширяющий возможности языка Python средствами системного программирования, подходящий для широкого круга задач и сочетающий простоту применения для исследовательских разработок и быстрого создания прототипов с пригодностью для формирования высокопроизводительных конечных продуктов.

Простота достигается благодаря использованию привычного синтаксиса языка Python, а разработке конечных продуктов способствуют возможность компиляции в машинный код, механизмы безопасной работы с памятью и задействование средств для аппаратного ускорения вычислений. Для достижения высокой производительности поддерживается распараллеливание вычислений с задействованием всех имеющихся в системе аппаратных ресурсов гетерогенных систем, таких как GPU, специализированные ускорители для машинного обучения и векторные процессорные инструкции (SIMD). При интенсивных вычислениях распараллеливание и задействование всех вычислительных ресурсов даёт возможность добиться производительности, превосходящей приложения на C/C++.

Язык поддерживает статическую типизацию и средства для безопасной низкоуровневой работы с памятью, напоминающие возможности языка Rust, такие как отслеживание времени жизни ссылок и проверка заимствования переменных (borrow checker). При этом в языке доступны и возможности для низкоуровневой работы, например, возможно прямое обращение к памяти в режиме unsafe с использованием типа Pointer, вызов отдельных SIMD-инструкций или доступ к аппаратным расширениям, таким как TensorCores и AMX.

Mojo может использоваться как в режиме интерпретации с использованием JIT, так и для компиляции в исполняемые файлы (AOT, ahead-of-time). В компилятор встроены современные технологии автоматической оптимизации, кэширования и распределённой компиляции. Исходный код на языке Mojo преобразуются в низкоуровневый промежуточный код MLIR (Multi-Level Intermediate Representation), развиваемый проектом LLVM. Компилятор позволяет применять для генерации машинного кода различные бэкенды, поддерживающие MLIR.

Среди изменений в Mojo 1.0.0b1:

  • Ключевое слово «fn» объявлено устаревшим - для объявления функций следует использовать ключевое слово «def» (возможности «fn» и «def» объединены, и в «def» реализована семантика «fn» без генерации исключений).
  • Унифицирована реализация замыканий (closure). Не учитывающие контекст замыкания (stateless closure) теперь автоматически преобразуются в функции верхнего уровня и могут использоваться как callback-вызовы в FFI (Foreign Function Interface). Добавлена поддержка захвата по ссылке (ref capture). При объявлении функций добавлен признак «thin» для объявления простого типа указателя на функцию без захвата состояния.
  • Указатели с типом UnsafePointer теперь не могут принимать значение null по умолчанию, а для работы с null-указателями необходимо использовать «Optional[UnsafePointer[…]]», что позволяет исключить накладные расходы при работе с null-указателями и сохранить возможность безопасного применения в FFI.
  • По умолчанию в коде для CPU в коллекциях включена проверка допустимых границ (на GPU проверка отключена для производительности, но может быть включена при сборке с «mojo build -D ASSERT=all»). Прекращена поддержка указания отрицательных значений в индексах (запрещено «x[-1]», но можно указывать «x[len(x)-1]»).
  • Из стандартной библиотек удалён тип NDBuffer, вместо которого следует использовать TileTensor.
  • Расширена поддержка работы с GPU через графический API Metal на системах Apple (например, появилась поддержка print() и матричных инструкций M5). Добавлена поддержка ускорителей AMD MI250X и NVIDIA B300.
  • Идентификаторы примитивов GPU (индексы потоков и блоков) переведены на возвращение типа Int вместо UInt.
  • Контекст CPU (‘DeviceContext(api=«cpu»)’) стал потокозависимым (stream-ordered). Для упорядоченного выполнения задач добавлены функции enqueue_cpu_function() и enqueue_cpu_range().
  • В типах String и StringSlice добавлена поддержка графемных кластеров (Unicode UAX #29), позволяющая корректно вычислять длину и обрезать строки с emoji и комбинированных символов. Добавлены методы graphemes() и count_graphemes(), а также синтаксис слайсов «[grapheme=…]».
  • Реализовано уточнение типов (Type Refinement) на этапе компиляции для автоматического сужения типов внутри выражений «where», «if» и «assert» (позволяет обойтись без явного указания trait_downcast).
  • Предложен унифицированный API рефлексии, в котором предложена новая функция reflectT (---), возвращающая Reflected[T] и заменяющая семейство функций struct_field_* и старые методы get_type_name().

Одновременно сформирован выпуск движка MAX Framework 26.3, предлагающего платформу для разработок в области машинного обучения. MAX Framework дополняет инструментарий Mojo средствами для разработки и отладки приложений, использующих модели машинного обучения в различных форматах (TensorFlow, PyTorch, ONNX и т.п.). В новой версии MAX Framework добавлена возможность генерации видео, расширена поддержка работ с использованием нескольких GPU, значительно повышена производительность интерпретатора (некоторые операции стали выполняться быстрее в 10-20 раз).

Источник

Перемещено hobbit из opensource

★★★

Последнее исправление: unclestephen (всего исправлений: 1)

Финальный релиз Mojo 1.0 ожидается в начале осени

Так может тогда и стоит запостить новость?

zabbal ★★★★☆
()

Синтаксис Mojo основан на языке Python, а система типов близка к C/C++

Решили совместить худшее из двух миров?

Это как взять GUI от Андроида и консоль от винды))

wandrien ★★★☆
()
Ответ на: комментарий от wandrien

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

LightDiver ★★★★★
()

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

hobbit ★★★★★
()
Ответ на: комментарий от anonymous

Вопрос не в том, что там будет, а в том что сам синтаксис сишечки откровенно говно. Он был придуман очень уж давно. А вот типы сишечки - откровенно плюс, наверное лучшее, что было придумано.

LightDiver ★★★★★
()

Я краем глаза смотрел на этот язык года 3-4 назад когда он только стал публичным.

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

Чтобы его ускорить, его можно перевести с питона на mojo. На первом этапе достаточно просто *.py файлы переименовать в *.mojo и, возможно, все взлетит даже без особых правок. Сам синтаксис языка старается быть максимально совместимым с питоновским. И разрешается импортировать и использовать любые питоновские модули. После этого проект начнет работать быстрее из-за того, что mojo компилируемый.

Если скорости все равно не хватает, то можно найти хотспоты в проекте и начать их постепенно переписывать на более низкоуровневый код. Для этого у функции ключевое слово def заменяется на fn. Внутри def функций код должен быть максимально совместим с питоном и поэтому, например, все объекты должны быть словарями, ведь на них в динамике могут навешиваться новые проперти, могут выбрасываться исключения, подсчет ссылок и т.п.

Внутри же fn функций все намного строже, типы объектов должны выводиться на этапе компиляции (не нужно каждый объект делать словарем), исключений, вроде, нет и т.п. И поэтому fn функции работают быстрее, чем def функции.

Т.е. язык позволял без глобального переписывания проекта гибко переписать отдельные его части на более низкий уровень. Вызовы def, fn функций и сторонних питоновских модулей абсолютно прозрачны и разрешались вызываться одно из другого без ограничений.

Ну и плюс были какие-то свои встроенные средства для запуска кода на gpu для нейронок.

По поводу того, что система типов близка к C/C++ очень странно, ведь она была сильно слизана с раста. Наследование через трейты, ошметки заимствований, какие-то ключевые слова, типа fn. Но, возможно, раст слишком токсичен и поэтому написали про более нейтральные плюсы.

Они задепрекейтили fn функции, что, вроде, убивает основную идею языка. Может, концепция поменялась за это время или что-то другое придумали. Релизнится стабильный релиз, можно будет посмотреть, к чему же они пришли.

Darfin
()

Ключевое слово «fn» объявлено устаревшим

вот это я понимаю, разрабы сопли не жуют, ещё первая версия не вышла, а уже что-то устарело

madcore ★★★★★
()
Ответ на: комментарий от madcore

Ну это норм - до первой версии. Вот если после стабильного выпуска так делать, уже не норм)

wandrien ★★★☆
()
Ответ на: комментарий от Darfin

Ага, то есть это был «ускоренный питон» для перевода на него ML и всего такого. В таком описании концепция понятная, благодарю.

wandrien ★★★☆
()

Этот mojo на поверхности - статически типизированный питон, но под капотом - совершенно другой язык, основанный на MLIR. Килер фича - поддержка гетерогенных архитектур через MLIR.

Если бы он появился хотя бы 5 лет назад, мог бы быть хорошей альтернативой расту. Но у mojo ещё бета, а раст уже есть здесь и сейчас, и экосистема растёт не по дням, а по часам. Может так получиться, что mojo так и останется языком одного проекта, но посмотрим.

yvv1
()
Ответ на: комментарий от madcore

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

yvv1
()
Последнее исправление: yvv1 (всего исправлений: 1)
Ответ на: комментарий от LightDiver

сам синтаксис сишечки откровенно говно

Поэтому-то чуть ли не все популярные языки - суть наследники синтаксис сишечки: сравни сколько языков с фигурными скобками и сколько с begin/end

А вот типы сишечки - откровенно плюс, наверное лучшее, что было придумано

Особенно строки люди любят :)

pihter ★★★★★
()
Ответ на: комментарий от pihter

Я сравнил. Бегин энд тоже говно не сильно меньшее. Питон тем и хорош, что избавился от лишних элементов. Добавил конечно некоторых проблем, но его синтаксис мне нравится больше, хоть я с ним почти и не работаю.

LightDiver ★★★★★
()
Ответ на: комментарий от pihter

Поэтому-то чуть ли не все популярные языки - суть наследники синтаксис сишечки: сравни сколько языков с фигурными скобками и сколько с begin/end

Уровень компетенции в computer science понятен…

wandrien ★★★☆
()
Ответ на: комментарий от LightDiver

Добавил конечно некоторых проблем, но его синтаксис мне нравится больше, хоть я с ним почти и не работаю.

Это как раз потому, что не работаешь.

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

Питон того же поля ягода, что и «лаконичные модерновые дизайны сайтов», которые хорошо продаются, но нихрена не соответствуют реальным научным практикам из сферы UI & UX.

И народ такой: точно, как лаконично, как здорово! Берём!

wandrien ★★★☆
()
Ответ на: комментарий от LightDiver

Не всегда доступна сишечка. Иногда есть жестко ограниченные песочницы.

С каким-то неведомым говном вместо проверенных решений. Ну да, ага.

Zhbert ★★★★★
()
Ответ на: комментарий от wandrien

Тьфу ты. Ладно с этим синтаксисом. Изначально просто типы в си ставились как минус ему, как плохое. А ведь это великолепный инструмент для сырой работы с памятью по сути. Без всяких оберток практически.

Вот мне даже в раст типы не так нравятся, потому что их там уже обернули. Оно конечно стало безопаснее, логичнее, но теряется то самое ощущение, работы с сырыми данными. Можно конечно в ансейф уйти, но это уже не то.

Если откинуть эту всю шелуху про безопасность итд, то как по мне си это эталон работы с данными. База, вокруг которой уже остальные что то надстраивают. Со своими вытекающими плюсами и минусами, но плюсов не меньше, а то и больше в итоге.

LightDiver ★★★★★
()
Ответ на: комментарий от Zhbert

А какие проверенные решения ты предлагаешь? Вот у меня есть песочница с проверенным за 20 лет решением. Которое великолепно работает. Но там всего три типа по сути и минимальный два байта. А это уже иногда слишком много.

Там луа5.1. Предложи более проверенное решение.

LightDiver ★★★★★
()
Ответ на: комментарий от Zhbert

Я отступы соблюдать стараюсь в любом языке по умолчанию, иначе сам запутаешься. Так что это не минус, а скорее даже плюс. Или ты про чисто визуальное восприятие, что отступы плохо воспринимаются? Ну это уже от опыта наверное зависит.

LightDiver ★★★★★
()
Ответ на: комментарий от LightDiver

Я не знаю, что автор новости имел в виду под «а система типов близка к C/C++», но система типов C++ - это лютый монстр из шаблонов на шаблонах на шаблонах, обильно смазанный нечитабельным синтаксисом.

Мощная-то она мощная, но радоваться тут особо нечему. Приемлемо.

wandrien ★★★☆
()
Ответ на: комментарий от wandrien

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

Хотя, говорят в Zig что то там намутили побогаче, но я лично ни разу не видел и не пробовал - слухи.

LightDiver ★★★★★
()
Последнее исправление: LightDiver (всего исправлений: 1)
Ответ на: комментарий от wandrien

Вот это все, что я о нем пока слышал. Все его хвалят! Раст все почему то ругают, а Zig все хвалят. А у меня характер такой - если хвалят, скучно лезть.

LightDiver ★★★★★
()
Ответ на: комментарий от LightDiver

Раст ругают? Наоборот, пиарят из каждого утюга, аж до аллергии. В зубах кариес от Раста проходит))

А Zig это качественная, продуманная работа. Да, без хайпа. И не без недостатков. Серебряную пулю не продают.

wandrien ★★★☆
()
Ответ на: комментарий от wandrien

Я не про пиар от компаний, а про обычных пользователей. Я и заинтересовался растом, потом что его тут на ЛОР вечно ругали. Если мы возьмем стандартную тему, где есть что то про раст, сразу вылезет куча хейтеров.

LightDiver ★★★★★
()
$ pixi init hello_mojo -c https://conda.modular.com/max-nightly/ -c conda-forge`
$ cd hello_mojo
$ pixi add mojo
$ du -sh .

895M .

$ du -sh ~/.cache/rattler

906M /home/dataman/.cache/rattler

$ pixi shell
$ cat hello.mojo
def main():
   print("Hello, Mojo!")
$ mojo hello.mojo

Hello, Mojo!

$ mojo build hello.mojo
$ stat hello

File: hello
Size: 18040

$ ldd hello
linux-vdso.so.1 (0x00007f1437d4c000)
libKGENCompilerRTShared.so => /home/dataman/hello_mojo/.pixi/envs/default/lib/libKGENCompilerRTShared.so (0x00007f1437c96000)
libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007f1437a52000)
libm.so.6 => /usr/lib/x86_64-linux-gnu/libm.so.6 (0x00007f143795c000)
libstdc++.so.6 => /home/dataman/hello_mojo/.pixi/envs/default/lib/libstdc++.so.6 (0x00007f1437600000)
libMSupportGlobals.so => /home/dataman/hello_mojo/.pixi/envs/default/lib/libMSupportGlobals.so (0x00007f143794b000)
libAsyncRTRuntimeGlobals.so => /home/dataman/hello_mojo/.pixi/envs/default/lib/libAsyncRTRuntimeGlobals.so (0x00007f1436a00000)
libNVPTX.so => /home/dataman/hello_mojo/.pixi/envs/default/lib/libNVPTX.so (0x00007f1433200000)
libAsyncRTMojoBindings.so => /home/dataman/hello_mojo/.pixi/envs/default/lib/libAsyncRTMojoBindings.so (0x00007f14374f7000)
libgcc_s.so.1 => /home/dataman/hello_mojo/.pixi/envs/default/lib/libgcc_s.so.1 (0x00007f143791c000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1437d4e000)
libdl.so.2 => /usr/lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1437917000)

How to build a standalone application:

Mojo does not currently support static linking. For now, users MUST use magic to run Mojo applications. This comes from a requirement to link with cpython, which doesn’t support musl particularly well, for the python interop features. Modular is aware that this is a strong desire for some users, like you and me, who are building pure mojo applications.

dataman ★★★★★
()
  • Markdown
Пустая строка (два раза Enter) начинает новый абзац. Знак '>' в начале абзаца выделяет абзац курсивом цитирования.
Внимание: прочитайте описание разметки Markdown.
Используйте Ctrl-Enter для размещения комментария