LINUX.ORG.RU

Mojo 1.0

 , , , ,


2

3

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

Одновременно сформирован выпуск движка MAX Framework 26.5, предлагающего платформу для разработок в области машинного обучения. MAX Framework дополняет инструментарий Mojo средствами для разработки и отладки приложений, использующих модели машинного обучения в различных форматах (TensorFlow, PyTorch, ONNX и т. п.). В версии 26.5 добавлена возможность установки только необходимых зависимостей, используя синтаксис max["имя"], а также добавлена поддержка двух новых семейств AI-моделей — GLM-5.2 и Nemotron-H.

>>> Источник: OpenNET

★★★★★

Проверено: hobbit ()
Последнее исправление: dataman (всего исправлений: 2)
Ответ на: комментарий от mister_VA

Так оп том и речь: выделять куски, двигать туда сюда вместо расстановок скобок и автоматического выравнивания.

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

Смысла в Питоне ни на грош без библиотек на других языках, а если все питонистами заделаются, кто библиотеки писать будет?

Смысл в Питоне именно что в читаемости. Библиотеки приложились.

Так что Питон удел не программистов или для недлинных скриптов.

А это уже мимо фактов.

  • Сайты спокойно пишутся на Питоне
  • МЛщики любят Питон
  • CI/CD можно писать на Питоне
  • системные скрипты
  • ну и скриптики, куда ж без них.
bbc69
()

Достали, еще один навайбкоженый язык. ИИ слоп сплошной.

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

компиляция в различные архитектуры без костылей

GCC - тут абсолютный чемпион по поддержке архитектур и ОС. А не эта корпоративная шляпа.

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

GCC - тут абсолютный чемпион по поддержке архитектур и ОС

Речь идёт про gpu и другие ускорители, не только про cpu. И тут чемпион получается MLIR.

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

тех кто мешает разные типы отступов всё равно следует убивать на месте

Слишком гуманно. Пусть пару терабайт нейрослопа переделает.

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

Боюсь, я Вас не понял. Я видел сайты на 1М+ строк. Это по Вашему скриптики? Или всё, что не системное, не программы, а значит пишут их не программисты?

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

Боюсь, я Вас не понял. Я видел сайты на 1М+ строк. Это по Вашему скриптики? Или всё, что не системное, не программы, а значит пишут их не программисты?

Как будто сайт на миллион строк — это что-то хорошее. Нет, в трехзвенной архитектуре на звене с бэкендом должен быть минимум кода. И заложен шардинг для масштабируемости. Миллион строк у фронтенда — тоже ничего хорошего.

sarumeister
()
Ответ на: комментарий от seiken

Смотрел примеры с лямбдами - ни одного примера со сложным statement

Абсолютно надуманная претензия. Лямбды в сишке появились по историческим меркам буквально вчера. И ничего, как-то справлялись. К тому же сложные лямбды не способствуют читабельности кода. Если нужно делать что-то сложное, то лучше вынести ее в отдельный метод. Потому что иначе как вы напишите юнит тесты для нее?

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

главное их не мешать внутри одного файла

Специально никто не мешает. Скопировал код в свой ide и вот уже перемешивание. Главное, чтобы был функционал исправления в ide.

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

Абсолютно надуманная претензия. Лямбды в сишке появились по историческим меркам буквально вчера.

Указатель на функцию - это ещё не лямбда. Лямбда - это фундаментальная форма функции, которой не обязательно имя. Но все остальные фичи ФП при ней - closure, currying. Передача функции как аргумента другой функции - это всего лишь одна из фич функции как «гражданина первого класса» в ЯП. Другое дело, что если пишешь в обычном процедурном стиле, плюс немножЕчко классов, то всё это ФП в полный рост не особо нужно. Задачи на фильтрацию в питоне решаются через list comprehension, а для вспомогательных функций, которыми не хочется засорять внешние пространства имён, в питоне есть вложенные функции.

Но в данном случае я просто сравнивал питон с моджо, лямбды лично для меня не критичны.

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

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

int *a, b;
captain_cat
()

Лучший язык уже придуман - Scala 3, для всего остального есть раст и питон

tzekunosyosha
()

Продолжаю тыкать палкой этот моджо, в позе питониста.

Одной из особенностей питона, за которую его пользователей предлагалось расстреливать, являлось угрёбищное ad-hoc добавление костыля, призванного заменить отсутствие деструкторов - менеджеры контекста и with-блоки.

В модже, типа, исправили ситуацию, и появился полноценный деструктор. Но что-то они перемудрили то ли с синтаксисом владения, то ли ещё с чем-то, но делается это так:

struct A:
    def __init__(out self):
        pass
    def __deinit__(deinit self):
        print("destroyed")

Это перебор и синтаксическая помойка. Если мы в конструкторе, то понятно, что мы будем модифицировать заново создаваемую структуру. Аналогичная логика с деструктором.

seiken ★★★★★
()

String interpolation а ля питон не работает.

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

Так сложились обстоятельства. Нет, как и в любом большом проекте, там тоже есть мёртвый код и всё прочее, но в целом ровно столько и надо было строчек, чтобы всё работало. Считайте это следствием бизнес-требований.

bbc69
()
Последнее исправление: bbc69 (всего исправлений: 1)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.