Здравствуйте, niXman, Вы писали:
X>на баше я очень быстро пишу, и опыт лет восемь =)
я когла искал более лучший язык, тоже sh проходил в самом начале. но быстро выяснилось, что bash<perl<ruby<haskell. а самым первым я пробовал 4dos — вот на чём fb написать было надо
Люди, я люблю вас! Будьте бдительны!!!
Re[15]: а какие языки кроме C/C++ вы можете посоветовать для
Здравствуйте, kaa.python, Вы писали: KP>А как-то объяснить свою позицию можешь? Дело в том, что я могу внятно объяснить почему ожидаю что Rust ждет светлое будущее
Попытаюсь. Все ИМХО.
Во первых начну с того, где си/си++ по моему незаменим. Встраиваемые системы. Там все завязано на ручном управлении периферией, что бы сделать компиляторы, которые будут правильно компиллировать rust для такого огромного кол-ва архитектур нужно будет времени и усилий гораздо больше чем сейчас.
Хотя там по моему даже обычного си хватит, просто некоторым индивидуумам очень хочется ООП на армах.
Предположим что компиляторы есть. И они подходят для всех платформ. Безопасность же сожрет производительность. Так было и так будет всегда, т.е. если мы используем rust то только unsafe, а зачем изучать новый язык, похожий на си++ если можно просто взять си++?
Обычные десктоп приложения мало кто делает, а если и захотят возьмут проверенное временем QT, GTK+.
Если rust и ждет какое-то успешное будущее, то только там где сейчас си++ проводит сложные параллельные вычисления.
Но там уже есть языки, такие как эрланг, которые уже отхватывают свою долю.
В общем rust может быть и выстрелит, но это будет не супер бабах как у java или c в свое время.
Ну и я не особо люблю функциональщину.
Ваша очередь.
Re[2]: а какие языки кроме C/C++ вы можете посоветовать для решения таких же зад
Здравствуйте, мыщъх, Вы писали:
М>что такое высокоскоростная обработка данных?
Написать нечно, что не имеет аналогов в либах, с жесткими ограничениями по времени выполнения.
М>на питоне полно библиотек, написанных на си. если писать на питоне только "клей", то по скорости получится как си, только более наглядно.
А зачем программисту, который пишет высокопроизводительный код, заниматься всяким клеем? У меня обычно задача быстро выплеснуть результаты наверх в виде некоторого API, а уж как оно будет использоваться не моя забота.
Re[3]: а какие языки кроме C/C++ вы можете посоветовать для решения таких же зад
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, мыщъх, Вы писали:
М>>что такое высокоскоростная обработка данных? M>Написать нечно, что не имеет аналогов в либах, с жесткими ограничениями по времени выполнения.
такого не бывает. по крайней мере базовые структуры данных изобретать не надо
M> А зачем программисту, который пишет высокопроизводительный код, заниматься всяким клеем?
а разве си не клей? открываю сорцы стандартной библиотеки и что я вижу? ассемблер.
M> У меня обычно задача быстро выплеснуть результаты наверх M> в виде некоторого API, а уж как оно будет использоваться не моя забота.
это не значит, что ваши задачи не могут быть решены эффективнее с использованием питона или других языков. на питоне развиты средства метапрограммирования и потому можно сделать так, чтобы ваш алгоритм, описанный на питоне, транслировался в любой целевой язык типа си, джавы или чего-то еще, включая джава-скрипт. для библиотеки это полезно.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Re[4]: а какие языки кроме C/C++ вы можете посоветовать для решения таких же зад
Здравствуйте, мыщъх, Вы писали:
М>такого не бывает. по крайней мере базовые структуры данных изобретать не надо
Это Вы на собеседованиях скажите, а то там любят справшивать про фибоначиевы кучи
и просят за пять минут написать реализацию.
М>а разве си не клей? открываю сорцы стандартной библиотеки и что я вижу? ассемблер.
В libc многое неоптимально, например недавно написал свою реализацию quick сортировки,
которая оказалась быстрее, чем qsort из glibc. На 10^8 элементах разница на линуксах 3 сек.
Правда перегнать sort из stl так и не удалось, но там и не quick сортировка вообще-то.
Re[20]: а какие языки кроме C/C++ вы можете посоветовать для
Здравствуйте, -n1l-, Вы писали:
N>Во первых начну с того, где си/си++ по моему незаменим. Встраиваемые системы. Там все завязано на ручном управлении периферией, что бы сделать компиляторы, которые будут правильно компиллировать rust для такого огромного кол-ва архитектур нужно будет времени и усилий гораздо больше чем сейчас.
С поддержкой арихтектур на Rust все сравнительно просто – они базируются на LLVM и как следствие "бесплатно" получают поддержку ряда процессоров, так на данный момент есть поддержка не только x86/64, но и ARM.
N>Предположим что компиляторы есть. И они подходят для всех платформ. Безопасность же сожрет производительность. Так было и так будет всегда, т.е. если мы используем rust то только unsafe, а зачем изучать новый язык, похожий на си++ если можно просто взять си++?
Безопасность может не жрать производительности, если делать все необходимые проверки на этапе компиляции, чем, собственно, Rust и занимается. Unsafe в Rust это не более чем хак, использование которого должно быть сведено к минимуму.
N>В общем rust может быть и выстрелит, но это будет не супер бабах как у java или c в свое время.
Супер бабаха и не надо, сейчас есть Python, Java, C++ и их хватает доя решения большинства задач. Но ряд задач которые на данный момент решаются на C++ и Java можно проще и надежнее решить при помощи Rust.
Re[5]: а какие языки кроме C/C++ вы можете посоветовать для решения таких же зад
Здравствуйте, smeeld, Вы писали:
S>В libc многое неоптимально, например недавно написал свою реализацию quick сортировки, S>которая оказалась быстрее, чем qsort из glibc. На 10^8 элементах разница на линуксах 3 сек.
покажите, пожалуйста, код. этот фрагмент ведь бессмысленно делать коммерческим или закрытым кодом.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[16]: а какие языки кроме C/C++ вы можете посоветовать для
Здравствуйте, -n1l-, Вы писали:
BZ>>C++ язык низкоуровневый и не описывает область действия указателей.
N>Ну да, ниже некуда. Все остальное попросту смешно.
в/у программирование увеличивает надёжность программ, заменяя опасные конструкции более безопасными. при этом необязательно безопасные конструкции проще для программирования, вспомни насколько сложен самый в/у массовый язык — haskell. теория регионов (кстати один из компиляторов haskell, jhc, использовал как раз её, правда с автоматическим выводом областей действия) увеличивает надёжность программ, следовательно это в/у механизм
Люди, я люблю вас! Будьте бдительны!!!
Re[21]: а какие языки кроме C/C++ вы можете посоветовать для
Здравствуйте, kaa.python, Вы писали:
N>>Предположим что компиляторы есть. И они подходят для всех платформ. Безопасность же сожрет производительность.
KP>Безопасность может не жрать производительности, если делать все необходимые проверки на этапе компиляции, чем, собственно, Rust и занимается.
думаю, вы оба неправы. чаксть проверок ухолдит в compile-time за счёт умищи компилятора и регионов (т.е. усложнения программирования). часть, как проверки границы массивов, остаются, хотя вероятно все run-time проверки можно отключить и получить скорость как в C++, и всё же большую, хоть и не абсолютную безопасность
Люди, я люблю вас! Будьте бдительны!!!
Re[6]: а какие языки кроме C/C++ вы можете посоветовать для решения таких же зад
Здравствуйте, Abyx, Вы писали:
A>а на плюсах ты сначала напечатаешь 100 строк, еще наверное cmake или bat/sh файл напишешь, потом пять раз перекомпилируешь чтобы поправить все ошибки — это конечно же проще чем питон с его REPLом
Здравствуйте, BulatZiganshin, Вы писали:
KP>>Безопасность может не жрать производительности, если делать все необходимые проверки на этапе компиляции, чем, собственно, Rust и занимается. BZ>думаю, вы оба неправы. чаксть проверок ухолдит в compile-time за счёт умищи компилятора и регионов (т.е. усложнения программирования).
Регионы для проверки границ не очень хорошо подходят. Гораздо важнее то, что в Rust'е есть иммутабельные типы данных.
Т.е. для типичного прохода по массиву компилятор может вообще убрать все проверки выхода за границы. Для random-access кода, конечно, это не сработает — но такого кода и не так много.
Sapienti sat!
Re[9]: а какие языки кроме C/C++ вы можете посоветовать для решения таких же зад
Здравствуйте, smeeld, Вы писали:
C>>А что ты хотел? Библиотечный qsort на каждое сравнение вызывает callback, в этом и вся разница. S>Ну дык калбек приделать там делов на 30 секунд, и от этого положение никак не меняется. S>Проверял.
Компилятор его точно не инлайнит? Да, как насчёт стабильности поиска в паталогических случаях, типа обратно отстортированного массива?
Sapienti sat!
Re[12]: а какие языки кроме C/C++ вы можете посоветовать для решения таких же за
Здравствуйте, Cyberax, Вы писали:
C>Компилятор его точно не инлайнит?
Конечно инлайнит. И вообще тут о том, что не правы те, кто про велосипедистов и наколеночников.
Варианты для общих случаев всегда проигрывают заточенным под случай конкретный.
В этом и заключается неоптимальность функций стандартных либ.
Re[13]: а какие языки кроме C/C++ вы можете посоветовать для решения таких же за
Здравствуйте, smeeld, Вы писали:
C>>Компилятор его точно не инлайнит? S>Конечно инлайнит. И вообще тут о том, что не правы те, кто про велосипедистов и наколеночников.
Ну а теперь сравни с std::sort.
S>Варианты для общих случаев всегда проигрывают заточенным под случай конкретный.
Попробуй написать memcpy или memcmp более быстрые, чем в glibc.
