Answering my own question here.
If you don't have any interest in how the tools you use work, programming isn't "for you" (take that with a grain of salt). If you are writing code and have never looked into how compilers/interpreters work or are using a library and haven't even taken a peak at the library's source code you should because it will make you a better programmer in the long run. And I'm not saying you can't get anything done without that curiosity but curiosity is a major part of being a programmer. Also you don't need to have a deep understanding of the tool just a overview of what it's doing. Like for a compiler understanding what lexers, parsers, ASTs, code generators are will allow you to write code with that in mind.
I agree that make is confusing at first but I don't think it should fall out of use. It's a great tool that I use everyday it is far simpler than its competitors once you get used to it. It is basically glorified bash scripting.
For navigating files quickly fzf is pretty much crucial to my workflow. Being able to get my home directory to the directory of the project I want to work on in two seconds flat is such a nice feeling after manually typing the path in for months.
https://github.com/junegunn/fzf
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.
Can't use bottom because for some reason phone manufacturers decided to remove physical home keys and just have virtual ones. Whenever I try to click or swipe at the bottom of my screen I end up hitting it.
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.
Other than having first class support on Apple's hardware Swift dosen't have much going for it. There is no killer feature in Swift, it dosen't widespread features and it only has a small niche. If you want to develop for mainly Apple devices I would say go for it as that is the niche it was designed for. Although I see from your post you want to do ML, Python for the high level stuff + C++ for the low level stuff is probably your best pick for that. May I ask what type of ML are you going for? Are you mainly using libraries like Tensorflow, Pytorch etc... or are you into the nitty gritty of building these things yourself and writing the required code for the matrix math and training algorithms.
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.
My bad, I should have been more specific in my post. I was talking in the context of software which in most music players has the pause and play buttons occupying the same space. On physical devices such as dvd player I obviously consider the pause button as "to pause" and the play button as "to play"
The code is produced by the compiler but they are not the original source. To qualify as source code it needs to be in the original language it was written in and a one for one copy. Calling compiler produced assembly source code is wrong as it isn't what the author wrote and their could be many versions of it depending on architecture.
By excluded he means macro assemblers which in my mind do qualify as an actual langauge as they have more complicated syntax than instruction arg1, arg2 ...
Yes I understand that but in most software they don't have seperate play and pause buttons but rather only one which swaps symbols when you click and so for me when I want to know whether it is currently playing I just look at the button.
Answering my own question here. If you don't have any interest in how the tools you use work, programming isn't "for you" (take that with a grain of salt). If you are writing code and have never looked into how compilers/interpreters work or are using a library and haven't even taken a peak at the library's source code you should because it will make you a better programmer in the long run. And I'm not saying you can't get anything done without that curiosity but curiosity is a major part of being a programmer. Also you don't need to have a deep understanding of the tool just a overview of what it's doing. Like for a compiler understanding what lexers, parsers, ASTs, code generators are will allow you to write code with that in mind.