Slashdot Mirror
Criticizing the Rust Language, and Why C/C++ Will Never Die
An anonymous reader sends an article taking a harsh look at Rust, the language created by Mozilla Research, and arguing that despite all the flaws of C and C++, the two older languages are likely to remain in heavy use for a long time to come. Here are a few of the arguments: "[W]hat actually makes Rust safe, by the way? To put it simple, this is a language with a built-in code analyzer and it's a pretty tough one: it can catch all the bugs typical of C++ and dealing not only with memory management, but multithreading as well. Pass a reference to an assignable object through a pipe to another thread and then try to use this reference yourself - the program just will refuse to compile. And that's really cool. But C++ too hasn't stood still during the last 30 years, and plenty of both static and dynamic analyzers supporting it have been released during this time."
Further, "Like many of new languages, Rust is walking the path of simplification. I can generally understand why it doesn't have a decent inheritance and exceptions, but the fact itself that someone is making decisions for me regarding things like that makes me feel somewhat displeased. C++ doesn't restrict programmers regarding what they can or cannot use." And finally, "I can't but remind you for one more time that the source of troubles is usually in humans, not technology . If your C++ code is not good enough or Java code is painfully slow, it's not because the technology is bad - it's because you haven't learned how to use it right. That way, you won't be satisfied with Rust either, but just for some other reasons."
Further, "Like many of new languages, Rust is walking the path of simplification. I can generally understand why it doesn't have a decent inheritance and exceptions, but the fact itself that someone is making decisions for me regarding things like that makes me feel somewhat displeased. C++ doesn't restrict programmers regarding what they can or cannot use." And finally, "I can't but remind you for one more time that the source of troubles is usually in humans, not technology . If your C++ code is not good enough or Java code is painfully slow, it's not because the technology is bad - it's because you haven't learned how to use it right. That way, you won't be satisfied with Rust either, but just for some other reasons."
No, I'm pretty sure the heat death of the universe will kill those languages
SJW's don't eliminate discrimination. They just expropriate it for themselves.
"... but the fact itself that someone is making decisions for me regarding things like that makes me feel somewhat displeased. C++ doesn't restrict programmers regarding what they can or cannot use."
That's exactly what I said about C vs. 360/Assembler 25 or more years ago. And I still prefer to code in Assembler.
No. Well...maybe. Actually, yes. It really just depends.
A programming language is better if it does one thing: Solves a particular type of general problem more efficiently and clearly than the language of comparison. The larger this set and scope of general problems, the better the language; the fewer corner cases hinder the language, the better the language.
You will find the integration of mathematical languages, physics languages, or graphics languages into a general programming language a pile of clutter and complication. They won't integrate with much of the language, or they'll complicate it, or they'll constrict it. This is why you have libraries in a language to do some general tasks (Box2d, PhysX APIs, etc.), low-level specialized assemblies (OpenGL CUDA, shader assembly), and specialized high-level languages (R, Matlab): these tasks are best integrated by interfacing with a black box that takes in a data set, runs it through a set of coded procedures, and spits out a result.
What makes a programming language "better" than state-of-the-art is its ability to supply general programming practices and functionality in an efficient way for humans. Classes that can be easily swiveled or overloaded or extended or polymorphed, but only in a way that a human being can reliably understand--that is, that a human being who has studied the language won't still struggle with understanding the workings of the language due to its conflict with the method of human thought. Code bodies which are simultaneously readable, maintainable, and efficiently executable. The ability to represent a wide variety of specialized tasks as API classes and functions, even if less effective than a specialized language, should someone seek to integrate physics or mathematics or cryptography or other such things with their program. All of these things, reflected in a way a human can grasp and use with fewer human-introduced defects, and also in a way that does not constrict the human from approaching the subset of programming tasks carried out in nearly 100% of code (imagine if 1 in 100 functions needed a specialized language, not a simple library API or raw programming code; even the Linux kernel is far less than 1% low-level assembly).
It is not valid to say that people are bad at programming in C++ because they are bad programmers; but it is valid to say that bad programmers will not become good programmers if given a good language. If we assume, for example, that Perl is terrible and Python is some form of holy perfection, then we can claim that Perl will cause a good, studied, skilled Perl programmer to make many more defects than a good, studied, skilled Python programmer will make in Python; indeed, our metric for whether Perl or Python is superior to one another would be both the speed at which a new inductee to the language can learn to code with similar defects--how much programming exposure over a variety of challenging tasks does a person need in order to use the language for tasks of similar complexity without creating defects? Swift, Rust, C#, and so forth will face the same challenges: what is the defect rate produced by the programmer, relative to the amount of effort and resulting skill of the programmer in the given language, and how does it compare to all other languages?
Bad languages will make good programmers produce more bad code. Good languages will not make bad programmers produce good code; they will enable good programmers to produce less bad code.
Support my political activism on Patreon.
Why did they name the programming language after the byproduct of the corrosion of iron?
Do not look into laser with remaining eye.
Amen to that. It's like the old argument of the GOTO keyword. Sure it can easily be abused. But for certain limited cases, it's a godsend for making clean code. As the OP says, if someone's a bad programmer, they're going to write bad code no matter what language is used. Straight-jacketing people as to what they can use may help newbies, but you end up constraining what experienced programmers can do.
It seems pretty ranty.
C is never going to die. C++ is never going to die. That's for unrelated reasons. There's vast bodies of solid, efficient, debugged code written in those two languages so it will take a long time to replace it all. C++ also isn't staying still so while there's the fight against the C legacy there are usually faster, cleaner, less verbose, safer and more obvious ways of doing things.
That said, rust seems pretty cool. The underlying machine model semantics aren't a world away from C/C++ (one of the few cases where that's an appropriate use) so I expect the compilers will catch up pretty soon especially as they will all sue the same back ends.
Rust does seem in many ways to be a good thing: a similar machine model to C/C++ with all the associated efficiency but combined with a type system which makes whole classes of nasty bug impossible.
My guess is that will make it feel restrictive, especially at first. Well, at first, I didn't really get all the new-fangled C++ shit with classes derivation and templates and whatnot and didn't really see what was wrong with hacking around with void* and casta the whole time. Then I realised I wasn't as smart as I thought.
So, to me, Rust is interesting. It has roughly the expressibility and speed of C++ (in theory), the same low resource usage but is memory safe.
SJW n. One who posts facts.
it's not because the technology is bad - it's because you haven't learned how to use it right
Well, technically this is an ideology... and it's not because this ideology is bad - it t's because they haven't learned when to use it right!
It will be better for me not to angry more fellow Slashdoter with my Greek lessons, but technology and ideology are both Greek words...
Antisthenes: "Wisdom begins by examining the words/names." - excuse my English, i am (slightly...) better with my Greek!
> the source of troubles is usually in humans, not technology
Exactly, and that's why C/C++ is bad. Humans are terrible at programming. This isn't an insult to anyone and it's not me trying to say "no one is as good a coder as I am." It's a statement of fact, and everyone - including you and me - is terrible at programming. The human brain did not evolve to program computers. Programming computers is just something we kind of stumbled upon by accident and we have been continuing to stumble and fumble and generally make fools of ourselves. This is why we desperately NEED languages to hold our hands. Ironically, in the early days of programming, when people seemed to have a more mature attitude towards the art, this was a commonly-accepted fact. That's why Fortran and Lisp were developed even though it was hard and time-consuming and expensive to write compilers for those languages in those days (only a handful of people around the world knew how to write a compiler) and the code produced by those languages was typically awful and strained already-poor hardware to its limits. And when C was developed, it was a HIGH-LEVEL language. It was the python or the scala of its day. It was designed as a labor-saving device, a way to write operating systems without fucking around with assembly. "Writing an operating system in a high-level language? You're fucking nuts!" And just like a proper high-level language, it held the programmer's hands and put major restrictions on what he was allowed to do, at least relative to assembly.
The modern programmer is a victim of luxury. His computers are powerful and he has a choice of thousands of languages, many of them really good. And like the rich bohemian who decides to live in filth for no reason, he thinks there's something impressive or 'cool' or 'edgy' about programming in a complex unstructured language. There isn't.
A fool and his hard drive are soon parted.
"To put it simple, this is a language with a built-in code analyzer and it's a pretty tough one: it can catch all the bugs typical of C++ and dealing not only with memory management, but multithreading as well. Pass a reference to an assignable object through a pipe to another thread and then try to use this reference yourself - the program just will refuse to compile. "
Why do we need another language to accomplish those things? Better IDEs, compilers and analyzer tools should be able to all that for existing languages. If you have a better paradigm for expressing algorithms that you think merits a new language, make that case, but complaints in the quote don't need that.
If your C++ code is not good enough or Java code is painfully slow, it's not because the technology is bad - it's because you haven't learned how to use it right.
While he is right, you can use C++ perfectly safely, or even assembly would be fine with a team of skilled programmers. And I'd rather work in assembly with a team of skilled programmers than in any language with incompetent programmers: we will produce better code and deliver faster.
That said, writing solid assembly takes intense attention to detail, and a higher-level language language does make things easier. A language that prevents you from making mistakes definitely has a place in the world.
"First they came for the slanderers and i said nothing."
So they've solved the halting problem?
They may have made some improvements and are capable of catching many bugs automatically but to say "all" is quite a stretch. I have yet to see a source code analyzer catch all mistakes and have a low false positive rate and a low false negative rate.
Or perhaps I'm reading too much into it and they are simply capable of detecting bugs of all the typical C++ bug categories.
Ascalante: Your bride is over 3,000 years old.
Kull: She told me she was 19!
Human fallibility or the language/compiler?
Spoken like someone who has no clue about the breadth and depth of the various programming paradigms available. The fact that he still considers inheritance as somehow essential just reveals his ignorance on the progress on comp sci over the past 20+ years.
Exceptions are more debatable, since we don't yet have a better error handling abstraction that scales from local to global error handling (checked exceptions are the best we have so far).
I don't even... So by this argument, C++ restricts me from using generators and first-class delimited continuations, so it's not good enough either.
This argument is both a contradiction because C++ also makes such decisions thus disqualifying it despite the author's claims, AND it's tautological because every language makes opinionated decisions about acceptable idioms. Really, no language could possibly satisfy the author's requirements.
Given its goals, I think Rust made a pretty good set of opinionated choices though. Certainly better than C++ overall.
Higher Logics: where programming meets science.
Rust has a clear purpose, and that is to embody and enforce the coding guidelines chosen by some members of the Mozilla team, to reduce bugs. And IMO it does that very well. If you don't like those coding guidelines, then you won't like Rust. If you do like them, then Rust will be a great language for you.
Whether those coding guidelines will become popular outside of Mozilla remains to be seen, but there is nothing wrong with them.
"First they came for the slanderers and i said nothing."
It's actually some of both. Java is a kindergarten language, and is all too often written by people who aren't very good. The good ones will have moved on to more advanced stuff.
Yes, you get a performance hit from the layer that the JVM introduces (which isn't as significant since dyna-rec), but it's still more commonly the fault of programmers who don't get it.
Rust is not yet production-usable. It has enough known bugs in the tracker that I can't even contemplate using it for a personal project, let alone for real.
And yet they're already pushing the marketing, proclaiming it as a guaranteed C-killer. I'm sorry, but they've said that about every compiled language since C, and it hasn't been true for one of them. And you're pushing it this hard, when you're still this early along in development?
Nobody uses C or C++ because they love the language. They use it because it has all the tools they need to debug, and all the libraries they need to run, and all the performance they need for the task. Rust maybe has the last one, but only has the second by being C-compatible (defeating the purpose of using a new language, particularly when you have to write this much wrapper code around it) and has none of infrastructure needed for large modern projects.
Dear Rust devs: stop writing articles about how great Rust will be, and start writing stuff to make your language actually usable. Maybe then people with their heads outside their asses will listen to you.
How dare you! All my classes require AbstractFactoryFactoryBuilders.
You don't give a 3'5" person an unmodified school bus and then say 'it's their fault for not having long enough legs'.
You design FOR the actual people that will use your product, not the mythical perfect user.
If people consistently make a set of mistakes, then a better designed product will prevent or at least warn/push them away from that mistake. Anytime there is a 'typical newbie error', that means that your product is bad - or at the very least should come with better free training. Minimal training required is one of the key functions of any product.
If I give you a frozen dinner, that if properly prepared, is the most delicious thing in the world - wouldn't a version where 'properly prepared' means "Open package and wait 30 seconds for it to warm" be a lot more valuable than "Open package, season to taste, poor into sauce pan, heat until it you smell the cinnamon begin to burn, transfer to microwave, cook 5 minutes at 1000 watts, return to freezer and let sit for 2 minutes, before slicing and serving on individual plates"?
"Open package and wait 30 second" is clearly the far superior product.
Similarly, a variant of C++ that stops common errors is better than one that lets you do things that no one ever wants.
excitingthingstodo.blogspot.com
This is the definition of a bondage and discipline language. The idea is that the central committee designing the language knows better than the programmer. The central committee will prevent the programmer from making certain "mistakes" by leaving the concepts out of the language.
If only the central committee had control of natural language as well, they could prevent the programmer from committing thought crime by thinking forbidden thoughts.
As it is, the programmer will flee the bondage and discipline language as soon as he figures out what is going on.
Simply not true, unless you believe that non-terrible code requires God himself to reach down and personally touch type.
I heard a bit of CBC episode recently, where a breathing consultant by the name of James Chambers argues that humans are terrible at breathing, and that with proper training (this takes about a year), we're almost competent (and then flowers bloom everywhere in an orchestral swell).
Breathe In, Breathe Out
One thing I will say is that a programmer is only as good as the API he or she programs against. In the spirit of Bill Maher, I hereby announce a New Rule: Garbage under, garbage above.
Most of the programmers with legendary reputations for writing correct systems have worked at (or fairly close to) the bare metal (or some POSIX-ratified virtual bare metal with extra starch).
Humans actually suck at just about everything. Programming is not especially special (modulo rampant innumeracy). All the greats in any discipline recognize and work within their personal limitations.
It's not constructive to become so bitter that you give up, or delegate the hard work to a tool that can only take you so far (perhaps less far than you wish to go).
Just the other day I listened to this Econtalk episode from six months back: Joshua Angrist on Econometrics and Causation
For the entire episode, Russ Roberts is trying to play the same pessimism card, effectively implying that humans suck at everything.
Joshua Angrist is having none of it. He directly refutes the posture of excessive pessimism time and again. It's a joy to hear Russ taking one on the chin for a change.
Now we just need an enterprising academic to self-subscribe to a personal mission to save us all from ourselves to come along and wrap up the whole of econometrics into a protective cocoon inside of which many of the basic errors simply can not be made.
Brave new world? Or cult of pessimism?
In my corner of the world, hard-baked optimists don't write unthinking rants anchored on assertions prefaced with "statement of fact". Wits on dial tone predicts no good thing.
Some cases I've used them for that I didn't feel dirty about are:
* checking for failure conditions from calls to sub-methods, and jumping to a common cleanup and exit code block. Difficult to replicate cleanly without massive if blocks, or abusing exceptions.
* Cleanly breaking out of multiple nested loops
* I've used them for an implementation of coroutines, which simulates threading for systems which don't have threads. In this case the GOTOs were nested inside macros and stub classes for holding context, but the whole scheme wouldn't have worked without them.
People who say 'C/C++' are likely to know neither language.
Religion is what happens when nature strikes and groupthink goes wrong.
When has a goto ever been incorrect? Your question doesn't make much sense.
Obviously you can use structured programming constructs to emulate a goto, and vice-versa. And in either case end up with _correct_ code. But when you're using a single-iteration loop or deeply nesting conditional blocks just to get the same effect as using goto, the goto should be preferred for the benefit of simplicity and readability.
In C code goto's are very useful for jumping to error handling code that rewinds the state of the local function. They're also useful when trying to follow a single-point-of-return discipline, whether in C or any other language. They're useful for writing explicit state machines--I use a switch more often, but sometimes using gotos is cleaner, and in GCC computed gotos are helluva fast. Finally, gotos are exceptionally useful when generating code. In fact, Lua re-added goto support in 5.2 because the authors realized how unnecessarily painful it was to machine-generate Lua code without goto support.
You should be focusing on writing clear and simple code, using whatever constructs your language provides. Feeling "dirty" about using gotos doesn't make any sense. When was the last time you carefully paid attention to arithmetic overflow in your code (C or otherwise)? Ignoring that stuff should make you feel dirty. Not use of goto.
C++ isn't the only one. COBOL is still around, and even has object-oriented extensions these days. Fortran, RPGII...I can't think of a single outdated but widely-used language that has every gone away.
If your C++ code is not good enough or Java code is painfully slow, it's not because the technology is bad - it's because you haven't learned how to use it right. That way, you won't be satisfied with Rust either, but just for some other reasons."
Gods, I wish we could force EVERY programmer to take some basic neurophysiology and at least one human factors course.
If the language is hard to use and makes it easy to make mistakes, the language design is wrong. NOT the humans. The humans, by definition *can't* be wrong. A language is like any other machine. In this case, it's purpose is to provide a highly granular interface to the system FOR HUMANS.
Machines, any machine, exist for exactly, and only one reason, to serve humans efficiently (i.e to reduce human physical and cognitive labor to a minimum while allowing them to accomplish their goals).
If a language accomplishes that, the language is well designed. If it doesn't do that due to obfuscated syntax, a lack of safety checks, over-engineering (It does so much) and under-design (What it does is almost impossible to understand and use), then the language is badly designed, and the language designers, incompetent, because they neglected to consider the human part of the system in their design.
Please do not read this sig. Thank you.
I'll limit myself to the 286 word (!) summary and not RTFA — because Damn! — that's bad enough.
[W]hat actually makes Rust safe, by the way? To put it simple, this is a language with a built-in code analyzer
What makes Rust safe is language design that permits that code to be analyzed. Costly C++ code analyzers that hardly anyone actually uses can't match Rust's built-in, for-free, automatic analyzing compiler because the C++ language itself precludes this.
The rest of the first paragraph amounts to `Rust isn't necessary because C++ is improving.' Anyone that's been watching C++ develop for the last 30 years knows there are both technical and political limitations to how much C++ can ever improve and some people can't wait another 30 years to get halfway there.
Then we get into this drivel;
I can generally understand why it doesn't have a decent inheritance and exceptions, but the fact itself that someone is making decisions for me regarding things like that makes me feel somewhat displeased.
Decent? C++ has `decent' inheritance? I'd be surprised if the author actually understood C++ inheritance. I know most C++ programmers don't. Rust spaces that '80s OO crap and gives you a clean, simple system of traits. You're not limited in any way by that design unless you're employed to write FAQ answers and blog posts about the subtleties of mis-designed C++ OO.
As for C++ exceptions; here is Mozilla's policy on C++ exceptions: "do not use try/catch or throw any exceptions." Here is Google's policy on C++ exception's: "We do not use C++ exceptions." C++ exceptions are broke. Full Stop. These people understand this. The author doesn't.
If the lack of C++ inheritance and C++ exceptions are the best you can come up with to disparage Rust then sign me up for Rust.
Maw! Fire up the karma burner!
Given the support for the functional paradigm that rust has, I am dissapointed that parallelizing folds and maps is so verbose and thought requiring. Not sure why a fold can't just use all the cores like in haskell.
Sting slices vs strings. Verbose again but it works.
No tail call optimization, makes some FP stuff impossible.
No metaprogramming.
Regex library is slow. But I don't use regex and it is on the long list to improve.
Compile times. It rebuilds everything in a library or exe even if you only changed one line. Also it is just slow. Even hello world takes surprisingly long. This is really annoying because I have a habit of recompiling quite regularly as I code.
Cargo, the package manager and build system is inflexible in that it does not let you pass command line parameters to rustc. This means that if you want to cross compile or use simd or any of the other cool stuff you get by building on the llvm back end, you have to roll your own build system with make or cmake or whatnot.
That said, I am still excited about it.
refactor the law, its bloated, confusing and unmaintainable.
you're not going to achieve anything clever with an invalid pointer
Shitty programmers write shitty code, regardless of language.
C is "obtusely large"? C is fairly small, and is only moderate sized when the standard libraries are used (and not all programs need all the standard libraries.) To consider C "obtusely large" you have to be considering all commonly used libraries including such things as jpeg and regular expressions. It's just not a reasonable estimate.
Contribute to civilization: ari.aynrand.org/donate
Some cases I've used them for that I didn't feel dirty about are:
* checking for failure conditions from calls to sub-methods, and jumping to a common cleanup and exit code block. Difficult to replicate cleanly without massive if blocks, or abusing exceptions.
Or using C++...
* Cleanly breaking out of multiple nested loops
Tough one. I have to be honest, I've never used a goto in my code since I stopped writing BASIC, but I've sometimes missed this ability. Still, a language-level keyword like "breakall;" would be better than goto. Except insofar as it doesn't exist, and "goto" does...
* I've used them for an implementation of coroutines, which simulates threading for systems which don't have threads. In this case the GOTOs were nested inside macros and stub classes for holding context, but the whole scheme wouldn't have worked without them.
Sounds clever. I hate macros even more than goto, so I expect seeing the code would send me into anaphylactic shock.
When has a GOTO ever been correct?
In assembly language. :-)
* Cleanly breaking out of multiple nested loops
Tough one. I have to be honest, I've never used a goto in my code since I stopped writing BASIC, but I've sometimes missed this ability. Still, a language-level keyword like "breakall;" would be better than goto. Except insofar as it doesn't exist, and "goto" does...
The problem is break one and break all are not the only cases. Perhaps you only want to break some but not all levels of nesting.
it's not the implementations that are too large, it's the specification that's too large.
How many ways are there to dereference a pointer? you can use either *foo or foo[0] but why? Nothing is gained from having two ways to do it, it just makes the language more obscure.
The c preprocessor by its nature is a hulking uncontrolled nightmare that can and will deposit horrible bugs everywhere in your program, you can choose any one of a literally infinite array of options to solve your problem.
And then there is the typedef operator, which can also be abused in fascinating ways to achieve truly unfindable bugs, without really contributing much of anything to the language. Or maybe you can just use the preprocessor instead. For extra points, use both the preprocessor and typedefs to drive your fellow coders absolutely insane.
To be honest, if your loop structure is that deep then you'd be better off refactoring the code into a function that performs the inner loop or loops. This is quite likely to make the code easier to read anyway. I've never written code with a triple-nested loop and found myself needing to break out of the inner loop, straight into to the outer loop. Perhaps I haven't lived :)
I guess it's a personal thing. I personally don't like goto, because it can go anywhere. Other people like it for exactly the same reason. So it goes.
Since this is Rust/Swift day on /., I'd bring up that swift doesn't have `goto` but it does have named break statements.
Don't blame me, I voted for Baltar.
Nah dude. Real men use tail recursion and binding expressions.
C++ has const, volatile, static, thread_local, and a whole host of atomic flags in std::atomic [...] It's mostly a factor of people not caring enough to learn what they need to do.
That and needing to compile for targets that have only a pre-C++11 legacy compiler.
I disagree. I have long experience from C and C++ plus few other languages. And I moved to Java because I like it. You can easily write crap with it. But the difference is that it is easy to refactor.
Quite often it is because the "developer" that wrote it has no clue how Java gets compiled and executed. One problem is that the Java compiling and execution mechanism is far too complicated. Another is that it is relatively simple to get something to work (badly) in Java, so average developer skill is not very good. C++ has far less problems in those regards and C has even less. The point is that while Java appears to be simple, it is hugely complex behind the scenes and as soon as you do something a bit more complicated, that complexity does not stay hidden anymore.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Rust is walking the path of simplification.
Really?
Author apparently hasn't seen the crazy monstrosity the Rust's preprocessor is.
Otherwise, IMO, Rust and this type of languages - "the perfect cage" - to me are dead end.
(A) I want an utilitarian language. I want language which provides me with strict and weak typing, static and dynamic binding, compiled/jitted/interpreted execution with eval() function. At the same time. Probably all that in different scopes - but the scopes should be able to inter-operate. Think Objective-C++ - but with something better than Objective C on the weak side of things, with bits of Perl-ness built-in.
I want a language which gives me choice. Not another language with dozen theoretical papers why I can't do something and I'm better off for it.
(B) For security, I would rather want an language which can be easily validated and proofed. Rust tries to create a perfect cage - for developers - while the main security vulnerability is the user input. Compilers still can't guess whether I have properly validated the input or not. The Rust went in a different direction: annihilating C/C++ bugs. The problem is that all other bugs programmers make - still remain.
All hope abandon ye who enter here.
GOTO is fine when doing a state-machine in a certain style. Also, things like "continue" and "break" are limited forms of GOTO that are generally accepted and breaking out of nested loops becomes very tedious if you have to do it one at a time.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I would be also interested to see the author's opinion on D and how it compares with C++.
An comment which not only makes sense, but it also touches on the most important point. That in the right hands, a language like C++ is a very powerful tool.
Let me just add that in the scientific computing community the much-maligned FORTRAN is very much alive. Remember the saying "You can write FORTRAN in any language" ?
You can't do much structured programming in this language, but then you don't have to. Read in a file, run a bunch of nested loops, write the output. And it is very, very fast, a necessary asset when you run all the time into the limitations of the hardware. In the right hands, FORTRAN is a very powerful tool indeed.
I agree with most of the submitter's points, except for the "if Java is slow for your then you aren't using it right". Sure, if all you're doing is a tightly optimized PI calculation simulator, Java can match (or even, in some cases, beat) C/C++ performance. In a real-world user application though, it falls apart. I have never, ever used client-side Java application that wasn't a huge RAM and CPU hog. All you need to do is look at any big client-side Java application to realize that. Practically anything that has a user GUI is a disaster. Case in point : Eclipse, Open/LibreOffice. If it runs on Java, it's on that list.
Java works really well for some server workloads with well-defined inputs, processing, then output. Anyone using Java to develop client GUI apps is using the wrong tool for the job. I'm looking at you, Cisco (ASDM, SDM, Network Assistant, etc).
I used to be a huge java on the desktop proponent, but the end results have since changed my mind. Show me a few large desktop applications that aren't slow and painful to use and maybe I'll change my mind. Until then, please stop using Java on the client side.
Religion is the best example of mass psychosis
How many ways are there to dereference a pointer? you can use either *foo or foo[0] but why? Nothing is gained from having two ways to do it, it just makes the language more obscure.
Something is gained, though: self-documentation. The way you dereference a point (should) reflect what the pointer is being used for.
Even java has labeled breaks
To be honest, if your loop structure is that deep then you'd be better off refactoring the code into a function that performs the inner loop or loops. This is quite likely to make the code easier to read anyway. I've never written code with a triple-nested loop and found myself needing to break out of the inner loop, straight into to the outer loop. Perhaps I haven't lived :)
I guess it's a personal thing. I personally don't like goto, because it can go anywhere. Other people like it for exactly the same reason. So it goes.
Personally I think its a length thing. If the loops are very short, if all the nesting is simultaneously visible on screen, no scrolling necessary, then it might be OK. It all depends on the complexity of the code too, the logic would also need to be something readily understandable, the partial bailout something natural, not just some optimization trick.
:-)
Have I done so, in C/C++ not sure, in assembly probably.
Really?
You do realize that break is a goto and is being used is the same way as a goto and you don't have to clean up on success?