SoylentNews is people
SoylentNews
Eric S Raymond, author of "The Cathedral and the Bazaar", blogs via Ibiblio
I wanted to like Rust. I really did. I've been investigating it for months, from the outside, as a C replacement with stronger correctness guarantees that we could use for NTPsec [a hardened implementation of Network Time Protocol].
[...] I was evaluating it in contrast with Go, which I learned in order to evaluate as a C replacement a couple of weeks back.
[...] In practice, I found Rust painful to the point of unusability. The learning curve was far worse than I expected; it took me those four days of struggling with inadequate documentation to write 67 lines of wrapper code for [a simple IRC] server.
Even things that should be dirt-simple, like string concatenation, are unreasonably difficult. The language demands a huge amount of fussy, obscure ritual before you can get anything done.
The contrast with Go is extreme. By four days in of exploring Go, I had mastered most of the language, had a working program and tests, and was adding features to taste.
Have you tried using Rust, Go or any other language that might replace C in the future? What are your experiences?
(Score: 3, Insightful) by Anonymous Coward on Monday January 16 2017, @08:58PM
What's wrong with C and C++? Oh wait, right... you actually have to *know* what you're doing when using these tools...
(Score: 0, Informative) by Anonymous Coward on Monday January 16 2017, @09:31PM
What's wrong is there are programs written in C which are older than the average coder. Unix people are old or dead and old code is old and old is bad. It's a new generation of coder people and they need to rewrite everything because no way are they going to maintain dead people's code in a dead language.
Linux needs a rewrite but Linus just won't die soon enough.
(Score: 0) by Anonymous Coward on Monday January 16 2017, @09:56PM
"Inspectis ante laminis, tollere de curru equorum."
(Score: 4, Insightful) by ledow on Monday January 16 2017, @10:24PM
Old = stable, targettable, tested.
From a security perspective, sure, it needs to be maintained but are you suggesting C projects are any less likely to be maintained than a program written in a language only a handful of years old and not deployed in any major project?
I don't get that people think that "new" languages are any better from this kind of perspective. You have to think of how many people CAN maintain a project. Rust is a niche language, still, C is not. You can find a C programmer with an advert in a newspaper, I've never met anyone who programs in Rust seriously.
People are attracted to languages they can learn, maintain, and which can extend with them, and if Rust is this tricky to get started in, people aren't going to flock to it. That's a death-knell for such a language.
(Score: -1, Flamebait) by Anonymous Coward on Monday January 16 2017, @10:27PM
I've never met anyone who programs in Rust seriously.
You're old and young people won't talk to you. Have you considered suicide.
(Score: 2) by rleigh on Monday January 16 2017, @10:57PM
> I've never met anyone who programs in Rust seriously
I've never met anyone who programs in Rust *at all*!
Rust annoys me. It's not the language, it's the incessant hype around it, as though it were the second coming. It's not the only one, Go is almost as bad, and Swift isn't much better. I can't abide the thoughtless fanboyism behind the hype; at least be truly honest about both its advantages and its shortcomings.
I'm a scientific C++ programmer primarily (and C, Perl, Python, Java, R and others as needed). I'm not averse to new languages and new ways of doing things, but I might just hold off on investigating Rust in detail until a few years have passed. If it's still around, then maybe it might be worth my time. I've never worked in any other field which was so influenced by new and shiny over tried and tested. I wouldn't mind so much if the new and shiny was actually better, but it's often less well designed and implemented than the older stuff.
(Score: 3, Insightful) by ledow on Tuesday January 17 2017, @01:04AM
Same for me, but the languages I use are generally a little older.
I remember PHP coming in and was going to solve all those horrible Perl CGI security problems - yeah, that worked a treat! (What's Soylent running? *cough*)
I remember Java going to be write-once-run-anywhere. It almost made it too. But the fact is that 90% of the Java programs I see are locked to a platform one way or another. In the last month alone I've had to update Java modules on photocopiers, a library system and an access control system. Because the first was using a feature that not all photocopier's JavaVM's implemented, the second demanded Java 1.8 for some feature or other (prompting JRE updates on 200+ machines) - and incidentally it only uses Java on PC and on other platforms they rewrote in something else entirely, and the third has to stay on ancient-Java if it's to work at all.
I remember all kinds of "We're going to fix C" languages, whether they were structures in the language itself, or rewrites, or incompatible but similar languages. We still write in C. The languages are mostly dead now but some spawned some of the ones you mention.
I tried to run a program in Python the other day. It took ages to get a compiler that worked, and then it ran into all kinds of problems (something to do with incompatibilities between Python 2.5 and OpenSSL libraries that had never been fixed?), and then the Python program wouldn't compile anyway, and it would have had required further tweaking to get it working on other platforms.
C is probably the language that has changed the least. There's not much written in C that won't run on a modern compiler, and if you stick to even C99 (18 years old at least!) you get even better chances of success. That's probably why we stick with it.
(Score: 3, Insightful) by NCommander on Tuesday January 17 2017, @07:11AM
I'll note for the record if I recoded rehash today, it won't be in Perl, and I would be very hesitant to start any new projects in Perl. Realistically, for performance reasons, I'd consider Ruby, a fast Python implementation, or even possibly Java; I might even consider Rust based on my previous experiences with the language. We've been in a LOT of pain because some of the poor design decisions made for perl web applications; specifically binding the request ($r) object to Apache internal structures. A lot of the codebase changed due to subtle behavior changes in $r, such as the ability write back to form variables, and them later. I had to write a shim to copy the array in initialization to get the old schematics back. It took several weeks of dedicated effort to migrate us to an Apache of this century.
Because there's no standardized (de-facto or other) way to get fast performance, it's not trivial to migrate an existing application from one framework to another. Right now, the leaning feeling of the staff is the next time we get a breaking API change with Apache, we're going to rip it out and migrate the mess to fastCGI and possibly switch nginx. This creates a process barrier to help reduce crashes, and at least in theory makes our life suck less since FastCGI has been relatively stable API vs. Apache's mod_perl. We still can't use Apache 2.4 due to broken dependencies all over the ecosystem. Even once all the dependencies are available for 2.4, I'm expecting I'm going to have to apply a fresh set of hacks to keep things lumbering on.
Furthermore, I've had plenty of C code go bang trying to switch compilers. For old K&R or C89 code I could understand it, but I've seen C99 code explode on different versions of GCC when you switch platforms or compilers because someone did something stupid and was depending on uninitialized data. I don't have much issue with C itself though I question the validity of using it for anything beyond system-level programming where you have both experience and the need for direct memory access. Userland applications are a lot harder to justify because a typo is a security hole.
Still always moving
(Score: 2) by NCommander on Tuesday January 17 2017, @07:14AM
If you're getting C programmers from a newspaper, you'll end up having to hire someone like me who's made a good part of his living cleaning up people's messes. A recent firmware program was done by very cheap bidding, and the resulting code quality was filled with memory initialization errors, deadlocks, and plenty more issues along that way such as dangling pointers. I've used Rust pretty heavily for a personal project that I may try selling in the future, and I'm all around happy with it as it prevents you from blowing off a foot.
Even dealing with nearly a decade of C experience I've made mistakes that weren't obvious at first, and a linter sometimes fails to catch. I rather be in a world where I can't make those mistakes than one where something could slip by.
Still always moving
(Score: 2) by Bethany.Saint on Monday January 16 2017, @10:30PM
We need to change society so that people only live till 30. Once they reach 30 we give them a big celebration whereupon we kill them. This would truly be a utopia.
(Score: 3, Insightful) by bob_super on Monday January 16 2017, @10:41PM
Considering the number of people under 30 who have mastered the subtleties of advanced analog design, it will soon be a no-tech utopia.
(Score: 0) by Anonymous Coward on Monday January 16 2017, @10:42PM
Referencing a book from 50 years ago? How old of you.
No, we don't kill people over 30. We don't celebrate them. We ignore them. We exclude them from society. Presumably they kill themselves or starve to death or something. Life doesn't exist after 30.
(Score: 2) by BasilBrush on Tuesday January 17 2017, @06:21AM
Pedantry mode: Actually he's referencing a film. In the book, the Lastday comes when people reach 21. Take that young programmers!
Hurrah! Quoting works now!
(Score: 0) by Anonymous Coward on Monday January 16 2017, @11:02PM
We need to change society so that people only live till 30. Once they reach 30 we give them a big celebration whereupon we kill them. This would truly be a utopia.
That's not a bad idea! We'd need to give the celebration a festive sounding name, what do you think of "Carrousel"?
We'd also, at least at first, feed them a line about being reincarnated afterwards. That way, they're not going to their deaths, they're going to "renew" themselves. Catchy! Sounds like a decent movie setting, if you can get a decent set of twentysomthing actors involved. Back in her prime, Farrah Fawcett [imdb.com] would have been a great choice for this.
=P
(Score: 2) by Fnord666 on Tuesday January 17 2017, @05:42AM
(Score: 2) by choose another one on Tuesday January 17 2017, @08:52PM
> Back in her prime, Farrah Fawcett would have been a great choice for this
Yeah but in that timeframe, someone like Jenny Agutter would have been really awesome, gotta Walkabout a bit before you run...
(Score: 1, Touché) by Anonymous Coward on Tuesday January 17 2017, @04:05AM
(Score: 2) by meustrus on Monday January 16 2017, @09:54PM
Yeah, you and everybody else conspiring with you on an open source project. Don't ever forget all the undocumented details of file X among 200 other files with just as many idiosyncrasies. I'm sure everybody else knows how it works anyway.
Any successful project will eventually be held back by how long it takes to effectively review a pull request.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: 1, Funny) by Anonymous Coward on Monday January 16 2017, @10:01PM
Any successful project will eventually be held back by how long it takes to effectively review a pull request.
That's easy. Was the pull request on the wishlist of features we wish contributors would do for us? If yes, accept the pull request if the continuous-integration thing said it compiled. If no, ignore forever.
(Score: 3, Insightful) by shipofgold on Monday January 16 2017, @10:16PM
IMHO the language that it is written in has no bearing on the undocumented details of file X.
The age of the project has a huge bearing on it. Take any give software project and start with today's requirements (as opposed to the initial requirement and all the mods done over the years) and the re-write will look completely different.
I doubt that after 20 years of changes/updates/new featuers a rust or go program will look any better.
(Score: 0) by Anonymous Coward on Monday January 16 2017, @10:31PM
I doubt that after 20 years of changes/updates/new featuers a rust or go program will look any better.
ding ding ding, and we have a winner. The reason that there are no horror-codebases in Rust is because there are no codebases in rust...
(Score: 2) by meustrus on Tuesday January 17 2017, @02:59PM
Different languages have different levels of referential transparency. This is a key concept that describes, among other things, whether you actually know what a function does based solely on its method signature. When you convert an existing function with all kinds of side effects (memory management, throwables, write-only API calls, networking, etc.) to a completely referentially transparent function, you tend to end up with a huge mess of templates/generics wrapping your result. That shows you the full complexity of what you were doing all along, but it makes the function really hard to deal with because you have to handle every single eventuality. A referentially transparent function will cause compiler errors if you don't.
Rust makes pointers more referentially transparent, thereby making them safer while making them harder to use. In this case Raymond has found the safety not worth the trade-off in ease of use. Which raises the question: if propagating or handling the side effects of memory management is necessarily this hard, should we ever do it to begin with?
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: 4, Insightful) by turgid on Monday January 16 2017, @10:16PM
The problem with C++ is that it keeps getting bigger and bigger and bigger and...
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 0) by Anonymous Coward on Monday January 16 2017, @10:51PM
Yeah, but the good subset keeps getting more and more and more well defined.
(Score: 2) by rleigh on Monday January 16 2017, @11:21PM
Why is this a problem? The subset of C++ you knew before the new standard comes out is just as valid afterward. If I use C++98, I can carry on using it indefinitely. My work projects made the switch to C++11 just last week, six years after it came out, and many projects will never switch. The new keywords are optional, but make the language vastly easier to use, likewise with the library features. I for one am not complaining; it's a long overdue improvement that actually makes the language easier and safer to use. Use the subset of the language and library that makes sense for your project, and ignore the rest.
(Score: 2, Insightful) by Anonymous Coward on Tuesday January 17 2017, @01:53AM
The problem is that C++ is an insanely complicated language and the 80/20 rule applies: 80% of C++ programmers know at most 20% of the language.
The real kicker is that no two programmers are likely to know the same 20%.
C++ appears to be designed under the assumption that extra features cannot cause any problems, only missing features can. But C++ features often have complex interdependencies that very often mean that you can't just avoid using them.
(Score: 5, Insightful) by cubancigar11 on Tuesday January 17 2017, @04:18AM
You are assuming everyone is working on their pet project. The biggest problem of C++ is that it is extremely difficult to market. Every project is working on a subset of language and every interviewer wants someone who knows exactly that subset.
(Score: 0) by Anonymous Coward on Monday January 16 2017, @11:28PM
Which C/C++? C++11? C++14? Because C++ has changed a lot over the years. I don't mean the core language so much, of which most changes were only minor tweaks, such as ways to reduce some of the pointer syntax, and declare constants. Namespaces are possibly the biggest of the older changes to the core. More recent is this "auto" return type. The change I'm thinking of is the addition of the Standard Template Library, which, it could be argued, isn't integral to the language at all, any more than stdio or string ever were.
Perl was hot when it was the best regex engine readily available. Then we had PCRE for C/C++, which makes the use case for Perl weaker. Hashes? C++ has that too, in STL Maps. Other parts of STL cover other native features of Perl. So what does that leave for reasons to pick one over the other? C++ still has ugly pointer syntax, but Perl's syntax is loaded with the ugliness of sigils. C++ has a larger ecosystem. Yet Perl has tons of wrapper libraries to access all these useful C libraries. Perl 6 supposedly improved greatly over Perl 5 in ability to call C library functions, which could remove that reason to pick C++ over Perl. They're both curly brace languages. Maybe fast compiling is a reason to pick Perl over C/C++? But really, why not ditch both for Python?
(Score: 2) by rleigh on Monday January 16 2017, @11:46PM
Minor nitpick, in the C++ standard library map is a red-black tree; you want unordered_map for a hash map.
(Score: 3, Funny) by Ethanol-fueled on Monday January 16 2017, @11:52PM
Because Python is clumsy and retarded.
Python is a language one uses because they don't know C/C++/Perl well enough to avoid blowing up their call stack or reading from unallocated memory.
Oh, shit. I've been trolled again.
(Score: 0) by Anonymous Coward on Monday January 16 2017, @11:38PM
Nothing is wrong with them, but there're a lot of idiots who like to blame their own deficiencies on the languages they failed to properly utilize. They write shitty, unsafe code like the incompetent fuckwits they are and then it's the language's fault, so a new language with more crutches and automatic turd polish has to be fabricated to alleviate the inconveniences.
(Score: 3, Informative) by HiThere on Tuesday January 17 2017, @12:38AM
What's wrong with C is huge numbers of programs with buffer overflows, memory leaks, etc.
Also, it's a pain to work with hash tables, etc. in C. I've done it, but it's a real pain, so I often (recently invariably) use something else. I also don't like C++'s STL. D is much better. Even Ada is better, but it's got other problems. Also both C and C++ are terrible at handling unicode. I could list a few other reasons that they need replacing.
Ah...but with what? That's the real problem. I think that D is a generally superior replacement for C++, but I haven't a clue as to what a better replacement for C would be. (Neither Go nor Rust come even close to filling the bill.) I've got a few opinions as to what some of it's features should be, e.g. it should be difficult to reinterpret an integer as a pointer and conversely. (Not impossible, just difficult.) Conversion operations should be clearly separated from reinterpretation. (C++ is doing that, but backwards compatibility keeps it insecure.) Both utf32 and utf8 libraries, and conversions between them should be parts of the standard. (And the standard should require at least isapha, isalphanumeric, ispunct, isspace be defined for codepoints emitted by both the utf32 and utf8 libraries. The need for templates, macros, etc. should be strictly minimized. It should be between easy and trivial to avoid memory leaks. (There's more than one way to do this. I don't think which approach is used is as important as that it is done.)
Now clearly D doesn't fit this prescription, as it makes heavy use of templates, though it does minimize the need for macros. And anyway it's much too heavy a language to be a C replacement. Go and Rust both make stabs at being the appropriate language, but neither really feels right. Both appear to be trying to be light-weight C++ replacements rather than C replacements. And neither seems generally superior (to C++), though both are safer, and both are superior in their handling of unicode. (I think Rust borrowed it's approach from Go, as the term "rune" is used by both for a codepoint.)
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 0) by Anonymous Coward on Tuesday January 17 2017, @01:40AM
If you honestly don't know what is wrong with C++ yourself then there is no point even having the discussion with you...
Elitism in coding practice is just pathetic.
(Score: 2) by linuxrocks123 on Tuesday January 17 2017, @05:45AM
No language is perfect, and the comment you're replying to was not very constructive, but modern C++ is a very nice language.
I just wrote an interpreter for a subset of Java in C++ and am now writing an interpreter for a toy language in Java. Writing in Java, I had to copy-paste the same method four different times with only the type parameters different. In C++ I would have been able to use template functions, but Java generic methods weren't flexible enough. So now I have four methods with identical copy-pasted code, because of Java.
The power of C++ templates is unmatched by almost anything else in any other statically typed language anywhere. The runtime efficiency of C++ is unmatched by anything other than C or FORTRAN. Safety can be an issue, but, if you follow a modern coding style, you can avoid safety problems fairly easily. Oh, and you can get garbage collection in C++, if you want it, with the Boehm GC. Never manually freeing anything means never having use-after-free issues :)
C++ is definitely a complex language, and it has some really esoteric stuff like rvalue references, but you can jettison a lot of that complexity if you're starting a new program from scratch, because much of it is there just for backwards compatibility.
For instance, if you're writing from scratch, you can use an std::variant instead of a union. So you don't need to learn or think about the union part of the language, if you're starting a new program from scratch.
(Score: 3, Insightful) by tonyPick on Tuesday January 17 2017, @07:32AM
And you're not having to deal with a third party framework that needs you to understand the union part of the language, and you're not having to deal with other programmers some of whom *want* to use the union part of the language because they understand it better than the variant stuff, and you're not having to deal with a compiler/platform that doesn't understand C++17 features, and... and... and...
So it's great solution for a pet project, but as soon as you nave to build code involving other people and larger systems you're dealing with variants in addition to union, as well as the "esoteric stuff like rvalue references" (which were themselves supposed to solve problems), and manual memory management, and a grab bag of other stuff that's been thrown into the language and which often interact in strange and unexpected ways.
(Score: 2) by linuxrocks123 on Tuesday January 17 2017, @05:37PM
- The collaboration stuff you mention is what coding standards are for.
- Frameworks mostly don't make use of anything remotely obscure in their outward-facing APIs.
- Regarding rvalue references, they cause no problems. They're specifically designed so that you can completely ignore them if you want; you just won't get the performance benefits if you do.
Actually, even if you do ignore rvalue references, you'll still get the benefits when you use rvalue reference-enabled STL containers. What a deal.
(Score: 2) by tonyPick on Wednesday January 18 2017, @08:04AM
very true, but unless you're running the whole show then the assumption that they're going to fit with your specific view of modern C++ is optimistic; for example I've seen guidelines that heavily restrict the coders from implementing functionality using template metaprogramming, which is a feature you seem quite keen on.
Everybody agrees you only need a "useful" subset of the language, but IME nobody actually agrees on what that subset is.
I wouldn't call unions (your example) as obscure; they're uncommon (mainly since C++ restricts you to default constructors for union members), but they're a routine part of the language, and quite common in places, particularly C-compatible style API definitions. Not to mention the wacky-hacky stuff you sometimes see on vendor specific APIs.
(And if you think unions are obscure but variants aren't then I'm guessing that you've never written a DBus client and had to figure out what an 'oa{sa{sv}}' actually contains)...
Since your OP mentioned them as "esoteric stuff" I'd figured to re-use them as an example - feel free to replace that with any feature of the language you personally hate, be that lambdas, assertions or whatever. It's not like C++ is exactly short on features to dislike :)
Sooner or later you will meet someone who will agree with you on the whole "why can't we all just use modern C++" thing, but will then name your pet hated feature as an essential part of the "modern" language. (Outside of manual memory management, perhaps, because everybody hates that).
(Score: 0) by Anonymous Coward on Wednesday January 18 2017, @09:57AM
Sounds like you should have had those objects implement an interface and have your function only take instances of said interface. Or you could have used attributes and had the function be auto-generated for each marked typed. There's are a few other ways to do it too. Mind posting your code? I'd love to see some identical code that simply can't be simplified.
(Score: 2) by linuxrocks123 on Wednesday January 18 2017, @05:37PM
///These four redundant methods should be a C macro or C++ template. Java is inadequate.
private static int do_operator(int x, int y, int op)
{
switch(op)
{
case '+': return x+y;
case '-': return x-y;
case '*': return x*y;
case '/': return x/y;
case '%': return x%y;
case Bolvangar.Lexer.EQUALS: return (x==y ? 1 : 0);
case Bolvangar.Lexer.NOT_EQUALS: return (x!=y ? 1 : 0);
case '<': return (x<y ? 1 : 0);
case Bolvangar.Lexer.LT_EQUALS: return (x<=y ? 1 : 0);
case Bolvangar.Lexer.GT_EQUALS: return (x>=y ? 1 : 0);
case '>': return (x>y ? 1 : 0);
case Bolvangar.Lexer.AND: return ((x!=0 && y!=0) ? 1 : 0);
case Bolvangar.Lexer.OR: return ((x!=0 || y!=0) ? 1 : 0);
default: assert false;
}
return -1;
}
///These four redundant methods should be a C macro or C++ template. Java is inadequate.
private static double do_operator(int x, double y, int op)
{
switch(op)
{
case '+': return x+y;
case '-': return x-y;
case '*': return x*y;
case '/': return x/y;
case '%': return x%y;
case Bolvangar.Lexer.EQUALS: return (x==y ? 1 : 0);
case Bolvangar.Lexer.NOT_EQUALS: return (x!=y ? 1 : 0);
case '<': return (x<y ? 1 : 0);
case Bolvangar.Lexer.LT_EQUALS: return (x<=y ? 1 : 0);
case Bolvangar.Lexer.GT_EQUALS: return (x>=y ? 1 : 0);
case '>': return (x>y ? 1 : 0);
case Bolvangar.Lexer.AND: return ((x!=0 && y!=0) ? 1 : 0);
case Bolvangar.Lexer.OR: return ((x!=0 || y!=0) ? 1 : 0);
default: assert false;
}
return -1;
}
///These four redundant methods should be a C macro or C++ template. Java is inadequate.
private static double do_operator(double x, int y, int op)
{
switch(op)
{
case '+': return x+y;
case '-': return x-y;
case '*': return x*y;
case '/': return x/y;
case '%': return x%y;
case Bolvangar.Lexer.EQUALS: return (x==y ? 1 : 0);
case Bolvangar.Lexer.NOT_EQUALS: return (x!=y ? 1 : 0);
case '<': return (x<y ? 1 : 0);
case Bolvangar.Lexer.LT_EQUALS: return (x<=y ? 1 : 0);
case Bolvangar.Lexer.GT_EQUALS: return (x>=y ? 1 : 0);
case '>': return (x>y ? 1 : 0);
case Bolvangar.Lexer.AND: return ((x!=0 && y!=0) ? 1 : 0);
case Bolvangar.Lexer.OR: return ((x!=0 || y!=0) ? 1 : 0);
default: assert false;
}
return -1;
}
///These four redundant methods should be a C macro or C++ template. Java is inadequate.
private static double do_operator(double x, double y, int op)
{
switch(op)
{
case '+': return x+y;
case '-': return x-y;
case '*': return x*y;
case '/': return x/y;
case '%': return x%y;
case Bolvangar.Lexer.EQUALS: return (x==y ? 1 : 0);
case Bolvangar.Lexer.NOT_EQUALS: return (x!=y ? 1 : 0);
case '<': return (x<y ? 1 : 0);
case Bolvangar.Lexer.LT_EQUALS: return (x<=y ? 1 : 0);
case Bolvangar.Lexer.GT_EQUALS: return (x>=y ? 1 : 0);
case '>': return (x>y ? 1 : 0);
case Bolvangar.Lexer.AND: return ((x!=0 && y!=0) ? 1 : 0);
case Bolvangar.Lexer.OR: return ((x!=0 || y!=0) ? 1 : 0);
default: assert false;
}
return -1;
}
(Score: 0) by Anonymous Coward on Tuesday January 17 2017, @06:57AM
Exactly. What's wrong with them is they aren't suitable for most programmers. Most programmers should be using other safer languages.
With C and C++ too often common simple mistakes like typos or buffers not being big enough can result in "attackers can execute arbitrary code".
With safer languages the level of wrongness/stupidity needs to be higher. Like not escaping stuff or not using bind variables/parameters for DB stuff, or even explicitly running arbitrary code from an unsafe source.
It's fairly easy for a half-decent programmer to always escape stuff and use bind params but it's not easy to never make an "arbitrary code execution" mistake in C/C++. The programmer has to make special effort to have an buffer overflow arbitrary code execution exploit in a Perl/Python/Java/Lisp program. If there's one it's probably in the library/interpreter's C code.
And performance in safer languages is often good enough. Many years ago I wrote a db-backed rules-based DHCP server in perl for work reasons. Performance was fine (in fact it handled hundreds or thousands of network interfaces much better and faster than ISC DHCPD - the target servers would often have many VLAN interfaces). There was far less danger of "attackers can execute arbitrary code" compared to ISC's dhcpd (which kept having exploits for quite a number of years: https://www.cvedetails.com/vulnerability-list/vendor_id-64/product_id-2017/ISC-Dhcpd.html [cvedetails.com] ).
(Score: 2) by darkfeline on Wednesday January 18 2017, @04:15AM
The problem with C is that for most projects, doing your own memory management is a waste of time.
The problem with C++ is that there are programmers who are dumb enough to think they're smart enough to use it competently.
Join the SDF Public Access UNIX System today!