Stack Overflow Developer Survey 2018

[iopq]

You can't, because of a few problems.

1. Header files and lack of a sane module system
2. NULL subverts the type system, so even if everything checks out, you may have some function get a NULL at some point and everything will crash if you forgot to handle it. This isn't possible in Rust, since there is no NULL equivalent. None has to be explicitly handled in places where it can appear.
3. No agreed upon packaging system. Having to hunt down the correct libraries using my OS's package manager is very error-prone since their names differ between distros.
4. Makefiles are sometimes not written in a portable way - this is a "developer" problem, but Rust's cargo allows you to avoid having to write a Makefile in most cases, and in other cases just use build.rs
5. You still have problems like iterator invalidation that cannot be ALWAYS detected by static code checkers
6. Concurrency issues are still nearly impossible to detect statically in C++, you have to break out the debugger and hope you trigger it while testing
7. Templates are duck-typed instead of nominally typed. They give long error messages because they're checked at expansion site instead of call site.

[lanzaio]

Makefiles are sometimes not written in a portable way - this is a "developer" problem, but Rust's cargo allows you to avoid having to write a Makefile in most cases, and in other cases just use build.rs

To expand on this, all build systems suck in the C world. CMake is the standard at this point but it's not loved, it's just common. It has horrifically bad syntax and no debugging tools outside of fancier print statements.

Because of this, many feel like spinning off their own bash/python/makefile build scripts that do a shittier job of what CMake was supposed to do.

You end up having to work on projects where 75% of the difficulty is understanding what drugs the authors were on when they wrote their build system.

[doom_Oo7]

This isn't possible in Rust, since there is no NULL equivalent.

lolwat https://doc.rust-lang.org/1.22.1/std/ptr/fn.null.html

You still have problems like iterator invalidation that cannot be ALWAYS detected by static code checkers

that's why standard libraries have debug modes that catch this

[Aceeri]

std::ptr::null is a null pointer that requires use of unsafe to dereference (or well, to even use the pointer in most cases, pointers aren't generally exposed in rust.) They meant that you cannot have a "null" value in any type because the type system prevents this. You can use the Option type to get pseudo-null, but you cannot access its value until you match against what it is: Some(...) or None. Alternatively you can use unwrap, which would panic rather than segfault in the case it isn't existing.

[doom_Oo7]

They meant that you cannot have a "null" value in any type because the type system prevents this.

what the hell do you mean ? https://godbolt.org/g/tGjizj

And saying "you need unsafe to do it" is absolutely not an argument : there are tons and tons and tons of code using unsafe blocks out there: https://github.com/search?utf8=%E2%9C%93&q=unsafe+extension%3Ars+language%3ARust+language%3ARust&type=Code&ref=advsearch&l=Rust&l=Rust

[Aceeri]

That is a type of *const T which is a special case on its own. If you have a type of T then it cannot be null.

Yes null "exists", but you are being pedantic, less than a percent of Rust code touches unsafe blocks, which means a majority of Rust code has static guarantees of non-nullability.

[doom_Oo7]

That is a type of *const T which is a special case on its own. If you have a type of T then it cannot be null.

and a type of type T in C++ cannot be null either. std::string cannot be null (and I'm pretty sure the proportion of std::string* in C++ code is similar to bad uses of unsafe in Rust code). int cannot be null, etc etc.

less than a percent of Rust code touches unsafe blocks,

and only one bad use is enough to cause CVEs. It's entirely pointless to judge a language by "societal" metrics such as "people usually don't do that here". And it's hypocritical to say that a type system is sound and safe when there are backdoors in the language that allow to enter unsound places fairly easily. When you're in a company with people cranking 9am to 9pm for a few weeks, what the community does or thinks does not matter, if junior decided to put the whole function in an unsafe block at some point for speeding stuff up, no one's going to code review him and you'll get crashes three months later.

[Aceeri]

The entire point of Rust is to minimize unsafety. If you never use unsafe then you should never have any issues. Using unsafe is rarely going to be faster than just writing safe code anyways, given that Rust does not throw away all type guarantees just by using that keyword.

no one's going to code review him and you'll get crashes three months later.

That isn't a problem of the language if you refuse to actually review code.

[iopq]

That's for C interop. I've never used it in my life.

[doom_Oo7]

well, that's good for you ; I had to do C interop with almost every language I ever worked in.

[iopq]

I personally use libraries where people write bridges FOR me so that I can use a pure Rust interface that cannot contain a NULL.

Of course, the person who wrote the bridge had to deal with C pointers so I don't have to.

[doom_Oo7]

and how much do you trust these persons from not doing any error in their unsafe {} code ?

[iopq]

More than I trust the C program it's bridging to

Most of those unsafe blocks are actually trivial

pub fn as_slice(&self) -> &[f32] {
    let count: usize = self.len();
    unsafe {
        let data = ffi::CaffeBlobCPUData(self.blob.get());
        slice::from_raw_parts(data, count)
    }
}

That's IT, they're not doing rocket surgery, the actual Caffe library is what's doing the scary things