Из анонса проекта на блоге корпорации зла:

These efforts have borne a lot of fruit over the years, but we always run up against the same issue: it's very difficult to make concurrent workloads perform well on CPython.
To solve this problem, we investigated a number of other Python runtimes. Each had trade-offs and none solved the concurrency problem without introducing other issues.

Grumpy избавлен от ключевой проблемы Python - глобальной блокировки интерпретатора (GIL, Global Interpreter Lock), не допускающей параллельного выполнения нескольких нитей кода.

Обычно, когда питонщикам нужно немного параллельности, они кладут рядом ещё один процесс (привет, Tornado).

транслятор из python в ненужно

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

Это более серьёзная проблема, чем такая же для компилируемых языков, т.к. в них чаще распространяются уже готовые бинари и все проблемы по несовместимости выявляет и решает сборщик пакета.
А в скриптовых языках распространяется почти всегда лишь исходный код и с проблемами «на этапе компиляции» может столкнуться уже конечный пользователь/заказчик, что совсем не комильфо.

не люблю питон, но корпорация зла со своим го — ещё хуже. так что нет, спасибо, не надо.

фигня этот фибоначчи

fafhrd@alpha:~$ php -v
PHP 7.1.0-3+deb.sury.org~trusty+1 (cli) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.1.0-dev, Copyright (c) 1998-2016 Zend Technologies
    with Zend OPcache v7.1.0-3+deb.sury.org~trusty+1, Copyright (c) 1999-2016, by Zend Technologies
fafhrd@alpha:~$ 
fafhrd@alpha:~$ 
fafhrd@alpha:~$ time php -r 'print fibonacci(40, FIBONACCI_METHOD_SLOW);'
102334155
real    0m0.524s
user    0m0.520s
sys     0m0.004s
fafhrd@alpha:~$ 

В PyPy есть GIL. Гугл ругается именно на GIL.

php -r 'print fibonacci(40, FIBONACCI_METHOD_SLOW);'

В каком месте тут измеряется скорость работы с объектами? Создание, вызовы, свойства?

Судя по истории коммитов, это проект инженера Youtube или группы какой-то внутри. Я тоже части биллинга переписываю с Python на Go, но мне гугл за это не доплачивает :) хотя одно другому не мешает

В данном случае ни в каком. Внутри чистая рекурсивная функция без объектов. Думаю с объектами будет не сильно хуже.

Но смысл в том, что если сравнивать с go, то надо компилять ^_^

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

в те годы самое крутое было в том, что питон 1.6, если память не изменяет, использовался в Severance: Blade Of Darkness :) копание в потрохах игры было хорошей прикладной задачей для изучения

Они очень сильно зафакапились с питоном 3, да?

Бредишь что ли? Все хорошо с третьим питоном))

Улучшить масштабируемость перейдя на язык с масштабируемостью хуже чем у С++? Гениально однако.

Я бы на ихнем месте транслировал в Genie.

idris - 4 сек

Проблемы от третьей ветки сравнимы с проблемами от стандартов C++XX

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

удачи с миграцией на питон 4. не знаю только, придётся ли мигрировать, или тебя уволят и перепишут всё на го.

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

ты хоть одну программу на новом С++ написал?

или скомпилировал старую свою где использовались ссылки и обращение к функциям/классам/объектам просто дергая/писуя в/из память,да даже простая сортеровка деревом используя ссылки,и как оно хотяб ЗАРАБОТАЛО на новом С++ после компиляции...ммм?

или ты таки переписываешь на каждое минорное обновление языка и компилятора(привет gcc4 и gcc6) фикся баги компилятора языка,когда у тебя в проекте логика уже 10 лет работает

вот и вопрос возникает к таким языкам,также как к python3 как и C++XX - зачем мне тратить время фиксить код в котором нет ни ошибок логики ни ошибок в коде(все работает на старой версии),зачем мне переписывать половину кода только потому что так решили обновляторы

А конкретно?
Даже odoo почти переписали.

«почти переписали» за восемь лет с момента релиза - это конечно очень хорошо и почти считается, но в гугле работает сколько человек, 30 тысяч или уже 50 тысяч? что-то у них не нашлось желающих переписывать и желающих за это платить. такая же ситуация в нормальных компаниях которые не привыкли выбрасывать деньги на ветер. для аутсорса работы наверное прибавилось, да.

питон 3 решает только проблемы языка, но не решает ни одной проблемы которую этот язык должен был бы решать для компаний. print со скобочками - очень хорошо, модули переставили с одного места в другое и попереименовывали - прекрасно, для юникодных строк не надо писать u" - великолепно. но зачем это всё, что из этого было поломано, что это надо было чинить?

сортеровка деревом

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

что-то у них не нашлось желающих переписывать

А когда Гугл что-либо переписывал? Они просто выкидывают и начинают по-новой.

Но автор пишет:

Basically, we needed to support a large existing Python 2.7 codebase.

То есть тройкой его не собрать?

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

жаль, что питон 3 для этого не подходит потому что это тоже самое, что и питон 2, только код другой.

Звучит разумно.
Но две заметные плюшки - дефолтный юникод везде и асинхронный код без тредов. А МС часто тянул легаси код до последнего (не для совместимости, а в плане развития софта). Офис с нуля переписали только в середине 2000-х.

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

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

Со скоростью какой-то просто мегафейл :)

На opennet есть график. Subj на одном потоке сливает, но уже при двух дает газу до отказу, а при большем количестве потоков уходит в полный отрыв.

Кстати, было бы полезно сделать многопоточный фибоначчи.

Гугля имеет привычку с большой помпой объявить про новую мегафичу, а потом тихонько ее придушить, если бабло не пошло.

Гуглу Go, также как и Python до этого, нужен для внутренних нужд скриптования, поэтому бабло тут ни при чем. Раньше они держали Гвидо на зарплате, чтобы он пилил язычок удобный для скриптования из задач, ну и пиарили его заодно. Затем появился Go для тех же целей, но пошустрее, они стали подкармливать его разработчиков (Гвидо уже не в гугле). Теперь решили, чтобы не переписывать тонны старых скриптов на Python, сделать для них ускоритель, пока не отпадет в них надобность. А заодно - решили попиарить и эту поделку.

Ну, а когда у гугла не останется Python'овых скриптов, тогда они и бросят этот велосипед, но бабло тут ни при чем.

фигня этот фибоначчи

Ох, ты ж, блин. Фибоначчи Балансера - это не только измеритель скорости создания объектов и вызова их методов, это еще и детектор школьников, которые не читают «Что это такое» и для чего этот набор тестов был создан.

Кстати, было бы полезно сделать многопоточный фибоначчи.

У меня такая мысль была, даже в сорцах -mt каталог завёл. Но во многих языках многопоточность задача совсем не настолько тривиальная, так что так и не собрался сделать :)

Ещё хотел вариант с наследованием сделать, чтобы оценивать и на него оверхед, тут-то всё относительно просто — но уже просто лень :)

Крон, давай многопоточный фибоначчи! Для твоего любимого php, например.

Я тоже части биллинга переписываю с Python на Go, но мне гугл за это не доплачивает :) хотя одно другому не мешает

Те пацаны работают на гугл - он им и платит. У тебя похожая ситуация, хоть платит и не гугл.

на жабоскрипте

function Fib (number) {
	this._value = number;
}
Fib.prototype = {
	get value () {
		if (this._value <= 2)
			return 1
			
		let f1 = new Fib(this._value - 1);
		let f2 = new Fib(this._value - 2);
		
		return f1.value + f2.value;
	}
}

console.time('Fibonacci number');
console.log(new Fib(40).value);
console.timeEnd('Fibonacci number'); 

Fibonacci number: таймер запущен
102334155 
Fibonacci number: 48763.34мс

прогрев интерпретатора? зачем.

У гугли много внутренних инструментов, которые не пиарятся. Если что-то раскручивают, значит попытаются монетизировать. Пистон они не раскручивали, а скорее сами накосили дивидендов, создавая образ корпорации добра.

угу, очередной анонимный школоло пытается доказать, что он один читать умеет и понимает суть вещей ^_^ ты бы потрудился понять для начала, что за код у меня был приведён, и почему там константа «SLOW»

First, we decided to forgo support for C extension modules.

То есть прощай, numpy? Питон без numpy никому не нужен.

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

Ахахахха, слышь, мужики, тут keinu говорит что питон без numpy никому не нужен! Да этот сраный numpy сам по себе только и нужен для академегов если надо перфоманса в перемножении матриц. Много людей этим занимается? Ну наверное много. Только вот 100% ГОРАЗДО больше человеков используют питоний для простых скриптов + джанги бекэнды вот это все. Им то numpy зочем?

На Kotlin так же как и на Java. Хоть где-то нет оверхеда...

транспилировать

это как?

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

Java на некоторые вещи ругается, мол, deprecated, но работает. Чем больше ковыряю Java, тем больше нравится.

Последующее это то что после предыдущего. Код для java 8 не скомпилится на Java 7. Инструкции разные.
А вот зачем пытаться новой версией исполнять старый код, а не взять для него интерпретатор соответствующей версии, это вопрос на который я не имею ответа. Это к болезным людям.
Другое дело когда вторую ветку отовсюду повыкидывают... Но на переход отведено было минимум 10 лет. И судя по инертности сообщества ещё лет 10 добавят. Так что проблема высосана из пальца.

Другое дело когда вторую ветку отовсюду повыкидывают... Но на переход отведено было минимум 10 лет. И судя по инертности сообщества ещё лет 10 добавят

какой смысл переходить на новую ветку если скрипты в старой продолжают работать? а то ВСЕ разработчики имеют типично русское отношение «пока гром не грянет мужик не перекрестится». хочешь чтоб на новую ветку перешли? убивай старую. тогда у некоторых будет хоть какой-то стимул

какой смысл переходить на новую ветку если скрипты в старой продолжают работать?

Никакого. Так же, как и начинать новый проект на второй ветке.
Всё в точности как с серверными операционками. Работают и работают, никто не бежит обновлять сервер сразу как выходит новая версия. Но вот начинать в 2017-м году проект под Debian 4.0 это уже терминальная стадия кретинизма.

Этот ответ повторяют уже на протяжении многих лет в каждой ветке про питон. Но всё равно находятся те, кто знаком с ситуацией только по заголовкам новостей на лоре и которые влезают со своими «ценными» замечаниями.

А ещё те, чей кругозор ограничен не только конпеляторами и втыканием закорючек между фигурными скобочками, прекрасно знают, что в процессе интеграции приложений какое-то старое решение совсем не гарантированно заведётся на чем-то новом. Скорее даже наоборот. Нельзя просто так взять и скопировать /etc с третьего RedHat на седьмой и ожидать, что всё будет работать как работало. Это не повод сходить с ума и заявлять, что всё пропало и мы все обречены.

Но вот начинать в 2017-м году проект под Debian 4.0 это уже терминальная стадия кретинизма

поставим вопрос так: имеет ли смысл продолжать разрабатывать проект который работает только в 4ке? он ведь работает, зачем обновлятся? а потом жалуются что в 4ке что-то не работает

Это не повод сходить с ума и заявлять, что всё пропало и мы все обречены

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

Так тем, кто с джангой, тем и Go вполне подойдет, и PHP.

эфективные менеджеры Гугла слышите, НИНУЖНО! НИНУЖНО!

Последующее это то что после предыдущего. Код для java 8 не скомпилится на Java 7. Инструкции разные.

А, пардон, неправильно понял. Я подумал о сохранении обратной совместимости (как в Java - даже самый старый код скомпилится, но компилятор вполне разумно может на что-то указывать, мол, deprecated).