Slashdot Mirror
Criticizing the Rust Language, and Why C/C++ Will Never Die
An anonymous reader sends an article taking a harsh look at Rust, the language created by Mozilla Research, and arguing that despite all the flaws of C and C++, the two older languages are likely to remain in heavy use for a long time to come. Here are a few of the arguments: "[W]hat actually makes Rust safe, by the way? To put it simple, this is a language with a built-in code analyzer and it's a pretty tough one: it can catch all the bugs typical of C++ and dealing not only with memory management, but multithreading as well. Pass a reference to an assignable object through a pipe to another thread and then try to use this reference yourself - the program just will refuse to compile. And that's really cool. But C++ too hasn't stood still during the last 30 years, and plenty of both static and dynamic analyzers supporting it have been released during this time."
Further, "Like many of new languages, Rust is walking the path of simplification. I can generally understand why it doesn't have a decent inheritance and exceptions, but the fact itself that someone is making decisions for me regarding things like that makes me feel somewhat displeased. C++ doesn't restrict programmers regarding what they can or cannot use." And finally, "I can't but remind you for one more time that the source of troubles is usually in humans, not technology . If your C++ code is not good enough or Java code is painfully slow, it's not because the technology is bad - it's because you haven't learned how to use it right. That way, you won't be satisfied with Rust either, but just for some other reasons."
Further, "Like many of new languages, Rust is walking the path of simplification. I can generally understand why it doesn't have a decent inheritance and exceptions, but the fact itself that someone is making decisions for me regarding things like that makes me feel somewhat displeased. C++ doesn't restrict programmers regarding what they can or cannot use." And finally, "I can't but remind you for one more time that the source of troubles is usually in humans, not technology . If your C++ code is not good enough or Java code is painfully slow, it's not because the technology is bad - it's because you haven't learned how to use it right. That way, you won't be satisfied with Rust either, but just for some other reasons."
No, I'm pretty sure the heat death of the universe will kill those languages
SJW's don't eliminate discrimination. They just expropriate it for themselves.
"... but the fact itself that someone is making decisions for me regarding things like that makes me feel somewhat displeased. C++ doesn't restrict programmers regarding what they can or cannot use."
That's exactly what I said about C vs. 360/Assembler 25 or more years ago. And I still prefer to code in Assembler.
No. Well...maybe. Actually, yes. It really just depends.
A programming language is better if it does one thing: Solves a particular type of general problem more efficiently and clearly than the language of comparison. The larger this set and scope of general problems, the better the language; the fewer corner cases hinder the language, the better the language.
You will find the integration of mathematical languages, physics languages, or graphics languages into a general programming language a pile of clutter and complication. They won't integrate with much of the language, or they'll complicate it, or they'll constrict it. This is why you have libraries in a language to do some general tasks (Box2d, PhysX APIs, etc.), low-level specialized assemblies (OpenGL CUDA, shader assembly), and specialized high-level languages (R, Matlab): these tasks are best integrated by interfacing with a black box that takes in a data set, runs it through a set of coded procedures, and spits out a result.
What makes a programming language "better" than state-of-the-art is its ability to supply general programming practices and functionality in an efficient way for humans. Classes that can be easily swiveled or overloaded or extended or polymorphed, but only in a way that a human being can reliably understand--that is, that a human being who has studied the language won't still struggle with understanding the workings of the language due to its conflict with the method of human thought. Code bodies which are simultaneously readable, maintainable, and efficiently executable. The ability to represent a wide variety of specialized tasks as API classes and functions, even if less effective than a specialized language, should someone seek to integrate physics or mathematics or cryptography or other such things with their program. All of these things, reflected in a way a human can grasp and use with fewer human-introduced defects, and also in a way that does not constrict the human from approaching the subset of programming tasks carried out in nearly 100% of code (imagine if 1 in 100 functions needed a specialized language, not a simple library API or raw programming code; even the Linux kernel is far less than 1% low-level assembly).
It is not valid to say that people are bad at programming in C++ because they are bad programmers; but it is valid to say that bad programmers will not become good programmers if given a good language. If we assume, for example, that Perl is terrible and Python is some form of holy perfection, then we can claim that Perl will cause a good, studied, skilled Perl programmer to make many more defects than a good, studied, skilled Python programmer will make in Python; indeed, our metric for whether Perl or Python is superior to one another would be both the speed at which a new inductee to the language can learn to code with similar defects--how much programming exposure over a variety of challenging tasks does a person need in order to use the language for tasks of similar complexity without creating defects? Swift, Rust, C#, and so forth will face the same challenges: what is the defect rate produced by the programmer, relative to the amount of effort and resulting skill of the programmer in the given language, and how does it compare to all other languages?
Bad languages will make good programmers produce more bad code. Good languages will not make bad programmers produce good code; they will enable good programmers to produce less bad code.
Support my political activism on Patreon.
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.
> 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.
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 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
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.
Nothing screams efficiency, well maintained, clean, and smooth running software like calling it "Rust"
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.
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.