Приближение выхода Rust 1.0

Судя по записи в официальном блоге Rust, ожидать выхода Rust 1.0 осталось всего ничего:

We plan to ship the 1.0 beta around the end of the year.

Что на мой взгляд просто отличная новость! А дальше еще интереснее:

After 1.0 is released, future 1.x releases will be backwards compatible

Что недвусмысленно намекает на то, что разработчики языка Rust куда более вменяемые по сравнению с разработчиками D. Как следствие, возлагаемые на язык надежды в плане использования в промышленной среде становятся все более и более оправданными.

А вот заключительное утверждение:

In many ways, Rust 1.0 is not so much an endpoint as it is a starting point.

Напоминает мне шутку о том, что C++ разработчики скоро разделятся на две группы: те кто успел выучить язык до выхода C++17 и те кто уже не выучит %)

На что бы заменить Python?

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

Плюсы

В качестве главного плюса этого выбора выступает простота самого языка и, как следствие, требованию к уровню разработчика необходимого для вхождения в проект очень низкие.
Динамическая природа языка способствует экспериментам в REPL и облегчает поиск оптимального решения.
Язык очень емкий, что сильно сокращает объем код и позволяет в пару строк написать очень не тривиальные для многих других языков вещи.
Огромное количество библиотек на все случаи жизни позволяет сосредоточиться на задаче, а не инструменте.
Ряд отличных IDE, например PyCharm, сильно облегчают разработку. Continue reading

Миграция с Vim на Emacs

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

0509_Hacking Vim 7.2covТак что, я решил в дальнейшем использовать Vim исключительно для правки небольших текстов и конфигов, благо в любой *NIX системе он есть “из коробки”, а для чего-то большего использовать Emacs. Помня о том, что в стародавние времена мне очень сильно помогла книга Hacking Vim, я начали искать что-либо не менее полезное про Emacs.

lrgК сожалению, на практике быстро выяснилось, что чего-то на столько же выдающегося про Emacs никто не написал. Тем не менее, достойная книга есть, это – Learning GNU Emacs, 3rd Edition. Ее нельзя назвать на столько же интересной и полезной, т.к. в ней маловато информации обо всяческих трюках но в любом случае очень достойно. В итоге довольно быстро дочитал до раздела про ELISP, и бросил, т.к. вроде все понятно и удобно стало. Как захочу улучшить конфиг собственными функциями – дочитаю

Если захотите научиться пользоваться Vim либо Emacs, очень-очень рекомендую эти книги. Не так страшен черт, как его малюют, а удобств ну просто море

Заметки везде и всегда

Screen Shot 2014-05-26 at 21.31.15  Это удивительно, но Microsof таки сумел выпустить продукт, который не хочется немедленно развидеть! По началу я хотел было написать про два продукта, так как на первый взгляд OneDrive очень не плох. Но это только на первый взгляд, а на практике OneDrive отказался синхронизировать мои файлы, как это не прискорбно, но Майкрософт продолжает штамповать откровенное говно. Continue reading

Как бороться с динамической типизацией?

Я довольно часто писал на Python какие-то вспомогательные вещи, иногда сравнительно крупные, но почти всегда не знание типа объекта с которым работаешь было не критичным. Плюс возможность разрабатывать в IPython сильно облегчала жизнь. И так было до тех пор, пока я не решил плотно использовать Twisted. И оказалось что в IPython не попишешь нормально, а занание типов параметров в функциях обратного вызова и классов из обширного становится необходимостью.

И вот тут то я оказался в неком тупичке. Есть большое количество разнообразных классов со сложными интерфейсами. Перепробованные IDE (Eclipse, PyCharm и даже Emacs) не позволяют воспользоваться автодополнением в незнакомых им классах, что логично. В результате, весь код начинает выглядеть как пример ниже.

def _call_later(self, request):
"""
тут какое-то описание функции
@param request: тут какое-то описание параметра
@type request: Request (1)
"""

Да, безусловно, указывать 1 для каждой из создаваемых функций типы передаваемых параметров это решение, только оно выглядит как откровенный костыль. В итоге, у меня создается ощущение, что я как-то не верно использую этот замечательный язык… Что не так? Как с этим жить? Наиболее подходящим вариантом выглядит то, что все помнят параметры у API наизусть, я же вполне могу писать на C++ с подстановкой параметров исключительно из открытых файлов.

Разбитые надежды или просто непонимание?

В одной из лекций с PyCon US 2014 проскочила очень заинтересовавшая меня информация о том, что с Python 3.3 CPython поддерживает оптимизацию для классов, и старый вариант использования Python, когда класс могли просто заменить на Dict не верен в корне, т.к. Dict не поддерживает никакой типизации. Вроде все верно и логично: никак не ограничиваемый по данным ассоциативный массив против класса, в котором можно предсказать используемые типы и количество полей. Continue reading

Rust 0.10

Сегодня вышел, на мой взгляд, интереснейший релиз Rust 0.10. Ломающих изменений в нем не очень много, зато был проведен просто грандиозный рефакторинг: две основные библиотеки libstd и libextra были разделены на полтора десятка библиотек “одной функции” в процессе чего libextra перестала существовать. Это хорошо в первую очередь тем, что появилась реальная возможность начать использовать Rust практически в пределах libstd (все же необходимо еще немного порезать libstd для отключения работы с задачами), а не только самого компилятора, на низком уровне, к примеру в драйверах. Сейчас как раз занимаюсь подобным экспериментом, выглядит ну очень заманчиво!

Ну, все изучать Rust!

Быстро разобраться в новом проекте

Довольно часто возникает необходимость разобрать новый большой проект и не совсем очевидно с какой стороны подступиться к огромной горе исходных кодов которая свалилась на вас. Если вам повезло и проект написан на C++, C, Objective-C, Python, Java, PHP, C#, Фортран или VHDL то простое решение есть – Doxygen + GraphWiz.

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

В качестве примера я решил взять LLVM с размером исходного кода около 12Мб. На построение документации ушло около 2 минут, что, конечно, не мало, но с учетом однократности подобной операции совершенно не критично. Continue reading