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 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.
Likewise, modern CPUs tend to aggressively cache vectors in ways that are absolutely beautiful. But in embedded systems with simpler CPUs, they may very well be accessing each element of the vector via a pointer indirection.
The world's a much bigger place than server farms and laptops. In those areas, yeah, std::vector<T> is a lifesaver. But in the IoT world there's still a very real need for C-style stack arrays.
This is, incidentally, the entire motivation for std::array<T, std::size_t> in C++11. The embedded guys insisted on a container with an STL-compatible API which would be compiled down to straight-up C arrays. I've never found anything in the embedded space where a std::array<T, std::size_t> was an inappropriate choice, but I've been in lots of projects where a std::vector<T> was simply not in the cards.
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)
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:How to automate C++ auditing? (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, modern CPUs tend to aggressively cache vectors in ways that are absolutely beautiful. But in embedded systems with simpler CPUs, they may very well be accessing each element of the vector via a pointer indirection.
The world's a much bigger place than server farms and laptops. In those areas, yeah, std::vector<T> is a lifesaver. But in the IoT world there's still a very real need for C-style stack arrays.
This is, incidentally, the entire motivation for std::array<T, std::size_t> in C++11. The embedded guys insisted on a container with an STL-compatible API which would be compiled down to straight-up C arrays. I've never found anything in the embedded space where a std::array<T, std::size_t> was an inappropriate choice, but I've been in lots of projects where a std::vector<T> was simply not in the cards.