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."
"... 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.
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.
File under 'M' for 'Manic ranting'
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.
>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.
> 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.
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.
Given that they said "all the bugs typical of C++" one might think they they're implying that they are "simply capable of detecting bugs of all the typical C++ bug categories". If they'd said "it can catch all the bugs that have ever been put in C++ and God DAMN but we solved the halting problem!" then you might have a point, but they didn't, so you don't.
Learning how to read is a useful skill. I advise practice.
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.
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.
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!
SJW n. One who posts facts.
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.