Lets talk about RUST [language]

Go To Last Post
32 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So "rust" [EDIT: the newish programming language - sorry for the confusion] is a hot topic lately. 

 

It might be worth starting some early discussions on how this affects the AVR world.

So far all I have found is a git branch on it. 

https://github.com/dylanmckay/avr-rust

 

Shall we talk about the practicalities of adopting a new language?

Will it create divides in the community? will it change nothing?

 

What do people think?

Last Edited: Wed. Nov 4, 2015 - 01:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rust is a hot topic? First time i've seen it here. Your post sounds a bit spammy.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First time I have heard of it until now as well. Spam? we'll see.

 

I did find something that covers rust thought:

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

http://www.rust-lang.org/

Rust is a systems programming language that runs blazingly fast, prevents nearly all segfaults, and guarantees thread safety. 

What constitutes "blazingly" fast? Relative to what?

 

Are "segfaults" and "thread safety" Big Issues to the average AVR application?

 

  • minimal runtime

 

Again, what constitutes "minimal"?

 

Is the like the Java people who rave about a "small" (sic) runtime at "only" (sic) 64K ... ?!

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We've had Pascal for years and its runtime could do bounds checking. How many people use Pascal in embedded systems?

 

Shall we talk about the practicalities of adopting a new language? Go ahead..... I could talk about the realities - if I need some programmers, where will I look? If I needed some guys to do web, php and javascript then I'd be overrun with candidates. How about embedded guys with 5 years 'rust' experience? Bzzzzzt. Pascal experience - they'd be a murmur. C/C++ - yeh!

Will it create divides in the community? We're not talking about segregation....

will it change nothing? You can't change nothing - nothing is nothing. Sort of like infinity plus 1.

 

What do people think? The excitement has yet to overtake us. I'll wait to it gets some more traction. Someone needs to do a killer app with it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My completely uninformed guess is that to do anything useful with it, the size of the runtime and standard libraries will make generated code too big to fit into AVRs. Without those things, I don't really see much difference when compared with C. ARM cortex-m might be more appropriate.

 

- S

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
We've had Pascal for years and its runtime could do bounds checking. How many people use Pascal in embedded systems?
There are apparently some.

For AVR :

  • Free Pascal - a Delphi follow-on though only up to the AVR6 architecture (iow no XMEGA); runtime's copyright is LGPLv2.1
  • Pascal-scm - a commercial AVR Pascal with zero price IDE for small AVR (megaAVR, XMEGA E AVR).
  • LunaAVR - dual license (free, low priced commercial); a very recent updated release.

Free Pascal - Advanced open source Pascal compiler for Pascal and Object Pascal - Home Page

http://www.freepascal.org/

http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/COPYING.txt?revision=24986&view=markup&sortby=file

http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/embedded/avr/?sortby=file

Pascal-scm for Atmel AVR

http://www.e-lab.de/AVRco/index_en.html

LunaAVR

About

http://avr.myluna.de/doku.php?id=en:about

14.06.2015 : http://avr.myluna.de/doku.php?id=en:lunaavr_2015.r1

 

Edit : added LunaAVR 2015r1 URL.

"Dare to be naïve." - Buckminster Fuller

Last Edited: Mon. Jun 15, 2015 - 05:14 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Indeed: Pascal is well established, and several implementations exist for small microncontrollers (including AVR) - but that's not the point.

 

The point is, how many people are actually, actively using it?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Let's not mention ADA then.....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just rounding up the list

 

http://users.iafrica.com/r/ra/ra...

 

although a bit dated... or shall we say mature? ;-)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Please define what "RUST" is and how iron oxide affects an AVR microcontroller.

Neither your message nor the link defines what "RUST" refers to.

 

A general mental defect of the electronics/programmer community is to assume that everyone is born with a list of a million stupid acronyms in their head.

 

Thank you,

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry if it sounded spammy. I heard it was getting some attention as a C alternative in other places like kernal. 

 

Im by no means advertising rust... I don't know much about.

It does sound likes it memory management could be helpful. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think there are some good points about the user/support base made here. 

 

I was kind of hoping to hear some more from people who have some experience with it and might have some insights on its relevance to micro-controllers. 

 

The Pascal analogy seems pretty relevant. 

But Pascal was developed 40 years before AVR existed and there are many other reasons as to why its not widely adopted here. 

and people have been making these kinds of analogies every time a new language appears.

 

I also think that when a "new" language comes out that is in development, its always worth a look at and a heads-up.

These things work in both directions. 

It may be in our interest that people shaping a new language have an awareness of if the interests of AVR developers. 

Especially in the early stages when it gains momentum/funding/new_blood/etc.

 

Its not about "this feature" or "that feature" alone,

its about looking at the communities that follow other trends and seeing what we can gain from that. 

 

p.s.

Sorry i forgot about the actual literal "rust" ... hehehe...  : P

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just a moment though. The opening page there even says "this is a front end for LLVM" then correctly goes on to say "The AVR port of LLVM is not ready yet". So this is an unusable language is it?

 

Every programmer in the world probably thinks they can write the perfect programming language. Many have tried:

 

https://en.wikipedia.org/wiki/Li...

 

Of those exactly how many are in regular day to day usage by large numbers of programmers?

 

So there's more to making some language popular than the very fact that it is "better" than all the rest.

 

Assuming LLVM for AVR was complete personally I'd like to see some evidence of how this is "better" than C anyway. The existing C compilers for AVR will generally convert things like Rust's:

*PORTB = 0b11111111;

to the simplest LDI/OUT that is most compact and fastest already. How is Rust going to better that?

 

I know you are going to say "it's not about the code size/speed efficiency" but, to be honest, when it comes to embedded 8bit micros like AVR then yes it is. Read the forums here - the perennial topic is how close are language compilers getting to the best hand crafted assembler code - that's what people want.

 

Now you may say "it's not about the speed/size , what sets it apart is the more structured, strong typed, .. aspects of the language". Well, yeah, but how does C++ not already deliver most of that and in a dialect that is fairly easy for C/Asm programmers to convert to? For example there is an implementation of Ada for AVR. There are many reasons why this might be considered a "better" language than C or even C++ and it's not new, it's been around for years. Now do a search here and see if you can find a post that is actually an end user asking a question about how you achieve something in avr-ada. So, as I say, "better" does not mean "this is going to replace C".

 

There is a reason why C (and now C++) are possibly the widest used of all medium/high level languages and that's because it hits exactly the right level of abstraction between the hardware itself and what the programmer wants to achieve with that hardware. It's a very tricky balance and so far, not many things come close. In fact I guess second place goes to Basic in fact (the modern ones, not Dartmouth).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
For example there is an implementation of Ada for AVR. There are many reasons why this might be considered a "better" language than C or even C++ and it's not new, it's been around for years. Now do a search here and see if you can find a post that is actually an end user asking a question about how you achieve something in avr-ada. So, as I say, "better" does not mean "this is going to replace C".
The intent of the following is to point the one searching to the maintainers of AVR-Ada :

SourceForge

AVR-Ada / Mailing Lists

avr-ada-devel — General discussion about GNAT on AVR

http://sourceforge.net/p/avr-ada/mailman/avr-ada-devel/

P.S.

A possible limiter on usage of Ada on AVR is the variety of AVR Ada runtime copyrights :

  • AVR-Ada, GPLv3 GCC Runtime Library Exception
  • GNAT GPL 2012, GPL
  • GNAT Pro, GNAT Modified GPL (GMGPL)

http://sourceforge.net/p/avr-ada/code/ci/master/tree/gcc-4.9-rts/adainclude/a-except.adb

http://libre.adacore.com/css/libre_images/branding.gif

GNAT Technology Comparison Chart

http://libre.adacore.com/comparisonchart/

http://libre.adacore.com/tools/gnat-gpl-edition/faq/#licensing 

AdaCore

AVR | Platforms | GNAT Pro Safety-Critical

http://www.adacore.com/gnatpro-safety-critical/platforms/avr

"Dare to be naïve." - Buckminster Fuller

Last Edited: Wed. Jun 17, 2015 - 04:23 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But as I say, avr-ada may have lots of plus points as a language but let's face it you could count the users on the fingers of one hand. Rust faces the same challenge.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Sorry if I step on a few long C toes here, given the usual "C is king attitude" present in the above. I am not involved in Rust. But I know a few things about it.

 

First, people programming for embedded controllers typically use a ridiculously small subset of C, without pointers, and base their experience of the language on that. That is a mistake. With controllers now reaching i486 levels of performance and project sizes growing, C is not as well suited. At this level bugs are even easier to make and sometimes impossible to spot.

 

Rust does not have these bugs, it is safe by default (and unsafe when desired). Rust also brings much better pre-processor abilities to the table, allowing code to run at compile-time, creating all the data-structures exactly as needed, increasing performance and clarity. Bounds-checking, as cited, can obviously be turned off, so you don't have to pay for what you don't need.

 

Then there is https://zinc.rs/, an existing effort to run Rust on embedded ARM controllers. The big problem is that code-generators such as start.atmel.com have no support for Rust, so one needs to work in a dual language configuration. That complicates everything to the point that we accept C as king even though we have 40 years of compiler experience and we can do (much) better.

 

Note that it should be very *low-cost* to adapt code-generators like start.atmel.com to another target language, like Rust. I repeat, Rust support does *not* mean we need a compiler. A compiler for Rust is available now on most ARM devices.

 

The folks here preaching "U C, I told U so", seem specially preoccupied in keeping C out of a fight. They in effect want to win the fight by taking away our options. They know C is an old dog, like they are, because it is the one they grew up with, when it had no real challengers. But the younger generation doesn't have the time to endure the torture most of you probably are not even conscious of *anymore*. C sucks, badly, even in the rudimentary form practiced in embedded, even for experienced programmers. Besides, only when we have a choice, we can see whether people really prefer C.

 

My opinion is that Rust in its current state probably isn't the ideal language for embedded (given the simplistic core of C people use), but the key thing is that it probably can be made to be (supporting something like http://oosmos.com/), because of its compile-time abilities. Note Atmel need not be involved, it only needs to provide the peripheral configuration logic.

 

So, for Atmel, Rust is a big opportunity. Atmel would be pleasing the best minds in the industry, only good can come of that. It is a cheap opportunity with a potentially *big* payoff. Much like Arduino was in its early days.

 

Tip: get in touch with the folks at zinc.rs, and let them enlighten you on how to scaffold a Rust project in the code-generator.

Note: I won't reply or clarify as this topic is notoriously prone to trolling, as seen above.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Note: I won't reply or clarify as this topic is notoriously prone to trolling, as seen above.

So you create an account to reply to a post thats been dormant for almost four months then say you will say no more because of trolls?  THat's rich

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's just like Forth again! It's interesting how the term 'safe' is used, but not clarified. Unfortunately, Rust could not be used in a safety application at this time.

Arduino for Atmel was great advertising, but i doubt it increased its fortunes to any great degree.

Last Edited: Wed. Oct 28, 2015 - 08:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

chromebin wrote:
They know C is an old dog, like they are,

chromebin wrote:
best minds in the industry,
Troll, indeed.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Troll, indeed.

As a proponent of a new/different/"better" approach, I don't really have a problem with promoting RUST (or whatever).  But indeed, putting in "C sucks" and similar is certain to get knee-jerk reactions.

 

I focused on one little phrase among the paragraph listing the virtues -- "increased performance".  Now, RUST developers have no magic AVR8 instructions that aren't available to the rest of us plebeians, do they?  It would be nice to see an example. ;)

 

Probably true, though, that us dinosaurs that did AT90S4433 apps fifteen years ago and Mega48 apps 10 years ago to keep the micro cost down are now indeed an outdated branch of the hominid family tree.  So today when starting an app destined for a $5 micro, it can be huge and complex.  So better structure may well contribute to overall less dev time.

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

chromebin wrote:

..... With controllers now reaching i486 levels of performance and project sizes growing, C is not as well suited. At this level bugs are even easier to make and sometimes impossible to spot.

 

Ahh, here is the confusion. 'controllers' means too many things to too many people.

 

This does not sound like a 8 bit AVR MCU language, but there ARE ARM's with ever-larger resources being spun...

 

and finally, from above :

 

"this is a front end for LLVM" then correctly goes on to say "The AVR port of LLVM is not ready yet".

 

Looks like we wait for real-word-numbers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

+1 for the Troll finding or creating a second troll account....

one not just comes here and in their first post start kicking up an old thread were the OP clearly could not make his point.

 

Personally suggest the moderators take a deep breath and decide if it is not better to lock this thread.

it might be coincidence that in the next 4 months when the topic drops from page 2 another great mind arises and "up-s" the topic again to re spark this discussion.

 

one the C code supremacy.....

if the troll still lives and looks at the responses.

Nothing beats assembly code. C compilers get close to perfect code but assmbly is the king.

why use C code because it is almost independent of using STM/freescale/renesas/atmel/nxp/microchip controllers. and it is a heck of al lot easier to learn as in learn once use on all platforms. with assembler each processor has its own instruction set and you need to learn how it is best used. The C compiler writers have done just that and taken that large learning curve from you.

 

have fun in live and stop trolling it willin the long run make your life easier and a lot more relaxed

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

but assembly is the king.

...just like me....

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just had a quick look (I did not know about RUST), and I don't see what "real" new it brings.

For me it sounds like they have some kind of p-code like driver at the button, and I don't see how that can be as fast as C. (and for good reason never ASM)

And the range check reminds me about pascal, and even my 30 year old turbo pascal could remove the check to add speed.  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Regarding start.atmel.com (which is the only support needed from Atmel): please think about an open sourcing at least the code-generator (backend), so the community interested in other languages, of which Rust is just one, can adapt it to their needs.  

 

Regarding the AVR: this topic does not apply to the AVR, for that would mean writing a compiler (while Rust already compiles well to ARM). Besides, ARMs are already recomended for new designs, as they are more cost-effective than AVRs. Example: a 48Mhz/16k/4k SAMD09 with 22 I/O costs about the same as the cheapest AVR, an 1k ATTiny with just 4 I/O (@10k). 

 

Regarding the elderly: get a life. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ahh, youth. Wasted on the young.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Regarding the AVR: this topic does not apply to the AVR, for that would mean writing a compiler (while Rust already compiles well to ARM).

Ok, so you dredging up this thread is to bring to light that RUST is really for ARM devices?  I will move this to the ARM community then if that's the case.

 

Besides, ARMs are already recomended for new designs, as they are more cost-effective than AVRs.

That's a debate that has been going on for quite some time in many other threads already.

 

Example: a 48Mhz/16k/4k SAMD09 with 22 I/O costs about the same as the cheapest AVR, an 1k ATTiny with just 4 I/O (@10k). 

So what.  I have designs where I only need a few I/O pins and not much FLASH so why put a big engine in for something a 2 cycle will handle quite efficiently?  Also, form my workings with the D10/D21 ARMS I find it ridiculous that I need over 10k of code space and 2k of SRAM to turn an LED on or off, when I can do the same in an AVR with less than 50 bytes of flash and a couple bytes of SRAM.

 

 

Personally suggest the moderators take a deep breath and decide if it is not better to lock this thread.

Since most of the posts are from well established members and only two from our new friend the lock may come out.  But I would like to give 'chromebin' one last opportunity to make their point otherwise yes I would agree that this is going nowhere.

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But it's it's a new chip from Atmel !

But I guess that a young person don't care.

 

My my guess is that there are errors even on first page of the datasheet.
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

chromebin wrote:

Note: I won't reply or clarify as this topic is notoriously prone to trolling, as seen above.

 

For future reference, the definition of trolling is not "posts by people who disagree with you."  That's called a discussion, typically.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

chrombin wrote:
They know C is an old dog, like they are

chrombin wrote:
Regarding the elderly: get a life.

 

Now I'm no expert, but if I wasn't so... what's the word?... I can't think of it.  Or remember.  Or something.  Darned Alzheimer.  Or Dementia.  Now here me out...

 

Was I just saying something?

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

THis has gone on long enough.....

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

Topic locked