SoylentNews is people
SoylentNews
After many years of waiting, version 1.0 of the Rust programming language has finally been released. The Rust home page describes Rust as "a systems programming language that runs blazingly fast, prevents nearly all segfaults, and guarantees thread safety."
Thanks to the hard work of noted Rust core team members Yehuda Katz and Steve Klabnik, Rust is now poised to become a serious competitor to established systems programming languages like C and C++.
The announcement has brought much jubilation to the followers of Rust, who have been eagerly awaiting this milestone release for so long. With only 1,940 open issues and over 11,500 issues already closed, Rust is finally ready for users to build fantastically reliable software systems using it.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Recursion n.:
See Recursion.
-- Random Shack Data Processing Dictionary
(Score: 2) by maxwell demon on Saturday May 16 2015, @11:13AM
RAII is not "great difficulty". Of course if you insist to still use manual new/delete, then things can get complicated. But there's normally no reason to do that.
You demonstrate that you have no clue about C++. C++ code runs just as fast as C code, unless it got programmed by a complete moron.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 3, Insightful) by turgid on Saturday May 16 2015, @11:21AM
You demonstrate that you have no clue about C++. C++ code runs just as fast as C code, unless it got programmed by a complete moron.
I've seen an awful lot of C++ code over the years, and the more I see of it, the more I realise that 99.9% is written by complete morons.
C++ code tends to be complex, brittle and buggy, slow to compile, hard to debug (people think the "strict type safety" of C++ absolves them of writing unit tests and checking errors), incompatible at the binary level with everything else (and the library you compiled last week)...
And lets not mention that C++ people are allergic to actually writing proper code to solve a specific problem because there are "standard libraries" that they can throw at it until it superficially hides it.
And just what on earth are C++ exceptions about? Talk about giving people a machine gun to shoot themselves in the foot with...
C++ will always be with us, I'm afraid, so it's best to know your enemy.
If you're thinking about writing something in C++, do yourself and the world a favour an write it in plain C. You stand a chance of getting it to work correctly, understanding it 6 months later, and being able to reuse it in another project.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by maxwell demon on Saturday May 16 2015, @12:11PM
So you think the people who don't write unit tests for C++ would write them for C?
And what is wrong with using the standard library? Do you also reimplement printf to avoid using the C standard library? The standard library is there to be used, and should consist of decent code; if not, use another vendor (if the standard library implementation is shit, probably the compiler is, too).
Of course you have to learn how to correctly use the library, just as you have to learn how to correctly use the language (and mind you, there's more than enough C code written by morons as well). If you think that implementing a stack by inserting/removing values at the beginning of a vector (yes, I've seen that!) is a good idea, then you are simply clueless. But that's not a fault of the standard library, that is the fault of the code author.
And there are many more ways to shoot yourself in the foot with C style return-error-code error handling; You can simply ignore errors without immediate consequences — until the error actually occurs. In which case the ignored error can have fatal consequences. Now in C++, you of course also can ignore exceptions, but you have to do so explicitly. just not handling the exceptions will cause the program to terminate, instead of simply continuing despite of the error.
And of course, if you prefer C-style error handling, you can use it in C++ as well; however you can even improve on that by making completely ignoring the return value a runtime hard fail even if no error occurred (I don't know a way to make it a compile time error, though).
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Saturday May 16 2015, @06:52PM
People who write bad C++ code aren't going to magically write good Rust code!
(Score: 0) by Anonymous Coward on Monday May 18 2015, @07:03PM
No, they're going to hang out on interweb forums boasting about how wonderful C++ is and that all the people that can't see that are ignorant morons.
(Score: 1, Funny) by Anonymous Coward on Saturday May 16 2015, @10:09PM
I've seen an awful lot of C++ code over the years, and the more I see of it, the more I realise that 99.9% is written by complete morons.
OTOH Rust will attract programmers who are far, far, above average, and will be studiously careful to use the language only in the right way...
(Score: 1, Funny) by Anonymous Coward on Sunday May 17 2015, @10:48PM
Even the designers of Rust couldn't implement the Rust compiler using Rust without introducing a shitload of bugs.
(Score: 3, Interesting) by bart9h on Saturday May 16 2015, @12:43PM
C++ could run just as fast as C code, *IF* you mostly use C-style coding.
I once rewrote a routine to read a file huge text file with 3D coordinates and values,
from using standard C++ streams to C's fscanf().
It was EIGHT times faster. And no, it was not badly written in C++. I had already optimized the hell of it, avoiding creating std::string objects, etc, even with the help of my brilliant coworkers (one of them, which is a HUGE fan of C++, was latter hired by Amazon).