Hi Rusters
About 4 months ago I've rewritten old Go based server networking application to Rust using mio as a networking engine. Results are really incredible and we all happy with that.
But now when I've started hiring process to scale project and add more features, most of the team members wanted to rewrite Rust codebase to C++, because they have C++ background.
I tried both and for me Rust's type safety and memory management is Great! But for me as a project/company owner is important to keep balance and comfortable environment for my employees.
So the problem is how convince developer with C++ background to start developing with Rust ?
And if someone have that kind of experience in their teams please share that story if you can!
Ultimately its their choice what they want to use. You may try to convince them that its an improvement over C++, but if they are unwilling to learn new things or see their career as C++ developers, there isn't much you can do about it.
One more question: were they informed that they will write Rust when you hired them?
Yes they have been informed, but after spending 1 week of learning Rust, they started fighting with compiler and even one of the team members implemented task using C++ then called it from Rust, just because he didn't liked Rust syntax
Work is going and somehow they are doing tasks, but I'm trying to find a way to convince that Rust isn't bad. That's why I just wanted to hear some thoughts is there anyone else who have similar problem ?
I strongly disagree. In a team it is important, that everyone uses the same language, style, etc, otherwise you end up with an unmaintainable mess.
I don't say that the team leader should decide without considering the feedback of the developers, but in the end someone he to make a decision.
Also, the preference of the developers should never be the only decision criterion. For an exposed server application, memory safety is a very strong argument.
TBH this sounds quite strange to me...
I mean, a comfortable environment is great, but they are hired to work for the company, not against it.
It seems to me that they do not want to learn the language at all. Are you sure that they are the right for the job?
Well they are the first hired people, so they maybe not the right developers, but I don't have that match choice.
Just interested how you came up with the idea of using Rust ? Are you using it for side projects or you are working on it with a team ?
By saying "its their choice" I didn't meant authority within company. but personal decision about individual career direction.
You cannot force people to use something they really don't want to (and keep them).
The whole thing looks like a bad hire. Actively avoiding tool they were hired for and told to use is really not something I'd ever accept.
I mainly use C++ on my day job. I actually like it quite a lot but I'm also aware of its many shortcomings.
So I was always looking for an alternative language in the spirit of C++. That way I found Rust, but I'm only using it for fun.
Also, I'm a bit of a PL enthusiast. But I also know that for many programmers, the language is just a tool they use, not more.
To add on to this, technology choices aside, I'm very suspicious whenever someone suggests a rewrite of existing software without a good reason. Not being comfortable with one of the technologies doesn't cut it for me. Rewrites can be fun for an engineer, but extremely expensive for the company. If someone is quick to jump to rewrite then it can be a sign they are either too junior or might be missing some of the business sense needed for start up work. I agree it could be a bad hire.
Sounds like a bad hire to me. A good developer should be excited to learn a new language, especially if he gets paid for it! And especially one as incredible as Rust is. And if asked to program in a certain language, he should program in that language, not write it in C++. You could practically argue that those hours weren't spent working for the company, because he wasn't doing the task he was assigned to do. I'd recommend telling them that they need to learn Rust or find a new job, there is pretty good documentation out there and anytime they have an issue, the Rust community is extremely helpful.
Speaking of which, I am looking for a job, and I would love such an opportunity if you want to explore the idea of other developers! Where are you located? Open to remote work if not close?
I personally would love to learn new languages at work. It's like getting paid for something you'd have to spend your personal time anyway...
Given that, not every programmer has to be like that. Not everyone has to be fast-new-language learner and some people enjoy being proficient and experienced X-language developer, and don't want to waste time with new shiny things. Some have harder time learning new conceptc, and might feel reluctant about leaving their comfort zone. It's not a good trait for our trade, IMO, but it's fair and managing people requires accommodation of different types of people. If having to learn and work with Rust was clearly communicated during hiring, etc. it's fair to just part ways.
Saying that, while I love working with Rust myself, think twice if it's a good choice to force people to use it. Is your current team really wanting to work with Rust? How about future hires - will you be able to hire Rust devs at the price point you can pay in the numbers you might need? Is all the tech you might need ready (or you are willing to fill the missing pieces)? Are compilation times acceptable? I'm not trying to discourage you, just making sure that in 6 months you won't be posting here "how picking Rust was a mistake" post.
Now if you're reasonably sure, to answer your real question. I'd focus on pointing out the benefits for the people you're trying to convince:
no weird crashes and segfaults; no wasting time debugging silly mistakes
much less boilerplate; (deleting copying constructors etc.)
easy to reuse high quality libraries from the ecosystem (C++ sucks at it)
learning; sure it's nice to stay in comfort zone, but in 3 years Rust in production experience on your resume might make you an attractive employee
Then have some arguments to counter common complains:
it's difficult to learn: Writing normal Rust code rarely makes you deal with lifetimes etc. it's only when you're really trying to save couple of copies and allocations when you have to deal with summoning The Elder Gods; when you're stuck community is quick to unstuck you;
no IDE etc. ; It's getting better really quick; it's a matter of finding a best solution for yourself
and so on
Then point some benefits for the company:
much less chance of security holes, and whole class of bugs eliminated
I am a new Rust developer coming from C++ and the Rust Compiler enforces a lot of good patterns.
The problem comes when things that would be easy in C++ are impossible in safe Rust. Graphs for me are the biggest stumbling block. For an experienced developer, this can be extremely humiliating so I do sympathise.
If you want to succeed you really need to help you staff get over the hump .
I am surprised this is an issue. I guess graphs are really only an issue until someone implements a really good graphing library. I assume there is none by the looks of it.
Does your company run internal tech talks as a mechanism for continuous professional development? I can recommend trying to schedule an hour to give a talk and do some Q/A, walking through the advantages (and disadvantages - let's not pretend its perfect) and see if you can generate some enthusiasm.
Rust is a surprisingly weird language for low-level datastructure work, especially as cycles are a pain.
What Rust excels at in my opinion is allowing to wrap this. So working at the level of "I have a graph and I need to moderate access patterns to that graph", Rust is amazing.
So any work in that area is great.
The reason why I don't feel this is (too much) of an issue is that data structure implementation takes up a small amount of most programming and it is a topic where much thought is required anyways. (I don't want to say it is unimportant)
What Rust doesn't quite support well is the style of "I don't need a library for that, because i quickly write that data structure out of my head" (which I'm unable to do anyways, for $reasons).
First of all: choice of technology is a decision and decisions must be respected. Developer playing subterfuge and just trying to torpedo or ignore decisions should be handled like people refusing to take instructions: let go[1]. This counts doubly so for people that just joined.
The other side of the coin is that decisions should never be arbitrary. Make an effort of documenting how you came to this decision and what was considered. But also make clear that the decision is fundamental and the time for fundamental debate is over.
Finally, form expectations of project progress and don't accept "but in C++, I would have" as an argument. Often, people hide their insecurities about the task at hand by blaming the tech. Most day-to-day programming is not held back by the choice of programming language. If there's issues in implementation, either ask them about a direct analysis of issues with the current path and call them out if they diverge towards comparative analysis. So, try to steer the discussion from:
"In C++, I would have just used Thingammabob and boost::MagicProblemSolver and be done with it".
to:
"I'm rather new to Rust, I'm not quite sure how to solve that problem yet, because I don't know how to implement Graphs properly in the language"
The latter gives you the ability to work with people along with it. You can encourage them to post the question here, get assistance from more experienced people and create more forward-thinking momentum.
Finally, many programmers have an odd sense pride. Make it clear that what you feel that they are hiding their unwillingness to learn a new programming language that you are giving them the opportunity to. Challenge them to it.
[1]: I don't say fired, as you could still try to find other jobs for them.
Why is implementing graphs a concern? Petgraph is an awesome crate, at least as far as my needs go. Implementing a graph is as much a concern as implementing Vec. Sounds fun but it's already done.
Implementing a graph or linked list is, in my experience, a very common exercise that one does when first learning C or C++. So perhaps a new rust user wants to try the same thing, but gets frustrated with rust in the process. This is fine, and can be a good opportunity to explain how rust differs from C or C++
Knowing about what 3rd party crate to use can be a very challenging thing. For example, if you search for "graph" on crates.io, you find many results, and its not obvious which is the right one
