I have read this thread with pleasure and I find the analysis very accurate.
I would like to add something since I am the main developer behind Viper.
Instead of pointing out the technical differences between Viper and MicroPython, I would like to
highlight the "philosophical" ones.
The main difference is the target audience Viper has been developed for. If they had asked me to write a Python implementation for microcontrollers, I would have said "Hey, there's already MicroPython out there and it's extremely good". Instead, they asked me to solve a problem: build a series of tools to increase the number of people that can use microcontrollers for their job without being programmers. There are engineers, designers and artists that are not interested in the intricacies of C, don't want to know why memory must be allocated and deallocated, tremble in fear in front of a volatile variable. They just want their prototype and product to work.
A survey was made and Python selected as the more appealing language for such people. Most of them already used it for web interactions or advanced math. Another survey was done to research the biggest obstacles for these people to enter the embedded world. Just to name a few:
- the Arduino C model of one big loop: doing more than one thing with fake concurrency is a nightmare.
- the lack of uniformity between boards: if, by chance, the selected board is not good enough for a project, selecting another one generally means to code again with a different toolchain
- the lack of an easy to use IDE
- the difficulty in making a board connected to the internet
I hope to have made my point clear: Viper isn't born to be "real Python" as much as Android wasn't born to be "real Java". Actually, Viper hopes to be for the embedded world what Android has been for the mobile.
I also find the remark of pfalcon about Exceptions very interesting. Yes, Viper doesn't have full support for Exceptions. A Viper exception is not an instance, it has no methods, but it has a traceback and info about the bytecode location where it happened. Again, is a matter of target: people from the Arduino world are not programmers, usually discover their bugs when everything hangs and do debug by printf. I saw many of our alfa testers jump on their chairs when they understood that if something bad happens between a try-except it's not the beginning of a unfruitful day of debugging.
Finally, ChibiOS. Viper has been designed to be loosely coupled to an underlying RTOS and can be used on top of any other RTOS that provides threads with priority, mutexes and semaphores. In the near future Viper will be usable on top of the mbed OS by ARM or FreeRTOS or others, it will depend on the market choice. It is just that ChibiOS, in my opinion, was the best choice both in terms of resources needed, performances and code elegance. Its lack of support for less than 32-bit platforms was not an issue: I believe that in the near future 32-bit microcontrollers will become mainstream providing orders of magnitude of performance (hey, the M7 is dual core!) at a fraction of the cost of an Arduino.
Sorry for the long post, I really appreciate to be a guest of this forum.