Posts by karlnapf42

Re: Why?

The problem is that Rust has proven that you can have memory-safety without a garbadge collector or other runtime tolls. It does not matter whether rust stays or gets replaced with something else, it has moved the bar already.

Languages now need to deal with that, one way or thebother.

Re: Much too easy to make memory errors

I see few crates (libraries in rust) that actually use unsafe blocks. Those that do tend to have a good reason for it: E.g. interacting with code in other languages via C bindings or hairy data structures.

The idea is to build safe abstractions around that unsafe code so that normal programmers do not have to deal with all the hardship. That is very much the same approach good C++ libraries around existing C code use as well: They hide away as much of the complexity of using the C interfaces in exactly the right way by providing simpler to use and safer APIs using C++ features missing in C.

Re: Memory safety

> Memory safety isn't just about "corruption", "leaks" and so it;

You can leak memory in safe Rust: That is fine and not a safety issue at all.

> Does Rust allow memory allocation to be controlled in the same way as C++ does (user-provided allocators and the like)?

That is in the works still: Linus rightfully insisted that this is needed to use Rust in the kernel. Usually Rust will panic when running out of memory.

> A lot of safety systems prohibit the use of dynamic memory

Rust comes with three standard libraries: Core, alloc an the std nowadays. Core holds all the core stuff and does not allocate memory ever. The alloc crate adds memeory allocation and data structures that need that. The actual standard library (which core and alloc were split out of) is basically a combination of those two plus a few extras.

It is perfectly possible to write code using core only -- that is widely used in embedded development. There is a ever growing library eco-system that is "no-std" and avoids alloc or allows to opt out of alloc use.

Re: Funky new ecosystems == bleeping annoying to use in an existing environment

> Rustup needing internet access

You do pick the specific version of the compiler you want and they promise not to replace the packahes behind your back. So the situation is pretty similar to any other project, just that rustup downloads the packages for you -- instead of you downloading them yourself.

> Building an existing C library

Yeap, you need a build.rs to build non rust code with Cargo. There are lots of examples out there: Check crates.io for any crate ending in -sys. Those will contain an example build script for some existing library. If you are lucky you might find that somebody else already went through the trouble for you.

Note that there is no real way around cargo when using rust: Cargo is the "offical" interface to building rust code. Calling the compiler directly is not supported. You can not drop the rust compiler into your build system (and get support for that combination!), you have to drop the rust build system into your build system.

In the setup you propose I would not bother to switch the overall build system to cargo, but use cargo in the existing build system. Depending on the build system you use there are projects to help with that. E.g. corrosion-rs/corrosion on github helps to integrate cargo into an existing CMake project.

Re: C/C++ - really?

> How does Rust handle "can't open socket", "corrupted input", "hardware vanished", "insufficient contiguous memory available" and the like?

Like it handles all errors: By returning an Result.

Results need to be handled, there is no way around it. If you force it, then application panics when an error actually happens.

Yes, there is boilerplate passing Results up the call chain: `?` gets the OK value out of a Result or bubbles the problem up the call stack. I love it: It is simple, obvious and you always know where and what can actually happen.

> Idiomatic C++ uses exceptions for this, automatically cleaning up everything until it reaches a level in the stack that knows how to handle it.

... except when your code is not exception safe: Things explode in a nice display of color -- sometimes.

Or uses Qt or something that has banned the use of exceptions.