43
Karma
0
Rating

User

Почему я больше не использую современный C++

-1
Примеры, и правда, интересные, но согласитесь, таким подходом много толкового не напишешь. Да и первый пример, фактически, CGI-скрипт. Для полноценного сервера нужно ещё системный API вызвать, сокет открыть, а pshttpd всё же придётся положить под inetd.

Почему я больше не использую современный C++

-1
Всё же неточность: PostScript — язык описания страниц, Tex — язык низкоуровневой разметки в системе компьютерной вёрстки. Язык программирования — всегда инструмент написания алгоритмов. В системах пожарной сигнализации также можно задать алгоритм срабатывания сирены, дозвона, и это называют в быту программированием, хотя фактически является конфигурированием, даже несмотря на то, что в результате получается простейший алгоритм.
Я не говорю, что конфигурирование проще программирования, просто это принципиально разные вещи.

Спасём Firefox

+1
Хочу дополнить. Если на рутрекер это не поставят, то человечество, определённо, спасено ) Сказать по правде, все эти игры «не технарей» менеджеров в попытку обойти «законы физики» кажутся смешными. Я не случайно упомянул об опыте рутрекера.

Но интересно даже другое, что российские компании, продающие фильмы через интернет, нередко сами забирают исходники с трекера, так как правообладатель — нерасторопный мастодонт не в состоянии обеспечить вовремя нужным контентом, им важно быстро заключить договор и взять деньги. Я это всё к тому, что фантазии об исключительно платном интернете некой группы коммерсантов никогда не станут определять, за что я лично захочу платить. Голосуйте рублём. На видео свет клином не сошёлся, я фильмы всё равно только в кинотеатре смотрю, а без подборки «самые смешные котики 2016» уж как-нибудь проживу.

Firefox — респект.

Rust 1.5: Cargo с блэкджеком

0
Это Windows + MSYS2. Раньше использовал VisualStudio, чтобы отлаживать C, всё перенёс на Rust, теперь Win не требуется.

Хотя в Linux всё же удобнее. Например, Ctrl+C не всегда корректно обрабатывается. Если запустить cargo run, прервать выполнение сервера нельзя, приходится в диспетчере отлавливать, потому привык к паре:

cargo build && RUST_LOG=debug ./target/debug/main.exe

Тем не менее сборка и продакшн у меня в EC2 на CentOS. Ни разу не возникли проблемы с переносимостью. Оба варианта компилируются как родные.

Выпущен Rust 1.4

0
Если, действительно, прокачать фишками, то работы для языка побольше, конечно. Тут точно Rust хорошо ляжет. Сам язык/компилятор к продакшн точно готов, а вот во внешних библиотеках слегка будет дефицит функционала, иногда ошибки. До полной практической прокачки лэнда осталось всего месяцев 6-10. Спустя этот период писать будет чуть полегче, но я думаю сейчас самое время испытать все это добро на опережение. На изучение самого языка уходит не мало времени, месяца 2 минимум, при опыте в С, Java, Erlang, хотя поначалу он кажется очень простым, прочитать учебник без перерывов на еду мне удалось ровно за день. Потом долго будет ощущение, что вроде пишите и много пишете, но будто топчитесь на месте. Потом приходит озарение как всё правильно сделано и желание выкинуть всё остальное с GC.

Кстати, а как конфигурируется сервер? Скриптом на мини-языке или конфигом?

Выпущен Rust 1.4

0
Спасибо. Фронт работ в направлении игр, конечно, ещё большой, хотя базовые вещи, действительно закрыты.

Выпущен Rust 1.4

0
Прирост скорости, действительно, спрогнозировать сложно. Но если он был маленький на C, то возможно просто упёрлись в возможности ОС, а прослойка над ней была довольно маленькая. Например, отдавать видео-поток, по скорости примерно все одинаково: nginx = go = python = rust = erlang = с, так как во всех случаях будет использоваться sendfile, и в нём программа будет находиться 70-80% времени. Тут ускорить не получится, к сожалению. С другой стороны в Rust полный контроль над памятью и реально без сегфолтов, это на случай транскодера.

Выпущен Rust 1.4

0
Полностью согласен. В unsafe очень помогло заходить под GDB. Некоторые абстракции работы с кучей довольно хитрые и не всегда очевидно, что под ними лежит. Часто исходный код Rust очень помогает.

Выпущен Rust 1.4

0
В действительности, пока дошли до релиза по ряду вопросов сформировалось мнение, которое иногда отличалось от первого впечатления. Я думаю написание статьи — это хорошая идея, постараюсь найти время.

Выпущен Rust 1.4

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

Есть статистика, сколько FPS удаётся выжать?

Выпущен Rust 1.4

+3
Мы начинали как раз с того, что написали несколько расширений для проекта на Erlang + С. Постепенно проект на Rust поглотил проект на Erlang (на последнем кусок был небольшим). В результате получилась такая штука: чтобы написать хорошее расширение на Rust нужно погрузиться в unsafe, что-то хорошо сделать в unsafe совсем не просто, это не самая комфортная зона языка, придётся много колдовать с Box, Cell, Rc. Rust очень многое хранит в стеке, и тут легко что-нибудь перепутать и потерять данные (язык без GC, всё мгновенно режет, да и в стеке ничего надолго не сохранишь). В зоне unsafe язык просто промолчит и разрешит всё уничтожить.
Другими словами, чтобы хорошо написать расширение пришлось основательно изучить Rust, но изучив захотели попробовать его для всего проекта.

В итоге: в проекте есть прирост по скорости в целых 16 раз. Задача — имитационное моделирование. Много CPU-bound, не так много IO. Может потому и такой прирост. Программа просто стала монолитом на системном языке. На C++ по скорости был бы тот же результат. Но с блэкджеком хотелось…

Выпущен Rust 1.4

0
Игра — это интересно! Пока не удалось опробовать пласт графических и звуковых библиотек. Какие библиотеки используете? Быстро ли работают? Какие есть недостатки в их реализации?

Выпущен Rust 1.4

+1
В продакшене можно и нужно, но пока не всё, например, веб-сервер hyper болеет этим: github.com/hyperium/hyper/issues/368
Проблема вроде бы решена, но просто таймаутом, который и то, добавили недавно в стандартную библиотеку, 10К так не решить. Для последнего есть MIO, который весьма хорош. Драйверы БД тоже иногда болеют багами, но в целом всё можно исправить самому, честное слово, git clone && cargo build и у вас все готово к отладке внешнего проекта. Код всегда строгий и простой, так что проблем разобраться в чужом коде точно не будет.

Выпущен Rust 1.4

0
Согласен! Некоторые другие возможности тоже хочется видеть стабильными (плагины компилятора, например, но это пока всё ещё довольно сырое).

Что касается Result, заметил интересную особенность: если никогда не делать unwrap, код очень выигрывает в качестве, так как приходится явно продумать как Result дойдёт до верхушки стека. Это привело к тому, что код на Rust для меня теперь является эталонным в проекте, все протоколы описаны в нём и я получаю подробнейшее указание, где была ошибка в одном лаконичном сообщении. Скорость решения любой проблемы удивительно высокая. Да, и больше не требуется пугать системных администраторов трассировкой исключений.

Rust попал в индекс TIOBE

+2
Всё верно. Для удобства компилятор даже носит подсказки с собой, их всегда можно посмотреть командой:

rustc --explain E0xxx

Rust попал в индекс TIOBE

+1
Ну вот к примеру, если в двух типажах есть один и тот же тип Output, как конфликт имен разрешить?

Если правильно понял проблему, такие конфликты разрешаются через Universal Function Call Syntax.

Пример (положил в playground):
trait First {
    type Output;
    fn conflict(&self) -> Self::Output;
}

trait Second {
    type Output;
    fn conflict(&self) -> Self::Output;
}

struct Both;

impl First for Both {
    type Output = String;
    fn conflict(&self) -> Self::Output {
        "First<Output=String>".to_owned()
    }
}

impl Second for Both {
    type Output = String;
    fn conflict(&self) -> Self::Output {
        "Second<Output=String>".to_owned()
    }
}

fn main() {
    let its_both = Both;
    println!("{}", First::conflict(&its_both));
    println!("{}", Second::conflict(&its_both));
}

Внутренние типы в примере вполне могут быть разными. А если нужно узнать сам внутренний тип реализации, то так:

<Both as Second>::Output

Rust попал в индекс TIOBE

+21
Если верить правилам оценки язык активно используется в реальной работе:
The TIOBE Programming Community index is an indicator of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. Popular search engines such as Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube and Baidu are used to calculate the ratings. It is important to note that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.

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

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

Или когда я сталкивался отсутствием какого-то биндинга, я просто из голого Rust вызывал нужный мне нативный метод (требовался HDF5 и Lua, хотя их уже покрыли удобными обёртками). Не бывает, в принципе, такого, что библиотека с трудом собирается под Win. Как это бывает в том же Python. Переносимость просто отличная.

При этом компилятор очень хитромудрый, чувствую что пишу на OCaml, если программа скомпилировалась, она на 99% правильно работает. В этом, конечно, помогает монадная обработка ошибок, отсутствие исключений. Ошибки чисто технически нельзя оставить «на потом». Есть, конечно, unwrap, но на нём не уедешь, далеко, и почти сразу его приходится заменить на человеческий код.

В итоге, комфорт и удобство в работе вынуждают меня генерировать море рабочего кода, которым иногда удаётся поделиться, отправив PR. Язык просто лёг к рукам, хотя до этого я очень долго себя убеждал, что люблю сусликов и Go, наклеечки везде клеил…

Что касается убийцы всех и вся, и что якобы у C++ скоро повиснет указатель, то тут очень трудно что-то прогнозировать. Я люблю Rust больше, но по сути это OCaml, в который добавили фигурные скобочки, чтобы народ мог похоливарить. Знание C++ вряд ли серьёзно поможет в изучении, скорее нужен хаскель со штангой.

Rust, дисциплинирующий язык программирования

0
Когда это сделают, я вернусь к изучению Rust и сэкономлю кучу времени

Зачем ждать? Почему бы не принять участие в доработке Rust, если знаете как решить проблему? Там точно всегда рады помощникам. По-моему прелесть Rust как раз в серьёзной ориентации на комьюнити, безо всяких там диктаторов, которых периодически нам навязывает корпорация «добра».

Сравнение скорости обработки данных (ETS, DETS, Memcached, MongoDb) в Erlang (сферическое в вакууме)

0
Использование внутренних механизмов допустимо, а надёжность лучше обеспечивать в традициях OTP — через сегрегацию процессов (храните кэш в несколько слоёв из процессов). Хотя в таком случае выигрыш не факт, что окупит стоимость разработки.

Использование Python в многопоточном приложении на C++ и настоящая многопоточность в Python

+3
Отличная статья, ставлю плюс! Получился такой missing manual по управлению GIL.

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

Помните эпоху распространения Win XP? Уверен, у многих был тогда один процессор с одним ядром. И вы запускали на нём программы, которые, казалось работают параллельно. Фантиастика! Программистам того времени приходилось писать грамотный код, чтобы не «убить» компьютер. А что теперь? Каждый, кто не в состоянии подумать об архитектуре программы, плодит десятки (сотни) потоков, на выполнение любой псевдо-параллельной задачи. Нужно посылать запросы, когда пользователь кликнул мышью, ок, давайте сделаем отдельный поток, который будет стоять 99.999% времени! Спрашивается, зачем? Не жалко ресурсов?! У вас не так много ядер, как выдумаете.

Так вот. GIL учит писать хорошие программы, используя волокна и сопрограммы. Нужно выполнить сложную вычислительную задачу? Используйте CUDA, напишите её на Fortran, или создайте отдельный процесс, разверните задачу в PiCloud. При необходимости используйте межпроцессное взаимодействие и Google Compute Engine. Но не ругайте GIL, только потому, что не пробовали использовать шаблон Reactor и вычислять penalty для приостановки потока.

Взаимодействие интерпретаторов Python-IronPython-Jython

Взаимодействие интерпретаторов Python-IronPython-Jython

0
Всё верно, даю ссылку, это Console2, очень приятная консоль. (Даже прозрачность поддерживает, но отключил для статьи =)

Удобно, что можно много типов вкладок зашить: под все питоны и шеллы. И запускать в одном окне, когда требуется.

Ninja IDE – открытая среда разработки для Python

0
Тоже придерживаюсь такой философии. Долго писал в programmers notepad но Wing устроил так как он не перегружен модулями (yikes!) и питонизируется с ног до головы.
Там даже проекты uniform с произвольной структурой. На проект один файл или можно сразу много файлов проекта создать, например, под разное окружение и задачи. Удобно.

Ninja IDE – открытая среда разработки для Python

0
Из крутых плюшек Wing: удалённая отладка. Можно код прямо на серваке или App Engine стопить.

Ninja IDE – открытая среда разработки для Python

Ninja IDE – открытая среда разработки для Python

0
Жаль, в Windows 7 работало уверенно, хотя юзал всего минут 15. Может что-то не так с Qt? Обновить попробовать…

Ninja IDE – открытая среда разработки для Python

0
Согласен. Но уж очень радует их маркетинг: о простых вещах так хорошо написано, и так красиво нарисовано, что начинаешь верить в чудо )

Генераторы vs классы

0
+1, согласен! генератор должен кормиться непрерывними последовательностями и сразу

Генераторы vs классы

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

Генераторы vs классы

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

Генераторы vs классы

+1
На самом деле мне нужен как раз миллион, а точнее 7. Так как это кусок кода оптимизатора торговых стратегий. Испытать на большом потоке данных ещё предстоит )

Генераторы vs классы

0
Безусловно я не против генераторов! Сам использую их постоянно. Задача статьи — показать, что выбирать генераторы, предполагая, что они очень быстрые, неправильно.

Разворачиваем cron в Windows

Пошаговое руководство к исполняемым файлам (EXE) Windows

-1
Вот еслиб сделали такое про файлы с байткодом Java, Python или .NET, было бы более актуально.

Пошаговое руководство к исполняемым файлам (EXE) Windows

-1
Отличная работа. Но грузится долго… да и в работе мне вряд ли пригодиться )

Делаем standalone exe на IronPython

Делаем standalone exe на IronPython

Делаем standalone exe на IronPython

Делаем standalone exe на IronPython

+1
Могу предположить, что всё дело в философии: Python компилируется только в Python bytecode, который можно прогнать через dis. А если поддерживать технологию компиляции напрямую в байткод виртуальной машины, это усложнит сам проект.

Python, наверное, потому и получил популярность, что развивать его код было просто. Хотя, согласен, компиляция в другой байткод/naive была бы полезна.

Разворачиваем cron в Windows

0
Проблема в удобстве настройки «Вход в качестве пакетного задания», а здесь пароль не поможет (
1 There