> I was referring to mandate to use it at big companies.
I've worked in almost all of big tech, and these companies don't create mandate just because "Trust me bro" or to gain some "political achievements". Their are teams who champion new technology/languages, they create proof of what new technology will bring to the table which cannot be filled with existing ones.
I left amazon 7 years ago so don't know about recent development. However at Meta/Google teams are encouraged to choose from the mandate languages and if they can't they need to request for exemption and justify the exception.
> It might be counterintuitive, but garbage collectors in multithreaded code can be very efficient.
What has garbage collector to do with multithreaded code? Once you have two or more threads which needs to share data, they need to sync and you'd end up using some kind of lock, which will affect the performance. GC doesn't make anything efficient or less efficient here. It might make the code simpler as you don't have to worry about allocation/deallocation, but I don't see how it's magically going to remove the lock.
And tell me how that pointer semantics would do
* a very strict type checking
* Pattern matching
* Algeberic data type
Plenty of people don't write Rust for additional memory safety, they write Rust because the features provided by it is overall very balanced & encourages developer to write code which handles almost all edge cases.
This, from my limited experience working on AOSP at Google, only the newer code were being written in Rust, not the existing code. But that was 2 years ago.
> 3 years working with I might have had at most 3 times nil pointer crashes in prod
I've been running a rust app for my personal trading app and a small service at a very large FAANG company for more than 3 years, and guess what I'm yet to see a nil crash.
It could be different for other teams, but in my team we spend a lot of time writing design docs, discussing new features (which we never end up implementing), taking a lot of time in code reviews, making sure that public changes are backward compatible. Hence at the end producing very little output and wasting tons of time in the due process.
Not really, especially Facebook (Meta) moves really fast. They have a slogan "Move fast, break things", okay not "Break things" anymore. But you get the gist, in my experience working at almost all of FAANG, Meta and Netflix move the fastest.
As far as I can tell from my prior experience of working at Insta is that all the work is done by various services written in C++/hack. Python/Cinder would be just interface layer routing the incoming request/response from/to client.