despite developers' positive feelings toward Rust, 97% of them hadn't actually used it.
Who says they love something they have not used???
I might say something seems decent, but no way would I say I *LOVE* a language until I've done a few real things in it.
The top issues that respondents say the Rust project could do to improve adoption of the language are better training and documentation, followed by better libraries, IDE integration, and improved compile times...
I don't see why anyone would "love" any programming language.
I have looked at Rust and written some simple toy programs. But I don't use it for work.
The problems Rust claims to fix, such as memory leaks, buffer overflows, and safe threads, can be done in C++ with "safe pointers", proper programming practices, and coding standards.
So, with a huge code base of working C++, it doesn't make sense to switch. It would be yet-another-language that everyone we hire would need to know. We would be constantly swit
The problems Rust claims to fix, such as memory leaks, buffer overflows, and safe threads, can be done in C++ with "safe pointers", proper programming practices, and coding standards.
How do you automate auditing a C++ project for use of the sort of "proper programming practices and coding standards" that prevent the same problems that safe Rust prevents?
The problems Rust claims to fix, such as memory leaks, buffer overflows, and safe threads, can be done in C++ with "safe pointers", proper programming practices, and coding standards.
How do you automate auditing a C++ project for use of the sort of "proper programming practices and coding standards" that prevent the same problems that safe Rust prevents?
If you need to assure high code quality, you need to audit a lot more stuff than Rust does automatically. And then the difference in language stops to matter and the difference in coder skill is everything.
How do you automate auditing a C++ project for use of the sort of "proper programming practices and coding standards" that prevent the same problems that safe Rust prevents?
1. Static analysis tools can warn if naked pointers are used.
2. Memory allocation can be instrumented for testing. A good programming practice is to fully unwind all memory allocation before exiting. Any leaks will be detected. This will even catch leaks from cyclic references that Rust does NOT prevent (yes, Rust can leak memory).
3. I don't know much about Rust's concurrency model, but if I Google for "rust deadlock", I get plenty of hits. So it looks like Rust isn't a magic solution.
If you are using new (or god forbid malloc) instead of the STL containers and class members to allocate and delete objects, you are setting yourself up for failure.
So no shared_ptr for you? No objects with dynamic lifetime? Looks like you would enjoy using linear type system like Rust has.
shared_ptr requires you to use new or malloc? And what do you imagine by "dynamic lifetime"? Don't you mean indefinite lifetime? Since otherwise it doesn't make a lot of sense to me.
Seriously. Their docs tell me that it can automate the really easy case with smart pointers that C++ does fine if you write sensible code. But what about the difficult stuff? How does it hanndel a linked list?
You have to work hard to get past all the propaganda to find the meat, if there is any. I have not had time.
What I have seen is that you use Rust essentially like old Visual Basic, with lots of variable length arrays that you ReDim (aka "Vectors"). An easy style to use safely with C++, and not a b
The major problems with C++ all started when STL was adopted. Just my opinion, but I'm glad I'm off of C++ and doing C. It means that code reviews can focus most of the time on bugs or actual problems, rather than endless complaints that current fashions aren't being followed.
The attitude that no one can use new or malloc, and yet STL uses new and malloc, causes people to start thinking that STL was written by the Gods themselves and no mere programmer could accomplish this, and even suggesting to alloc a
And before you start spewing about vectors vs C-style arrays performance, I would suggest you revisit some simple profiling code; vectors are just as fast as c-style arrays these days.
Actually, no.
The C++ standard doesn't give any guarantees on how quickly the OS has to service your request for a dynamically allocated block on the heap. Most modern desktop CPUs and OSes do this very quickly, but there are embedded platforms where allocating memory off in the heap takes multiple milliseconds.
I'm mostly embedded with C, so using pointers and malloc is normal. However most everything on small systems wants to use memory pools and not arbitrary mallocs, except for buffers. So with a bit of instrumenting, it's easy to find out if someone has leaked something and what code did it.
Wait a second... (Score:5, Insightful)
despite developers' positive feelings toward Rust, 97% of them hadn't actually used it.
Who says they love something they have not used???
I might say something seems decent, but no way would I say I *LOVE* a language until I've done a few real things in it.
The top issues that respondents say the Rust project could do to improve adoption of the language are better training and documentation, followed by better libraries, IDE integration, and improved compile times...
That is a pretty tall list of things that
Re: (Score:2)
I don't see why anyone would "love" any programming language.
I have looked at Rust and written some simple toy programs. But I don't use it for work.
The problems Rust claims to fix, such as memory leaks, buffer overflows, and safe threads, can be done in C++ with "safe pointers", proper programming practices, and coding standards.
So, with a huge code base of working C++, it doesn't make sense to switch. It would be yet-another-language that everyone we hire would need to know. We would be constantly swit
How to automate C++ auditing? (Score:1)
The problems Rust claims to fix, such as memory leaks, buffer overflows, and safe threads, can be done in C++ with "safe pointers", proper programming practices, and coding standards.
How do you automate auditing a C++ project for use of the sort of "proper programming practices and coding standards" that prevent the same problems that safe Rust prevents?
Re: (Score:2, Funny)
How do I automate auditing the morals of Rust developers so I can continuously judge (CJ) them and reject them from a project?
Re: (Score:2)
The problems Rust claims to fix, such as memory leaks, buffer overflows, and safe threads, can be done in C++ with "safe pointers", proper programming practices, and coding standards.
How do you automate auditing a C++ project for use of the sort of "proper programming practices and coding standards" that prevent the same problems that safe Rust prevents?
If you need to assure high code quality, you need to audit a lot more stuff than Rust does automatically. And then the difference in language stops to matter and the difference in coder skill is everything.
Re: (Score:2)
How do you automate auditing a C++ project for use of the sort of "proper programming practices and coding standards" that prevent the same problems that safe Rust prevents?
1. Static analysis tools can warn if naked pointers are used.
2. Memory allocation can be instrumented for testing. A good programming practice is to fully unwind all memory allocation before exiting. Any leaks will be detected. This will even catch leaks from cyclic references that Rust does NOT prevent (yes, Rust can leak memory).
3. I don't know much about Rust's concurrency model, but if I Google for "rust deadlock", I get plenty of hits. So it looks like Rust isn't a magic solution.
Re: (Score:1)
This will even catch leaks from cyclic references that Rust does NOT prevent (yes, Rust can leak memory).
Please elxplain how this can happen in Rust without unsafe keyword.
Re: (Score:2)
A good programming practice is to fully unwind all memory allocation before exiting.
That is a waste time - and leads to unlogical code.
Why does this object get deleted here? "Oh, because the app is quitting ... oh!"
Re: (Score:2)
Re: (Score:1)
If you are using new (or god forbid malloc) instead of the STL containers and class members to allocate and delete objects, you are setting yourself up for failure.
So no shared_ptr for you? No objects with dynamic lifetime? Looks like you would enjoy using linear type system like Rust has.
Re: (Score:2)
Re: (Score:2)
What does Rust actually do? (Score:2)
Seriously. Their docs tell me that it can automate the really easy case with smart pointers that C++ does fine if you write sensible code. But what about the difficult stuff? How does it hanndel a linked list?
You have to work hard to get past all the propaganda to find the meat, if there is any. I have not had time.
What I have seen is that you use Rust essentially like old Visual Basic, with lots of variable length arrays that you ReDim (aka "Vectors"). An easy style to use safely with C++, and not a b
Re: (Score:2)
The major problems with C++ all started when STL was adopted. Just my opinion, but I'm glad I'm off of C++ and doing C. It means that code reviews can focus most of the time on bugs or actual problems, rather than endless complaints that current fashions aren't being followed.
The attitude that no one can use new or malloc, and yet STL uses new and malloc, causes people to start thinking that STL was written by the Gods themselves and no mere programmer could accomplish this, and even suggesting to alloc a
Re: (Score:2)
Re: (Score:2)
Actually, no.
The C++ standard doesn't give any guarantees on how quickly the OS has to service your request for a dynamically allocated block on the heap. Most modern desktop CPUs and OSes do this very quickly, but there are embedded platforms where allocating memory off in the heap takes multiple milliseconds.
Likewise, mode
Re: (Score:2)
P.S. I would love a compiler warning that prevents pointer arithmetic. So when I write
"the answer is " + 5
I get a proper error message.
It should be possible to force safe C++ in all but a few selected modules.
(Overloading "+" for string concat was madness, they should have followed VB and used "&". )
Re: (Score:2)
I'm mostly embedded with C, so using pointers and malloc is normal. However most everything on small systems wants to use memory pools and not arbitrary mallocs, except for buffers. So with a bit of instrumenting, it's easy to find out if someone has leaked something and what code did it.
Re: (Score:2)
If you trust Rust to the degree that you don't need proper programming practices and coding standards, then good luck with your project.