а какие языки кроме C/C++ вы можете посоветовать для решения таких же задач для которых используется C/C++?
то есть доступ к системе, высокоскоростная обработка данных, математика

Здравствуйте, tttraveler, Вы писали:

T>а какие языки кроме C/C++ вы можете посоветовать для решения таких же задач для которых используется C/C++?
T>то есть доступ к системе, высокоскоростная обработка данных, математика

Pascal, Ada, D, Rust, ...

Здравствуйте, tttraveler, Вы писали:

T>а какие языки кроме C/C++ вы можете посоветовать для решения таких же задач для которых используется C/C++?
T>то есть доступ к системе, высокоскоростная обработка данных, математика

если не писать свои велосипеды — то любой язык, например питон с numpy и т.п.

Здравствуйте, tttraveler, Вы писали:

T>а какие языки кроме C/C++ вы можете посоветовать для решения таких же задач для которых используется C/C++?
T>то есть доступ к системе, высокоскоростная обработка данных, математика
что такое высокоскоростная обработка данных? на питоне полно библиотек, написанных на си. если писать на питоне только "клей", то по скорости получится как си, только более наглядно. доступ к системе есть у того же питона. есть даже кросс-платформенный отладчик для нативных файлов оси, работающий как под виндой, так и под линухом с маками. если, например, стоит задача потрейсить программу, а затем обработать лог, свернув циклы и осуществив декомпозицию с разбием на функции, то мы получаем системно-независимую утилиту. крысота. не нужно изобретать свой трейсер. не нужно учитывать разницу 32 и 64 бит. и так далее.

Здравствуйте, Abyx, Вы писали:

T>высокоскоростная обработка данных
и
A>питон
? =)

ты, наверное, и для многопоточного программирования станешь рекомендовать питон?

Здравствуйте, мыщъх, Вы писали:

М>если писать на питоне только "клей", то по скорости получится как си
нет.

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, мыщъх, Вы писали:

М>>если писать на питоне только "клей", то по скорости получится как си
X>нет.
давайте потестим. например, вот. https://code.google.com/p/esmre/
давайте так же возьмем достаточно большой словарь: http://svn.pietdepsi.com/repos/projects/zyzzyva/trunk/data/words/North-American/OWL.txt
и найдем все слова в библии, которых нет в этом словаре: http://www.ccel.org/ccel/bible/kjv.txt

или давайте забьем на клей и будем писать на питоне. возьмем Lex/yacc для питона (http://www.dabeaz.com/ply/) и в качестве разминки напишем транслятор для бейсика. сравним скорость трансляции с си.

Здравствуйте, мыщъх, Вы писали:

думаю, что тут любые тесты будут лишними, ибо вы наверняка понимаете, что даже "клей" — рантайм оверхед.

тестить нужно, если интересна оценка этого оверхеда.

Здравствуйте, niXman, Вы писали:

T>>высокоскоростная обработка данных
X>и
A>>питон
X>? =)

X>ты, наверное, и для многопоточного программирования станешь рекомендовать питон?

"многопоточность" — это способ решения задач.
если например надо обрабатывать картинки, и есть С или С++ либа которая делает это в много потоков — почему бы не вызвать ее из питона?

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, мыщъх, Вы писали:

X>думаю, что тут любые тесты будут лишними, ибо вы наверняка понимаете, что даже "клей" — рантайм оверхед.

X>тестить нужно, если интересна оценка этого оверхеда.

конечно, рантайм оверхед 10мс работы питона на 10 минут работы либы это очень существенно.

Здравствуйте, Abyx, Вы писали:

A>если например надо обрабатывать картинки, и есть С или С++ либа которая делает это в много потоков — почему бы не вызвать ее из питона?
если например надо обрабатывать картинки, и есть С или С++ либа которая делает это в много потоков — то просто юзаем ее.

да и холиварная это тема...

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

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, мыщъх, Вы писали:

X>думаю, что тут любые тесты будут лишними, ибо вы наверняка понимаете, что даже "клей" — рантайм оверхед.
нет. не понимаю. откуда такой страх перед оверхидом? давайте тогда брать оверхид смарт-поинтеров. это же ведь жуткий оверхид по сути. давайте брать оверхид динамической памяти, что вообще ужос. аргументы функции -- оверхид. глобальные переменные -- наше все. они (как вы понимаете) иницилизируются даром при загрузке файла. а перменные только на чтение еще и не сваливаются в своп. вот только тесты что-то не показывают разницу этого оверхида (в большинстве случаев).

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

Здравствуйте, niXman, Вы писали:

A>>если например надо обрабатывать картинки, и есть С или С++ либа которая делает это в много потоков — почему бы не вызвать ее из питона?
X>если например надо обрабатывать картинки, и есть С или С++ либа которая делает это в много потоков — то просто юзаем ее.

просто и на С, да?
вот простой код на питоне

import my_image_processing_lib
src = open('src.img', 'rb').read()
result = my_image_processing_lib.process()
open('out.img', 'wb').write(result)

я могу набрать и выполнить его в REPL

а на плюсах ты сначала напечатаешь 100 строк, еще наверное cmake или bat/sh файл напишешь, потом пять раз перекомпилируешь чтобы поправить все ошибки — это конечно же проще чем питон с его REPLом

Здравствуйте, мыщъх, Вы писали:

М>оверхид смарт-поинтеров.
я могу не использовать смарт-поинтеры
но, по аналогии, используя питон — я не могу не использовать питон

М>это же ведь жуткий оверхид по сути
нет.

Здравствуйте, мыщъх, Вы писали:
X>>думаю, что тут любые тесты будут лишними, ибо вы наверняка понимаете, что даже "клей" — рантайм оверхед.
М>нет. не понимаю. откуда такой страх перед оверхидом? давайте тогда брать оверхид смарт-поинтеров. это же ведь жуткий оверхид по сути. давайте брать оверхид динамической памяти, что вообще ужос. аргументы функции -- оверхид. глобальные переменные -- наше все. они (как вы понимаете) иницилизируются даром при загрузке файла. а перменные только на чтение еще и не сваливаются в своп. вот только тесты что-то не показывают разницу этого оверхида (в большинстве случаев).

Ви будете смеяться, но таки да. Динамическая память — это адский оверхед, особенно, когда речь идёт о десятках-сотнях миллионов маленьких объектов, занимающих гигабайты.
Я тут уже писал про блеск и нищету unordered_map.

Здравствуйте, tttraveler, Вы писали:

T>а какие языки кроме C/C++ вы можете посоветовать для решения таких же задач для которых используется C/C++?
T>то есть доступ к системе, высокоскоростная обработка данных, математика


Да любой где есть оптимальный компилятор, но нет виртуальной машины.
Если связаны с матаном то я бы предложил посмотреть на fortran, forth, Haskell, Prolog.

Здравствуйте, niXman, Вы писали:

X>да и холиварная это тема...

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

рассмотрим это на примере формата pdf. основные вычислительные затраты это расжать все стримы и отредерить контент. но для начала файл нужно распарсить. и снова, Lex/Yacc для питона могут (при необходимости) генерить выходной файл на си, так что "клей" в ран-тайм не попадает _совсем_. но программа написана на питоне.

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

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

так что ваше утверждение о том, что питон всегда дает оверхид в рантайме неверно по трем причинам:
1) метапрограммирование: результатом работы программы на питоне является сгенерированная программа на си с машинной высокоуровневой оптимизацией (например, повторное использование переменных для уменьшения кол-ва выделяемой памяти);
2) для питона есть _компиляторы_ в нативный код и тут вопрос лишь в их эффективности, но разрыв между си и "клеем" питона сокращается до погрешности измерений;
3) JIT компилятор питона потенциально способен обогнать си, т.к. JIT распологает информацией недоступной компилятору си;

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

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, мыщъх, Вы писали:


К> Ви будете смеяться, но таки да. Динамическая память — это адский оверхед, особенно,
K> когда речь идёт о десятках-сотнях миллионов маленьких объектов, занимающих гигабайты.
разумеется. даже если блоки храняется не в списке, а в виде дерева, то расходы все равно чудовищны. я тут разбирался с разными реализациями Aho-Corasick и обнаружил, что народ активно пишет свои аллокаторы. не от хорошей жизни.

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

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

Здравствуйте, tttraveler, Вы писали:

T>а какие языки кроме C/C++ вы можете посоветовать для решения таких же задач для которых используется C/C++?
T>то есть доступ к системе, высокоскоростная обработка данных, математика

спасибо всем за ответы
теперь очередной набор вопросов
1. каковы перспективы и недостатки D для коммерческого использования на ближайшие лет 10?
2. насколько комфортно будет использовать связку Python + D для разработки десктопных мультиплатформенных оконных приложений?

Здравствуйте, мыщъх, Вы писали:

М>чуть позже я допилил и стековую память. все дочерние функции хранили локальные переменные на стеке материнской функции
каким образом вычислялся объем необходимой стековой памяти? особенно с учетом того, что чтоб его подсчитать, нужно было предварительно пройтись по всем остальным функциям?

Здравствуйте, Abyx, Вы писали:

A>

A>import my_image_processing_lib
A>src = open('src.img', 'rb').read()
A>result = my_image_processing_lib.process()
A>open('out.img', 'wb').write(result)
A>

а чем этот способ плох?:

#include <my_image_processing_lib.hpp>

std::ifstream ifile('src.img');
auto result = my_image_processing_lib::process(ifile);
std::ofstream ofile('out.img');
ofile << result;

Здравствуйте, niXman, Вы писали:

X>а чем этот способ плох?:

Тем что тебе нужно написать как минимум CMakeFile, качать библиотеки и собрать my_image_processing_lib, разложить их по соответствующим путям. Ну и еще тем, что довольно хорошо совместимых между собой библиотек в Python до чертиков, а в C++ ты еще не маленький промежуток времени будешь детские болезни лечить, со флагами сборки играться.

Здравствуйте, tttraveler, Вы писали:


T>1. каковы перспективы и недостатки D для коммерческого использования на ближайшие лет 10?

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

T>2. насколько комфортно будет использовать связку Python + D для разработки десктопных мультиплатформенных оконных приложений?

Ужас, ты серьезно?

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, Abyx, Вы писали:

A>>

A>>import my_image_processing_lib
A>>src = open('src.img', 'rb').read()
A>>result = my_image_processing_lib.process()
A>>open('out.img', 'wb').write(result)
A>>

X>а чем этот способ плох?:
X>

X>#include <my_image_processing_lib.hpp>

X>std::ifstream ifile('src.img');
X>auto result = my_image_processing_lib::process(ifile);
X>std::ofstream ofile('out.img');
X>ofile << result;
X>

1) тем что тебе надо его перекомпилировать из за "" vs ''
2) в питоне для данных есть один тип — байты, а в плюсах тебе надо будет поконвертировать твой istream в какуюнить пару (void*, size_t) — одним словом больше бойлерплейта, больше возни

Здравствуйте, Abyx, Вы писали:

A>

A>import my_image_processing_lib
A>src = open('src.img', 'rb').read()
A>result = my_image_processing_lib.process()
A>open('out.img', 'wb').write(result)
A>

A>я могу набрать и выполнить его в REPL
За такой код надо по рукам бить тапком. Так как в PyPy или на других Питонах он будет работать только иногда.

Правильнее будет:

import my_image_processing_lib
with open('src.img', 'rb') as fl:
    src = fl.read()
result = my_image_processing_lib.process()
with open('out.img', 'wb') as fl:
    fl.write(result)

Здравствуйте, Cyberax, Вы писали:

A>>

A>>import my_image_processing_lib
A>>src = open('src.img', 'rb').read()
A>>result = my_image_processing_lib.process()
A>>open('out.img', 'wb').write(result)
A>>

A>>я могу набрать и выполнить его в REPL
C>За такой код надо по рукам бить тапком. Так как в PyPy или на других Питонах он будет работать только иногда.

всмысле если подсчета ссылок нет — файл не сразу закроется? да и пофиг, по завершении скрипта всё закроется

Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, tttraveler, Вы писали:


T>>1. каковы перспективы и недостатки D для коммерческого использования на ближайшие лет 10?
KP>Это труп с точки зрения коммерческой разработки, разве что палочкой потыкать можно прикола ради.

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

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

я по нему пока только статью в вики прочел
и если судить по концепции, то концепция языка мне нравится

что вы имеете в виду под коммерческой разработкой?
если поиск вакансий в этой сфере, то меня это мало интересует
поскольку все будет использоваться только для собственной коммерции

так что единственное, что меня может волновать, это возможно подключения к платформе Python+D каких-то сторонних готовых вещей

T>>2. насколько комфортно будет использовать связку Python + D для разработки десктопных мультиплатформенных оконных приложений?

KP>Ужас, ты серьезно?

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

таким образом я пришел к указанному выше вопросу

Здравствуйте, kaa.python, Вы писали:

KP>Тем что тебе нужно написать как минимум CMakeFile
не факт.

KP>качать библиотеки и собрать my_image_processing_lib
my_image_processing_lib — header-only библиотека. а libjpeg/libpng/libz/etc — у меня в системе уже есть.

KP>разложить их по соответствующим путям.
$ make install

KP>Ну и еще тем, что довольно хорошо совместимых между собой библиотек в Python до чертиков, а в C++ ты еще не маленький промежуток времени будешь детские болезни лечить, со флагами сборки играться.
ну, если учесть, что контекст у нас такой, что my_image_processing_lib — всего лишь клей для С/С++ либы, то для питона нам придется так же, собирать эту либу, писать этот самый клей, лечить болезни, етц...


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

Здравствуйте, Abyx, Вы писали:

A>всмысле если подсчета ссылок нет — файл не сразу закроется?
да, даже я это знаю =)

Здравствуйте, kaa.python, Вы писали:

T>>2. насколько комфортно будет использовать связку Python + D для разработки десктопных мультиплатформенных оконных приложений?

KP>Ужас, ты серьезно?

вот еще насчет окошек
смотрю тут помаленьку сайт D и вот список GUI-библиотек, которые можно из него использовать
http://wiki.dlang.org/GUI_Libraries

вообще же, при оценке возможности использования D для оконных десктопных приложений сравнение идет явно не с дельфи и дот нет, а с аналогичной разработкой оконных приложений на C++ с использованием того же набора GUI-библиотек, что перечислены выше

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

А чем C++ не угодил?

Здравствуйте, tttraveler, Вы писали:
T>очевиден выбор питона для бизнес логики
T>и вдобавок нужно что-то для системной части
T>с/с++ по ряду личных соображений использовать не хочу
T>но нужно что-то близкое

Нет ничего близкого. Если нужно что бы было все легко и кроссплатформенно, да еще и десктоп, то это java, тут сам бог велел,
при условии что c|c++ мы не рассматриваем, потому что если бы рассматривали то GTK+ и QT это несомненные лидеры в этой области.
Для примера можно посмотреть на rubymine от джетбрейнс. Сделано на java и весьма сносно.

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

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

Здравствуйте, tttraveler, Вы писали:

может быть все же пояснишь реальные причины поиска альтернативы? возможно, не все так плохо?

Здравствуйте, -n1l-, Вы писали:

N>Здравствуйте, tttraveler, Вы писали:
T>>очевиден выбор питона для бизнес логики
T>>и вдобавок нужно что-то для системной части
T>>с/с++ по ряду личных соображений использовать не хочу
T>>но нужно что-то близкое

N>Нет ничего близкого. Если нужно что бы было все легко и кроссплатформенно, да еще и десктоп, то это java, тут сам бог велел,
N>при условии что c|c++ мы не рассматриваем, потому что если бы рассматривали то GTK+ и QT это несомненные лидеры в этой области.

близкое в том, что D позиционирует себя для написания нативного кода, который должен летать
java никогда так себя не позиционировала в принципе, и имидж у нее совсем не тот (хотя во многом проблема как обычно в кривых руках)

и GTK+ и QT можно использовать и из D, как я писал выше давая ссылку на сайт языка

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, tttraveler, Вы писали:

X>может быть все же пояснишь реальные причины поиска альтернативы? возможно, не все так плохо?

там проблемы не технические
с одной стороны личные и с др стороны коммерческие
так что обсуждать это здесь смысла нет
я знаю точно одно, с/с++ мне не нужен

однако нужна (на перспективу) возможность писать летающий нативный код на серверах и летающие нативные десктопные приложения

ни питон ни джава под эту перспективу не очень подходят
хотя как замена для пхп, питон мне подходит

Здравствуйте, tttraveler, Вы писали:
T>близкое в том, что D позиционирует себя для написания нативного кода, который должен летать
T>java никогда так себя не позиционировала в принципе, и имидж у нее совсем не тот (хотя во многом проблема как обычно в кривых руках)

T>и GTK+ и QT можно использовать и из D, как я писал выше давая ссылку на сайт языка

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

а вот что мненравится в D
цитаты из вики статьи
надеюсь это правда

D's design goals attempt to combine the performance of compiled languages with the safety and expressive power of modern dynamic languages. Idiomatic D code is commonly as fast as equivalent C++ code, while being shorter and memory-safe.

D is designed with lessons learned from practical C++ usage rather than from a theoretical perspective. Even though it uses many C/C++ concepts it also discards some, and as such is not compatible with C/C++ source code. It adds to the functionality of C++ by also implementing design by contract, unit testing, true modules, garbage collection, first class arrays, associative arrays, dynamic arrays, array slicing, nested functions, inner classes, closures, anonymous functions, compile time function execution, lazy evaluation and has a reengineered template syntax. D retains C++'s ability to do low-level coding, and adds to it with support for an integrated inline assembler. C++ multiple inheritance is replaced by Java style single inheritance with interfaces and mixins. D's declaration, statement and expression syntax closely matches that of C++.

http://en.wikipedia.org/wiki/D_(programming_language)

Здравствуйте, -n1l-, Вы писали:

N>Здравствуйте, tttraveler, Вы писали:
T>>близкое в том, что D позиционирует себя для написания нативного кода, который должен летать
T>>java никогда так себя не позиционировала в принципе, и имидж у нее совсем не тот (хотя во многом проблема как обычно в кривых руках)

T>>и GTK+ и QT можно использовать и из D, как я писал выше давая ссылку на сайт языка

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

на перспективу

Здравствуйте, tttraveler, Вы писали:
T>на перспективу

Нет в области разработки ПО такого понятия, как выбор языка на перспективу.
У тебя есть задача, ее нужно классифицировать и выбрать самый легкий инструмент, который ее решит.

Вот смотри, если ты работаешь с данными, какими-то, которые приходят и уходят, отображаются на других компах, плюс нужна кроссплатформенность, то бери что-то, что охватит полностью всю задачу. Т.е. и сервер и клиент и все-все-все на одной и той же платформе. Ну как вариант java, да?
В java ксати очень много готовых решений, связанных с математикой. Вот я например как-то искал средство для отображения 3-х мерных поверхносте, созданных из моих данных. Ну сварганил все быстренько на java и забыл. До серьезной работы над проектом даже не дошло, так как его просто напросто отложили до лучших времен.
Если бы задачуначали детально разбирать, что-то там меня бы не устроило, то я бы высказал свое веское мнение о том, что java не подходит. Но пока она подходила по всем параметрам, а такая графическая обработка данных, как ты наверное догадываешься дело объемное. Но все летало.

Была другая задача, у меня было 2мб оперативной памяти, и нужно было этот буффер использовать для транспортировки более ста тысяч значений из разных источников.
Плюс нужно было действовать быстро, раз, два принял, обработал, вывел в stream вывода, взял оттуда, отчистил память там уже на очереди еще приплыли значения и так далее. Вот тут я делал уже все на си++, хотя подошел бы и обычный си, но я захотел плюсы.

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

Здравствуйте, -n1l-, Вы писали:

N>Здравствуйте, tttraveler, Вы писали:
T>>на перспективу

N>Нет в области разработки ПО такого понятия, как выбор языка на перспективу.
N>У тебя есть задача, ее нужно классифицировать и выбрать самый легкий инструмент, который ее решит.

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

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

Здравствуйте, tttraveler, Вы писали:

как уже говорили выше, присмотрись к Rust.
многие сильные плюсовики именно его рассматривают как альтернативу, а не Go или Haskell.
я, кстати, тоже вижу перспективу только в нем.

Здравствуйте, niXman, Вы писали:

X>многие сильные плюсовики именно его рассматривают как альтернативу, а не Go или Haskell.
и не D, кстати =)

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, tttraveler, Вы писали:

X>как уже говорили выше, присмотрись к Rust.
X>многие сильные плюсовики именно его рассматривают как альтернативу, а не Go или Haskell.
X>я, кстати, тоже вижу перспективу только в нем.

для практического использования он еще слишком молод
http://en.wikipedia.org/wiki/Rust_(programming_language)
он еще даже до первой версии не дошел

так что разве только поиграться
а по D уже Александреску книгу написал давно

а вот кстати, хороший топик в котором и даны все ответы, покрывающие как личные, так и коммерческие причины, почему мне не нужен с++
http://www.rsdn.ru/forum/cpp/5473329.flat

Автор: jazzer
Дата: 18.02.14

Чет не сильно в это верится, после прочтения о самом языке, его сроке жизни и главных идеях.

Ля строгая типизация мисьё, что в этом удивительного?
Это очевидный факт.

Здравствуйте, -n1l-, Вы писали:

N>Чет не сильно в это верится, после прочтения о самом языке, его сроке жизни и главных идеях.

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

Здравствуйте, kaa.python, Вы писали:
KP>контроль за памятью без потери производительности,

Performance of safe code is expected to be slower than C++ if performance is the only consideration, but to be comparable to C++ code that manually takes precautions comparable to what the Rust language mandates.

Все равно как-то не верится.
Наверное я просто ярый противник функциональщины.

Здравствуйте, -n1l-, Вы писали:

N>Все равно как-то не верится.
N>Наверное я просто ярый противник функциональщины.

Я бы не назвал Rust функциональным языком. ПО моему мнению, он чуть-чуть более функциональный, нежели ожидающий на C++14, но не более того.

Здравствуйте, tttraveler, Вы писали:

T>а вот кстати, хороший топик в котором и даны все ответы, покрывающие как личные, так и коммерческие причины, почему мне не нужен с++
T>http://www.rsdn.ru/forum/cpp/5473329.flat

Автор: jazzer
Дата: 18.02.14

все о чем говорится в том посте, так это о сложности языка. ни о каких коммерческих и личных причинах — нет ни слова.

Rust — не функциональный ЯП.

и да, он очень молод, и, к сожалению, пока не для продакшна.

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, tttraveler, Вы писали:

T>>а вот кстати, хороший топик в котором и даны все ответы, покрывающие как личные, так и коммерческие причины, почему мне не нужен с++
T>>http://www.rsdn.ru/forum/cpp/5473329.flat

Автор: jazzer
Дата: 18.02.14

X>все о чем говорится в том посте, так это о сложности языка. ни о каких коммерческих и личных причинах — нет ни слова.

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

а вот в D (или Java, как здесь предлагали) закопаться самому на некоторое время снова можно
и если сторонний контрактор облажается, то проще будет поправить

вот и все в целом

и, еще раз о "кстати".

думается мне, о тормознутости пайтона уже однозначно говорит и тот факт, что интернет гиганты не используют его. насколько мне известно, — никто.
зато повсеместно используется Go/C/C++и всякие модифицированные версии PHP и кодогенераторы в С/С++.

Здравствуйте, niXman, Вы писали:

X>и, еще раз о "кстати".

X>думается мне, о тормознутости пайтона уже однозначно говорит и тот факт, что интернет гиганты не используют его. насколько мне известно, — никто.
X>зато повсеместно используется Go/C/C++и всякие модифицированные версии PHP и кодогенераторы в С/С++.

гугл и youtube активно использовали python
правда для чего я не знаю
но по моему они с него вообще начинали

yahoo давно активно использовал php, но для чего не знаю
facebook использовал php только для каких-то базовых задач

go придумали в гугле и причем сравнительно недавно

Здравствуйте, tttraveler, Вы писали:

T>гугл и youtube активно использовали python
T>правда для чего я не знаю
гугл когда-то давно пилил пайтон в надежде оптимизировать его хоть сколько-то, но в итоге забил, и написал Go
про ютюб — я не слышал о таком.

кстати, еще один пример:
http://habrahabr.ru/company/vkontakte/blog/214877/

наверное, кампании не хватает абикса и товарища с непроизносимым ником, чтоб они им точно объяснили, что пайтон — все =)

T>facebook использовал php только для каких-то базовых задач
у них своя, оптимизированная/допиленная/порезанная версия PHP. на хабре где-то и об этом был пост.

что гугл, что яндекс, очень любят С++.

Здравствуйте, niXman, Вы писали:

X>и да, он очень молод, и, к сожалению, пока не для продакшна.

Все языки когда-то были молодые, но лично я верю в его светлое будущее

Здравствуйте, kaa.python, Вы писали:

KP>Все языки когда-то были молодые, но лично я верю в его светлое будущее
и я верю, многие верят...

Здравствуйте, niXman, Вы писали:

T>>гугл и youtube активно использовали python
T>>правда для чего я не знаю
X>гугл когда-то давно пилил пайтон в надежде оптимизировать его хоть сколько-то, но в итоге забил, и написал Go
Они выбрали в качестве основы LLVM, что оказалось не очень хорошим выбором для адаптивного JIT-компилятора. В PyPy писали JIT сами с нуля и у них это получилось.

X>про ютюб — я не слышал о таком.
Ютюб почти целиком написан на Питоне, там на С++ только утиллиты перекодирования видео. По оценкам Гуглу — это самое большое приложение на Питоне сейчас.

Здравствуйте, niXman, Вы писали:
Разве что для своих браузеров и других приложений.

Здравствуйте, Cyberax, Вы писали:

X>>про ютюб — я не слышал о таком.
C>Ютюб почти целиком написан на Питоне, там на С++ только утиллиты перекодирования видео. По оценкам Гуглу — это самое большое приложение на Питоне сейчас.


таким образом Python — это все таки нормальный выбор для высоконагруженных приложений?

А я нет.
Ибо таких как он как ...на.

Здравствуйте, -n1l-, Вы писали:

N>А я нет.
N>Ибо таких как он как ...на.

А как-то объяснить свою позицию можешь? Дело в том, что я могу внятно объяснить почему ожидаю что Rust ждет светлое будущее

Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, -n1l-, Вы писали:

N>>А я нет.
N>>Ибо таких как он как ...на.

KP>А как-то объяснить свою позицию можешь? Дело в том, что я могу внятно объяснить почему ожидаю что Rust ждет светлое будущее

объясните, плиз

Здравствуйте, tttraveler, Вы писали:

T>таким образом Python — это все таки нормальный выбор для высоконагруженных приложений?

Однажды решил от делать нечего проверить скорости прог на разных языках.
Подопытной была простая прожка прямого подбора слова из n символов
некоторого алфавита из m символов, делалось в виде n-раз вложенного цикла с m количеством
итераций в каждом. Python, perl, java, C, C++, x86/assembler.
Первые три языка срабатывали в три раза более медленнее, при n=10, m=10, чем С/С++. При
увеличении и m, и n разница увеличивалась в геометрической прогрессии. Для m=30 и n=30
результатов от первой тройки так и не дождался, хотя C/C++ выдавали результат за минуты.
Самыми быстрыми были результаты проги на asm. Самым тормознутым был perl.
Оптимизаций вроде упомянутых мыщъх-ом на pythone не производил. А басня в том, что может
автору топика придумать и поставить ряд тестов, отражающих специфику тех задач, которые собираются решать?

Здравствуйте, tttraveler, Вы писали:

X>>>про ютюб — я не слышал о таком.
C>>Ютюб почти целиком написан на Питоне, там на С++ только утиллиты перекодирования видео. По оценкам Гуглу — это самое большое приложение на Питоне сейчас.
T>таким образом Python — это все таки нормальный выбор для высоконагруженных приложений?
Конечно. Средненький сервер сейчас без проблем даёт более пары тысяч запросов в секунду на Django без учёта БД. Пара тысяч запросов в секунду — это примерно 20 миллионов посетителей в день, то есть уже весьма крупный сайт.

Здравствуйте, tttraveler, Вы писали:

KP>>А как-то объяснить свою позицию можешь? Дело в том, что я могу внятно объяснить почему ожидаю что Rust ждет светлое будущее
T>объясните, плиз

Основная, уникальная фича Rust которой нет ни в одном языке программирования – модель памяти. Она (я не буду вдаваться в детали, если интенесно можно почитать либо в статье у нас тут

Автор(ы): Александр Ставонин
Дата: 20.06.2013
Краткое описание ключевых возможностей нового языка программирования Rust. Основной акцент делается на особенностях Rust, которых не хватает многим системным и сетевым разработчикам в других языках программирования.

, либо у меня в блоге), с одной стороны, позволяет обеспечить скорость работы аналогичную C++ (при наличии соответствующего оптимизатора) при этом дает гарантии сопоставимые с управляемыми языками. Вторая, не менее важная, но уже не на столько уникальная фича – поддержка многопоточности. Она крайне органичено сочетается с моделью памяти, что делает ее очень эффективной. Третья особенность языка – за пределами модели памяти он очень простой в изучении, слегка сложнее Си, но ощутимо проще C++, т.е. любой (совершенно любой) Си или C++ разработчик его освоит "на ура" и при этом обладает достаточно обширными возможностями.

Если же попытаться сравнить его с вышеупомянутым D, то становится очевидно еще одно преимущество Rust – язык развивается крупной компанией для решения конкретных проблем (разработка движка Web-браузера), над языком работают не только и не столько энтузиасты, сколько профессиональные разработчики работающие в корпорации. Это дает тебе ощутимые гарантии того, что Rust 2.0 будет совместим с Rust 1.0 как минимум не хуже чем C++03 с C++11, а так же то, что разработчики будут писать то, что важно для развития языка, а не только лишь "интересные фичи".

Здравствуйте, kaa.python, Вы писали:

KP>Если же попытаться сравнить его с вышеупомянутым D, то становится очевидно еще одно преимущество Rust – язык развивается крупной компанией для решения конкретных проблем (разработка движка Web-браузера), над языком работают не только и не столько энтузиасты, сколько профессиональные разработчики работающие в корпорации. Это дает тебе ощутимые гарантии того, что Rust 2.0 будет совместим с Rust 1.0 как минимум не хуже чем C++03 с C++11, а так же то, что разработчики будут писать то, что важно для развития языка, а не только лишь "интересные фичи".

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

Здравствуйте, tttraveler, Вы писали:

T>а есть языки, которые столько же много обещали вначале и имели поддержку корпораций и некоммерческих организаций, но в итоге сдулись?

Мне о таких не известно (особенно с учетом наличия столь впечатляющих уникальных фич как в Rust), даже .NET помирать не собирается, хотя, казалось бы
Для простоты, Rust можно сравнить с Erlang, который еще и компилируется

Здравствуйте, Cyberax, Вы писали:

C>Конечно. Средненький сервер сейчас без проблем даёт более пары тысяч запросов в секунду на Django без учёта БД.
думается мне, основным тормозом тут должен быть процесс генерации контента, а не выдачи его в сокет. и да, я не тестил, но что-то я сильно сомневаюсь, что генератор на пайтоне, таки сможет генерить пару тысяч страниц в секунду...

Здравствуйте, niXman, Вы писали:

X>думается мне, основным тормозом тут должен быть процесс генерации контента, а не выдачи его в сокет. и да, я не тестил, но что-то я сильно сомневаюсь, что генератор на пайтоне, таки сможет генерить пару тысяч страниц в секунду...

Сможет-сможет. Недавно делал тесты на тему производительности Python. По большому счету, язык достаточно быстрый, просто он может достаточно капризно реагировать (классический пример – сравнение целых числе с числами с плавающей запятой) на не оптимальный код.

Здравствуйте, kaa.python, Вы писали:

KP>Сможет-сможет.
значит для веба сойдет.

Здравствуйте, niXman, Вы писали:


X>значит для веба сойдет.


На python/django соц. сеть с всем набором за пару дней
написать вообще можно. Как-то легко и просто пишется.

Здравствуйте, niXman, Вы писали:

C>>Конечно. Средненький сервер сейчас без проблем даёт более пары тысяч запросов в секунду на Django без учёта БД.
X>думается мне, основным тормозом тут должен быть процесс генерации контента, а не выдачи его в сокет. и да, я не тестил, но что-то я сильно сомневаюсь, что генератор на пайтоне, таки сможет генерить пару тысяч страниц в секунду...
Вполне может, на реальных проектах проверено.

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

Здравствуйте, smeeld, Вы писали:

S>На python/django соц. сеть с всем набором за пару дней написать вообще можно.
написать можно и на баше, поверь

Здравствуйте, Cyberax, Вы писали:

C>У нас Питон используется для не-веб тоже под достаточно большой нагрузкой. Вполне неплохо работает, особенно при проектировании приложения сразу с учётом особенностей Питона (типа несуществующей многопоточности).
а у вас, питон из каких соображений используется? в любом случае же на плюсах будет производительней.

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, smeeld, Вы писали:

S>>На python/django соц. сеть с всем набором за пару дней написать вообще можно.
X>написать можно и на баше, поверь

Верю, но говорил про быстрое написание.

Здравствуйте, tttraveler, Вы писали:

T>а какие языки кроме C/C++ вы можете посоветовать для решения таких же задач для которых используется C/C++?
T>то есть доступ к системе, высокоскоростная обработка данных, математика

D, Rust, Go, Vala, а также Nimrod

Здравствуйте, smeeld, Вы писали:

S>Верю, но говорил про быстрое написание.
на баше я очень быстро пишу, и опыт лет восемь =)

Здравствуйте, BulatZiganshin, Вы писали:

BZ>D, Rust, Go, Vala, а также Nimrod
кстати да, Vala. тыкал одно время, весьма приятный и человеческий кодогенератор.

раз уж пошли в экзотику, посмотри еще на Optrick.
смесь питона и С. использует LLVM. может использоваться как интерпретатор, так и как компилятор.

Здравствуйте, niXman, Вы писали:

X>раз уж пошли в экзотику, посмотри еще на Optrick.
X>смесь питона и С. использует LLVM. может использоваться как интерпретатор, так и как компилятор.
тут, кстати, есть результаты сравнительного теста.

Здравствуйте, niXman, Вы писали:


S>>Верю, но говорил про быстрое написание.
X>на баше я очень быстро пишу, и опыт лет восемь =)

Верю. Но формирование html для отправки клиенту по шаблону с переменными вставками:
django-одна строка, bash-одна сотня строк.

Здравствуйте, tttraveler, Вы писали:

T>очевиден выбор питона для бизнес логики

ещё js сейчас популярен

T>и вдобавок нужно что-то для системной части
T>с/с++ по ряду личных соображений использовать не хочу

каких? я в своё время озадачился той же проблемой, выбрал haskell&c++. если писать на C++ только то что должно максимально быстро работать, то это вполне жизнеспособное решение (разумеется python будет ничуть не хуже хаскела, это вопрос личных предпочтений)

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

Здравствуйте, niXman, Вы писали:

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

если у тебя прога делится на оптимизируемую и неоптимизируемую части, и связность мжду ними достаточно мала, то связка из двух языков — очень мощное оружие. я так freearc сделал — алгоритмы сжатия на C++, остальное на хаскеле. по сравнению с rar/7zip есть только один практический сценарий, где freearc заметно медленней — открытие большого архива. в остальных случаях медлительность haskell тонет в ещё большей медлительности системных функций, работающих с архивируемыми файлами

Здравствуйте, smeeld, Вы писали:

S>django-одна строка, bash-одна сотня строк.
нет у нас джанго. есть только некоторые ЯП, из которых предстоит выбрать подходящий для этой задачи.
баш+sed отлично подходит, очень по-гиковски =)

Здравствуйте, tttraveler, Вы писали:

T>я знаю точно одно, с/с++ мне не нужен
T>однако нужна (на перспективу) возможность писать летающий нативный код на серверах и летающие нативные десктопные приложения

ну используй objective c. это c++ done right

Здравствуйте, niXman, Вы писали:

C>>У нас Питон используется для не-веб тоже под достаточно большой нагрузкой. Вполне неплохо работает, особенно при проектировании приложения сразу с учётом особенностей Питона (типа несуществующей многопоточности).
X>а у вас, питон из каких соображений используется? в любом случае же на плюсах будет производительней.
Ага, и писать раз в 10 дольше. При том, что найти хороших С++-ных программистов примерно в те же 10 раз сложнее, чем питоновских.

Здравствуйте, tttraveler, Вы писали:

N>>Учитывая что сейчас ты вообще используешь язык который не компиллируется а интерпретируется, то тебе ничего из того, в чем так силен си++ не нужно.

T>на перспективу

кстати самые быстрые JIT для интерпретируемых языков — у js и luajit. честно говоря, не похоже что тебе нужен C++ и его столь же низкоуровневые аналоги

Здравствуйте, niXman, Вы писали:

X>как уже говорили выше, присмотрись к Rust.
X>многие сильные плюсовики именно его рассматривают как альтернативу, а не Go или Haskell.
X>я, кстати, тоже вижу перспективу только в нем.

сравнил! Go пока не знаю, но уж хаскел-то... Rust — это такой C++ для докторов наук, где программа получается как побочный эффект док-ва её корректности :D

Здравствуйте, tttraveler, Вы писали:

T>а вот кстати, хороший топик в котором и даны все ответы, покрывающие как личные, так и коммерческие причины, почему мне не нужен с++
T>http://www.rsdn.ru/forum/cpp/5473329.flat

Автор: jazzer
Дата: 18.02.14

кто тебе мешает изучить C++ образца скажем 88-го года?

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, smeeld, Вы писали:


X>нет у нас джанго. есть только некоторые ЯП, из которых предстоит выбрать подходящий для этой задачи.
X>баш+sed отлично подходит, очень по-гиковски =)

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

Здравствуйте, -n1l-, Вы писали:

KP>>контроль за памятью без потери производительности,

N> Performance of safe code is expected to be slower than C++ if performance is the only consideration, but to be comparable to C++ code that manually takes precautions comparable to what the Rust language mandates.

N>Все равно как-то не верится.
N>Наверное я просто ярый противник функциональщины.

Rust имеет не больше отношения к ФП чем современный C++. safe code медленней чем unsafe из-за проверки границ массивов и т.п. классических вещей. фишка же Rust — в привязке указателей к регионам кода, что сокращает число проверок при сохранении безопасности кода. иными словам — на C++ у тебя код опасен и быстр. проверку безопасности указателей делать затруднительно поскольку сам язык низкоуровневый и не описывает область действия указателей. в Rust всё описывается, проверяется, но при этом часть проверок перенесена в compile-time. но из-за писать на нём сложней, чем шпарить на C++ надеясь на авось

Здравствуйте, Cyberax, Вы писали:

C>Ага, и писать раз в 10 дольше.
не факт.
мне, к примеру, раз в десять дольше писать на пайтоне, с моим-то опытом =)

это я к тому, что времязатраты на разработку не столько зависят от ЯП, сколько от опыта кодера.


C>При том, что найти хороших С++-ных программистов примерно в те же 10 раз сложнее, чем питоновских.
есть такое...

Здравствуйте, tttraveler, Вы писали:

T>таким образом Python — это все таки нормальный выбор для высоконагруженных приложений?

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

Здравствуйте, smeeld, Вы писали:

S>А накой в вебе python без джанги?
злой ты

ладно, сдаюсь, вас больше =)

Здравствуйте, kaa.python, Вы писали:

KP>Основная, уникальная фича Rust которой нет ни в одном языке программирования – модель памяти.
KP>Третья особенность языка – за пределами модели памяти он очень простой в изучении

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

KP>Если же попытаться сравнить его с вышеупомянутым D, то становится очевидно еще одно преимущество Rust – язык развивается крупной компанией для решения конкретных проблем (разработка движка Web-браузера), над языком работают не только и не столько энтузиасты, сколько профессиональные разработчики

с опытом куда большим чем у александреску и брайта

Здравствуйте, kaa.python, Вы писали:

T>>а есть языки, которые столько же много обещали вначале и имели поддержку корпораций и некоммерческих организаций, но в итоге сдулись?

KP>Мне о таких не известно (особенно с учетом наличия столь впечатляющих уникальных фич как в Rust)

это даже не смешно. берёшь over 9000 мёртвых языков и отбираешь из них по любым критериям. algol-68, ada, apl, smalltalk, J#

Здравствуйте, kaa.python, Вы писали:

X>>думается мне, основным тормозом тут должен быть процесс генерации контента, а не выдачи его в сокет. и да, я не тестил, но что-то я сильно сомневаюсь, что генератор на пайтоне, таки сможет генерить пару тысяч страниц в секунду...

KP>Сможет-сможет.

обычно в таких тестах отдают просто "hello". я видел и до 50 тыщ, проблема в том что стандартизированных тестов с генерацией сложного контента нет, поэтому остаётся меряться только самыми простыми ответами

Здравствуйте, niXman, Вы писали:

X>на баше я очень быстро пишу, и опыт лет восемь =)

я когла искал более лучший язык, тоже sh проходил в самом начале. но быстро выяснилось, что bash<perl<ruby<haskell. а самым первым я пробовал 4dos — вот на чём fb написать было надо

Здравствуйте, BulatZiganshin, Вы писали:
BZ>C++ язык низкоуровневый и не описывает область действия указателей.

Ну да, ниже некуда. Все остальное попросту смешно.

Здравствуйте, kaa.python, Вы писали:
KP>А как-то объяснить свою позицию можешь? Дело в том, что я могу внятно объяснить почему ожидаю что Rust ждет светлое будущее

Попытаюсь. Все ИМХО.

Во первых начну с того, где си/си++ по моему незаменим. Встраиваемые системы. Там все завязано на ручном управлении периферией, что бы сделать компиляторы, которые будут правильно компиллировать rust для такого огромного кол-ва архитектур нужно будет времени и усилий гораздо больше чем сейчас.
Хотя там по моему даже обычного си хватит, просто некоторым индивидуумам очень хочется ООП на армах.
Предположим что компиляторы есть. И они подходят для всех платформ. Безопасность же сожрет производительность. Так было и так будет всегда, т.е. если мы используем rust то только unsafe, а зачем изучать новый язык, похожий на си++ если можно просто взять си++?

Обычные десктоп приложения мало кто делает, а если и захотят возьмут проверенное временем QT, GTK+.

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

В общем rust может быть и выстрелит, но это будет не супер бабах как у java или c в свое время.

Ну и я не особо люблю функциональщину.

Ваша очередь.

Здравствуйте, мыщъх, Вы писали:

М>что такое высокоскоростная обработка данных?
Написать нечно, что не имеет аналогов в либах, с жесткими ограничениями по времени выполнения.

М>на питоне полно библиотек, написанных на си. если писать на питоне только "клей", то по скорости получится как си, только более наглядно.
А зачем программисту, который пишет высокопроизводительный код, заниматься всяким клеем? У меня обычно задача быстро выплеснуть результаты наверх в виде некоторого API, а уж как оно будет использоваться не моя забота.

Здравствуйте, Mystic, Вы писали:

M>Здравствуйте, мыщъх, Вы писали:

М>>что такое высокоскоростная обработка данных?
M>Написать нечно, что не имеет аналогов в либах, с жесткими ограничениями по времени выполнения.
такого не бывает. по крайней мере базовые структуры данных изобретать не надо

M> А зачем программисту, который пишет высокопроизводительный код, заниматься всяким клеем?
а разве си не клей? открываю сорцы стандартной библиотеки и что я вижу? ассемблер.

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

Здравствуйте, мыщъх, Вы писали:

М>такого не бывает. по крайней мере базовые структуры данных изобретать не надо

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

М>а разве си не клей? открываю сорцы стандартной библиотеки и что я вижу? ассемблер.

В libc многое неоптимально, например недавно написал свою реализацию quick сортировки,
которая оказалась быстрее, чем qsort из glibc. На 10^8 элементах разница на линуксах 3 сек.
Правда перегнать sort из stl так и не удалось, но там и не quick сортировка вообще-то.

Здравствуйте, -n1l-, Вы писали:

N>Во первых начну с того, где си/си++ по моему незаменим. Встраиваемые системы. Там все завязано на ручном управлении периферией, что бы сделать компиляторы, которые будут правильно компиллировать rust для такого огромного кол-ва архитектур нужно будет времени и усилий гораздо больше чем сейчас.

С поддержкой арихтектур на Rust все сравнительно просто – они базируются на LLVM и как следствие "бесплатно" получают поддержку ряда процессоров, так на данный момент есть поддержка не только x86/64, но и ARM.

N>Предположим что компиляторы есть. И они подходят для всех платформ. Безопасность же сожрет производительность. Так было и так будет всегда, т.е. если мы используем rust то только unsafe, а зачем изучать новый язык, похожий на си++ если можно просто взять си++?

Безопасность может не жрать производительности, если делать все необходимые проверки на этапе компиляции, чем, собственно, Rust и занимается. Unsafe в Rust это не более чем хак, использование которого должно быть сведено к минимуму.

N>В общем rust может быть и выстрелит, но это будет не супер бабах как у java или c в свое время.

Супер бабаха и не надо, сейчас есть Python, Java, C++ и их хватает доя решения большинства задач. Но ряд задач которые на данный момент решаются на C++ и Java можно проще и надежнее решить при помощи Rust.

Здравствуйте, smeeld, Вы писали:

S>В libc многое неоптимально, например недавно написал свою реализацию quick сортировки,
S>которая оказалась быстрее, чем qsort из glibc. На 10^8 элементах разница на линуксах 3 сек.
покажите, пожалуйста, код. этот фрагмент ведь бессмысленно делать коммерческим или закрытым кодом.

Здравствуйте, -n1l-, Вы писали:

BZ>>C++ язык низкоуровневый и не описывает область действия указателей.

N>Ну да, ниже некуда. Все остальное попросту смешно.

в/у программирование увеличивает надёжность программ, заменяя опасные конструкции более безопасными. при этом необязательно безопасные конструкции проще для программирования, вспомни насколько сложен самый в/у массовый язык — haskell. теория регионов (кстати один из компиляторов haskell, jhc, использовал как раз её, правда с автоматическим выводом областей действия) увеличивает надёжность программ, следовательно это в/у механизм

Здравствуйте, kaa.python, Вы писали:

N>>Предположим что компиляторы есть. И они подходят для всех платформ. Безопасность же сожрет производительность.

KP>Безопасность может не жрать производительности, если делать все необходимые проверки на этапе компиляции, чем, собственно, Rust и занимается.

думаю, вы оба неправы. чаксть проверок ухолдит в compile-time за счёт умищи компилятора и регионов (т.е. усложнения программирования). часть, как проверки границы массивов, остаются, хотя вероятно все run-time проверки можно отключить и получить скорость как в C++, и всё же большую, хоть и не абсолютную безопасность

Здравствуйте, Abyx, Вы писали:

A>а на плюсах ты сначала напечатаешь 100 строк, еще наверное cmake или bat/sh файл напишешь, потом пять раз перекомпилируешь чтобы поправить все ошибки — это конечно же проще чем питон с его REPLом

JFYI http://root.cern.ch/drupal/content/cling — ling is an interactive C++ interpreter

Не все так просто конечно как с питоновским REPL-ом, но вполне интерактивно.

Здравствуйте, niXman, Вы писали:


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

Мне сюда выложить, или просто ссылку кинуть?

Здравствуйте, smeeld, Вы писали:

S>Мне сюда выложить, или просто ссылку кинуть?
меня оба способа устраивают.
спасибо.

Здравствуйте, niXman, Вы писали:

как-то так

Здравствуйте, BulatZiganshin, Вы писали:

KP>>Безопасность может не жрать производительности, если делать все необходимые проверки на этапе компиляции, чем, собственно, Rust и занимается.
BZ>думаю, вы оба неправы. чаксть проверок ухолдит в compile-time за счёт умищи компилятора и регионов (т.е. усложнения программирования).
Регионы для проверки границ не очень хорошо подходят. Гораздо важнее то, что в Rust'е есть иммутабельные типы данных.

Т.е. для типичного прохода по массиву компилятор может вообще убрать все проверки выхода за границы. Для random-access кода, конечно, это не сработает — но такого кода и не так много.

Здравствуйте, smeeld, Вы писали:

S>как-то так
А что ты хотел? Библиотечный qsort на каждое сравнение вызывает callback, в этом и вся разница.

Здравствуйте, Cyberax, Вы писали:


C>А что ты хотел? Библиотечный qsort на каждое сравнение вызывает callback, в этом и вся разница.

Ну дык калбек приделать там делов на 30 секунд, и от этого положение никак не меняется.
Проверял.

Здравствуйте, smeeld, Вы писали:

C>>А что ты хотел? Библиотечный qsort на каждое сравнение вызывает callback, в этом и вся разница.
S>Ну дык калбек приделать там делов на 30 секунд, и от этого положение никак не меняется.
S>Проверял.
Компилятор его точно не инлайнит? Да, как насчёт стабильности поиска в паталогических случаях, типа обратно отстортированного массива?

Здравствуйте, Cyberax, Вы писали:

C>Компилятор его точно не инлайнит?

Конечно инлайнит. И вообще тут о том, что не правы те, кто про велосипедистов и наколеночников.
Варианты для общих случаев всегда проигрывают заточенным под случай конкретный.
В этом и заключается неоптимальность функций стандартных либ.

Здравствуйте, smeeld, Вы писали:

C>>Компилятор его точно не инлайнит?
S>Конечно инлайнит. И вообще тут о том, что не правы те, кто про велосипедистов и наколеночников.
Ну а теперь сравни с std::sort.

S>Варианты для общих случаев всегда проигрывают заточенным под случай конкретный.
Попробуй написать memcpy или memcmp более быстрые, чем в glibc.

Здравствуйте, Cyberax, Вы писали:

C>Ну а теперь сравни с std::sort.
Сравнивал, обогнать не смог, но в std::sort не quick sort вовсе.


C>Попробуй написать memcpy или memcmp более быстрые, чем в glibc.
На какой архитектуре?

Здравствуйте, smeeld, Вы писали:

C>>Ну а теперь сравни с std::sort.
S>Сравнивал, обогнать не смог, но в std::sort не quick sort вовсе.
И что?

C>>Попробуй написать memcpy или memcmp более быстрые, чем в glibc.
S>На какой архитектуре?
А вот в том и фича, что на любой. В glibc используются оптимизированные реализации для примерно десятка разных комбинаций.

Здравствуйте, Cyberax, Вы писали:

C>А вот в том и фича, что на любой. В glibc используются оптимизированные реализации для примерно десятка разных комбинаций.

Смотрел на спарковый ассемблер, который в C asm, и который генерит gcc, возможности и особенности
этих процессоров задействуются не полностью, прога на чистом спарковом ассемблере memcpy/memcmp порвёт в лёгкую.

Здравствуйте, smeeld, Вы писали:

C>>А вот в том и фича, что на любой. В glibc используются оптимизированные реализации для примерно десятка разных комбинаций.
S>Смотрел на спарковый ассемблер, который в C asm, и который генерит gcc, возможности и особенности
S>этих процессоров задействуются не полностью, прога на чистом спарковом ассемблере memcpy/memcmp порвёт в лёгкую.
Ты бы ещё OS/360 посмотрел. Попробуй быстрее сделать на реальных процессорах — вариантах x86/64 и ARM.

Здравствуйте, Cyberax, Вы писали:


C>Ты бы ещё OS/360 посмотрел.
Не знаю таких, а с спарками работал много и долго.
И сейчас имеется две машины.

>Попробуй быстрее сделать на реальных процессорах — вариантах x86/64 и ARM.

А чем падший не шутит, подучу AVX.

Здравствуйте, Cyberax, Вы писали:

C>Попробуй написать memcpy или memcmp более быстрые, чем в glibc.

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

Здравствуйте, smeeld, Вы писали:

S>А чем падший не шутит, подучу AVX.

лучше агнера фога. например, на последних cpu обычный rep movs при выравненных src+dst быстрее любого simd-варианта

Здравствуйте, BulatZiganshin, Вы писали:

C>>Попробуй написать memcpy или memcmp более быстрые, чем в glibc.
BZ>у меня в программе такой есть. не знаю каким чудом, но 32-битный gcc из простого цикла генерит код более быстрый чем бибилиотечная функция. правда, для всех остальных компиляторов этот трюк не работает
Ага, при каком-то совпадении звёзд оно лучше работает. Но обычно хуже, потому добавление -fno-builtin-memcpy в ключи почти всегда ускоряет работу.

Здравствуйте, BulatZiganshin, Вы писали:


BZ>лучше агнера фога. например, на последних cpu обычный rep movs при выравненных src+dst быстрее любого simd-варианта

rep movs работает с какими то внутренними буферами в процессоре размеров больших/равных ZMMx?

Здравствуйте, smeeld, Вы писали:

BZ>>лучше агнера фога. например, на последних cpu обычный rep movs при выравненных src+dst быстрее любого simd-варианта
S>rep movs работает с какими то внутренними буферами в процессоре размеров больших/равных ZMMx?
Нет, процессор может его распараллелить, выполняя копирование сразу всеми ALU.

Здравствуйте, smeeld, Вы писали:

S>как-то так

вынеси компаратор и сортировку в разные единицы трансляции, и увидишь как просядет производительность.
далее, думаю, не нужно объяснять почему qsort() медленнее?

qsort(), на самом деле, отлично реализован.

Здравствуйте, Cyberax, Вы писали:

BZ>>>лучше агнера фога. например, на последних cpu обычный rep movs при выравненных src+dst быстрее любого simd-варианта
S>>rep movs работает с какими то внутренними буферами в процессоре размеров больших/равных ZMMx?
C>Нет, процессор может его распараллелить, выполняя копирование сразу всеми ALU.

вот поэтому и надо читать фога

Здравствуйте, мыщъх, Вы писали:

Написано правильно. Но вот именно такими текстами прикрываются потом те, кто на всяких питонах пишет ВСЁ.

Здравствуйте, Abyx, Вы писали:

A>просто и на С, да?
A>вот простой код на питоне
A>

A>import my_image_processing_lib
A>src = open('src.img', 'rb').read()
A>result = my_image_processing_lib.process()
A>open('out.img', 'wb').write(result)
A>

A>я могу набрать и выполнить его в REPL
A>а на плюсах ты сначала напечатаешь 100 строк, еще наверное cmake или bat/sh файл напишешь, потом пять раз перекомпилируешь чтобы поправить все ошибки — это конечно же проще чем питон с его REPLом

При чем тут язык? Всю обертку просто уже сделали до тебя и назвали этот пакет my_image_processing_lib люди, не имеющие отношения к написанию самого питона. Хвали их. Питон то при чем?
С таким же успехом можно какой нибудь буст в плюсах использовать без 100500 строк инициализации

Здравствуйте, kaa.python, Вы писали:

KP>Тем что тебе нужно написать как минимум CMakeFile,
Это за тебя делает манагер проектов или ты пишешь код через echo "my super code" >> cfile.c ?

KP>качать библиотеки и собрать my_image_processing_lib,
Качать библиотеки и собрать my_image_processing_lib, качать обертку этих библиотек для питона, если есть. Нету — писать.

KP>разложить их по соответствующим путям.
Разложить их по соответствующим путям, разложить питоновскую обёртку по своим путям

KP>Ну и еще тем, что довольно хорошо совместимых между собой библиотек в Python до чертиков, а в C++ ты еще не маленький промежуток времени будешь детские болезни лечить, со флагами сборки играться.
С флагами сборки играется манагер проекта, детские болезни есть и в питонах
Совместимость? Да-да. Питон2 — питон3.

Здравствуйте, Abyx, Вы писали:

A>1) тем что тебе надо его перекомпилировать из за "" vs ''
Надо быть идиотом, чтобы применить в плюсах "" вместо '' и наоборот. Ты уже совсем в питон угрузился, чтобы это позабыть?

A>2) в питоне для данных есть один тип — байты, а в плюсах тебе надо будет поконвертировать твой istream в какуюнить пару (void*, size_t) — одним словом больше бойлерплейта, больше возни
Строгая типизация. Возможные ошибки с типами выявляются на этапе компиляции а не когда нибудь потом, когда у юзера вместо рублей в отчете вылезет сериализованный объект

Здравствуйте, Cyberax, Вы писали:

C>Правильнее будет:
C>

C>import my_image_processing_lib
C>with open('src.img', 'rb') as fl:
C>    src = fl.read()
C>result = my_image_processing_lib.process()
C>with open('out.img', 'wb') as fl:
C>    fl.write(result)
C>

Подозреваю, что правильнее будет

import my_image_processing_lib
with open('src.img', 'rb') as fl:
    src = fl.read()
    result = my_image_processing_lib.process()
    with open('out.img', 'wb') as fl:
        fl.write(result)