4 ms·

We mostly use C rather than C++, but the same two big reasons get in the way of using Rust for everything: * Compiler support * Availability of suitable engin

We mostly use C rather than C++, but the same two big reasons get in the way of using Rust for everything: * Compiler support * Availability of suitable engineers Context - I work for the Wireless Division of Cambridge Consultants (Cambridge, UK). We build comms technology for our clients for basically anything you can think of - satphone, telecomms infrastructure, bluetooth headphones etc. This means that a lot of the software we right runs on an embedded target - that might be a microcontroller or it might be Linux. And importantly - often when we've designed something, our clients will carry on the maintenance and ongoing development. We have to take the long view - if we choose C/C++ we can guarantee that a compiler will exist for whatever hardware target they choose for the next generation of the product (or even the current generation - architecture swaps often happen at the cost reduction stage). Rust support is improving but can I guarantee that there will be a compiler available for some niche processor, or even the Xilinx Zynq target I'm using at the moment? And then when we hand over the code, we have to explain to the client that it's written in a language that none of their existing software engineers know, and if they advertise for people they may or may not be able to find them. All that said, we are pushing to use more suitable languages for our work. Using C/C++ for anything where security is important is beginning to look irresponsible, the above issues don't always apply and that combined with improved embedded support, more name recognition for Rust and ever more enlightened clients means that it's going to be an easier sell for more and more projects. But not all of them, not now. Actually it turns out that it's easier to sell Elixir as an alternative to some of our C development. My current project is a Linux target, microprocessor support is not important and the challenges it has are exactly what Erlang is designed to solve. I'd also suggest it's easier to incrementally teach the client Elixir than Rust. We'll keep pushing Rust though, and we'll get there eventually.

thenewwazoo 6y ago
I have experienced this horrible chicken-and-egg problem firsthand. I worked at Zipcar building the control boxes used for rentals and the fit for Rust was obvious and compelling, but was squashed by management because it was "too hard to hire" and "the language is underdeveloped". While those things are true, to fix them someone has to just do it. Instead, they fired me and now I make twice the money doing SRE work again at a FAANG.
- bluGill 6y ago
  The problem doesn't exist for in house software. Any good programmer can learn whatever language in a week. They can become good over the next few years. Coworkers to help teach help a lot. When you turn code over to someone else it matters because who you turn it over to needs to learn the language fast and they won't have a few weeks or someone else to teach them.

thenewwazoo 6y ago

I have experienced this horrible chicken-and-egg problem firsthand. I worked at Zipcar building the control boxes used for rentals and the fit for Rust was obvious and compelling, but was squashed by management because it was "too hard to hire" and "the language is underdeveloped". While those things are true, to fix them someone has to just do it. Instead, they fired me and now I make twice the money doing SRE work again at a FAANG.

bluGill 6y ago
The problem doesn't exist for in house software. Any good programmer can learn whatever language in a week. They can become good over the next few years. Coworkers to help teach help a lot. When you turn code over to someone else it matters because who you turn it over to needs to learn the language fast and they won't have a few weeks or someone else to teach them.