> 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 indeed doesn't look elegant, however I've never in my experience seen a usage like this. Do you have any reference where you might have seen this kind of usage.
No, let me try to explain differently. If `compact_str` was not used, then your normal `String` would take 24 bytes of stack space (regardless of the string size) + heap space. What `compact_str` is trying to do is not use heap when string content is less than 24.
How's your experience with Leptos so far? I gave it a try over a weekend for my pet project, felt that it's not ready for prime time yet, so decided to go ahead with Dioxus (which doesn't mean that it's more stable or anything).
Looks very impressive, I've been tinkering with this idea to have a Kotlin type of language which transpiles to Go, but didn't go past writing a parser. Kudos for working on it, I hope it gains some popularity.