Я являюсь пользователем и энтузиастом Python с 2011 года. В то время друг предложил мне попробовать Python вместо Perl, и передо мной открылся целый новый мир. Удобочитаемость важнее всего остального в этом мире, и существует четкое эмпирическое правило.
Даже после 7 с лишним лет использования Python мой энтузиазм по отношению к нему остается таким же сильным, как и прежде. Однако по прошествии лет настало время для всех искать новые возможности и приключения. Время попробовать другой язык!
Другие переводы (1)Проблемы с Питоном
Во-первых, перечислю некоторые проблемы, с которыми я столкнулся в Python:
-
Бэйл: Этот аспект является проблемой для большинства интерпретируемых языков. упакован в установочный файл, который включает в себя весь virtualenv,FPMТакие инструменты, как могут сделать этот процесс очень простым, но ему все еще не хватает элегантности одного двоичного файла.
-
статический тип: Подобно тому, как некоторые люди переходят от начала использования C++ к полной любви к нему, я скучаю по безопасности типов, которую я использовал в C++. Это тесно связано с проверкой во время компиляции и действительно помогает нам гарантировать качество нашего кода еще до его выполнения.
-
скорость: еще одна проблема с большинством интерпретируемых языков. Python достаточно быстр для многих задач, но все же сильно отстает от компилируемых языков.
-
длинный: У нас есть только f-строки в Python 3.6, это действительно облегчение. Тем не менее, у нас все еще есть очень подробный синтаксис self в классах и структурах с self.var = var везде, что может вызвать проблемы вКлассы данных для Python 3.7частично решен.
-
Неявные частные члены класса: Я имею в виду, что личное это чертовски личное! Как бывший программист C++, я нахожу формат префикса подчеркивания для частных свойств и методов Python немного... извращенным? :')
Идя дальше, я не уверен, что мне действительно нравится направление, в котором Python движется в нескольких областях, особенно с точки зрения асинхронности и типов.
-
сопрограмма: Несмотря на свою популярность, новые асинхронные методы в Python кажутся очень недружественными и трудными для понимания. Существующий код также требует большой работы, прежде чем он станет неблокирующим. Я думаю, что эта ситуация будет улучшаться по мере того, как будет становиться доступно все больше и больше библиотек, а также по мере того, как я буду узнавать и использовать все больше и больше новых библиотек.
-
Типовые аннотации (и mypy ): Честно говоря, аннотации типов популярны... если они действительно что-то делают в CPython. Идея использования аннотаций типов для различных структур (например, классов данных) кажется спорной без основной поддержки в основном выпуске CPython. Между тем, mypy еще не стал мейнстримом, но в долгосрочной перспективе показывает большой потенциал в качестве средства проверки типов Python, особенно когда включен флаг --strict.
Я должен заявить, что я по-прежнему являюсь большим поклонником и сторонником Python и считаю, что это по-прежнему один из лучших интерпретируемых языков, особенно если учесть его потрясающую экосистему и зрелость.
что я ищу
Моя отправная точка — Python и Ruby. Я часто использую Ruby там, где он мне нужен, и мне это нравится. Ruby решает несколько проблем, которые есть у Python (правильные закрытые/защищенные атрибуты, менее подробный синтаксис и т. д.), но по-прежнему имеет проблемы с производительностью и не имеет статической типизации.
Поэтому я начал искать новые языки со следующими характеристиками:
-
Аналогичный синтаксис для Python и Ruby
-
единый бинарный дистрибутив
-
скомпилированный, статически типизированный и быстрый
-
Объектно-ориентированный (о классы, как я вас люблю...)
Кандидат
Следующие языки исключены
-
GO: Никаких ключевых слов, исключений, классов, дженериков и ужасного стиля именования, из-за которого я отказался от Go (хотя, возможно, эта простота и привлекает многих). На самом деле я потратил довольно много времени на изучение и кодирование на Go, и я нахожу это самым разочаровывающим. После C такие языки, как C++, прошли долгий путь и дали нам больше гибкости, но кажется, что Go возвращает нас во времена C.
-
Elixir: привлекательный функциональный язык, но ему не хватает объектно-ориентированных функций, и тот факт, что единый бинарный дистрибутив не является целью этого языка, немного разочаровывает мой вариант использования. Тем не менее, многие в нашей команде используют Elixir в качестве основного языка для всех своих новых проектов и считают его превосходным в использовании. Elixir имеет богатое и солидное наследие, и если вам нужен функциональный язык, вам определенно стоит его рассмотреть.
-
Rust: Это интересный язык, который я потратил на изучение. На самом деле, я просто не думаю, что Rust подходит для моего случая использования. Это довольно сложный язык, и мне и многим другим он, похоже, не нравится.
-
Julia: Этот язык на самом деле предназначен для научных вычислений, а не для моего варианта использования. Ему также не хватает объектно-ориентированных возможностей, которые мне нужны.
-
Pony: очень привлекательный язык, который, похоже, многое позаимствовал у Python, но также и некоторые вещи, которые мне не нравятся (например, акцент на префиксных переменных, отсутствие симметрии и т. д.). Обычно я чувствую, что пони расходится с моим мнением о том, что он не так привлекателен, как другие языки, что делает его сейчас довольно примитивным.
Языки, которые мне действительно интересны и которые я хотел бы изучать дальше в будущем:
-
Nim: Ним — это следующий язык, который я собираюсь использовать для руководства, и я надеюсь посвятить ему больше времени в будущем.
-
Swift: еще один популярный объектно-ориентированный язык, который определенно заслуживает внимания в дополнение к разработке приложений для iOS и Mac.
Однако, в конце концов, я решил посвятить себя изучению Кристалла!
Причины следующие:
-
Crystal быстро знакомится, так как в основном следует синтаксису Ruby.
-
Он компилируется в быстрый единый исполняемый файл
-
Вся стандартная библиотека написана на Crystal и может быть легко прочитана при необходимости.
-
Он обеспечивает полностью объектно-ориентированный подход, аналогичный Ruby (включая настоящие защищенные и закрытые члены).
-
Crystal использует статическую типизацию, но также предоставляет объединения (возможность определять переменные, которые могут иметь несколько типов).
-
Он дает возможность разрабатывать Ruby-подобные DSL (что меня всегда интересовало).
-
Привязки к библиотекам C полностью нативны и написаны на Crystal (аналогично ctypes в Python, только лучше).
Меры предосторожности
Crystal — очень молодой язык, и его версия 1.0 еще не выпущена. Обычно он вносит критические изменения в релизы и ограничивает библиотеку.
Тем не менее, я намерен использовать этот язык только для своих личных проектов и хотел бы стать его первопроходцем, так как я чувствую, что язык имеет достаточно перспектив, чтобы его стоило использовать.
Опыт
стандартная библиотека
Всю стандартную библиотеку очень легко читать, и я постоянно на нее ссылаюсь. Библиотека также кажется несколько обширной и является хорошим базовым учебным пособием.
Вот пример добавления массива:
Вот функция для получения расширения файла:
Если вы решите попробовать Crystal, обязательно сохраните его исходный код, это очень ценно и полезно.
Привязать к библиотеке C
Это действительно потрясающе!
Ниже приведен пример связывания различных функций для получения информации о пользователе из системы Unix:
Обработка исключений
Аналогичная обработка исключений предусмотрена для Puby и Python:
Написать собственное исключение просто: достаточно интегрировать класс Exception.
система импорта и пространство имен
Это небольшая поправка по сравнению с Python, но поскольку Ruby следует подходу, подобному C++, это возвращает меня во времена C++.
Пространства имен C++ такие же, как вы можете настраивать модули Ruby/Crystal. Требуется, чтобы любая библиотека импортировала все элементы, которые она определяет, поэтому всегда гарантируется, что вся ваша библиотека будет включена в модуль, что позволяет избежать загрязнения пространства имен.
Сначала я немного волновался, но мне было легко собрать модуль из любого количества файлов. Тем не менее, я должен признать, что поиск источника вещей является более сложной задачей.