Здравствуйте, 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 тыщ, проблема в том что стандартизированных тестов с генерацией сложного контента нет, поэтому остаётся меряться только самыми простыми ответами