comment 0

First thoughts about the Rust language (Part 1/2)

rust-logo-128x128-blk-v2Since I heard a presentation about the Rust Language (actually, read it on Linuxfr), I’ve became really interested in this new language. It have lot of good promises and if it does so properly, I hope it will become my main programming language.

I’ve switched from being a C++ developer to a Python developer, earlier this year. And I have to admit I’m quite satisfied with Python. One can build a good software with it, and I found it learning curve quite smooth. Use with a proper IDE, learning it was very pleasant.

However, I’m mainly a system programmer, and I like having control on what I do. Python does things properly and transparently, but it has some major designs flaws. I’m talking about the official interpreter, and not one of the cutting edge, unvalidated, uncompatible with major modules, that can be found on the web. So these major design flaws are:

  • Garbage collection: I never really understand why people a jumping on the “everything should be garbage collected” paradigm. I don’t like GC. I don’t want GC. I know when I initialize a variable and I know when I need to delete it. Once my dialog box is close, I want to be sure all the resources that was allocates inside are not free. These variables may not have been zeroed but I want to have them disposed for 0 cycle. That the reason I really hate Java (not Dalvik, which seems to be “Java done properly”). I also don’t want to invest time in learning languages like D or Go.
  • Multithreading: If you want to do multithreading in Python, you have to directly go multiprocess. That is simply not acceptable. The main reason is the Global Interpreter Lock, which seem to be too complex to paralelized it correctly. So even if you write multithread code in Python, you will have so much penalty when executing them you will regret your choice. That is a shame, but this wont change in a near futur. Ok, interpreters like Pypy might do the job, but they are still experimental and thus cannot be used in a production server.
  • Slowness: OK, Python is not really fast. It could be acceptable if there wasn’t simple optimizations that could have been done while aren’t. The generated code could be much faster. For unknown reasons, these basic optimizations are not done. Like inlining simple functions, removing unneeded calls, avoiding unneeded variable association,… And if this requires a “run a little compiler to generate the faster *.pyc ” files to be run first, I think this is a cost most developers might accept to have.
  • agressive programming, or the “traceback” symptom. In Python, we are pushed to do aggressive programming. This mean you expect each methods to receive its data correctly. You may write some assume statements if you want, but if your software cannot handle some situation, just let it raise this exception. Because the trace is self explaining! You end up, when programming in Python, dealing with these traceback over and over. And that absolutely not user friendly. I even had lot of discussion with my collegues when I wanted to catch one exception and print a proper error message to the user. That is simply NOT “Pythonic” to write a bunch of tests inside each method to check that the input data are properly formatted. Just let it crash, you just have to write a general  except  statement that will receive every exception and present it one way or another to the user. I’m used to do defensive programming, in C++, where crash may costs of money. I write each function like if I can receive bad data from the outside world. Never trust other people. and by the way
  • Exception everywhere. I hate exception. I never liked them in C++, but in Python, even if they are a bit sexier, you don’t know when and where you can receive an which exception. Some method raise because of an inner call, if you don’t catch them properly… it crashes! Python doesn’t enforce to properly declare which exception a method can raise, and it all exception are properly handle. That’s absolutely ugly. On the principle, exceptions are good, and make the developer’s life easier at the beginning, but this makes the program very difficult to maintain over the time. Simply forget about exceptions, please.
  • why the hell len isn’t a method? while join  is?
However, with rigor and following a good coding style, one can write very beautify Python code, very flexible and extremely easy to maintain all over the year. And that’s very important nowadays, more than just “writing the fastest code”

So I read this news about the new version of the Rust language and I read the magical lines:

  • On demand Garbage Collector. Yes. You want GC you can have it. You don’t want, you don’t have to use it it.
  • Task oriented programming. Like Goroutines, you can start small tasks to be done on another processor, if available. Launching small tasks become the basis and that is very clever.
  • true immutability. If you already have to deal with the  const  keyword in C++, and if you really wanted to enforce immutability of variable that should not be modified whatsoever, you already know which mess we can have. All variables are immutable by default in Rust, and you need to be explicit on which can be modified or not
  • Strongly typed. I’m not a big fan of strong typed languages, but in Python, if you have to cover the lack of type check but write the unit tests. Lot of unit tests.
  • No exception. Faults are handled at tasks level, which result in you program NOT to crash. Simply the current task. Whaou !!

So I decided to give a try and cloned the latest version and compile it on both my Linux and Mac computers.

Next part will cover the writing of a simple library with it’s unit tests, documentation and packaging. The very syntax of the language will NOT be evoked yet.