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.
Java code is painfully slow, it's not because the technology is bad
Yes it is.
"... 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.
>the fact itself that someone is making decisions for me regarding things like that makes me feel somewhat displeased
Every language makes design decisions. The decision to take in every idea is a design decision. And guess what? Lots of people make fun of, and avoid, C++ for being the kitchen sink and a house attached.
Go made its own design decisions, and seems to be very successful in its domain. Rust has made similar decisions, and once 1.0 stable with updated docs, we can gauge as a community its value, its deployment, and its utility. But to say their very /act/ of making a subjective design decision makes you uneasy? Come off it with the contrarian clickbait.
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."
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.
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
When has a GOTO ever been correct? I've used GOTO's in production code. I've always felt dirty about it, as if it was an error in my youth (but I no longer have access to the source). Please help assuage my conscience.
Your ad here. Ask me how!
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++/C will be here forever, there is too much code to transfer to a new system" and other such wondrous hits.
Tell that to Quantum Computers. You can throw however many programs you want at it, it will still suck shit.
Not only that, future architectures in general will likely require huge changes to computing in general, never mind the probable QC age.
Already a massive amount of programs that depend on high speed are becoming more and more terrible as cores increase, and speed and core complexity decreases.
This WILL require rewrites or some genius to come out with a load-balancer amazingly better than the not-all-that-bad ones we have now.
As we breach 20 cores as common desktop processors, some programs will become unsuitably slow that it will need to be rewritten. (especially Dwarf Fortress. But Toady will be dead by then with his diet. It will never be finished. Go home and cry.)
The point I am trying to get across is new things are being rewritten all the time, it does happen, it will happen.
People also change languages all the time. They learn, slowly albeit, but they do learn.
More and more people are also adhering to the toolbox methodology, in that all languages have their good uses, and bad uses.
Ironically enough, C and C++ are a bit of a superposition of both. These languages are equally atrocious and brilliant, I don't think I have ever known anyone to like either of those languages, but they still use them because each discrete incompatible area of the language as they are still the best at what it does. .)
The issue with both, C++ especially, is they are too big a scope. It is almost like a language designed by committee.
Obtusely large and specific, unwieldy and abused most of the time.
C++ is literally "Goto is bad" as a language.
Honestly, I think these languages will evolve to a point where they will likely end up forking in to dedicated areas.
Stagnation is never a good thing, even if it does work.
They will die. They will not last past 2040. Period. And it this awful place hasn't been destroyed further and is still here at that year, I will come back to say I told you so. (unless I die with the Toad. In which case I will be
I love to fuck mens' butts. It's why I'm a Macbook-using Rubyist.
- Ruby Develope
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.
UNIX was not designed to stop you from doing stupid things,
because that would also stop you from doing clever things. (Doug Gwyn)
Agreed on the point about Java, but C++ needs some good error checking.
I always thought that they could just build some error checking in, so when you're running development code, the checking gets done,
and when you're running production code, you turn it off and get the speed edge. Anything is better than Seg faults. Why are they still possible in C++? It's 2015.
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!
I don't think I could ever get use to a language that has me yelling (println!) every time I want to print something....
That reasoning is what brought us the C library with its predilection to buffer overflows. Thank goodness Unix grew up in a university environment so that its security issues could be hammered out by a lot of hackers. There is a direct correlation between bugs and lack of security. Allowing just any old code to compile means that very small mistakes due to sloppy coding become a nasty exploit years down the road.
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.
Shitty programmers write shitty code, regardless of language.
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. :-)
When has a GOTO ever been correct? I've used GOTO's in production code. I've always felt dirty about it, as if it was an error in my youth (but I no longer have access to the source). Please help assuage my conscience.
goto is the cleanest way to implement a finite state machine. Every other method involves moving the states into a static data structure that you interpret in a loop or putting a huge switch statement into a loop.
All these harebrained ideas about "replacing" C and C++ are because shitty programmers use the languages to write shit code.
C++ is more approachable and safer than ever before, but that's like fitting an automatic transmission to an 18-wheeler.
It's crazy to let folks that don't have CDL licenses drive big rigs; auto transmissions or not.
Languages like Swift definitely have their place (I use it). However, there is unlikely to ever be a better systems language than C (and, in some cases, C++).
If a company insists on hiring cheap brogrammers, then they should keep those idiots away from dangerous languages like C. Give them a nice playroom, with brightly-colored, child-safe toys.
Keep the guns locked up in a safe.
* 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.
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.
From the rust page: // This code is editable and runnable! // A simple integer calculator: // `+` or `-` means add or subtract by 1 // `*` or `/` means multiply or divide by 2
fn main() {
let program = "+ + * - /";
let mut accumulator = 0;
for token in program.chars() { /= 2, /* ignore everything else */ }
match token {
'+' => accumulator += 1,
'-' => accumulator -= 1,
'*' => accumulator *= 2,
'/' => accumulator
_ => {
}
}
println!("The program \"{}\" calculates the value {}",
program, accumulator);
}
why not: // This code is editable and runnable! /";
main()
{
var program = "+ + * -
var mut accumulator = 0;
foreach token in program /= 2, /* ignore everything else */ }
{
switch(token)
{
case '+' : accumulator += 1,
case '-' : accumulator -= 1,
case '*' : accumulator *= 2,
case '/' : accumulator
default : {
}
}
println!("The program \"{}\" calculates the value {}",
program, accumulator);
}
I mean, if your going to create a 'new' language, why not use the already existing syntax of the most used languages.
Inventing a let x=1 is not helpful, get rid of the let altogether or do what javascript does and just use var
Also, why the ugly switch equivalent? Since everyone knows a switch statement leave it the same!?
Iterators are done in all languages, keep with the standard ones, C/C++/Java/Javascript centric....
Its just silly to 'change the syntax' just because you want to make yourself different.
If the language brings something to the table, BRING it...and only the differences please!
I get so tired of these lame 'new languages' get on with the improvements already and don't even get me started on using whitespace as a code block!
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.
It's probably Stockholm, but I kind of like C++. I've even gotten used to doing terrible things with templates when what you really wanted was reflection.
Portability is terrible though.
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.
For the person falling into the black hole, everything else in the universe seems to speed up more and more until you cross the event horizon. Not sure what happens at that point, my one semester general relativity class was looking ago.
IT is not hard to learn.
Down at the binary code level, there ARE no "while", "if-else", "do", "for-next", "case", etc statements - EVERYTHING is a GOTO (either an absolute jump or a relative jump, performed conditionally, or unconditionally).
All those "structured programming" concepts you young whipper-snappers cling to as the ideal way to do things are just figments of your imagination implemented for you by a compiler and pumped into your head by instructors both to try to limit your incompetence and to shield your precious, fragile, easily-offended little sensibilities from the actual reality of a "dangerous" three-letter mnemonic: "JMP" (and its powerful cousins).
If compiled exactly as written, those "structured programming" statements you use and that you think are superior would almost always be less efficient than GOTO/JMP statements, so your modern languages often optimize-out your exact structured code and produce code that you have been taught is EVIL "spaghetti code". You get away with this level of inefficiency and obscurity only because you generally have more memory and clock cycles to burn than you need for the tasks you are performing, unlike the generations of programmers who came before you and who had to be better coders than you.
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.
how to avoid goto but still have common cleanup:
int DoStuff()
{
Setup()
do
{
if (DoSubThing1() == FAILURE) break;
if (DoSubThing2() == FAILURE) break;
return SUCCESS;
} while(0);
Cleanup();
return FAILURE;
}
Who have heard of Cyclone? -> Rust is Cyclone Who have heard of Vala? -> The Gnome developers? As far as Limbo/BitC they are academic attempt. One more correction. The article talks about C++ and comes into conclusion that C++ is the best. If you follow the logic you can safely assume that C11 is the best language ever. It is even better than C++ because you can write code in C call it from D, export a C header for the DLL and call it from Go. Can you do it in C++ without wrappers? Mine is bigger than yours. Moreover there are more compilers for C than C++.
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
No, there is no infinite shift for a person falling into a black hole. If you are in actual free fall, there will be a slight red shift of things behind you and the rest of the universe. For powered flight into a black hole, you can get anywhere from a stronger red shift to a finite blue shift. The only way to get something close to an infinite blue shift is if you hover just above the event horizon, expending extremely large amounts of energy to keep yourself from falling in.
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.
So how stupid does one have to be to mistake Rust for Ruby?
Is there a negative number small enough to properly describe it?
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?