Стартап Exaloop опубликовал код проекта Codon, развивающего компилятор для языка Python, способный генерировать на выходе чистый машинный код, не привязанный к Python runtime. Компилятор развивается авторами Python-подобного языка Seq и позиционируется как продолжение его развития. Проектом также предлагается собственный runtime для исполняемых файлов и библиотека функций, заменяющая библиотечные вызовы на языке Python. Исходные тексты компилятора, runtime и стандартной библиотеки написаны с использованием языков C++ (с привлечением наработок из LLVM) и Python, и распространяются под лицензией BSL (Business Source License)...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=58395
Давай, Аноним, пошути уже про одну пропущенную букву в названии. Ты ведь такой оригинальный шутник у нас.
И давно ты сам с собой разговариваешь?
Пошутил.
Смешно.
Condon
Condom
Ну вообще-то нужно переместить n и добавить в конец m.
Гусары - надеть!
> перевод кода на лицензию Apache 2.0 через 3 года (1 ноября 2025 года)Вот 1 ноября 2025 года и приходите, а пока ВОН!!!
Ок, уходим :(
Угадаете, какая судьба постигнет этот очередной компилятор питона или подсказать?А всё потому что у языков одной реализации без стандарта, с BDFL и принципом развития "а давайте ещё этого хапнем" будущего нет.
Тем не менее, у питона десяток реализаций. Больше, чем у жавы.
>Тем не менее, у питона десяток реализаций.Пара-тройка подлагивающих, которые регулярно подзабываются и мейнстримом не используемы.
как будто это что-то хорошее, ага
Тем не менее эта пакость успешно пожрала мозги огромного количества кодеров.
Это были не кодеры :) Нормальный кодер за километр к такому г****ну не приблизится.
Ага, зато будущее есть у Go, у которого стандарт языка так и застрял в 70х годах.Недавно добавили темплейтинг, прогресс!
Дженерики.
ахахаха да, го, с, с++ все это дерьмо старое проперженное, нам бы свифтов да растов какихнить вот тогда и смузи польется.
> ахахаха да, го, с, с++ все это дерьмо старое проперженное, нам бы
> свифтов да растов какихнить вот тогда и смузи польется.Да ты что, по сравнению с C++ как ЯП Go даже рядом не стоит. Единственное преимущство Go - это сокеты и корутины по дефолту.
ладно тебе, всего лишь ещё 10 лет подождать и в твой любимый язык комитет стандартизации добавит и сокеты, и корутины, и модули, и пакетный менеджер, и небо, и даже аллаха может быть.потом ещё 10 лет подождать, и может даже в компилятор добавят все эти вещи.
тогда уж го точно на помойку отправится, ух заживём!
Кроме пакетного менеджера, которая не часть компилятора, лол .это уже есть. используйте нормальный компилятор (msvc) а не высеры вроде clang, где все перечисленное уже есть.
И более того, это уже применяем в продакшене.
Эх...С++ нормальные бы стандартные библиотеки, а не то что есть. Стандартную библиотеку развивают разработчики сами для себя, а не для рядовых программистов. И она все больше напоминает бред больного под высокой температурой. Типа, эллиптические функции в стандартной библиотеки есть, а сетевых нет. Ну да, эти интегральные функции чаще видно программистам в работе встречаются чем работа с сетью))).
> Эх...С++ нормальные бы стандартные библиотеки, а не то что есть. Стандартную библиотеку
> развивают разработчики сами для себя, а не для рядовых программистов. И
> она все больше напоминает бред больного под высокой температурой. Типа, эллиптические
> функции в стандартной библиотеки есть, а сетевых нет. Ну да, эти
> интегральные функции чаще видно программистам в работе встречаются чем работа с
> сетью))).Qt и Boost - это стандартные библиотеки для С++, а не тот позор, который в STL.
> у языков одной реализации без стандарта [...] будущего нет.Ты это замечательное обобщение сделал на одном примере? Или на трёх?
Или может ты не сторонник эмпирического знания, и считаешь, что любое знание о реальности должно выводиться из Вселенской Мудрости? Типа Библии, Корана, Торы или что там ещё претендует на звание Вселенской Мудрости? Если так, то ты можешь сформулировать вкратце ту Вселенскую Мудрость, из которой ты делаешь такие далекоидущие выводы?
Всё пытаются и пытаются ускорить питон. А он всё никак не ускоряется и не ускоряется.
Он ускоряется, но, при этом, и удлиняется.
Наверное надеятся на то что в конце концов лоренцево сокращение поможет.
Когда до этого дойдёт, то приращение скорости будет ничтожным.
ну согласно теории относительности при ускорении все укорачивается так то
Потому что удава надо душить, а не оттягивать! :)
мутная, какая-то, лицуха. Зачем так усложнять?
>мутная, какая-то, лицуха. Зачем так усложнять?Разрабы хотят икорки на хлеб намазать.
На ускорителе бесплатного пестона?! По-моему, ребята слишком амбициозны (читай "дол6оё...").
Да вроде норм. Подвоха явного не вижу, скрытого не нащупываю.
У тебя просто там уже всё подвохами разработано, вот и не чувствуешь.
Чтобы про неё сказал RMS?
> Чтобы про неё сказал RMS?Ребята хотят и мороженку съесть, и не обляпаться. Не, имхо, с целью заработать на ноу-хау -- интервал в три года вполне достаточный. А потом (после снятия сливок) -- отдать всем. Разумный компромисс.
Чтобы рабы улучшили. А потом купили свой труд.
Суть BSL.. в течение какого-то времени может применяться бесплатно (ТРИАЛ) только при соблюдении дополнительных условий(ДЕМОВЕРСИЯ), для обхода которых требуется (КРЯК)
По скорости еще не C, по удобству и безопасности уже не Python.Ну как не жалко этим людям натягивать питончика на ежа, а потом нестыдно добавлять в смузи всё что натекло-накапало при этом.
>а потом нестыдно добавлять в смузи всё что натекло-накапало при этом.Блеединг эдж - кровавый конец.
> поддерживается большая часть синтаксиса PythonНу то-есть переписывать все же придется. По-моему они такие не первые уже?
Поддерживается print('Hello world'). Заявленная скорость почти такая же, как и у int main() { prinf('Hello world'); }
Решено! Сажусь писать хелловорлд.
Осталось еще PCI-E 5.0 16x ASIC для аппаратного выполнения JS запилить
И он будет стопориться на 64 битах.
JS RTX будет с 768-битной шиной специально для вещественных типов Number и чтобы вместить значение Infinity.
До чего лицемерная лицензия:вы тут потестите, поулучшайте, а мы когда нам надо ограничим. Завоняло макакойдб и прочим подобным.
>Codon построен с использованием модульной архитектуры, позволяющей наращивать функциональность через плагины, при помощи которых можно добавлять новые библиотеки, реализовывать оптимизации в компиляторе и даже обеспечивать поддержку дополнительного синтаксиса.На что только люди не пойдут, лишь бы не улучшать компилятор Python из SBCL и CMUCL.
я как-то компилил Hello World Python/GTK4 через nuitka. В итоге получил каталог с бинарником и сотней библиотек где-то под 60 мб. Количество занимаемой ОЗУ во время отображения пустого MainWindow идентичное тому что просто тупо запускать на python, скорость запуска идентичная. Вопрос. Нафига козе боян?
а мог бы дёрнуть ecl
Зато прикинь, гошник с своими 6-меговыми хелловорлдами таким дилетантом смотриться по сравнению с твоим энтерпрайзным хелловорлдом :)
> Зато прикинь, гошник с своими 6-меговыми хелловорлдами таким дилетантом смотриться по сравнению
> с твоим энтерпрайзным хелловорлдом :)Какая восхитительная смесь глупости и ламеризма, преподнесенные с умным и уверенным видом. 294, ты вернулся?
Биндинги к Go для GTK они очень такие как сказать очень в разработке сильно повязшие. Там для железобетонного "готово" для применения еще долго.https://github.com/gotk3/gotk3
https://github.com/mattn/go-gtk
https://github.com/diamondburned/gotk4
Давайте обратимся к фактам:
$ go version
go version go1.18.3 linux/amd64$ cat hello_world.go
package main
import "fmt"func main() {
fmt.Println("Hello World");
}$ go build hello_world.go
$ du -s -h hello_world
1,7M hello_world$ strip hello_world
$ du -s -h hello_world
1,2M hello_world$ ldd hello_world
не является динамическим исполняемым файломСтатический файл без каких-либо зависимостей от библиотек весом 1.2 Мб после удаления отладочной информации. Для сравнения, программа на Си:
$ cat hello_world.c
#include <stdio.h>int main( void )
{
puts("Hello world");
return 0;
}$ gcc -static hello_world.c -o hello_world_c
$ ldd hello_world_c
не является динамическим исполняемым файлом
$ du -s -h hello_world_c
892K hello_world_c
$ strip hello_world_c
$ du -s -h hello_world_c
824K hello_world_c$ cat hello_world.cpp
#include <iostream>int main( void )
{
std::cout << "Hello World" << std::endl;
return 0;
}$ g++ -static hello_world.cpp -o hello_world_cpp
$ ldd hello_world_cpp
не является динамическим исполняемым файлом$ du -s -h hello_world_cpp
2,1M hello_world_cpp$ strip hello_world_cpp
$ du -s -h hello_world_cpp
1,7M hello_world_cppТ.е. разница между статической программой на чистом Си и Го составляет порядка 400 килобайт, а статически скомпилированная программа на Си++ оказывается на 500 килобайт больше, чем программа на Го.
> Давайте обратимся к фактам:Блин, говорю же - кто-то из гошников стопудово себя дилетантом ощутит после такого энтерпрайза.
Qt уже легковестнее GTK.
Qt5/6 и GTK3 примерно на идентичном уровне. GTK4 монстр, пожирающий аппаратные ресурсы на каждый чих пых. Зато libadwaita и CSS кнопочки рамочки иконочки. Меня как приверженца создания легковесных GUI утилит для линукса от gtk4 корёжит.
В дальнейшем из кутей ещё больше выкинут и сделают исключительно платным - так базовая версия ещё легковесней станет )
Ну-да, ну-да, давайте опять оценивать на хелловорлдах полезность программерских тулзов.
Неплохо, но лучше по возможности сразу писать на Паскале.
Сейчас как раз снег выпал, можно красиво пописать на Паскале прямо в снег и любоваться узорами.
Со следующего года удобнее лучше кодить сразу на Modula-2 (Спойлер: будет изкоробки).
fpc в репозиториях уже давно есть.
Имеется GCC >=13, имеется и Modula-2.
То есть Раст больше не нужен? Я правильно понимаю?
>Раст больше не нужен?Почему больше? Разве он вообще кому нужен был, кроме эффективных манагеров из мозиллы, которые не осилили, плюс пары сотен фанбоев с смузи?!
Таки Торвальдс ещё в июне заанонсил перекат ядра линуха на раст
Но Торвальдс же не заанонсил, сколько ему лично за это корпы задонатили.
Самое интересное, сколько ему пришлось во время этой эскапады принять в себя белковой массы.
Пока статическую типизацию нормально не притянут в язык - ничего хорошего не выйдет всё равно.IMHO, пока лучший компилятор для питониста - GoLang. Как минимум, повторяет массу странностей и перепозать будет не так больно, как с C или Паскаля.
> IMHO, пока лучший компилятор для питониста - GoLang.Оба гавно, потому что ни в том ни в другом нету type safety (в питоне есть, но на половину), а в Go вообще нужно писать "if err != nil" в каждой строчке.
Да это потому что на практике питона на игогоху заменяют в вебе. Не то чтобы он какой-то офигенный, но микросервисы лаконичные, проблему с тормозами решили предкомпиляцией, а чего еще хвостатым надо?И наполовину - это как? Немножечко беременна? Типичный питон вообще нихрена не проверяет и просто валится с трехстраничным трейсом где-то в рантайме, и потом удачи это воспроизвести вообще.
Осталось только узнать, где вы в вебе вообще нашли питона с игогохой...
Они там присутствуют, конечно, но на уровне статистической погрешности.
> Осталось только узнать, где вы в вебе вообще нашли питона с игогохой...Ну так, на мелочевки типа гугля, дропбокса, и прочих незначительных ерундовин. Впрочем дропбокс на третьей или какой там итерации вроде хруст полюбил, но на второй они таки вроде с питона на го как раз переписывали.
> Они там присутствуют, конечно, но на уровне статистической погрешности.Ну это смотря что и с чем сравнивать. Если какие-нибудь заглушки на доменах паркинга, там наверное статика победит с жутким отрывом, конечно.
> в Go вообще нужно писать "if err != nil"можешь не писать, но плохие ребята просто заворачивают в трай кетч и играют в мем всё хорошо, всё хорошо...
В golang нет try/catch
> Пока статическую типизацию нормально не притянут в язык - ничего хорошего не выйдет всё равно.В Cython есть.
Это смотря в какой областиЛучший компилятор для питониста, связанного с "наукой" и модным сейчас AI - Julia. Этот язык изначально позиционировался как для "научных расчетов", но на самом деле сейчас его уже начинают позиционировать и как "для Бизнеса" тоже. Пока не хватает библиотек, но дело наживное.
Что-то куда не глянь, всюду "Говорим AI - подразумеваем Python".
Пока да. Но это - инерция. Потому что Python - это не AI. Python - это над AI. AI - это С/C++/Fortran.Если перейти к наглядной терминологии, то С/C++/Fortran - это движок автомобиля. А Python - это кузов, колеса, руль. Без движка кузов сам по себе никуда не поедет, разве что с горочки и очень медленно.
Джулька же в отличие от питона не нуждается в в "движке" из библиотек С/C++/Fortran. На Джульке можно писать этот "движок", который будет таким же мощным как и на С/C++/Fortran, и можно писать "кузов", который будет таким же удобных как и написанный на Python. При этом из коробки различные виды распараллеливание вычислений.
Джулька заруливает Питон на 200% по быстродействию программ при схожием времени написания одних и тех же программ. Имеет более лучший синтаксис. Джулькке пока не хватает "инфраструктуры" - заправок, СТО, диллеров и т.д. (библиотек, интеграций, мест от работодателей и т.д.)
А в бизнес сфере, я бы сравнил Джульку с языком Go и Java. Возможна она будет даже лучше Go и Java с точки зрения быстроты и простоты разработки бизнес-приложений при сравнимых показателях производительности.
Название крайне неудачное. Как будто не хватает буквы m в конце, а n не в том месте.
Казалось бы, уже и денег свободных нет. А нет же, находятся какие-то инвесторы, готовые вкладываться в стартапы на питоне..... Куда катится мир?.....
Codon как оказывается и частичную JIT компиляцию поддерживает. Проект появился из биоинформатики.
Биоинформатики сейчас активно переходят на Джулию. Зачем им проект траскомпиляции питона на C?
Тем более, что в научных расчетах в общем-то и не питон работает, а библиотеки на С и Fortran. А питон - обвязка сверху них. Юлька - язык прикольный, но пока имеющий достаточно много проблем и мало библиотек, отсутствие нормальной компиляции в отдельный исполняемый файл, жор памяти как не в себя и другие детские болезни роста.Современный Fortran - ООП язык, со строгой типизацией, динамическим выделением памяти, распараллеливанием из коробки, указателями, кучей библиотек и т.д. тоже очень и очень не плох.
Круче MKL ничего не придумали, во всяком случае, из доступного обывателю. На язык в принципе пофиг, главное это доступность либ с обёртками и тут питон топ.
Ну в общем-то да. Хотя Fortran IV и Fortran 77 были просто тихий ужас. Но даже на них умные люди смогли сделать много хорошего, не только MKL, а много чего в том числе и расчеты симуляций ядерных взрывов. Но по сравнению с Джулькой, Питоном и R, Fortran из коробки не хватает средств визуализации - это толстый минус.
> Юлька - язык прикольный, но пока имеющий достаточно много проблем и мало библиотек, отсутствие нормальной компиляции в отдельный исполняемый файл, жор памяти как не в себя и другие детские болезни роста.Не надо навешивать вечные ярлыки. На дворе уже не 2016-й, а почти 2023.
Если оборачиваете каждый итератор в collect, то да, жор памяти будет. Ну так голову надо иметь, чтобы не плодить ненужные объекты. От этого никакой язык не спасёт.
Про библиотеки, особенно в контексте https://github.com/JuliaInterop, это как раз разговоры десятилетней давности.
Ну а исполняемый бинарник, во-первых питонистов-биоинформатиков это вообще не волнует. Во-вторых, с каждой новой Джулией ситуация всё лучше и лучше. В 1.9 переработана компиляция. И даже добавлена полноценная условная компиляция зависимостей, чтобы обходиться без @require.
>На дворе уже не 2016-й, а почти 2023.Верните мне мой 2021.
Julia в 21-м уже тоже была весьма неплохим языком.
Просто взять С++ не пробовали?
>>ПростоЭто сложно
Чем это лучше cython?
Чистый машинный код не привязанный к исполнительной среде python? а сборщики мусора, а динамический тип переменной и подобное что? куда? остается! вот тебе и среда понадобилась...
Привязанный к их исполняемой среде с их лицензией.
Ну то есть любая скомпилированная им программа - производная работа.
Ну жаву же graalvm как-то компилирует в нативный бинарь без гц. Динамические переменные принимают вполне статическое чисто типов, которые можно обработать. Кроме того, тут говорят у них свой гц. Ограничения конечно могут быть, как и в случае с жавой, но на довольно специфические хотелки.
GIL работает?
Ещё один компилятор. Ещё один забытый проект, который никому будет не нужен.
Отличный проект. Жаль юникод не предусмотрен. Зато можно вернуться к кодированию строк в ASCII.
Вангую, если прогеры для текстильной промышленности выкатят свой компилятор, то он будет называться Cotton.
и целюлозобумажники с картоном
Круто, теперь на пайтоне можно писать и компилировать высокопроизводительные программы, которые по скорости не (сильно) уступают с++. Когда указатели, управление памятью и строгую типизацию завезут?