Earlier quoted context omitted.
Can you talk more about this? I'm very curious.
Every time I play with embedded Rust I get this feeling that some of the people driving it are more into language esthetics and don't have experience in real-world embedded systems. For example, I see inefficient patterns that are common in frontend world but have no place in an embedded system being promoted as "proper" way of doing things.
Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022
231–233 of 233 posts
Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022
#232Earlier quoted context omitted.
“It is difficult to get a man to understand something, when his salary depends on his not understanding it.” ― Upton Sinclair Amount of dislike on HN for Rust is frankly unexpected, one part might be response to evangelization, but I've seen more hate on evangelization than actual evangelization. Sure, Rust ain't perfect but like C++ is even more imperfect. So that leaves me with job security in C++.
I don't see much dislike for Rust on HN. It's probably the most loved language around here.
Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022
#233> Rumor 2: The Rust compiler is not as fast as people would like – Confirmed ! I wish there was more context to these, especially this one. For example, how much of this is perception compared to what they were used to (go?, Python?, C++?)? Or is it "any waiting is bad"? From an improvement perspective, I'd also love to know why their builds are slow. Is it proc-macro heavy? Do they have wide and deep dependency grap…
In my experience from a Googlish environment (tho mostly focusing on backend service development): 1. people don't know about check builds and have a much nicer iteration experience once they learn about it, 2: rust-analyzer red wiggles also help, and 3. a lot of the actual build time is from build/link of C++ dependencies from the rest of the codebase.