-
Just found this new subforum with nothing in it. Took the opportunity to start a thread about my favourite programming language, https://rust-lang.org It's a systems language, similar to C, but with more safety guarantees and modern features like iterators. It's slowly being adopted in the embedded landscape as well. Ask Me Anything.
-
Which microcontrollers have compilers?
-
Please, give some examples of the safety guarantees.
-
Ask Me Anything.
OK
How long have we got until the next ELE?
https://youtu.be/_Cje2LJJKS8?list=PLHSoxioQtwZfY2ISsNBzJ-aOZ3APVS8br
-
Which microcontrollers have compilers?
There are compiler targets for thumbv6-8 and MIPS. I thought there was MSP430 but I don't see it now. There is also a matter of board support packages, which are currently all community provided, STM32 has the most traction there. -
Please, give some examples of the safety guarantees.
Rust prevents common errors such as buffer overflows and data races statically at compile time. -
.
.
It's slowly being adopted in the embedded landscape as well.
Really? Then I must have been sleeping too much as I have not exactly stumbled upon that (unless "slowly" is to be taken VERY literally)... -
.
.
It's slowly being adopted in the embedded landscape as well.
Really? Then I must have been sleeping too much as I have not exactly stumbled upon that (unless "slowly" is to be taken VERY literally)...
Wow Rust has moved up to the #3 spot this year (was #9 last year). It seems to remain #1 in the "most loved language" category...
https://codinginfinite.com/best-programming-languages-to-learn-2019/
-
Please, give some examples of the safety guarantees.
Rust prevents common errors such as buffer overflows and data races statically at compile time.
Some types of races, at least. But you can't make things foolproof, since fools are so damn ingenious. The Dunning-Kruger syndrome is very evident in programming. -
Please, give some examples of the safety guarantees.
Rust prevents common errors such as buffer overflows and data races statically at compile time.
Some types of races, at least. But you can't make things foolproof, since fools are so damn ingenious. The Dunning-Kruger syndrome is very evident in programming.
There's no substitute for understanding programming paradigms and actually designing a program instead of just slapping code together. The last 20 years of my career I was responsible for writing, and later for analyzing a lot of third-party web code and the process seemed to be "let newly-fledged Java coders write huge apps and hope for the best". They apparently assumed Java's garbage collection and libraries were going to prevent them from doing anything bad, with the result that garbage collection and mismanaged libraries caused problems by the score. We actually were recommending suites of monitoring software to watch the behavior of all this bloated, misdesigned code - yes, it was so bad that we had software monitoring software.
In contrast, during my prior job we had to write a very large embedded program without the "help" of object-oriented languages and their concomitant structures. We actually prepared a series of templates and processes, analyzed the pseudocode before writing the functional version, and stepped through the result before committing it to the compiler. Lots more work than just coding and debugging, but I'm convinced it saved us a lot of effort and the code was highly reliable (it was a realtime system for aircraft avionics; not vital to the flight system, but important to the end user).
I'm just beginning to explore Rust and Go, but they do seem to be designed so that intelligently-written code is much better behaved than with monstrosities like C++ and Java. Of course you'll be able to write crap with any of them, but these languages, at least, seem to be built to provide more capability and make better software possible instead of effortful. I'm hopeful that with the attention (e.g.) Rust is receiving, it may displace a lot of the junk and encourage coders to think and design instead of just following the received wisdom of a failed generation of software implementation.
-
yes, it was so bad that we had software monitoring software.
Which in turn probably needs software monitoring software monitoring software, no doubt produced by a team managed by ex-Major Major Major Major.
There's a lot to be said for having been brought up in the era when you wrote on coding forms, had it punched, and then had to wait for the fan-fold printout. Aside from the obvious advantages of an endless supply of used 80-column cards for bookmarks and shopping lists, it made you careful and it made you plan. Recent research suggests that there's a factor of between 10 and a 100 in the amount of total effort expended between taking time to get it right at the start of the software development process versus fixing bugs in deployment or production. The further down the pipeline towards production you go before fixing things, the higher the ratio. -
Please, give some examples of the safety guarantees.
Rust prevents common errors such as buffer overflows and data races statically at compile time.
Some types of races, at least. But you can't make things foolproof, since fools are so damn ingenious. The Dunning-Kruger syndrome is very evident in programming.
There's no substitute for understanding programming paradigms and actually designing a program instead of just slapping code together. The last 20 years of my career I was responsible for writing, and later for analyzing a lot of third-party web code and the process seemed to be "let newly-fledged Java coders write huge apps and hope for the best". They apparently assumed Java's garbage collection and libraries were going to prevent them from doing anything bad, with the result that garbage collection and mismanaged libraries caused problems by the score. We actually were recommending suites of monitoring software to watch the behavior of all this bloated, misdesigned code - yes, it was so bad that we had software monitoring software.
I've seen all that, but don't place the root cause of the problems on a language.
The root cause is that OOP+GC has enabled large libraries to be easily created, bolted together and used. Much larger and more easily than without OOP+GC. While that has removed swathes of "old" problems, it has allowed others to emerge.
A classic example is blaming problems on "memory leaks", when actually it is "unintended data retention".QuoteIn contrast, during my prior job we had to write a very large embedded program without the "help" of object-oriented languages and their concomitant structures. We actually prepared a series of templates and processes, analyzed the pseudocode before writing the functional version, and stepped through the result before committing it to the compiler. Lots more work than just coding and debugging, but I'm convinced it saved us a lot of effort and the code was highly reliable (it was a realtime system for aircraft avionics; not vital to the flight system, but important to the end user).
I don't doubt that, but it is nothing to do with OOP+GC.QuoteI'm just beginning to explore Rust and Go, but they do seem to be designed so that intelligently-written code is much better behaved than with monstrosities like C++ and Java. Of course you'll be able to write crap with any of them, but these languages, at least, seem to be built to provide more capability and make better software possible instead of effortful. I'm hopeful that with the attention (e.g.) Rust is receiving, it may displace a lot of the junk and encourage coders to think and design instead of just following the received wisdom of a failed generation of software implementation.
Rust and Go are beguiling, but I've seen too many languages with claimed advantages that turned out to be minor and unimportant. Ignoring them and concentrating on the real advances has been key to my career.
Neither Rust nor Go directly tackles a key emerging problem: many core processors with NUMA memory hierarchy. The only languages I've seen that do tackle it head on are CSP, Occam and the modern incarnation, xC. Note that the concept of "channels" is taken directly from CSP and Occam. -
No, the specific problems are not linked directly to OOP/GC, but the fact that universities and employers push languages like Java without teaching the coders how to actually design programs first does cause that type of problem. It's so easy to make a gargantuan dogpile in Java or C++ that unless the coders actually blocked it out and analyzed it, they're likely to just cause problem after problem when they add more code to address the symptoms.
The "memory leak" issue comes from people writing spaghetti code or using libraries with unintended side effects, and not caring or knowing that they have to be aware of memory usage in spite of GC. Many of the problems we saw in production were the GC kicking in at a very bad time and grinding the programs to a halt because the programmers didn't bother to understand or stress test the code before submitting it to production. Everything to do with bad design and very little to do with the language - except that Java and its ilk are not taught along with proper design techniques (at least among the programmers we worked with at AT&T). I tended to write procedural Java (much despised by "real" OO programmers) but because I knew where memory was being used and for what, my code didn't have those issues; it may have run a bit slower at a guess, but it never crashed.
So my point was that languages like Java and C++ typically exhibit issues because the programmers aren't taught good techniques, and those languages are likely to be used a lot by inexperienced programmers IME who are too lazy to code wisely. They're also hard to use efficiently by fledgling programmers. Heck, I used Java for 16 years and never got familiar enough with it to be aware of all the pitfalls. C, on the other hand, is so easy to master that I think I understood it fairly well.
I haven't tossed my hat in the Rust or Go rings yet, but I'm watching to see if they do indeed exhibit advances which make them worth adopting. If so, then great. -
No, the specific problems are not linked directly to OOP/GC, but the fact that universities and employers push languages like Java without teaching the coders how to actually design programs first does cause that type of problem. It's so easy to make a gargantuan dogpile in Java or C++ that unless the coders actually blocked it out and analyzed it, they're likely to just cause problem after problem when they add more code to address the symptoms.
I'm certainly not going to defend C++ in any way; my attitude is that if C++ is the answer then exactly what was the question.
The gargantuan dogpiles that can accrete in Java are because of its success in avoiding many of the problems in C/C++. Essentially avoiding the problems has allowed run of the mill programmers to make much larger programs than is practical in C/C++.
As for not teaching how to design programs, t'was ever thus. Some people should never be allowed near a keyboard or a soldering iron!QuoteThe "memory leak" issue comes from people writing spaghetti code or using libraries with unintended side effects, and not caring or knowing that they have to be aware of memory usage in spite of GC. Many of the problems we saw in production were the GC kicking in at a very bad time and grinding the programs to a halt because the programmers didn't bother to understand or stress test the code before submitting it to production. Everything to do with bad design and very little to do with the language - except that Java and its ilk are not taught along with proper design techniques (at least among the programmers we worked with at AT&T). I tended to write procedural Java (much despised by "real" OO programmers) but because I knew where memory was being used and for what, my code didn't have those issues; it may have run a bit slower at a guess, but it never crashed.
I wasn't clear enough. My objection is calling "data cancer" a "memory leak".
And it is well known that you can write Fortran in any language
QuoteSo my point was that languages like Java and C++ typically exhibit issues because the programmers aren't taught good techniques, and those languages are likely to be used a lot by inexperienced programmers IME who are too lazy to code wisely. They're also hard to use efficiently by fledgling programmers. Heck, I used Java for 16 years and never got familiar enough with it to be aware of all the pitfalls. C, on the other hand, is so easy to master that I think I understood it fairly well.
As someone that first used C when there were precisely two books on the language (i.e. in 1982), I am only too well aware of how people think they know the language - but don't. C++ is even worse, and is beyond being salvaged.
Java is a much simpler language in that it has fewer gotchas - there's no need for "language lawyers", for example. The libraries can have gotchas, but that's a different thing altogether.QuoteI haven't tossed my hat in the Rust or Go rings yet, but I'm watching to see if they do indeed exhibit advances which make them worth adopting. If so, then great.
That's my attitude. They show promise, but I've seen that too often in the past to hold my breath! -
Indeed, also I tend to ignore languages until there is a standard document (with a version number that pins to a particular release of the standard, HTML '5' Looking at YOU!) and at least two competing implementations of that standard from different vendors...
Trying to keep up with a language under development is just an exercise in frustration (and means that a project you finished last year likely does not build with this years toolchain)
C for all its warts (and numerous implementation or undefined behaviour traps) is at least reasonably prone to maintain backwards compatibility, and you can, if you really know the language, do a surprising amount that is very likely to still compile reasonably cleanly 10 years from now, I am not so sure this applies to rust.
Regards, Dan. -
Trying to keep up with a language under development is just an exercise in frustration (and means that a project you finished last year likely does not build with this years toolchain)
C for all its warts (and numerous implementation or undefined behaviour traps) is at least reasonably prone to maintain backwards compatibility, and you can, if you really know the language, do a surprising amount that is very likely to still compile reasonably cleanly 10 years from now, I am not so sure this applies to rust.
I've heard that there are applications which are Rust version specific, which is another reason I'm not going to dive in right now. It's already beyond acceptable that finished applications require specific (not minimum) Java versions to run; if a 25 year old language is that unstable (or your app is so poorly written), maybe consider a different language? I would anyway, but then Java doesn't do anything I need in a language that (say) Python doesn' t have.
People moan about the "modern" language features that C is missing, but it is a low level language and wasn't designed to be the answer to all things. I'm glad to see that it has remained its economical architecture even as bloat infests the popular languages; a lot of the embedded micro chips still use C development tools because it's a time-tested and efficient language.
-
Trying to keep up with a language under development is just an exercise in frustration (and means that a project you finished last year likely does not build with this years toolchain)
C for all its warts (and numerous implementation or undefined behaviour traps) is at least reasonably prone to maintain backwards compatibility, and you can, if you really know the language, do a surprising amount that is very likely to still compile reasonably cleanly 10 years from now, I am not so sure this applies to rust.
I've heard that there are applications which are Rust version specific, which is another reason I'm not going to dive in right now. It's already beyond acceptable that finished applications require specific (not minimum) Java versions to run; if a 25 year old language is that unstable (or your app is so poorly written), maybe consider a different language? I would anyway, but then Java doesn't do anything I need in a language that (say) Python doesn' t have.
Oh, but for programs with an expected long lifetime, with C and C++ it is prudent not to insist on using the same version of the compiler. There are quite a few cases where newer versions of a compiler optimise code differently - and break the application. Hence SOP is to develop inside a virtual machine, and to archive that virtual machine as part of the deliverable.
Now the traditional C compiler writer's response is that the developer misused the language. While that may (or may not) be true, it is certainly an indictment of the fragility of the language+compiler+developer combination.QuotePeople moan about the "modern" language features that C is missing, but it is a low level language and wasn't designed to be the answer to all things. I'm glad to see that it has remained its economical architecture even as bloat infests the popular languages; a lot of the embedded micro chips still use C development tools because it's a time-tested and efficient language.
Er no:- C/C++ has changed considerably. The latest versions now have a defined memory model (a quarter of a century after Java demonstrated its advisability). Whether that memory model is defined well enough remains to be seen.
- You could not, until the latest version, even implement multitasking. To me it is remarkably that Hans Boehm even had to write a paper pointing that out: http://hboehm.info/misc_slides/pldi05_threads.pdf "Threads Cannot be Implemented as a Library"
In the 80s C/C++ was a low level language, but it became confused about its objectives in the early 90s. It would have been equally valid and useful to be either a low level language or a general purpose high level applications development language, but you can't be both. In trying to be both, it failed to be good at either.
Java then rapidly took over as a general high level applications language, and Python is also up and coming. -
C, on the other hand, is so easy to master that I think I understood it fairly well.
Mastering it of course does not allow any non trivial project with more than one programmer to avoid buffer overflows and use after free, they are defacto language features ... not bugs. -
You actually cannot implement malloc in a conforming way as a library either (The issue has to do with alignment, and not actually knowing which type has the tightest requirements), not news to anyone who has actually read the standard.- To me it is remarkably that Hans Boehm even had to write a paper pointing that out: http://hboehm.info/misc_slides/pldi05_threads.pdf "Threads Cannot be Implemented as a Library"
The getout is that the C library implementation is NOT itself required to be written in standards conformant C, and writing it using either knowledge of implementation defined details of the compiler or (in some cases) by dropping down to platform specific assembler is perfectly legit. So it is with threads (C has no native test and set atomic for example, makes locking primitives kind of hard).
VMs with all the project build tools are a good and happymaking thing, but C11 is mostly a superset of the earlier language and backwards compatibility is fairly good in my experience (C++ MUCH less so, that language has been bent out of all recognition).
The real win with the VMs is that they mean you can reproduce bugs with exactly the tools used to originally build the release, usually a difference between tools means you cocked it up, but still being able to reproduce exactly has value.
-
C, on the other hand, is so easy to master that I think I understood it fairly well.
Mastering it of course does not allow any non trivial project with more than one programmer to avoid buffer overflows and use after free, they are defacto language features ... not bugs.
True, but it is more than just those "features".
See the C++ Frequently Questioned Answers http://yosefk.com/c++fqa/ The standard response is "yes but the latest version of the standard is better", neglecting whether there are any compilers that fully and correctly implement the standard, and whether the new compilers can be used in the current project.
If C++ is the answer, you should re-evaluate the question. -
Hi Sajattack, Just found this new subforum with nothing in it. Took the opportunity to start a thread about my favourite programming language, https://rust-lang.org It's a systems language, similar to C, but with more safety guarantees and modern features like iterators. It's slowly being adopted in the embedded landscape as well. Ask Me Anything.
I'm a Forth user and would like to say Rust has been of great benefit to me indirectly
Some Rust folks wrote a program to convert the Texas Instruments version of CMSIS-SVD (everyone just has to have their own special stuff!) into the ARM version of CMSIS-SVD and it works perfectly! This allows me to use my SVD parsers on Ti MCUs' as well as ARM MCU's to automatically produce memory mapped and register bitfield Forth Words. Thanks guys! -
Totally off-topic, but I seriously read the subject of the thread as "Rust in Peace Megadeth"
-
I prefer Neil Young's Rust Never Sleeps.
-
Ad-Blocker Performance increased by 69x with New Engine Implementation in Rust
https://brave.com/improved-ad-blocker-performance/