Could Nim Replace Python?

Could Nim Replace Python?

  • 1936

Could Nim Replace Python .Though Nim is certainly a really cool, and even useful language, I highly doubt that a “ Python takeover” is imminent. Nim has a fraction of an ecosystem in comparison to Python, and furthermore would require a lot more work to get up to the grounds of Python,

Introduction

For many years now, no programming language has been better suited for scripting than Python. Python is an interpreted language written in the late 1980s by Guido Van Rossum written in the language C. Van Rossum, like many other famous Computer Scientists, is from the Netherlands, where he wrote Python from within Centrum Wiskunde & Informatica, or in a rough English translation,

National Research Institute for Mathematics and Computer Science

Python has massive benefits of traditionally lower-level languages that populated computers at the time, such as C, FORTRAN, BASIC, C++, and Lisp. Firstly, Python’s syntax is far more simple and easy to grasp. This makes Python perfectly usable by end-users to perform required tasks around their system. Additionally, though Python is widely considered “ slow” by today’s standards, in 1989 it was quite a feat to have a language that reads like English be even remotely as performance packing to its competitors.

This is image title

Python

Even more recently,

Python and the jobs that correspond with its popularity have overtaken “ the big boys” with Python becoming more popular than both Java, as well as Javascript. Python’s ecosystem is absolutely exceptional, not only in regards to programming in general but also very much in regard to the ever-expanding market of

This is image title

With Python’s growth in popularity, the flaws and problems with the languages have become more and more prevalent. Though Python is certainly a great language, it’s speed, which I touched on earlier is its

Though this isn’t to say that Python is not still viable for machine-learning, there certainly are some performance benefits to be had with a change from the most popular statistical language on Earth. This is also not necessarily Python’s fault, as the language has been developed for machine-learning only because of its sheer popularity. For most applications, Python works marvelously; but this can often change whenever many observations are loaded. For this reason, Scala is typically selected as the language for driving big-data inside of corporate America. Scala is not without its issues as well, although Scala certainly has a better ecosystem than the other two competitors,

Introducing: Nim

This is image title

Despite the similarities between both Nim and Python, Nim is significantly younger than Python, being rendered just 12 years ago in 2008. To this arises some significant advantages to Nim. Firstly, Nim is faster than Python while still being interpreted by the same language, C. Though Nim is technically run with an interpreter, it should be noted that Nim also has its own compiler. That being said, there are lots of cool features that make Nim a great potential replacement for Python that you might not have expected.

Compiled Executables

A common theme with Python is requiring Python in order to run Python, and this includes an application’s dependencies. This is problematic because it means that Python applications to be packages in one way or another with said dependencies. On top of that, it’s very likely that virtual environments will be frequented. While this isn’t terrible, and to confess most statistical languages do exactly the same, Nim does this significantly better by packaging an executable with the included dependencies needed to run. This not only makes managing dependencies from system to system a breeze, but also makes deployment

EASIER than Py (see what I did there?)

These compiled executables are also compatible universally across the Unix-like systems, Linux, Mac, and Berkley Software Distribution, but also the Windows NT kernel. Compiled executables take care of dependency issues and make it incredibly easy to publish an application, or even deploy an API with a simple “.” or “source” command.

Universal

Nim has a serious advantage to Python in that not only is Nim capable of being compiled in C, but also C++, and more excitingly:

Javascript

This means that not only does Nim have the potential to fill Python’s role as the scripting language that runs the data-based back-ends of the web, but Nim can also be used as a front-end similarly to Javascript. This is a huge benefit over Python. While Python is certainly great for deploying endpoints, and often does the job fine, having single-language fluidity across the board certainly has its advantages!

Features

Nim’s code-base is primarily structured on the functional paradigm. This means that Nim can be a very expressive language, and furthermore can easily implement far more cool features than Python can. One of these features is one of my favorite features of all-time to be implemented into programming back in 1958 with the release of Lisp,

macros.

This is image title

I will never understand why this is Lisp’s mascot, src = Common Lisp)

Macros and meta-programming have been around for nearly as long as computing itself, and can be very useful, especially on the grounds of machine-learning.

Speed

It’s no secret that as scale goes up, using Python for everything can be very problematic. This is because many training algorithms utilize a recursive Cost or Loss function that is intensive to run for any language. There are lots of languages and ideas with the intent to counter-act this, such as Julia, Python In Python (that’s a rabbit hole in and of itself), and more successfully: Cython.

With these solutions, however, come their own problems as well. Though Julia, which is, in fact, my favorite language, and likely the most apt to be a replacement for Python, does not have anywhere near the ecosystem that Python flaunts. Though there is a PyCall.jl, typically performance when using it dips below that of Python’s, and in that case,

why not just use Python?

Python in Python is an interesting concept, but has yet to see great implementations, as the concept itself is quite complex. Even worse, Python in Python is much more difficult to implement than a solution like Julia or Nim. As for Cython, contrary to popular belief, Cython does not work universally, and relying on it probably isn’t a good idea (been there, done that.)

Nim has the advantage of being faster than Python. For scripting, Nim’s added speed could certainly change the way that system-maintenance and various scripts are run. Using Nim might not be as fast as Julia, or C, but with the simple similarity to both Python and Bash that it boasts, it could certainly be a lot easier.

Conclusion

Though Nim is certainly a really cool, and even useful language, I highly doubt that a “ Python takeover” is imminent. Nim has a fraction of an ecosystem in comparison to Python, and furthermore would require a lot more work to get up to the grounds of Python, leaving it in somewhat of a limbo among the other programming languages. Though Nim certainly has features that outshine Python’s, it’s hard to argue with an established library of packages that everyone knows how to use.

I think Nim’s story is one similar to Julia. Nim is a beautiful language that is both expressive, easy, and efficient, but without a stable back-end, I consider it unlikely that Nim will ever become top-dog in the scripting and more importantly to me: statistical world. But all of this isn’t to say that Nim isn’t a valuable language to learn. Nim is a super cool, easy to use and fast high-level and functional programming language. Anything that combines all of those words is most likely beneficial to your programming toolbox.

Though Nim might not be the world’s next big thing, I’ve certainly been enjoying the time I’ve been spending with it. What’s more exciting to me is the potential that Julia shows, as opposed to Nim, and with a little more development, I think we could certainly increase the speed of ML as we know it. In this regard, the analogy of a processor certainly fits: in years past there was no processor with 64-bit registries, no processor with a clock speed above 1 GhZ (a total slug by today’s standards.) The future is exciting, and I simply can’t wait to see what technology stack it will include.