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."
> 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.
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.
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.
SJW n. One who posts facts.
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.
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.
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.