Haha, I just displayed the smallest I've tried myself. Nim runs just fine an the ATTiny85 with 4K available program memory and 512bytes of RAM with room to spare, so I wouldn't be surprised if you could run it on the ATTiny2313 as well :)
@@peterme Oh cool... one of my reasons for watching this was asking "how easy is it going to be to do fixed-point?"... and it's one of your examples... EXCELLENT!
@@a0um lisp typing is often gradual. common lisp has a form of it. racket and clojure added side type systems. there's also clap that, IIRC, is mostly static (aimed at low level perf).
Hard for me to get conclusive here, as my experience with Rust is extremely limited. I will however say that I use Nim in production for work and it's a joy. The use-case where I'm using Nim is as a dynamic library in another project that needs to handle quite a big volume of data. Nim has allowed me to write readable code that runs super fast (I originally ported the project from Python because it simply wasn't up to the task speed-wise). Rust has a lot of hype surrounding it, and it is starting to make its way into more and more software, so in the foreseeable it looks like it might be winning in terms of adoption. But as far as I can tell Rust can be a hard language to learn, and at least to get proficient at. Nim on the other hand is quite easy to pick up, but still allows you to write very fast software. The meta-programming I'm using in this presentation for creating zero-cost abstractions on microcontrollers is also a huge leg up for Nim. I haven't seen anything similar to this in any other language that didn't require significant tooling for the specific chip in order to work. Since Nim compiles to C all the things seen in the presentation was simply compiled with the C compiler that shipped with the chip I was using (a Teensy 2.0) and uploaded using the same toolchain as you would use for a C program. So in that sense Nim is just building itself into the already existing toolchain while allowing you to use a much more expressive language. I haven't seen a lot of Rust micro-controller firmware, but there was a post at around the same time that I wrote this presentation titled "Why I rewrote my keyboard firmware in Zig" which told a story about not getting anywhere with his Rust firmware because it had become unmaintainable. My Nim firmware, despite already having a lot of features, is very short with only 112 lines of code (which includes a two layer layout for both halves of the board). This means its very easy to see what's going on and easy to maintain.
I'll point out that Rust has a very different profile than Nim. They share a lot of features, and they're both modern, compiled languages that emphasize zero-cost abstractions, fast compilation, and magnificent constant-evaluated expression systems. Both languages are backed by commitments to static safety guarantees (if it builds, it runs), and to rich, composable expressiveness. Rust emphasizes the former, extending that commitment to software of arbitrary size. Nim just rotates those priorities. Rust was a pain to learn, as a JS dev, as many of the concepts and API's just don't make sense on the front end. Once you're in the door, it makes so much sense. The compiler was always correcting me on this or that, but always on problems that I did not even think of as concerns. It's the most therapeutic experience you can imagine, if you've suffered non-deterministic abuse from a dynamic language on a permissive VM. I work in a Python shop now, and folks are continually amazed at my ability to read a snippet and point out the problem, even if it's from the context the snippet came from. I owe that to learning Rust, past the frustrating "Fine! I'll just pass everything by value!" stage. Nim doesn't try to learn you. The focus on ergonomics is absolutely appreciated, and it might actually end up being something I can get more folks at work on board with, given that it feels similar to Python -- the L-expr syntax is objectively more readable. That makes it easier to iterate on a design, when you don't have a clear idea of the structure up front, and it's likely the better platform for generative scripts targeting a different language. I consider it remarkable when other languages can go toe-to-toe, in the court of my opinion, with Rust. Nim does, and it feels much easier to get "velocity", which makes it much more likely that a newbie coder or a front-end dev is going to like it a year down the road. Meanwhile, you might even be able to learn the same lessons Rust offers, if you implement your own allocator and/or GC!
Amazing presentation! Thanks Peter. Nim language is incredible.
Cool! I'm seriously starting to consider nim for some future projects.
I can highly recommend it! Come say hi over on Discord/IRC/Matrix once you're ready to try
Your microcontroller examples are HUGE! I use ATTiny 2313 with 2K program memory and 128 **BYTES** RAM ;) :)
Haha, I just displayed the smallest I've tried myself. Nim runs just fine an the ATTiny85 with 4K available program memory and 512bytes of RAM with room to spare, so I wouldn't be surprised if you could run it on the ATTiny2313 as well :)
@@peterme Oh cool... one of my reasons for watching this was asking "how easy is it going to be to do fixed-point?"... and it's one of your examples... EXCELLENT!
ast based macro is probably comedy endgame for any lisp programmer in existence
Do you know any statically typed lisp by any chance?
@@a0um lisp typing is often gradual. common lisp has a form of it. racket and clojure added side type systems. there's also clap that, IIRC, is mostly static (aimed at low level perf).
@@agumonkey Memory hungry Lisps are incredible.
Good talk, thank you.
This is pretty neat!
Any thoughts on Nim vs Rust's place in production? I'm a big fan of rust but this language seems very interesting
Hard for me to get conclusive here, as my experience with Rust is extremely limited. I will however say that I use Nim in production for work and it's a joy. The use-case where I'm using Nim is as a dynamic library in another project that needs to handle quite a big volume of data. Nim has allowed me to write readable code that runs super fast (I originally ported the project from Python because it simply wasn't up to the task speed-wise). Rust has a lot of hype surrounding it, and it is starting to make its way into more and more software, so in the foreseeable it looks like it might be winning in terms of adoption. But as far as I can tell Rust can be a hard language to learn, and at least to get proficient at. Nim on the other hand is quite easy to pick up, but still allows you to write very fast software. The meta-programming I'm using in this presentation for creating zero-cost abstractions on microcontrollers is also a huge leg up for Nim. I haven't seen anything similar to this in any other language that didn't require significant tooling for the specific chip in order to work. Since Nim compiles to C all the things seen in the presentation was simply compiled with the C compiler that shipped with the chip I was using (a Teensy 2.0) and uploaded using the same toolchain as you would use for a C program. So in that sense Nim is just building itself into the already existing toolchain while allowing you to use a much more expressive language. I haven't seen a lot of Rust micro-controller firmware, but there was a post at around the same time that I wrote this presentation titled "Why I rewrote my keyboard firmware in Zig" which told a story about not getting anywhere with his Rust firmware because it had become unmaintainable. My Nim firmware, despite already having a lot of features, is very short with only 112 lines of code (which includes a two layer layout for both halves of the board). This means its very easy to see what's going on and easy to maintain.
I'll point out that Rust has a very different profile than Nim. They share a lot of features, and they're both modern, compiled languages that emphasize zero-cost abstractions, fast compilation, and magnificent constant-evaluated expression systems. Both languages are backed by commitments to static safety guarantees (if it builds, it runs), and to rich, composable expressiveness. Rust emphasizes the former, extending that commitment to software of arbitrary size. Nim just rotates those priorities.
Rust was a pain to learn, as a JS dev, as many of the concepts and API's just don't make sense on the front end. Once you're in the door, it makes so much sense. The compiler was always correcting me on this or that, but always on problems that I did not even think of as concerns. It's the most therapeutic experience you can imagine, if you've suffered non-deterministic abuse from a dynamic language on a permissive VM. I work in a Python shop now, and folks are continually amazed at my ability to read a snippet and point out the problem, even if it's from the context the snippet came from. I owe that to learning Rust, past the frustrating "Fine! I'll just pass everything by value!" stage.
Nim doesn't try to learn you. The focus on ergonomics is absolutely appreciated, and it might actually end up being something I can get more folks at work on board with, given that it feels similar to Python -- the L-expr syntax is objectively more readable. That makes it easier to iterate on a design, when you don't have a clear idea of the structure up front, and it's likely the better platform for generative scripts targeting a different language.
I consider it remarkable when other languages can go toe-to-toe, in the court of my opinion, with Rust. Nim does, and it feels much easier to get "velocity", which makes it much more likely that a newbie coder or a front-end dev is going to like it a year down the road. Meanwhile, you might even be able to learn the same lessons Rust offers, if you implement your own allocator and/or GC!