-
My pet peeve are claims that C is a bad choice for new projects and that languages like Go or Rust are better options This is only true if you take a subset of the lessons history has taught us and disregard the rest. I see this as irresponsible.
Fundamentally: having programs that "work at all" is more important than any form of bug or memory safety issue. In a set of specific cases (medical, auto & other life-critical) you can argue that a program should have the opposite priorities; but in the vast majority of cases a device that works 99% of the time is better for society than not having that device at all.
I think we are living in the 'information dark ages', where a lot of our useful and amazing creations of code are simply not going to be around ten or twenty years from now. They will be broken (or passively deleted, another problematic topic).
We seem to have come to accept that a program written today won't be useful or usable ten years from now, and I think that's a very bad philosophy. Compare it with many of the machines (cars, factories), artwork (music, books, film), architecture and systems (society, education, etc) that show how good creations can last decades or more. Most don't, but they have at least a chance of doing it.
The idea that a program or code can't survive 10 or 20 years without severe rewriting, because of a choice in its design (eg programming language, framework), is really bad. A similar argument can be made about a lot of modern car designs and DRM in digital works: we dislike the idea that they have an almost fixed use-by date.
I see choosing "new" languages as a very risky proposition to the life of a project. These languages are less likely to be around in ten or twenty years time (newer and better Rusts and Gos are likely to form in the years ahead) and in the meantime require you to constantly expend effort to prevent your projects from being turned into a brick by language/environment/library changes. In contrast my old C projects from 5-8 years ago still compile and run, with one particular example only needing a small modification. It's not perfect, but it's much safer.
TL;DR: "time safety" is more important than "memory safety" et al. We live in a world where time destroys more things than software bugs will ever be able to do. You should choose a language based off the biggest threats to the (integrated) usefulness of your projects, not based off the threats in your local (sampling) region. C is much more likely to last many times longer and much more stably than these new languages.
Should you care about code and software longevity if you are only making personal projects?
I still say yes. I want to be able to show and demonstrate projects I made "when I was young" to my kids, just like I will be able to show them old pictures of family. I want to be able to show them the lessons of my life, not show them that the only lesson is about "oh yeah we lost all of that".
It's always useful to be able to use old code from old projects too. Ideally perhaps even forever, but in our current world that's a longshot. But even code snippets that survive a few years are very useful. Contrast this to how many environment or framework specific code examples from the web that you have tried but found do not work any more -- you do not want your code becoming that.
Should we persue these new languages?
Yes, experimentation and development drive our society. But ordinary people using them, IMHO, provides minimal benefit compared to the problems it causes.
This is the same reason that we don't all drive prototype cars and wear prototype clothes. Overall it would cause more harm than good.
As such: I don't think it's responsible to ask ordinary programmers to start their projects in new languages.
-
If anyone wants to get their feet wet with embedded Rust, The Discovery Book is a introductory tutorial using the STM32F3DISCOVERY board. Fair warning, it is not a tutorial on the Rust language itself. There's also The embedded Rust book, and The embedonomicon for more in-depth coverage.
The (Rust) Discovery Book is nicely written and I think will be a great assistance to anyone interested in Rust on a Cortex-M3 Discovery. I'm a Cortex-m0 Forth user and not interested in Rust but I have spoken with some keen and dedicated Rust users who seem to have a habit of writing programs very useful to me, i.e. :
svd2rust: https://github.com/whitequark/svd2rust Register definitions are extracted from the DSLite supplied with the TM4C module of the Energia IDE, converted to SVD using ti2svd and generated as Rust code using svd2rust.
The MSP430xx SVD is created by Vadzim Dambrouski, https://github.com/pftbest/msp430_svd. Msp430_svd takes DSlite files released by Ti and processes them with the Rust programming language into SVD files suitable for Svd2mecrisp.
I consider understanding CMSIS-SVD a top priority for any Cortex-M embedded designer, and note that this was one of the areas that Rust programmers looked at and mastered, and in so doing even solved my problems, namely converting the Texas Instruments debug-related files in Energia that are basically a not-invented-here variant of SVD. This indicates to me that Rust *is* a serious embedded language.
This meant that I could add the MSP430 and TM4C MCU's to my list of autogenerated support files for Forth PLUS I could now auto generate Assembly support files and modify the Mecrisp source using CMSIS-SVD consistent naming.
-
Quote
Agreed, but neither should they stay with something when something better is available. For example, I was once offered a job in a company that made core memory when semiconductor memory was available!
You imply the difference between Rust and C++ is like the difference between core and semiconductor memory?
So with Rust your memory needs a tiny fraction of the space?
So with Rust your memory becomes thousands of times faster?
So Rust makes your memory super cheap?
As software engineering is not a physical device, the somewhat physical thing here is the engineer. And you say if this engineer is using Rust he will get these dramatic improvements?
Yours are the typical cheers of someone wanting to suggest a benefit to people - if they believe him - that never can materialize.Quote
You miss a critical point: presuming it is even possible that can only be achieved in a subset of C++. And every person/group/company chooses a slightly different subset.
Now try to guarantee your program's properties when using libraries from 10 different sources - you simply cannot.
They can choose, what is wrong with that?
It seems Rust only limits these choices, you say it is only for the "good", but maybe too intrusive or limiting, i don't know.
So you imply engineers are too stupid or lazy to deal with their freedom and responsibility to install proper coding guidelines and proper tools themselves, which is not as expensive as throwing everything old away, so they better submit to Rust?
This is quite pretentious, you know?
And why do you think over time (or even already) the available libraries in Rust will not just become quite similar, have similar problems, because after all it is more about the people doing them, not the slight variation of a language these are coded it in? -
Out of curiosity, what is your background and experience?
I'm a professional engineer that has been using C and other languages since 1981, and been designing and implementing systems ranging from low-noise analogue electronics and RF, through soft and hard realtime digital+software systems, to high availability telecoms systems. Hence I do have considerable experience in such systems work, and how they can fail.Quote
Agreed, but neither should they stay with something when something better is available. For example, I was once offered a job in a company that made core memory when semiconductor memory was available!
You imply the difference between Rust and C++ is like the difference between core and semiconductor memory?
So with Rust your memory needs a tiny fraction of the space?
So with Rust your memory becomes thousands of times faster?
So Rust makes your memory super cheap?
I don't imply that, so those statements are irrelevant.QuoteAs software engineering is not a physical device, the somewhat physical thing here is the engineer. And you say if this engineer is using Rust he will get these dramatic improvements?
Yours are the typical cheers of someone wanting to suggest a benefit to people - if they believe him - that never can materialize.
I don't understand what you are trying to say, but it looks like there are strawman arguments there.QuoteQuoteYou miss a critical point: presuming it is even possible that can only be achieved in a subset of C++. And every person/group/company chooses a slightly different subset.
Now try to guarantee your program's properties when using libraries from 10 different sources - you simply cannot.
They can choose, what is wrong with that?
The problem is that people make poor choices, some of which can be avoided by using a better tool.QuoteIt seems Rust only limits these choices, you say it is only for the "good", but maybe too intrusive or limiting, i don't know.
So you imply engineers are too stupid or lazy to deal with their freedom and responsibility to install proper coding guidelines and proper tools themselves,
That is indeed the evidence from the real world.
Read comp.risks. Every software and hardware engineer should do that, since it is low volume, carefully curated, and full of high quality examples from very experienced professionals.
Pay attention to technical news reports.
Look at the CERT advisories.
Very few people understand all the implications of all the various sections in all the various C and C++ standards. Those that do understand them have to spend far too much time working around boring low-level problems caused by the tools. It would be far better if they used their intellect to address problems inherent in the application they are creating.QuoteThis is quite pretentious, you know?
I expect English is not your first language.QuoteAnd why do you think over time (or even already) the available libraries in Rust will not just become quite similar, have similar problems, because after all it is more about the people doing them, not the slight variation of a language these are coded it in?
I anticipate that, over time, there will be problems with such libraries. But they will be new problems associated with being able to address applications that are not very practical in existing languages - especially those related to networking and NUMA multicore processors.
-
Out of curiosity, what is your background and experience?
I'm a professional engineer that has been using C and other languages since 1981, and been designing and implementing systems ranging from low-noise analogue electronics and RF, through soft and hard realtime digital+software systems, to high availability telecoms systems. Hence I do have considerable experience in such systems work, and how they can fail.
"How they can fail" ... the most important experience a designer can get imho.
-
Out of curiosity, what is your background and experience?
I'm a professional engineer that has been using C and other languages since 1981, and been designing and implementing systems ranging from low-noise analogue electronics and RF, through soft and hard realtime digital+software systems, to high availability telecoms systems. Hence I do have considerable experience in such systems work, and how they can fail.
"How they can fail" ... the most important experience a designer can get imho.
Beginners and amateurs/hobbyists concentrate on how things work. Professionals concentrate on how things fail, and design to avoid the failures as far as possible.
Frequently such design appears to be "a tail that wags the dog" and "overly complex". Classic examples are the detailed requirements of various mains electrical installation codes.
Beginners then think the details aren't important, decide they can do without them, and make subtle old mistakes that should be avoided. -
So you imply engineers are too stupid or lazy to deal with their freedom and responsibility to install proper coding guidelines and proper tools themselves
Only the ones not considering alternative languages to avoid the common memory errors in C.
Which until recently was far far too many of them. They'd rather kludge on with tools and coding practices which can't even guarantee absence of those memory errors. Like good old MISRA C ... fat lot of good that did THREADX. -
So you imply engineers are too stupid or lazy to deal with their freedom and responsibility to install proper coding guidelines and proper tools themselves
Only the ones not considering alternative languages to avoid the common memory errors in C.
Which until recently was far far too many of them. They'd rather kludge on with tools and coding practices which can't even guarantee absence of those memory errors. Like good old MISRA C ... fat lot of good that did THREADX.
No need for a new language, just use smart pointers (which you can have since >20 years in C++), std::string, std::vector, etc. and proper coding techniques. -
So you imply engineers are too stupid or lazy to deal with their freedom and responsibility to install proper coding guidelines and proper tools themselves
Only the ones not considering alternative languages to avoid the common memory errors in C.
Which until recently was far far too many of them. They'd rather kludge on with tools and coding practices which can't even guarantee absence of those memory errors. Like good old MISRA C ... fat lot of good that did THREADX.
No need for a new language, just use smart pointers (which you can have since >20 years in C++), std::string, std::vector, etc. and proper coding techniques.
The "escape clause" in any such guarantee is, of course, "and proper coding techniques".
Even without smart pointers, there are "proper coding techniques". Demonstrably programmers don't use them, so smart pointer will be convenient but insufficient.
Alternatively, if programmers did use "proper coding techniques", then smart pointers would be convenient but unnecessary.
That's the problem with the real world: you have to assume imperfect people, and choose your strategy to take that into account. Hence, if C++ is the answer, just what was the question? -
Out of curiosity, what is your background and experience?
I'm a professional engineer that has been using C and other languages since 1981, and been designing and implementing systems ranging from low-noise analogue electronics and RF, through soft and hard realtime digital+software systems, to high availability telecoms systems. Hence I do have considerable experience in such systems work, and how they can fail.
Someone might note that you could have used C++ then instead of C as it was a way to avoid common errors, improve abstraction and ease coding.
A very successful and quite groundbreaking way, back then and still today.QuoteQuote
Agreed, but neither should they stay with something when something better is available. For example, I was once offered a job in a company that made core memory when semiconductor memory was available!
You imply the difference between Rust and C++ is like the difference between core and semiconductor memory?
So with Rust your memory needs a tiny fraction of the space?
So with Rust your memory becomes thousands of times faster?
So Rust makes your memory super cheap?
I don't imply that, so those statements are irrelevant.
So we agree? Rust is not significantly "better", definitely not worth discarding all proven?QuoteQuoteQuoteYou miss a critical point: presuming it is even possible that can only be achieved in a subset of C++. And every person/group/company chooses a slightly different subset.
Now try to guarantee your program's properties when using libraries from 10 different sources - you simply cannot.
They can choose, what is wrong with that?
The problem is that people make poor choices, some of which can be avoided by using a better tool.
And people always will. Look at history. The most persistent thing is human nature, making poor choices but also good choices that brought us into our world today.
It also looks like the effort spent to stop people from making presumably bad choices is less effective than just giving people choices and make them responsible for their choices.
Of course you have to be careful with whom you can give how much choices and responsibility. -
The "escape clause" in any such guarantee is, of course, "and proper coding techniques".
Even without smart pointers, there are "proper coding techniques". Demonstrably programmers don't use them, so smart pointer will be convenient but insufficient.
Alternatively, if programmers did use "proper coding techniques", then smart pointers would be convenient but unnecessary.
That's the problem with the real world: you have to assume imperfect people, and choose your strategy to take that into account. Hence, if C++ is the answer, just what was the question?
You call smart pointers in C++ unnecessary but convenient and advertise Rust having a kind of elaborated smart pointer implicitly built in?
I think you made my point clear, thank you. -
Out of curiosity, what is your background and experience?
I'm a professional engineer that has been using C and other languages since 1981, and been designing and implementing systems ranging from low-noise analogue electronics and RF, through soft and hard realtime digital+software systems, to high availability telecoms systems. Hence I do have considerable experience in such systems work, and how they can fail.
Someone might note that you could have used C++ then instead of C as it was a way to avoid common errors, improve abstraction and ease coding.
A very successful and quite groundbreaking way, back then and still today.
Oh, I did look at C++ and Objective-C in 1988. C++ didn't add any significant practical benefits, and introduced a whole new lot of traps. Even Soustroup said (and says) as much. If you dout
that, have a look at the C++ FQA, and alternately weep and giggle. https://yosefk.com/c++fqa/
Objective-C did add benefits, since it took inspiration from Smalltalk.
In the early 90s the committee(s) spent at least a year discussing whether it should be impossible to "cast away const", or whether that was a necessary ability - there are good rationales for both. I, and others, took the attitude that if that couldn't be easily resolved, something was rotten in the state of Denmark.
When Java appeared in 96, it was very notable how many significant libraries were instantly available, and how they interplayed nicely with other libraries. C++ had totally failed to achieve that in a decade of development!
Again, I ask "what is your background and experience?". The reason I ask is because your statements are typical of those that have some small-scale experience of a language, but have little experience of how things work (and fail) in larger, longer-lived projects.
-
The "escape clause" in any such guarantee is, of course, "and proper coding techniques".
Even without smart pointers, there are "proper coding techniques". Demonstrably programmers don't use them, so smart pointer will be convenient but insufficient.
Alternatively, if programmers did use "proper coding techniques", then smart pointers would be convenient but unnecessary.
That's the problem with the real world: you have to assume imperfect people, and choose your strategy to take that into account. Hence, if C++ is the answer, just what was the question?
You call smart pointers in C++ unnecessary but convenient and advertise Rust having a kind of elaborated smart pointer implicitly built in?
The detailed differences are important, both practically and theoretically. A key consideration is not any one feature in isolation, but how the sum of the features work together.QuoteI think you made my point clear, thank you.
If you think that, then you understand less than you think. -
Oh, I did look at C++ and Objective-C in 1988. C++ didn't add any significant practical benefits, and introduced a whole new lot of traps. Even Soustroup said (and says) as much. If you dout
Its a pity Stroustroup didn't look more closely at Objective-C. It has better functionality than (at least the early) C++, but I find the syntax of C++ more readable. Readable is good for reducing stupid errors.
that, have a look at the C++ FQA, and alternately weep and giggle. https://yosefk.com/c++fqa/
Objective-C did add benefits, since it took inspiration from Smalltalk.
More than this I wish there had been a true C++. A genuine incremental step from C that includes the basic structuring aspects of C++, like classes, but doesn't have all the stuff that can have serious performance issues, but only benefits a few applications. Sure, you can use C++ and try to avoid that stuff, but it only takes one slip.....
-
Oh, I did look at C++ and Objective-C in 1988. C++ didn't add any significant practical benefits, and introduced a whole new lot of traps. Even Soustroup said (and says) as much. If you dout
Its a pity Stroustroup didn't look more closely at Objective-C. It has better functionality than (at least the early) C++, but I find the syntax of C++ more readable. Readable is good for reducing stupid errors.
that, have a look at the C++ FQA, and alternately weep and giggle. https://yosefk.com/c++fqa/
Objective-C did add benefits, since it took inspiration from Smalltalk.
That would never have happened:- the philosophy was too different. Objective-C took one known good idea and implemented it simply and effectively. Soustroup made the deliberate choice to avoid making a choice, thus forcing every developer thereafter to make their own choices
- they were developed at the same time
- the C/C++ community traditionally ignores what is happening in other communities, whereas the Java (and other) communities have a far wider knowledge and select harmonious concepts from whereever they can find them. That is visible if you look at the references of academic papers. C/C++ reference other C/C++ papers, whereas Java (etc) reference a wider range of papers
Rust is avoiding that inward looking dysfunction, so it stands a chance.QuoteMore than this I wish there had been a true C++. A genuine incremental step from C that includes the basic structuring aspects of C++, like classes, but doesn't have all the stuff that can have serious performance issues, but only benefits a few applications. Sure, you can use C++ and try to avoid that stuff, but it only takes one slip.....
Yes, yes, and yes that's the problem that even Soustroup acknowledges. -
Again, I ask "what is your background and experience?". The reason I ask is because your statements are typical of those that have some small-scale experience of a language, but have little experience of how things work (and fail) in larger, longer-lived projects.
This is your argument? What about the subject?
So you say only what you call a "large scale" and "long lived" project is a valid project?
You again expose yourself as a authoritarian supremacist, but i hope you are retired and don't bother engineers anymore.
Your statements are typical of a bureaucrat that likes to take his place of power in the hierarchy of a big company, not being productive but more a politician or even activist.
I can assure you, even without your "advice", people will succeed in solving their problems adequately in their way, just as they did before you. -
The detailed differences are important, both practically and theoretically. A key consideration is not any one feature in isolation, but how the sum of the features work together.
These inconsistencies are called progress, of which C++ has made a lot since 11.
And surely the "inconsistency" of abandoning C++ totally is bigger.QuoteIf you think that, then you understand less than you think.
I at least gave a explanation why i came to my conclusion, you just imply i don't understand.
"You don't understand anything!" - a well known ultimate "Argument". -
I promised myself I'd stay out of this one, but I can't watch someone vigorously defending C++ as possible to write something safe in with STL and proper coding standards. To err, is human, and to err when the only tool you have is C++ is inevitable and a lot of the time no one in the company knows there's a big err. Programmers have always been arrogant enough to suggest that self-imposed rules and constraints are enough to prevent whole classes of defects, but they are wrong. That assumes humans are perfect, which they are not.
std::string a = "a";
std::string_view b = a + "b\n";
std::cout << b;
Spot the problem. A "thanks" to anyone who finds it in such a simple example. It requires that you truly understand how the compiler works.
Also lets remember that STL implementations vary in quality and some things are statically compiled with "some old shit from the 90s" or a variant of it...
To note, I don't write C++ any more. It's basically my job to persuade people not to write C++. I prefer to recommend C# these days. It has a decent type system, standard library and compilers, it's fast, the tools are good, humans exist who are moderately productive and it solves problems without turning everything into CVE factories. You can concentrate on the implementation bugs and constraints rather than the shaky foundation you build your crap pile on. The crap piles I deal with are around the 2-30 MLOC sized "platforms" not trivial stuff.
Final comment: C++ even at the latest and greatest version is a chunk of emmental where someone has attempted to putty up some of the holes on it and put a cloth over the mouldy bits.
I make no comment on rust. I don't use it. It's not mature. When it has been around for about 10 years, or ThoughtWorks come up with a condensed motivational paper for using it, I will evaluate it, but not before! -
Google uses smartpointers and has a ton of fuzzers/etc and still they get exploitable overflows and use after free.
-
Again, I ask "what is your background and experience?". The reason I ask is because your statements are typical of those that have some small-scale experience of a language, but have little experience of how things work (and fail) in larger, longer-lived projects.
This is your argument? What about the subject?
So you say only what you call a "large scale" and "long lived" project is a valid project?
You again expose yourself as a authoritarian supremacist, but i hope you are retired and don't bother engineers anymore.
Your statements are typical of a bureaucrat that likes to take his place of power in the hierarchy of a big company, not being productive but more a politician or even activist.
I can assure you, even without your "advice", people will succeed in solving their problems adequately in their way, just as they did before you.
Your as hominem attack is very wide of the mark.
Given that you continue to avoid telling us your experience and background, I think we are justified in presuming you have little real world experience of creating medium or large commercial programs.
Experience does matter. It makes you humbler and more aware of how difficult it is to avoid things failing. -
Code: [Select]
std::string a = "a";So... What happens?string_view gives you read-only access to another string, but a+"b\n" is just an rvalue without permanence (or is it?) Do you get a pointer off into space that no longer exists, or some sort of memory leak?
std::string_view b = a + "b\n";
std::cout << b;
To some extent, this demonstrates why I prefer simpler languages (like C, or very minimal C++) - It's one thing to write code that is bad (and you can look at it and see that it is wrong), and another to have some obscure language feature buried deep in some library that doesn't behave quite the way you thought it did (and most "modern" languages LOVE "obscure features for library writers.")
On the third hand, it's difficult to write complex programs without complex libraries from "someone else."
-
Correct. It's a use after free
So easy to fire a footgun it's unreal.
Same thing in C#
var a = "a";
var b = a + "b\n";
Console.WriteLine(b);
Literally no concern. Compiler assumes programmer is a dumbass
-
Your as hominem attack is very wide of the mark.
Given that you continue to avoid telling us your experience and background, I think we are justified in presuming you have little real world experience of creating medium or large commercial programs.
Experience does matter. It makes you humbler and more aware of how difficult it is to avoid things failing.
Again, no arguments, but you solicit something for your ad hominem attacks which you even project on me.
It is because you have no valid arguments for your claim we all should use Rust to make it into the brave new wold.
And surely does experience matter.
Because of this i question abandoning all experience with a old tool, get a new toy because you are told it will solve all your problems.
Experience tells me the first problem is myself when using the tools available to me, then the tools.
Scott Adams said you can't schedule stupidity.
The old stupidity will just find new ways to manifest.
And my experience also made me aware of your kind of activists that appeal to narcissistic people by telling them it is not them who are inferior but the tools they are using. -
Can we turn off the "usenet circa 1995" part of this thread and concentrate on the technical arguments.
-
I prefer to recommend C# these days.
This is a electronics forum, about mostly embedded systems.
Who in his right mind will use a garbage language, meaning a automatic garbage collected only, indeterministic, factually vendor proprietary language and eco-system there?
Possibly only someone who can't handle a gun, always shoots himself in the foot and thus wants to ban all guns.
The "bad boys" will always keep their guns.
And about your string_view example, the language allows you to do optimizations crucial in embedded or systems programming that simply aren't possible in less deterministic managed languages, and it's misuse can be detected by tools, either if it happens by accident, incompetence or even intentional like in your example.
And possibly there are people that want to do bloated toy embedded systems with managed languages, because the alternative is too difficult for them, but i suspect they don't earn much because the customer tends to buy what bangs most for his buck.
You see it with something like the Raspberry PI, or Adruino, for example.
The money there is made by selling people something that makes them feel they are a "maker", but what they "design" hardly makes any money by selling it, but of course he may tell others how great it is and increases sales of the "maker" supplies.