加载中

I have been a heavy user and lover of Python since 2011. At that time, when a good friend suggested I ditch Perl (eeek) and try Python instead, an entirely new world opened up to me. A world where readability counted above everything else and an explicit style ruled.

After around 7 years of using Python, I’m just as passionate about it now as I was then. However, as time goes on, one looks for new adventures and challenges. The time has come for me to try another language!

自 2011 年以来,我一直是 Python 的重度用户和爱好者。当时,一位好朋友建议我抛弃 Perl(eeek)并尝试使用 Python 时,一个全新的世界向我敞开了大门。 这个世界的可读性高于其他所有语言,并且明确统一样式。

在使用 Python 大约7年之后,尽管我还和当时有一样的热情,但是,随着时间的推移,人们也在寻找新的冒险和挑战。 现在是我是该尝试另一种语言的时候了!

Python Challenges

Let me start by noting some of the challenges I’ve faced with Python:

  • Packaging: This is one area where most interpreted languages share challenges. Tools such as FPM make it really easy to ship an installable artifact that includes an entire virtualenv, but this still lacks the elegance of a single binary.

  • Static Typing: As someone who started with C++ and absolutely adored it, I do miss the type safety that I was used to from C++. This goes hand in hand with compile-time checks that really helped me ensure my code was of reasonable quality before even being executed.

  • Speed: Once again, a challenge shared by most interpreted languages. Python is fast enough for many tasks, but falls far behind compiled languages.

  • Verbosity: We only got f-strings in Python 3.6, which was truly a big relief. However, we still have extremely verbose self syntax in classes and constructors are littered with self.var = var, which may be partly addressed with data classes in Python 3.7.

  • Implicit Private Class Members: When I say private, I mean private damn it! As a former C++ guy, I found Python’s underscore-prefix style for private attributes and methods a little … hacky? :‘)

Python 的问题

首先,列举我在 Python 中遇到的一些问题:

  • 打包:这方面是大多数解释型语言都会遇到的问题。打包成一个包括整个 virtualenv 的可安装程序,FPM 之类的工具可以让这个过程非常容易,但是它仍然缺少一个单一二进制程序的优雅。

  • 静态类型:就像一些人从开始使用 C++ 到完全喜爱它,我确实怀念我在 C++ 中用过的类型安全。这与编译时检查密切相关,它确实帮助我们保证我们的代码的质量,甚至在执行之前。

  • 速度:大多数解释型语言的又一个问题。Python 对于许多任务都足够快,但是仍然远远落后于编译型语言。

  • 冗长:我们只有在 Python 3.6 才有 f-strings ,它确实是一个解脱。然而,我们在类和结构中仍然有非常冗长的 self 语法,到处都是 self.var = var ,这可能会在 Python 3.7 的数据类中部分解决。

  • 隐式私有类成员:我说的私有就是那该死的私有!作为一个前 C++ 程序员,我发现 Python 的私有属性和方法的下划线前缀格式有一点…变态?:‘)

Further to this, I’m not sure that I really love the direction that Python is taking in a few areas, particularly around async and typing.

  • Coroutines: Although highly welcome, the new async functionality in Python feels very user-hostile and difficult to grasp. Existing code requires a good amount of work before it is made non-blocking too. I think this situation will improve in time as more libraries become available and as I understand and use the new libraries more though.

  • Type Annotations (and mypy): Honestly, type annotations are welcome … if they actually did anything in CPython. The new idea of using type annotations as part of various constructs (e.g. data classes) seems pointless without mainstream support in the main CPython distribution. In the meantime, mypy is not mainstream just yet but shows great promise as a type validator for Python in the future, particularly with the --strict flag enabled.

I should note that I’m still a massive fan and advocate of Python and think it’s still one of the best interpreted languages available today; particularly when you take into account its wonderful ecosystem and maturity.

进一步来说,我不确定我真的喜爱 Python 在几个领域的发展方向,尤其是在异步和类型方面。

  • 协程:尽管大受欢迎,Python 中新的异步方法让人感觉非常不友好而且很难掌握。现有代码在非阻塞之前也需要大量的工作。随着越来越多的库开放使用,以及随着我了解且会使用新的库越来越多,我觉得这种情况会随之改善。

  • 类型注解(和 mypy ):说实话,类型注解很受欢迎…如果他们真的在 CPython 做了什么的话。如果没有主 CPython 发布版本主流支持的情况下,使用类型注解作为各式结构体(如数据类)这种想法看起来毫无意义。与此同时,mypy 目前还不是主流,但长远来看,作为一个 Python 类型校验展示了巨大的潜能,特别是在将 --strict 标识开启的时候。

我应该说明我仍然是 Python 的忠实粉丝和支持者,而且认为它仍然是当前最好的解释型语言之一;特别是当你考虑到它惊人的生态系统和成熟度。

What I’m Looking For

My starting point is really Python and Ruby. I’ve used Ruby from time to time where it was needed and really love it too. Ruby solves several problems that Python has (proper private/protected attributes, less verbose syntax .etc) but still suffers from performance problems and lacks static typing.

As such, I started looking for a new language with the following features:

  • Similar syntax to Python and Ruby

  • Single-binary distribution

  • Compiled, statically typed and fast

  • Object-oriented (oh classes, how I love you…)

我在寻找什么

我的出发点是 Python 和 Ruby 。 我经常在需要的地方使用 Ruby ,也非常喜欢它。 Ruby 解决了 Python 所具有的几个问题(适当的私有/受保护的属性,较少冗长的语法等等),但仍然存在性能问题,并且缺少静态类型。

因此,我开始寻找具有以下特点的新语言:

  • 与 Python 和 Ruby 类似的语法

  • 单二进制分发

  • 编译,静态类型和快速

  • 面向对象(哦类,我多么爱你......)

Candidates

The following languages were ruled out:

  • Go: No keyword arguments, no exceptions, no classes, no generics and awful naming styles all led to me saying no to Go (although perhaps this simplicity is what attracts many to it). I have actually spent quite some time learning and coding in Go and found it frustrating at best. A language like C++ had made many advancements after C and offered us far greater flexibility yet it feels as though Go is taking us back to the days of C.

  • Elixir: A fascinating functional language, but lack of OO features and the fact that a single binary distribution is not the target of this language is a bit of a bummer for my use case. However, various folks in my team use Elixir as their primary language for all new projects and have found it great in use. Elixir has a rich and proven legacy and should definitely be considered if a functional language is what you’re after.

  • Rust: This is an interesting language that I have spent some time attempting to learn. Really, I just feel that Rust is not aimed at my use case; it is a rather complex language that just doesn’t seem to click with me and many others too.

  • Julia: This language is really targeted more for scientific computing as opposed my use case. It also lacks the OO abilities that I’m after.

  • Pony: A very fascinating language that seems to borrow a lot from Python, however it also borrows some things I dislike (e.g. underscore prefixed variables, lack of symmetry .etc). I generally didn’t feel that Pony aligned with the way I think nor did it have the same traction as other languages making it rather primitive currently.

候选项

下列语言被排除在外

  • GO:没有关键字参数、没有异常、没有类、没有泛型以及命名风格的可怕,这些都导致我拒绝了Go(尽管也许这种简单性吸引了很多人)。我实际上花了相当一段时间在 Go 的学习和编码上,我觉得这是最令人沮丧的。在 C 之后,像 C++ 这样的语言已经取得了很多进步,并为我们提供了更大的灵活性,但感觉 Go 似乎让我们回到了 C 语言的时代。

  • Elixir:一种引人入胜的函数式语言,但缺少面向对象的功能,以及单个二进制分发不是此语言的目标的事实对我的用例来说有点失望。然而,我们团队中的许多人将 Elixir 作为他们所有新项目的主要语言,并且发现它在使用中非常出色。Elixir 拥有丰富且可靠的传统,如果你想要一种函数式语言,你一定要考虑它。

  • Rust:这是个有趣的语言,我花了一些时间尝试学习。真的,我只是觉得 Rust 并不对症于我的用例。这是一种相当复杂的语言,我和其他很多人似乎都不喜欢它。

  • Julia:这种语言实际上是针对科学计算的,而不是我的用例。它也缺乏我想要的面向对象能力。

  • Pony:一种非常吸引人的语言,似乎借鉴了很多 Python ,但也借鉴了一些我不喜欢的东西(例如,强调前缀变量,缺乏对称性等)。我大体上感觉 Pony 与我的想法不一致,认为它不具有与其他语言一样的吸引力,这使得它现在相当原始。

Some languages that I’m really interested in and hope to examine further in the future are:

  • Nim: Nim was originally the front-runner as my next language and one which I hope to spend more time on in the future.

  • Swift: Another popular object-oriented language that definitely deserves attention beyond development of iOS and Mac apps.

But ultimately, I decided to commit to learning Crystal!

The reasons are as follows:

  • Crystal feels immediately familiar as it mostly follows Ruby’s syntax

  • It compiles into a fast, single executable

  • The entire standard library is written in Crystal which makes it very easy to read when required

  • It offers a full object-oriented approach similar to Ruby (which includes real protected and private members)

  • Crystal uses static typing but also provides unions (ability to define a variable that can be of multiple types)

  • It offers the ability to develop DSLs similar to Ruby (which is something I’ve always been interested in)

  • Bindings to C libraries are fully native and written in Crystal (similar to ctypes in Python, only better)

我真正感兴趣并希望在未来进一步研究的语言有:

  • Nim:Nim 是最初我准备用来领跑的下一个语言,我希望将来能花更多的时间来研究它。

  • Swift:另一种流行的面向对象语言,除了开发 iOS 和 Mac 应用程序外,绝对值得关注。

但是,最终,我决定致力于学习 Crystal !

原因如下:

  • Crystal 很快就能熟悉,因为它大部分遵循 Ruby 的语法

  • 它编译成一个快速、单一的可执行文件

  • 整个标准库都是用 Crystal 编写的,可以在需要时很容易阅读

  • 它提供了与 Ruby 类似的完全面向对象的方法(包括真正的受保护的和私有的成员)

  • Crystal 使用静态类型,但也提供了联合(能够定义可以具有多种类型的变量)

  • 它提供了开发类似于 Ruby 的 DSL 的能力(这是我一直感兴趣的)

  • 与 C 库的绑定完全原生,并且以 Crystal 编写(与 Python 中的 ctypes 类似,只不过更好)

Caveats

Crystal is a very young language that still hasn’t hit 1.0. It often introduces breaking changes in releases and has limited libraries.

However, I plan to only use this language in my personal projects and was willing to become an early adopter due to the fact I feel that the language has enough promise to be worth using.

注意事项

Crystal 是一个非常年轻的语言,仍然没有发布 1.0 版本。它通常会在版本中引入重大更改并且限制库。

不过,我打算仅在我的个人项目中使用这种语言,并且愿意成为早期使用者,因为我觉得这种语言有足够的前景值得使用。

Experiences

Standard Library

The entire standard library is extremely easy to read and is something I reference all the time. The library also seems moderately extensive and is a great base to work with.

Here’s an example of the addition of arrays:


And here’s the function that obtains the extension of a file:


If you choose to try out Crystal, ensure you keep its source right by your side; it’s incredibly valuable and useful.

经验

标准库

整个标准库非常容易阅读,我一直在引用它。库似乎也有一定的广泛性,是一个很好的基础教程。

以下是添加数组的示例:

这里是获取文件扩展名的函数:

如果你选择尝试 Crystal ,请确保让它的源码待在你身边; 它非常有价值和有用。

Binding to C Libraries

It’s amazing how easy this is!

Here’s an example of a binding to various functions that obtain user information from a Unix system:


Exception Handling

Similar exception handling is provided to both Ruby and Python:


Writing your own exceptions is trivial; simply inherit from the Exception class.

绑定到 C 库

这真的太神奇了!

下面是一个绑定从 Unix 系统获取用户信息的各种函数的例子:

异常处理

类似的异常处理提供给 Puby 和 Python :

写你自己的异常很简单;只需要集成 Exception 类。

Import System & Namespaces

This was a bit of an adjustment coming from Python, but really brought me back to C++ days as Ruby follows a similar method to C++.

C++ namespaces are equivalent to Ruby/Crystal modules which you can define yourself. Requiring any library will import all items that it defines, so it’s always ideal to ensure that your entire library is contained within a module to avoid namespace pollution.

Initially I was a bit concerned about this, but I find it liberating being able to easily build up a module from any number of files. However, I will admit that it makes finding where things came from more of a challenge.


导入系统和命名空间

这是来自 Python 的一些调整,但是因为 Ruby 遵循类似 C++ 的方法,把我带回到了 C++ 时代。

C++ 命名空间等同于你可以自定义 Ruby/Crystal 模块。要求任何库将导入它定义的所有项目,因此它总是完美的保证了你的整个库包含在模块中,以此来避免命名空间污染。

起初我还有点担心,但我发现它可以从任意数量的文件中轻松建立一个模块。然而,我得承认,找到事物的来源更像是一种挑战。

返回顶部
顶部