Rust сугубо для системного программирования, в то время как Go хм для программистов.
Это весьма спорное утверждение. Вы считаете Skylight и ZeroMQ системным программированием? Насколько я вижу, единственное, что мешает Rust потеснить Go в его областях — это существующие библиотеки. В частности, это web-разработка, где прогресс отличный, но до финала ещё далеко (AreWeWebYet).
Насколько мне известно, ситуация с IDE в последнее время идёт на поправку. Если сначала можно было использовать Vim/Emacs/Sublime/Kate/Geany с подсветкой, есть и авто-подстановка, которую можно прикрутить к Emacs или Atom (проект).
Я, право, не вижу проблемы. Перегрузка функций усложняет язык — не всегда понятно, что именно Вы вызываете, пока не сравните типы аргументов. А для чего всё? чтобы написать new() вместо new_something() или from_something()? Смешно.
С/C++ библиотеки выкидывать не надо. С ними надо линковаться и дружить. Смотрите группу «bindings» на rust-ci
Те, кому была важна безопасность уже давно пересели на Java
Я не так хорошо знаком с Java, чтобы проводить полноценный анализ, но уже тот факт, что там все объекты могут быть null, настораживает по поводу безопасности. Можете хоть на минутку допустить мысль о том, что Rust даст Вам больше гарантий надёжности?
Серьёзно, Вы ожидали увидеть другую статью. Как и WerewolfPrankster, Вам нужно полноценное доказательство , что Rust лучше С++ (а также D, Go, и чего бы то ни было ещё). Моя статья же носит исключительно показательный характер, при этом я попытался показать Rust как скрещение С++ с Haskell, что есть сугубо личный взгяд на происхождение языка.
Если Вас не убедило даже заглянуть на домашнюю страничку языка — это бывает. Но вот утверждение, что статья несодержательная, вызывает у меня недоумение. Вы просто искали другое содержимое.
Это полезная практика, однако у меня она приводит к усилению кровотока через всё тело, включая мозг на полную катушку, а там опять же асимптотики, эвристики и прочее…
Я пробовал наоборот оттащить кровь от мозга путём физических упражнений перед сном, и это вроде как работает.
Когда начинаю считать что-либо перед сном, активируется вычислительный модуль, и мозг улетает в дебри синусоид, асимптотик и эвристик, естественно при этом находясь в предельном возбуждении, так что о сне можно и забыть…
Отдельно стоит сказать про z-буфер. Для использования в SSAO его нужно сначала сделать линейным, в противном случае на среднем и дальнем плане сильно теряется точность. Обычно для этого значения глубины пишут в отдельный буфер, часто вместе с нормалями. Однако дополнительный буфер не сулит ничего хорошего в плане производительности, поэтому линеаризовывать значения и записывать их мы будем не в отдельный буфер, а прямо в действующий, стандартный буфер глубины (gl_FragDepth). Это может вызвать артефакты на переднем плане (очень близком, практически вблизи передней плоскости отсечения), однако в основном такой буфер ведет себя вполне нормально.
Вот уж сэкономили…
1) Заслуженно получили артефакты (не только в SSAO, а во всей геометрии, особенно ближней к камере).
2) Лишились Early-Z при рисовании всей геометрии(!). В Вашей сцене перерисовки пикселов почти нет, так что это не сказывается, но в общем случае — это катастрофа.
Да и сам способ вычисления линейной глубины вызывает сомнения:
Помимо прочих приёмов, всегда можно разделить алфавит на группы и кодировать сначала номер группы, а потом уже частоту внутри группы. Скажем, кодирование элемента из алфавита в 1000000 таким образом можно свести к кодированию двух элементов из алфавита в 1000. Вобщем, не вижу я принципиальных проблем тут…
А в плане скорости (это ответ автору) — если частоты статические, то можно свести общую сумму к степени двойки при кодировании. В этом случае арифметика будет использовать только битовые сдвиги и умножения, так что медленно уж точно не будет ;)
Мне не приходилось работать с такими большими алфавитами (десятки миллионов элементов), но давайте посчитаем, как арифметическое кодирование могло бы справиться с ними. Допустим, размер алфавита = E. Нам нужно хранить частоту для каждого символа, то есть всего E*K байт, где 1<=K<=4 — размер типа для частоты, зависящий от того, насколько Ваши частоты могут различаться. Далее, чтобы посчитать отрезок вероятности для конкретного символа, нужно просуммировать частоты от 0 до этого символа.
Если схема статическая — то эти суммы можно просто хранить для каждого элемента. Если динамическая — то мы можем хранить иерархические суммы частот: p0 — сумма от 0 до E/2, p1 — сумма от E/2 до E, p00 — сумма от 0 до E/4, p01 — сумма от E/4 до E/2, p10 — сумма от E/2 до E/4, и т.д. В этом случае нужно дополнительно E*K байт памяти, а поиск отрезка для символа и его обновление будут выполняться зя O(log(E)).
Итого, затраты к памяти: около 2*E*K <= 8*E байт. Асимптотическая сложность кодирования N символов: O(N*log(E)) для динамической адаптации или O(N) для статической. При этом арифметическое кодирование обещат почти оптимальное представление частот, то есть лучшее сжатие, чам любые бинарные деревья.
Ещё ни у кого не было возможности изучить последствия маломощного атомного взрыва в настоящем городе.
А потом:
Они слабее тех, что были сброшены на Хиросиму и Нагасаки, и совсем не сравнимы с боеголовками межконтинентальных ракет.
То есть сброшенные американцами бомбы были сравнимы по мощности с теми «гипотетическими» маломощными взрывами, о которых пишет автор. Японцы наверняка изучили досконально, как их города сровняли с землёй. Автор же видимо считает, что это было не на самом деле.
Именно так, и нет никакого передёргивания, для продакшена и больших проектов это не применимо.
Так и есть. Цель моего коммента — обратить внимание С++ программистов на Rust. Ведь С++14 и C++17 как бы тоже ещё не вышли, так может лучше посмотреть на Rust, чем ждать их?
К тому же бессмысленно утверждать, что внутри всё реализовано как надо, и не содержит ошибок.
Давайте не будем скатываться в банальности, никто такого не утверждал.
Эта модель прекрасна и удобна. вот только проблема в том, что железо, на котором работает машинный код, полученный из кода языка высокого уровня не поддерживает такую модель памяти, а это значит, что будут обязательные проверки на переполнение буфера в рантайме, избыточные инициализации и проверки указателей, и т.д, а посему рекомендовать такой язык для системного программирования просто не применим.
Вы делаете логически необоснованное умозаключение. Если язык близок к железу — то скорость выполнения будет хороша, это понятно. Но Вы утверждаете обратное (если не близок, то скорость пострадает), что ещё надо доказать:
— обязательные проверки на переполнение буфера в рантайме: огромная часть доступа к индексам массива в С идёт на перечисление. Используя итераторы в Rust, Вы получите один в один с Си машинный код перечисления элементов массива, без лишних проверок. Что же до остальных — есть функция доступа без проверки на выход за границы, если в каком-то конкретном месте это бьёт по производительности. К тому же LLVM, используемся в Rust компиляторе, вполне неплохо исключает лишние проверки.
— избыточные инициализации: во-первых компилятор (и, опять-же, LLVM) достаточно умён, чтобы оптимизировать такие вещи. А во-вторых, Вы видели хоть один проект, где инициализация созданных объектов была проблемой производительности? Я — нет.
— проверки указателей: вся прелесть в том, «плохие» указатели устраняются на этапе компиляции, а не в run-time. Тут работает философия «если оно скомпилировалось, то оно работает», заимствованная из Haskell.
Посмотрите, что используют для системного программирования — там чаще всего голый С, а то и вообще С--, а местами вообще asm, и это не просто так.
Что-то я не припомню ни одного серьёзного приложения на С--… Вы ничего не перепутали?
А вообще понятно, что они используют, эти системщики. Rust пытается потеснить эту нишу, как, впрочем, и многие другие.
к примеру безопасную генерацию кода, умные указатели, позволяющие получить полностью контролируемую, и при этом безопасную модель работы с памятью, и т.д.
Да, на С++ можно писать надёжный код. Да и на asm можно. Вся суть-то в том, что на Rust это делать и приятнее, и быстрее.
Вы слегка передёргиваете. Приведённый код «может оказаться нерабочим» не в том смысле, что будет вести себя некорректно или падать, а в том, что синтаксис или имена методов стандартной библиотеки могли немного измениться с мая 2013 года.
Да и вообще, русская Вики — это Вам не официальная документация. На сайте проекта есть tutorial, manual, API — всё, что душе угодно, притом одновременно и для последнего релиза, и для текущей версии в разработке.
Как только Вы освоили синтаксис и модель памяти Rust — можно начинать писать что-то серьёзное. Авторы языка неформально обещают выпустить версию 1.0 в этом году, так что «готовить сани к лету» можно уже сейчас.
Это весьма спорное утверждение. Вы считаете Skylight и ZeroMQ системным программированием? Насколько я вижу, единственное, что мешает Rust потеснить Go в его областях — это существующие библиотеки. В частности, это web-разработка, где прогресс отличный, но до финала ещё далеко (AreWeWebYet).
Я не так хорошо знаком с Java, чтобы проводить полноценный анализ, но уже тот факт, что там все объекты могут быть null, настораживает по поводу безопасности. Можете хоть на минутку допустить мысль о том, что Rust даст Вам больше гарантий надёжности?
Серьёзно, Вы ожидали увидеть другую статью. Как и WerewolfPrankster, Вам нужно полноценное доказательство , что Rust лучше С++ (а также D, Go, и чего бы то ни было ещё). Моя статья же носит исключительно показательный характер, при этом я попытался показать Rust как скрещение С++ с Haskell, что есть сугубо личный взгяд на происхождение языка.
Если Вас не убедило даже заглянуть на домашнюю страничку языка — это бывает. Но вот утверждение, что статья несодержательная, вызывает у меня недоумение. Вы просто искали другое содержимое.
Я пробовал наоборот оттащить кровь от мозга путём физических упражнений перед сном, и это вроде как работает.
Вот уж сэкономили…
1) Заслуженно получили артефакты (не только в SSAO, а во всей геометрии, особенно ближней к камере).
2) Лишились Early-Z при рисовании всей геометрии(!). В Вашей сцене перерисовки пикселов почти нет, так что это не сказывается, но в общем случае — это катастрофа.
Да и сам способ вычисления линейной глубины вызывает сомнения:
Что по-Вашему есть «p.z»? Несомненно, это z-координата, но в каком пространстве? В проективном… а Вам нужно линейное. Правильно было бы так:
А в плане скорости (это ответ автору) — если частоты статические, то можно свести общую сумму к степени двойки при кодировании. В этом случае арифметика будет использовать только битовые сдвиги и умножения, так что медленно уж точно не будет ;)
Если схема статическая — то эти суммы можно просто хранить для каждого элемента. Если динамическая — то мы можем хранить иерархические суммы частот: p0 — сумма от 0 до E/2, p1 — сумма от E/2 до E, p00 — сумма от 0 до E/4, p01 — сумма от E/4 до E/2, p10 — сумма от E/2 до E/4, и т.д. В этом случае нужно дополнительно E*K байт памяти, а поиск отрезка для символа и его обновление будут выполняться зя O(log(E)).
Итого, затраты к памяти: около 2*E*K <= 8*E байт. Асимптотическая сложность кодирования N символов: O(N*log(E)) для динамической адаптации или O(N) для статической. При этом арифметическое кодирование обещат почти оптимальное представление частот, то есть лучшее сжатие, чам любые бинарные деревья.
А какие параметры Вашего алгоритма кодирования?
А потом:
То есть сброшенные американцами бомбы были сравнимы по мощности с теми «гипотетическими» маломощными взрывами, о которых пишет автор. Японцы наверняка изучили досконально, как их города сровняли с землёй. Автор же видимо считает, что это было не на самом деле.
Так и есть. Цель моего коммента — обратить внимание С++ программистов на Rust. Ведь С++14 и C++17 как бы тоже ещё не вышли, так может лучше посмотреть на Rust, чем ждать их?
Давайте не будем скатываться в банальности, никто такого не утверждал.
Вы делаете логически необоснованное умозаключение. Если язык близок к железу — то скорость выполнения будет хороша, это понятно. Но Вы утверждаете обратное (если не близок, то скорость пострадает), что ещё надо доказать:
— обязательные проверки на переполнение буфера в рантайме: огромная часть доступа к индексам массива в С идёт на перечисление. Используя итераторы в Rust, Вы получите один в один с Си машинный код перечисления элементов массива, без лишних проверок. Что же до остальных — есть функция доступа без проверки на выход за границы, если в каком-то конкретном месте это бьёт по производительности. К тому же LLVM, используемся в Rust компиляторе, вполне неплохо исключает лишние проверки.
— избыточные инициализации: во-первых компилятор (и, опять-же, LLVM) достаточно умён, чтобы оптимизировать такие вещи. А во-вторых, Вы видели хоть один проект, где инициализация созданных объектов была проблемой производительности? Я — нет.
— проверки указателей: вся прелесть в том, «плохие» указатели устраняются на этапе компиляции, а не в run-time. Тут работает философия «если оно скомпилировалось, то оно работает», заимствованная из Haskell.
Что-то я не припомню ни одного серьёзного приложения на С--… Вы ничего не перепутали?
А вообще понятно, что они используют, эти системщики. Rust пытается потеснить эту нишу, как, впрочем, и многие другие.
Да, на С++ можно писать надёжный код. Да и на asm можно. Вся суть-то в том, что на Rust это делать и приятнее, и быстрее.
Да и вообще, русская Вики — это Вам не официальная документация. На сайте проекта есть tutorial, manual, API — всё, что душе угодно, притом одновременно и для последнего релиза, и для текущей версии в разработке.
Как только Вы освоили синтаксис и модель памяти Rust — можно начинать писать что-то серьёзное. Авторы языка неформально обещают выпустить версию 1.0 в этом году, так что «готовить сани к лету» можно уже сейчас.