What to learn next, Swift or Rust

Programming@programming.dev – 55 points – 1 years ago

I’ve been programming for decades, though usually for myself, not as a profession. My current go-to language is Python, but I’m thinking of learning either Swift (I’m currently on the Apple ecosystem), or Rust. Which one do you think will be the best in terms of machine learning support in a couple of years and how easy is it to build MacOS/ iOS apps on Rust?

You are viewing a single comment

View all comments Show the parent comment

Rust on the other hand is multiplatform and super low level

Not to nitpick here, (I agree with pretty much everything you said) but I wouldn't go around calling Rust super low level as it is garbage collected. The borrow checker acts as a abstraction over the actual malloc and free calls that are happening under the hood.

I think you don't know what garbage collection is. Allocations and Deallocations is how the heap works in memory, and is one of the two main structures in it, the stack being the other one. No matter what language you are using, you cannot escape the heap, except if you don't use a modern multitasking OS. ARC is a type of garbage collection that decides when to free a reference after it is allocated (malloc), by counting how many places refer to it. When it reaches 0, it frees the memory (free). With ARC you don't know when a reference will be freed on compile time.

In Rust, the compiler makes sure, using the Borrow checker, that there is only one place in your entire program where a reference can be freed, so that it can insert the free call at that place AT COMPILE TIME. That way, when the program runs there is no need for a garbage collection scheme or algorithm to take care of freeing up unused resources in the heap. Maybe you thought the borrow checker runs at compile time, taking care of your references, but that's not the case, the borrow checker is a static analysis phase in the Rust compiler (rustc). If you want to use a runtime borrow checker, it exists, it's called RefCell, but it's not endorsed to use. Plus, when you use RefCell, you also usually use Reference Counting (Rc RefCell)

Perhaps garbage collection is the wrong term to use as it dosen't happen at runtime (I wasn't sure what other term to call what Rust does). But Rust does provide a abstraction over manual manual memory management and if you are experienced with Rust sure you can probably visualize where the compiler would put the malloc and free calls so it is kind of a mix where you do technically have control it is just hidden from you.

Edit: It seems the term is just compile-time garbage collection so maybe you could consider it falling under garbage collection as an umbrella term.

Isn't that basically the same as how C++ RAII works?

Essentially although there are a few key differences:

In Rust there always only one owner while in C++ you can leak ownership if you are using shared_ptr.
In Rust you can borrow references you do not own safely and in C++ there is no gurantee a unique_ptr can be shared safely.
In Rust, A lot more compile time optimization for the borrow checker is available whereas in C++ the type system dosen't always let the compiler know for sure when an object goes out of scope, is moved, or is destroyed and so you miss out on a lot of optimization that would be trivial with Rust like syntax.

You raised an issue that the other bulletpoint has the solution for, I really don't see how these are "key differences".

In Rust there always only one owner while in C++ you can leak ownership if you are using shared_ptr.

That's what unique_ptr would be for. If you don't want to leak ownership, unique pointer is exactly what you are looking for.

In Rust you can borrow references you do not own safely and in C++ there is no gurantee a unique_ptr can be shared safely.

Well yeah, because that's what shared_ptr is for. If you need to borrow references, then it's a shared lifetime. If the code doesn't participate in lifetime, then ofcourse you can pass a reference safely even to whatever a unique_ptr points to.

The last bulletpoint, sure that's a key difference, but it's partially incorrect. I deal with performance (as well as write Rust code professionally), this set of optimizations isn't so impactful in an average large codebase. There's no magical optimization that can be done to improve how fast objects get destroyed, but what you can optimize is aliasing issues, which languages like C++ and C have issues with (which is why vendor specific keywords like __restrict exists). This can have profound impact in very small segments of your codebase, though the average programmer is rarely ever going to run into that case.

Pretty much, with some atomic additions like "you cannot mutate a reference when it is borrowed immutably elsewhere" or "you cannot borrow a reference mutably multiple times".

1 more...