Go 1.8 Performance Improvements on ARM (RasPi)(reddit.com)
reddit.com
Go 1.8 Performance Improvements on ARM (RasPi)
https://www.reddit.com/r/golang/comments/5o17c8/go_18_performance_improvements_on_arm_raspi/
2 comments
Go has the potential to be one of the most popular languages on rpis. Right now Python is probably most popular but for more sophisticated apps you need something more. Java is too bloated for the small memory, so Go is a great choice.
If those are the requirements then Nim would also fit almost perfectly for being native, fast and unbloated.
Sadly it doesn't get the PR it deserves and even on its own forums there doesn't seem to be that interest in using it for embedded systems.
Thank you for mentioning Nim here, it's always nice to see :)
Indeed, Nim doesn't see as much use on embedded systems as it deserves. I've used it once on an RPi to create a little camera security app and it worked rather well. If I had the time I would write something about that.
Actually, now that I think about it, I will definitely write something about it. My book was originally going to include a chapter on embedded development in Nim but I sadly had to remove it from my plans. I already promised some people that I will be writing some articles on embedded development in Nim as a replacement for that chapter :)
Indeed, Nim doesn't see as much use on embedded systems as it deserves. I've used it once on an RPi to create a little camera security app and it worked rather well. If I had the time I would write something about that.
Actually, now that I think about it, I will definitely write something about it. My book was originally going to include a chapter on embedded development in Nim but I sadly had to remove it from my plans. I already promised some people that I will be writing some articles on embedded development in Nim as a replacement for that chapter :)
Thanks for replying Dominik and thanks for promising some articles on the subject, now I'm waiting for them!:)
I don't want to hijack an article about a different language so I'll try to keep this very short. Nim probably needs a killer app to get the attention it deserves. Building GUIs easily could be one way to make it easier, but I had very unpleasant experiences with gui packages for Nim. The only one I could get to work after fiddling with dependencies (sorry, can't recall the name) was extremely slow.
So here is a challenge: why not making something like what Tekui is for Lua?
http://tekui.neoscientists.org/
I've compiled it on a few SBCs and it always worked. Some problems here and there with the framebuffer on old boards but it always worked (even on the venerable Hackberry A10) and was reasonably fast although Lua based. I can only wonder what
could be done if it was ported to Nim!
> I don't want to hijack an article about a different language so I'll try to keep this very short.
No need to worry about that. It's why we have threaded conversations on HN.
> Nim probably needs a killer app to get the attention it deserves.
I agree, and you'll be glad that I have some ideas already. Of course time is always the problem :)
> Building GUIs easily could be one way to make it easier, but I had very unpleasant experiences with gui packages for Nim.
Is it nimx that you have tried? Surely it's still early days for nimx but it is looking very promising. There is also work going to be put in to make a much more robust and idiomatic libui wrapper.
Unfortunately GUI libraries are difficult. It's actually no surprise that we so many projects using WebKit for a GUI these days. Can any library seriously compete? I'm not so sure anymore.
No need to worry about that. It's why we have threaded conversations on HN.
> Nim probably needs a killer app to get the attention it deserves.
I agree, and you'll be glad that I have some ideas already. Of course time is always the problem :)
> Building GUIs easily could be one way to make it easier, but I had very unpleasant experiences with gui packages for Nim.
Is it nimx that you have tried? Surely it's still early days for nimx but it is looking very promising. There is also work going to be put in to make a much more robust and idiomatic libui wrapper.
Unfortunately GUI libraries are difficult. It's actually no surprise that we so many projects using WebKit for a GUI these days. Can any library seriously compete? I'm not so sure anymore.
Ok. Hisss! I'll bite :)
How is Go better suited than Python for development of more "sophisticated" apps? And how do you define that? Where do you draw the line?
For me Go seems to suffer from many of the same shortcomings python has. And I say that liking Python.
How is Go better suited than Python for development of more "sophisticated" apps? And how do you define that? Where do you draw the line?
For me Go seems to suffer from many of the same shortcomings python has. And I say that liking Python.
Not the parent, but perhaps apps that require a high degree of concurrency, or apps that need to eke out all the performance of the CPU cores?
For me Go is more attractive than Python on the RasPi because there is no GIL limiting concurrency, the notion that compiled code performs significantly better, and that there are less installation dependency headaches to worry about.
For me Go is more attractive than Python on the RasPi because there is no GIL limiting concurrency, the notion that compiled code performs significantly better, and that there are less installation dependency headaches to worry about.
As the Pi isn't as fast as a typical desktop machine, the performance gain of natively compiled code in Go probably matters a lot.
Static types helps for complex apps, good concurrency control helps for ambitious apps, and fast performance helps for critical apps.
[deleted]
>Java is too bloated for the small memory, so Go is a great choice.
Java, the language, was first designed to run on all kinds of embedded devices, including cars, in cpus available 20+ years ago. You don't need to run the official JVM and SDK to run Java. There are even real-time options.
Java, the language, was first designed to run on all kinds of embedded devices, including cars, in cpus available 20+ years ago. You don't need to run the official JVM and SDK to run Java. There are even real-time options.
How does one get started with that?
About 10 years ago, I used something of that description with a Lego Mindstorms robot. The project site (looking at the Wikipedia page, we must've been using Lejos NXT) had API documentation like the Sun site did, links to their cut-down JDK, etc. I don't remember if we flashed the controller brick with a custom firmware, or if the JRE was linked into the class files produces by compilation, but it worked nicely for our purposes.
For reference, the NXT v1 brick has an ARM-based Atmel microcontroller with a clock of ~55MHz, 256KB of flash, and 64KB of RAM, along with a smaller ATMega4 microcontroller.
For reference, the NXT v1 brick has an ARM-based Atmel microcontroller with a clock of ~55MHz, 256KB of flash, and 64KB of RAM, along with a smaller ATMega4 microcontroller.
Oh, this takes me back to my university days where I spent time with Lejos [0] on an RCX brick (32 kilobytes of usable space).
I recall using Eclipse for development and I am sure the build process involved uploading the JVM and program code via a USB infrared interface.
Have to say that I preferred using "Not Quite C" [1] due to it having a simpler syntax and intuitive support for cooperative multitasking.
[0] http://www.lejos.org/ [1] http://bricxcc.sourceforge.net/nqc/
I recall using Eclipse for development and I am sure the build process involved uploading the JVM and program code via a USB infrared interface.
Have to say that I preferred using "Not Quite C" [1] due to it having a simpler syntax and intuitive support for cooperative multitasking.
[0] http://www.lejos.org/ [1] http://bricxcc.sourceforge.net/nqc/
I had a lab partner, and Java was our shared language. I don't remember the decision process that went into choosing our language, but I'm sure that was a big part of it.
Actually, looking at NQC's page, they don't support the NXT, just the RCX. That certainly would've been the killer for us, there.
Actually, looking at NQC's page, they don't support the NXT, just the RCX. That certainly would've been the killer for us, there.
Well, with 512 MB of RAM you're just fine with standard Java and frameworks. That's still A LOT of memory.
It's not like C is useless either. It worked out for Arduino anyway.
I'd like to bring up another thing for which this is relevant: https://github.com/golang/go/wiki/Mobile
Here's hoping for cross-platform development without JavaScript.
Here's hoping for cross-platform development without JavaScript.