Criticizing the Rust Language, and Why C/C++ Will Never Die 386
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."
Pretty sure the heat death of the universe will (Score:5, Funny)
No, I'm pretty sure the heat death of the universe will kill those languages
Re:Pretty sure the heat death of the universe will (Score:4, Insightful)
Re: (Score:3)
I'm pretty sure heat death was programmed in C.
Re: (Score:2)
Re: (Score:2)
No, it will just reset to a previous point in time.
Re:Pretty sure the heat death of the universe will (Score:4, Informative)
I predict that as heat-death approaches, time will slow down, and by the point of heat death, time will be at a complete standstill, much like approaching the event horizon of a black hole, so from its own frame of reference, the universe will actually seem to last forever.
Sounds like you don't understand time dilation. When you approach a black hole, time does not go at a different rate for you. It does however go at a different speed compared to an observer at a large distance (that's why time is *relative*). For them, all objects falling towards a black hole actually seem to pile up near the event horizon (but gravitational redshift and time dilation make the radiation gradually unobservable). For the person falling in, nothing changes, they just fall through.
To summarize, time never slows down, it may only slow down in one place compared to another place. You did not specify two places so your statement does not make any sense.
Re: (Score:2)
Once you have X amount of software written in a language the language will never die.
Fortran, Cobol, c, c++ will probably never die.
Re: (Score:2)
Cobol is in attrition as far as most of the world is concerned. The starvation may take a while, but its occurring. Fortran is link compatible with C and to many actively maintained simulations are based on it. Fortran will be around for at least as long as C is around. It will take generations of programmers to abandon C++ before that becomes a reality a honestly what takes over will likely be a certified subset of C++ that is considered safer and easier to work with.
Re: (Score:2)
"Cobol is in attrition as far as most of the world is concerned."
Old working code has a huge advantage over a rewrite... It works.
You may be shocked how much effort people will make to keep old software running.
http://www.comwaretech.com/PDP... [comwaretech.com]
http://www.dbit.com/ [dbit.com]
Re:Pretty sure the heat death of the universe will (Score:4, Insightful)
Just because a piece of software is old, doesn't mean it's suddenly doesn't do its intended function.
I'm not sure I'd be shocked by the effort that people make to keep old software running,. You mention PDP emulators, but how many people here use DOSBox on a regular basis to play old games.
Emulators are just one way do keep old software running of. The other way if the source is around is to keep updating the software for new platforms but avoiding too much feeping creaturism if you can. That's pretty much where I'm at with doing ircd work, keep the code updated for modern systems(with their own OS specific quirks) so it continues function.
It seems like people just want new and shiny software just for the sake of having new and shiny. New and shiny code however doesn't have X number of years of being used as production and all of the WTF bugs have long been squashed.
Meh.
Re: (Score:3)
Cobol is in attrition as far as most of the world is concerned. The starvation may take a while, but its occurring. Fortran is link compatible with C
Are you sure? FooBar() and foobar() are different functions in C but the same function in Fortran, so calling foobar() from C in a fortran-compiled libfb.so is probably not going to have the effect you intended if both FooBar() and foobar() are present in libfb.so, if it is even possible at all (name-mangling might be happening).
(My fortran may be a little ancient - do newer fortran compilers make a distinction between case?)
and to many actively maintained simulations are based on it. Fortran will be around for at least as long as C is around. It will take generations of programmers to abandon C++ before that becomes a reality a honestly what takes over will likely be a certified subset of C++ that is considered safer and easier to work with.
Nothing is going to take over from C; it's way too foundational :-(
Whether you are
Re:Pretty sure the heat death of the universe will (Score:5, Informative)
C++ code can only be called by other C++ code.
My JNI plugin written in C++ disagrees with you. That's a .so compiled from C, called by Java. If you write functions in C++ as extern "C", then they are link compatible with C and therefore callable by anything.
Re:Pretty sure the heat death of the universe will (Score:5, Insightful)
What the fuck are you talking about? It doesn't compile C++ code as C, it compiles C++ functions with C linkage conventions. IOW it disables name mangling.
That is all.
Come to think of it, I think I've argued with you about C++ before. From what I recall you are both astonishingly ignorant and astonishingly angry. A quite entertaining combination if I may say so myself!
Re: (Score:3)
Are you sure? FooBar() and foobar() are different functions in C but the same function in Fortran, so calling foobar() from C in a fortran-compiled libfb.so is probably not going to have the effect you intended if both FooBar() and foobar() are present in libfb.so, if it is even possible at all (name-mangling might be happening).
I was writing Fortran/C multi-language applications twenty years ago, so yeah, despite a few issues this is easily possible. There was some weirdness, as I recall, because Fortran implicitly pushed the size of arrays onto the stack, so you had to do some fiddling to accommodate them. There were a few other minor issues, but what the GP said is essentially correct: Fortran is link-compatible with C. C++ mangles names, so unless functions are declared with C linkage (extern "C") all bets are off.
Pretty much a
Re: (Score:2, Interesting)
Cobol is in attrition as far as most of the world is concerned. The starvation may take a while, but its occurring. Fortran is link compatible with C and to many actively maintained simulations are based on it. Fortran will be around for at least as long as C is around. It will take generations of programmers to abandon C++ before that becomes a reality a honestly what takes over will likely be a certified subset of C++ that is considered safer and easier to work with.
No way... Give me ANSI C over C++ ANY day. C++ was a really bad thing to do to C and IMHO was a mistake (although a mistake I would likely have made at the time). Literally ANYTHING you can do in C++, you can do in C and skip the hokey compile time Object Oriented stuff that really was only halfway implemented anyway and really just shoe horned into an already error prone language. Don't get me wrong, I make a living writing C++ code and previously did the same in C, it's just that trying to force OO int
An Old Story (Score:4, Insightful)
"... 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.
Re:An Old Story (Score:5, Funny)
Sorry, I realize it's 35 years ago. You can blame it on senility.
Re: (Score:3)
It was actually 31 years ago. And your octal's kinda rusty.
Re:An Old Story (Score:5, Insightful)
And I still prefer to code in Assembler.
There are all sorts of tools, many of them specialized and great for certain applications. But sometimes you just can't beat a sledgehammer. ASM, C, and to some extent C++ have a bad rep because of their lack of training wheels. But in the right hands they are the best and fastest solution to a problem. Plenty of people code, and plenty more people think they can code. Someone who knows what they are doing will not get into trouble in ASM, much less in C or C++. But there are lots of people who claim they know what they are doing when actually they know squat. They get "unintended results" when actually the language is doing exactly what they asked it to do - the problem exists in their understanding of how computers work. Yeah, maybe THOSE people should avoid these languages.
Re: (Score:2)
Don't blame the tool, blame the user. A chainsaw is dangerous, but if I'm clearing brush or cutting tree limbs blown down by a storm, it's the best tool for that job. If I cut off my foot with it, is it the chainsaw's fault?
Re: (Score:2)
Why should skill and table saws have a shield at all?
Plenty of carpenters pin back the shield on their skill saw.
I sure wouldn't. I'd cut off my leg.
Re:An Old Story (Score:4, Insightful)
The best reason for avoiding assembly is that it's almost never the fastest way to get the programming done, and with a good C compiler it may not be the fastest way for the program to run, either. Assembly is great for bootstrapping a compiler or OS and inside tight loops. It can be handy if your hardware has an advanced feature not yet exposed through a library for a higher-level language. Not everything needs it, though.
Even C or C++ is often not the fastest way to get a project done. Sometimes there's a pretty big runtime penalty for using something that enables faster development, though.
There are lots of cases out there of Lua, Python, or some other language being used to wrap around a small core of C or C++ with maybe the most time-critical parts in assembly. Sometimes a higher-level language is the right tool for the situation, but sometimes not.
Re: (Score:3)
Even C or C++ is often not the fastest way to get a project done........There are lots of cases out there of Lua, Python, or some other language being used
In my experience, the availability of libraries is more important than language choice in getting the job done quickly.
That is, if you had all the libraries you need, assembly would be faster than Perl/Python/Scheme without the libraries you need. Of course, there are not many libraries written in assembly.
Re: (Score:3)
But in the right hands they are the best and fastest solution to a problem.
Sure. Provided the "right hands" acknowledges that they are not usually the the right solution to a problem chosen at random.
Plenty of people code, and plenty more people think they can code. Someone who knows what they are doing will not get into trouble in ASM, much less in C or C++. But there are lots of people who claim they know what they are doing when actually they know squat.
Sure those completely worthless people do exist and most developers do overestimate their own abilities.
Q: Do you know how many really good ASM/ C / C++ devs are out there that you wouldn't dream of saying that they "don't know squat" that still produce and release code with subtle to obvious bugs in it?
A: All of them.
Yeah, maybe THOSE people should avoid these languages.
Nobody is perfect. And nobody gets better at something by not doin
Re:An Old Story (Score:4, Interesting)
Normally training wheels come off once you learn to ride that bike. But in many languages the training wheels are permanent.
I do wish that more people who call themselves programmers or engineers actually understood how computers work. Then we wouldn't need faster computers every 5 years just to keep running the same programs at the same speed.
Re: (Score:3)
ASM, C, and to some extent C++ have a bad rep because of their lack of training wheels. But in the right hands they are the best and fastest solution to a problem. Plenty of people code, and plenty more people think they can code. Someone who knows what they are doing will not get into trouble in ASM, much less in C or C++.
I contend that the entire history of computing disagrees with you and your hypothetical "person who knows what they are doing" does not exist. If you maintain otherwise, please name a large and widely used program written in any of the above languages that has never encountered the kinds of bug that more sophisticated type systems like Rust's prove can't exist.
Seriously, this article is hosted on a site about a static analyser, whose purpose for existence is to try to identify errors in C and C++ code cause
Re: (Score:3)
C++ isn't about productivity. It's really about performance. If your application isn't performance-critical, you probably don't have a good reason to be using C++. And actually, nowadays it's a lot easier to write much safer C++ than previously, especially with recent changes to the language. Overall, the language is a pretty good tradeoff between performance, productivity, and safety, with emphasis on the performance, of course. I'd imagine that's why game developers use C++ almost exclusively, at lea
Re: (Score:2)
C++ doesn't, but every reasonably large project has coding standards that do. I've often wanted to have a language that wouldn't compile unless it met my standards...
Re: (Score:3)
I've often wanted to have a language that wouldn't compile unless it met my [coding] standards...
Hush! That's how we got Python!
Re: (Score:3, Insightful)
C++ doesn't, but every reasonably large project has coding standards that do. I've often wanted to have a language that wouldn't compile unless it met my standards...
Coding standards won't save you. How often have you come across something like this in other's code?
QString qs;
...
char *filename = qs.toStdString().c_str();
(Might not even be QString getting abused here - might be something vendor provided).
The problem with C++ is not the extra complexity thrown in by the standards committee to save a few keystrokes, it's the opacity of the source code. It requires the user of a library to know implementation details of that library, but the source code using that li
Re: (Score:2)
How can you have a default deep copy? What about circular references? Plus the potential for massive duplication and logical fragmentation of dependent objects. You're talking about "hidden gotchas," but a default deep copy is no less gotcha-prone than a default bitwise copy.
Copying (and serializability) should be determined on a class by class basis. Your class can either provide different copy methods, or you should be able to mark it...whatever...Serializable via attributes.
I hate how much I like C#. The
Re: (Score:2)
How can you have a default deep copy? What about circular references?
Ah, the problem that never was but seems to come up again and again. The real issue is that the language doesnt provide a deep copy semantic, but because of this the common symptom is that people (like you) that try to implement deep copying (because the language lacks it) use a naive algorithm that doesnt handle circular references.
A deep copy that handles circular references is slower, but the addition cost is constant time because it only needs at most an O(1) lookup and O(1) insert at every node.
No
Programming languages must cater to humans (Score:5, Insightful)
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.
Re: Programming languages must cater to humans (Score:3, Informative)
> 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.
But without language semantics (e.g. for saying whether variables are threadsafe) these analyzers simply can't do anything other than guess at the programmers intentions. Even the best ones miss basic memory safety issues, while also producing far too many false positives. And this is all to be expected when the language can't expresss those semantics.
Re:Programming languages must cater to humans (Score:4, Interesting)
Re:Programming languages must cater to humans (Score:4, Funny)
The idea that C++ is a great barrier to keep out bad programmers is really dumb
Especially if you've seen much C++ code.......
Re: (Score:2)
I pretty much love you.
Named after the product of corrosion? (Score:2)
Re: (Score:2)
Re: (Score:2)
Re:Named after the product of corrosion? (Score:5, Funny)
Someone is making decisions for me regarding thing (Score:2)
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.
Re:Someone is making decisions for me regarding th (Score:5, Insightful)
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.
Re: (Score:2)
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.
Re: (Score:3)
* 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.
Re: (Score:3, Insightful)
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
Re: (Score:2)
When has a GOTO ever been correct?
In assembly language. :-)
A bit ranty. (Score:5, Interesting)
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.
Re: (Score:2)
Rust may be interesting, but is useless for multithreading because as we all know, Rust never sleeps.
Hey hey, my my....
C++ will never die....
Re: (Score:3)
There is also new C code for large machines. Just wrote some. Speed, memory-efficiency and fine-grained control over the execution is mandatory in some application scenarios.
Re: (Score:3)
No. These cause more problems than they solve, because the template system in C++ is utterly borked. (Look at what Eiffel offers to understand what I am talking about...) As to qsort(), in a sane implementation, there will not be any difference. The extra call that C does does not matter once the code is in 1st level CPU cache. And if you need maximum performance, you have to move away from the library anyways.
The source of troubles is usually in humans (Score:4, Insightful)
> 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.
garbage under, garbage above (Score:2)
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, Breath [www.cbc.ca]
Re: (Score:3)
> Humans actually suck at just about everything.
We are great at the things we actually evolved to do. Language, visual perception, navigating social situations, etc. These are the reasons we went from 500 cc of brain volume to 1500 cc. These are extremely hard problems that require the equivalent of petaflops of computation.
Yet it takes minutes of conscious effort for us to multiply two puny 10-digit numbers! We are extremely and demonstrably bad at doing arithmetic. The reason? Our working memory capaci
Re: (Score:2)
Re: (Score:3)
Whenever a programming task can be precisely defined, a machine can do it better. The process of converting C to assembly is hard for humans but machines can do it easily. The evolution of programming has mostly been a repetition of the same theme: Identification of a problem, clumsy efforts by humans to solve that problem manually, development of a process that automates that problem, and then sitting back and letting the computer handle that particular problem while we move on to more challenging ones. Yo
Re: (Score:2)
It's a statement of fact, and everyone - including you and me - is terrible at programming.
Well, since this isn't actually a statement of fact, the rest of your argument doesn't follow.
Re:The source of troubles is usually in humans (Score:4, Informative)
And when C was developed, it was a HIGH-LEVEL language.
Umm, no, it wasn't. It was (and is) considered a mid-level language, one step above assembler. High level languages of the day were things like COBOL and Fortran.
Re: (Score:2)
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.
That really, really was not the purpose of C. It's better to think of C as kind of a fancy macro library.....common functionality collected into a single place for the convenience of the programmer. The designers of C were not trying to limit programmers to prevent them from making mistakes, they trusted programmers to be able to handle great power (and be responsible).
Re: (Score:2)
In 1972 you would have been railing against C and insisting you need assembly to write an OS.
Tools get better over time. Yes, you need a language designed for systems-level coding to write some applications, but that doesn't equate to freedom to do anything you want and lack of restrictions. In fact it should mean quite the opposite.
Re: (Score:2)
You're again deciding to completely not listen. It's not worth arguing with you anymore.
Re: (Score:2)
I can't say I ever expected to see someone refer to "Ada[,] Pascal, C and Fortran" as "the latest fad language". Those were all old-hat when I got into this game 30 years ago.
Re: (Score:2)
Re: (Score:2)
No, I'm saying the reason is because they don't know how good they have it, and they are mostly coddled and shielded from the effects of their own bad programming.
You have a very shallow level of understanding.
You dont' need another language to do this. (Score:3)
"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.
Re: (Score:3)
We need it because that isn't what Rust is about - it is about making safe programming the default and making some common errors in other languages (like dangling pointers) impossible. And doing that while still being useful for systems programming and supporting high performance.
Re: (Score:2)
I've seen this argument before. Hmm. where was that. Oh yeah! Java. And Pascal before it. and Ada before that.
Re: (Score:3)
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.
Because there is some analysis that can't be done statically (provably!), and other analysis that is intractable, no matter how good your IDE or tools. The language works around this by simplifying the problem by disallowing certain things.
Another example of a language that solved the halting problem is Coq......it's impossible to write a program in that language that doesn't terminate.
language improvements (Score:2)
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.
Re: (Score:2)
you can use C++ perfectly safely
in case you have not been keeping up, automated code analysis tools are finding terrible bugs in EVERYBODY's code from Microsoft to Google to Apple and just about every free software project.
so the empirical evidence is that NOBODY out there knows how to use C++ "safely"
Re: (Score:2)
gnu grep 2.21, released Nov 23 2014, 10 active unfixed bugs on their bug report
hello can you write a bug-free grep? can anyone? go ahead I double dare you. come on it's a simple program, just support the posix options. it's been done probably a dozen times at this point, surely someone with your skillz can knock it off with no bugs at all.
Come again? (Score:3, Funny)
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.
Re: (Score:2)
Two big issues with what you said:
Most bugs aren't detectable by solving the halting problem. It literally just covers infinite loops. The bugs they're talking about are far more subtle.
Second, given sufficient constraints on the program being generated, the halting problem is solvable.
What's easier to change? (Score:3)
Human fallibility or the language/compiler?
I don't even... (Score:4, Interesting)
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.
Rust has a clear purpose (Score:3)
Whether those coding guidelines will become popular outside of Mozilla remains to be seen, but there is nothing wrong with them.
Re: (Score:2)
Rust is putting the cart before the horse (Score:4, Interesting)
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.
Re: (Score:3)
"Nobody uses C or C++ because they love the language."
I take issue with that. I absolutely love C. I also abhor any movement to 'prettify' algol-like languages (python, java), which I consider useless.
Re: (Score:2)
There's absolutely a beauty to C. I wrote my Master's thesis (a chip multiprocessor simulator) in C, 12 years ago, and I miss it. It's never been the right language for any project I've done since, but that doesn't mean I don't miss its simple honesty. You could write a line of C and have a pretty damn good idea what the assembler output would look like.
Re: (Score:3)
You could write a line of C and have a pretty damn good idea what the assembler output would look like.
Or maybe not, if your compiler does re-ordering or any sort of optimization. In fact the C standard states explicitly that the compiler is free to generate any code it wants to as long as it correctly executes your program. So that means that your stack variables will vanish, your unused code will vanish, your loop variables and exit conditions will be re-written and in general, depending on what works best for the platform you're compiling on, the code won't look anything like what you expected. Beside
Re: (Score:2)
Well, for me I meant. I specialized in computer architecture and knew to expect loop unrolling, instructions after a branch to still complete (in some architectures), etc. Also all depending on the value of the compiler optimization flag.
I guess I'm just saying I knew I could look at the assembly output, and that it would make sense to me. But once everything switched to virtual machines and intermediary languages...fuck it. You can only infer what comes between the VM and the metal.
Re: (Score:2)
But once everything switched to virtual machines and intermediary languages...f
You do realize that C has ALWAYS been just like this? BSD was running in the 1990s on systems like Stardent and Gould PowerNode that were not even close to the VAX/68000 security blanket so many programmers cling to. On these systems the C compiler had to perform frightful tricks to hide their strange architecture.
And maybe you've never worked on embedded systems? Have you ever seen the remarkable acrobatics that a C compiler has to do, to generate code for strange architectures like AVR and 8051? Again
Re: (Score:3)
Nobody uses C or C++ because they love the language.
I do. I routinely use about a dozen different languages, but C++ remains my favorite by a longshot, followed closely by C.
I despise the blame the human idea (Score:4, Interesting)
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.
Re: (Score:2)
I agree with your last sentence, but I think the key issue is whether the improvements of Rust are enough to justify the problems of using a language that almost no one is familiar with.
I'm no fan of PHP, but if you want to build a contributor community for a web thingy, you'll have more of a chance by using PHP than some other language which fans will explain is superior.
If GCC could be improved to provide to C and C++ the checking that Rust comes with, then that would be close to a win-win.
Re: (Score:2)
the problems of using a language that almost no one is familiar with.
maybe you can name for us a language that has never had this problem
Bondage and discipline Language (Score:2)
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. Th
Get the bullshit bingo bot out of here! (Score:4, Insightful)
People who say 'C/C++' are likely to know neither language.
Re: (Score:2, Insightful)
Old programming languages never die (Score:2)
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 I hear this again, I may puke. (Score:5, Insightful)
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.
Pretty weak (Score:2, Troll)
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
better reasons (Score:4, Informative)
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.
Re: (Score:2)
The only one on your list that actually worries me is the compile times.
It's explicitly not a goal to produce the most concise language possible. It's not a competitor of Haskell/Ocaml/F#/etc., and it doesn't need to be to succeed. Cargo is a build system for a beta language.... fixable. Slow regex isn't inherent to the language.
But if Rust suffers Scala like compile times then yeah, that's bad. Compile time matters.
Re: (Score:2)
Yup. Those arguments seem pretty weak to me. Both inheritance and exceptions are a total crapshoot in C++ (among other so-called features). Any change to those parts of C++ can only be a positive, including completely removing them from the language spec.
Just from TFS, it sounds like somebody who's only dabbled with C++ or maybe even Java and not C++ at all. Like somebody else posted above, whoever says C/C++ most likely knows neither language well, if at all.
I haven't looked at Rust at all, but if it's str
Re: (Score:3)
Yup. In other words, both Mozilla and Google have style guides that are good for filtering outside submissions. There's any number of style guides that endorse C++ exceptions, but they aren't typically as public-facing.
News Flash (Score:2)
Shitty programmers write shitty code, regardless of language.
Re: (Score:2)
you're not going to achieve anything clever with an invalid pointer
Re: (Score:2)