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?
Swift has little to no use outside the apple ecosystem, and even if you are currently using Apple, you have to consider your targets as well. Writing in Swift means your code will only be usable by other Apple users, which is canonically a rather small fraction of technology users. Rust on the other hand is multiplatform and super low level, there’s very few other languages out there that can match the potential of applications of rust code. Thus you will, in time, be introduced to many other technologies as well, like AI/ML, low level programming, web, integrations between languages, IoT, those are only a few of all the possibilities. On the other hand, even if Swift has a much more mature ecosystem, it’s still only good for creating UIs in all things Apple, which is pretty telling; Apple is not willing to put in the time and effort to open it’s language to other fields, because it sees no value in them being the ones providing the tooling for other purposes. They pretty much only want people to code web apps for them, and Swift delivers just fine for that. So if your current purpose is making Apple UIs, you could learn Swift, but be warned that either you’ll either be doing that your whole life or will eventually be forced to change languages again.
Then again, most languages nowadays aren’t that different from each other. I can code in a truckload of languages, not because I actually spent time making something coherent and complete with each one of them, but because I know some underlying concepts that all programming languages follow, like OOP, or functional programming, and whatever those entail. If you learn those you will not be afraid to switch languages on a whim, because you’ll know you can get familiar with any of them within a day.
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:
You raised an issue that the other bulletpoint has the solution for, I really don’t see how these are “key differences”.
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.
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
__restrictexists). 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”.
deleted by creator