LINUX.ORG.RU

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

 mojo


0

3

Представлен первый бета выпуск языка программирования 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 ★★★★★
()

Mojo настолько модное слово что скоро начнут путаться.

Как минимум уже есть одноимённый диалект Бейсика, ui-фреймворк JS, и питоно-прослойка к базам.

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

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

CVE-2025-46817: An integer overflow in the unpack function. While found in the context of Redis, it exploits the way Lua 5.1 handles extreme indices, potentially leading to memory corruption or Remote Code Execution (RCE).

CVE-2025-49844: A Use-After-Free (UAF) vulnerability in the luaY_parser function, which fails to anchor the chunk name string on the stack.

Takoe (C) …

anonymous
()

жаль что за 3 года публичности не особо взлетело

и как промежуточный итог в лучшем случае окажется нишевым по типу numba'ы али ещё какого обинаривания петухона

в 23 году в мае моджо виделось более шелковистой :(

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

имха zig лучшее rust

однако rust адекватней текущей повесточке(конь-канкуре)в достаточной часте первого мира

т.е. для делёжки пирога rust подручней

zig как копулятор меньше попиленоable чем rust - таков путь гниения

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

Увы, не нашлось такового.

вот вообще не удивлён

Там совершенно дикая инфо-атака и занос денег - даже поисковики по запросам mojo или mojo+linux выплёвывают только конкретный топик с недоязыком. Заметьте что прочии «можи» хорошо и давно известны.

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

петухон не предназначен на 7+ уровней отступов

т.е. максимум когда уже глаз должен(обязан начять) дёргатся это 4-5 уровней вложенности от нуля

т.е рефакторить через вынос в методы али ваще в беспризорные def

ваще отступы не самый главный недостаток петухона :(

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

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

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

имха zig лучшее rust

Как вам хватает ума их сравнивать? zig можно сравнивать с C, это низкоуровневый язычок где аллокатор нужно таскать через аргументы, и vtable ручками писать, а о БЧ и memory safety и помыслить нельзя. А rust можно сравнивать с плюсами - это высокоуровневый язык с ооп, async и прочими абстракциями. Между собой ни C с C++, ни Rust с Zig сравнивать смысла нет, но при этом стоит сказать что в современном программировании низкоуровневым язычкам применения не осталось - писать тонны бойлерплейт никто не хочет, да и незачем - никаких преимуществ они не дают, любое байтодрочерство что можно сделать на C/Zig можно сделать и на высокоуровневых языках, только короче, удобнее и безопаснее.

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

Всё через MLIR

Это промежуточное представление. На нижнем слое у Apple air и его надо как-то готовить. Основная проблема в том, что документации по нему нет и надо реверсить.

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

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

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

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