Our team is considering switching from java to c++ this year and concerns have been raised about field compatibility. Our prog team is very weak in terms of java [we struggle with PID loops something fierce] and switching to a language our coders are more familiar with would be a dream, but we don’t want to spend an entire regional translating code because we did an oopsies somewhere. For all of you who code your bots in c++, what has your experience been with it?
These aren’t really different in c++ and Java, at least in terms of implementation difficulty. The top-end performance is better, but if you’re struggling with controls in Java it’s unlikely a switch to c++ will make things easier.
I think it only makes sense to switch to c++ if you are extremely comfortable writing robot software and are willing to sacrifice ease-of-developer-experience for runtime performance. It doesn’t sound like this is the case for your team right now.
10 Likes
While I agree with Oblarg, if your coders are more experienced with a language, either due to the what your school teaches or what your mentors know, I would recommend using that language. FRC doesn’t allow much time for dealing with syntax issue or relearning language methodologies.
4 Likes
If your team’s programmers and particularly mentors are stronger in C++ than Java, use C++.
4 Likes
I’d echo @Oblarg here, that is a concept that isn’t language specific. If this is what you struggle with, take whatever robots you have available to you and practice tuning PIDs. If you don’t have robots available, build up some simple mechanisms (drive a wheel in velocity control, create a simple arm that you move to positions, etc.). Learning, understanding these concepts will make it easier in the future.
If you still want to understand JAVA/C++ decision, here is how it was for us:
We used JAVA many years ago and switched to C++ (probably a decade ago). When we switched we had some very valid reasons for switching.
In recent years, there has been discussion about ditching our code base and switching back to JAVA. It really isn’t about dissatisfaction with C++ as we are pretty comfortable with it.
The benefits with C++ for our team:
- Lower memory consumption (at least based on when we did the switch)
- Better loop times (garbage collection can be a killer and there are some things you can just do faster in C++)
- Mentors that are more familiar with C++ (mentors tend to be around longer than students and then should be helping the students create code and it is hard to help if you’re looking things up).
The benefits we’d see with switching to JAVA:
- Ability to leverage community project better (AdvantageKit, for instance, but others have better JAVA support).
- Easier to help and be helped at competitions. There are just so many more JAVA teams.
- Our feeder FTC teams use JAVA, so they would be familiar with the language alread.
- Having actual tracebacks
- Fast build times
- Mentors are coming from FTC so they’d be familiar too.
Notice I didn’t say AP Computer Science which when we last used JAVA was one of the arguments. We found this class happened too late (senior year) and didn’t give enough of a benefit. Many students take the C++ class earlier (though if they are robotics they learn it there before they take the class).
If you do choose to switch, I’d do it now, but I wouldn’t just do a straight translation. Refactor/Rewrite functionality taking advantage of what is available. You utilize the existing code and covert pieces, but I wouldn’t do it as wholesale plan. This is the opportunity to get rid of dead code, bad code, etc. I know we threw out a bunch of classes as well as methods in classes we kept last year and still have more to clean out.
2 Likes
Talk to me a bit more about what this familiarity looks like. Is it taught in classes at the school? Maybe there’s mentors who use it for work?
Yet another similar opinion: Bias your choice by what you expect to get the most support in.
Local mentor/teacher/experienced-student support is most important, CD and Discord (where the expertise is mostly Java) is a fallback if local is not available.
We switched Java to Python due to this. An equivalent argument could be made for C++ if the situation was different.
1 Like
Note that with a new robot controller coming in 2027, these are short term benefits (the next two FRC seasons). There’s not been an announcement yet of the actual 2027 controller capabilities, but based on the RFP requirements, it seems likely that the CPU will be the equivalent of a rPi 4 or better. Of course C++ will nearly always win on these two points just as a raw comparison, but if the controller is fast enough for it not to be a practical difference to robot performance (e.g. Java can run as fast as teams need), then it’s not really a benefit.
It’s also worth noting the absolute dominance of Java use in FRC (even with the current controller): [FRC Blog] Control System Beta Testing and Usage Reporting - #8 by pchild. While mentors are the first and most important people to provide programming guidance… where do they go for help when they run into FRC-specific (rather than language) issues? (the good news here is that the WPILib development team is largely C++ developers, so we often can, but we’re not always available)
4 Likes
We have zero coding classes at our school and our coding mentor is just teaching herself this year. Both of our prog students [I know close to nothing about this I’m just making the thread] have completely taught themselves to my knowledge. We might have a few local community members coming in to help, but we live in a town of 400 people in the middle of nowhere so I doubt that’s actually going to happen.
1 Like
I’ve been using C++ on my team for the past 4 years, and I’ve certainly enjoyed it. The advantages we’ve had were mostly that we had mentors who knew how to use it, as well as a few students. Thankfully, the two languages aren’t that different when it comes to FRC so we can still translate some other team’s code. We haven’t really seen the performance benefits people talk about, but we also do quite a bit of vision and swerve processing which slows the code down quite a bit. The largest disadvantages are that C++ error messages (especially linker errors) are difficult to parse, desktop simulation is a little harder because of differences in GCC and MSVC, and there aren’t as many resources. This last point means that swerve is a little harder for a lot of teams because of the lack of YAGSL.
However, all of these differences are trivial when compared to differences in training. Do what your programmers know how to do.
1 Like
It sounds like you should be using Java, without question. You need significant experience (sounds like everyone is still learning) to override that “default”. You will benefit from other teams and outside support much more than any other factor in the language decision.
12 Likes
Gotcha. Yup, local help will probably be thin in that case.
If I were in your shoes, I’d start by drawing a line in the sand with all the students: Whatever they choose to do, there needs to be proof that the team will be “no worse off than last year”. Not just feelings that will be the case, but hard proof. Hopefully that’s a non-controversial statement. 
Assuming you have a robot still available, a great proof would be to start up a new robot code project in the target language, and get that robot up and working same as last year - critically, before kickoff. If you can prove that out in the next few months, I’d say you have evidence to make the move without worrying about issues overall.
If no robot isn’t available, or the team wants to get creative, there’s other possible ways to prove it… it’ll be up to your own team to pick the standard for what counts as “proof”.
Another exercise: run the “five why’s” - “Why did you struggle on software last year?”. “Why was that?”. “Why was that?”. etc. - make sure the chosen solution of “change languages” aligns with the actual root cause of the struggles last year.
And, finally finally, definitely have the students and/or mentors explore the CD/Discord resources a bit. If they’re doing anything new/adventurous and questions come up, a key skill will be asking their questions in a way that makes it easy for folks who don’t know them and aren’t in the room with them to answer. This is definitely a learned skill, but one they can hopefully start to pick up on by looking back at the technical threads where people asked questions, and how responses were given.
To be clear… If I (again, not being in the room) was asked to choose, I’d say the same as others - “stick with java, and figure out what the real pain points were last year”. But that’s with limited knowledge of your situation. My suggestions above are to help you either walk yourself into that same conclusion, or figure out where we’re all assuming the wrong things .
4 Likes
Agree with all that you say. Fortunately, when we’ve run into FRC specific issues, we’ve either figured it out or reached out (usually this ends up being a vendor question and support is generally
quite responsive).
The performance one nags me a bit because when we help JAVA teams at comps, it is usually common to see loop overruns in their logs. This was the first year I’ve really seen this in our C++ code and it was due to two reasons:
- Not understanding the REV library (this is the first time in years we used REV motor controllers/motors and had some blocking calls in periodic loops originally)
- Some poorly structured code that ran too long as a result. This can happen in any language. C++ may be a bit more tolerant of this, BUT it comes at the expense of being easier to shoot yourself in the foot.
So, I sense a switch in our future (just not sure if it is JAVA command – we run a straight timed robot – or if we’ll jump on the ROS bandwagon). The new controller will likely cause us to look at a re-write (it almost happened the last two off-seasons).
1 Like
Seriously thank you for this. We’re likely going to stick with Java because of the huge amount of resources available for that online. I’ve thought about it more and talked to the team and I don’t think it’s an issue with the coding language and moreso just student experience [and. Cough. Slight stubbornness]. I am also now positive that if we switch we’re going to drown come build season and nobody wants that.
I’m 100% stealing that 5 why’s thing so thanks for that too!
For everyone else that posted here, I would respond to all of you but I have a lot of college work to get back to. Your input was super valuable and while we aren’t switching now, maybe in the future when our prog subteam is stronger we’ll take the dive. I appreciate everyone who commented and I hope you all have a fantastic Reefscape!
4 Likes