Programming Language selection Pro's and Cons

Hi Everyone:
I am trying to find the pro’s and con’s of the MAJOR 3 languages, i.e Java, Labview and C++. there are many posts already out there that are keep going into the ease of learning of each language this is not what this is post is about.

Labview -
- Debugging programs you can easily see values in realtime
- function completion timing for trouble shooting
- Parallel looping functions
- multiple examples
- getting labview to communicate with a co-processor is not easy due to cross language conflicts into dashboard
- command and control programming is complicated
- vison processing is limited to NI vision
- NI support is lacking in response time

C++ -

  • fast


  • “what”
    Real Pro/Con list


  • Is fast
  • efficient


  • May be hard to learn

I’ll update this, it’s quite late rn


  • Fast. This actually doesn’t matter whatsoever 99% of the time because the bottleneck is always going to be the HAL.
  • Memory sharing. This allows for advanced practices like 971 and 1678’s forking subsystems
  • No VM. Ditto for the above, but also like the above, there are probably less than five teams total in all of FIRST that do code that is remotely influenced or limited by the use of a VM and lack of memory sharing in other languages.
  • Hard to learn
  • Hard to debug
  • Easy to shoot yourself in the foot
  • Language benefits like speed are nullified by HAL-side slowness
  • Slow to code in, lots of code overhead


  • Generally easy to learn
  • Pretty advanced OOP is possible, for better or for worse
  • Lots of resources, teams that use it
  • A little confusing to learn
  • JVM can be a problem for frequently forking/complex programs (not a problem for more than a handful of teams)
  • Verbose syntax, bit more code overhead than some other languages (not including C++ haha)

I know you only said big three, but I’m going to go into two other languages that I think warrant mention and are able to be used in FRC.


  • Very easy to learn
  • Very fast to write code in, low syntax overhead
  • RobotPy’s MagicBot system is phenomenal
  • Good stack traces, nice and easy to debug
  • RobotPy has an integrated robot simulator which is easy to use and amazing
  • RobotPy has unit testing built in, also very nice to have
  • Dynamic typing. However, it does have type hinting, which might as well be static typing
  • Interpreted nature means you won’t know of a crash until you run that particular line of code. This is what unit testing is for.
  • Slower than Java and C++. However code performance is an issue for you then chances are you’re doing something wrong in your code.
  • Global Interpreter Lock (GIL). This only allows a single thread of python bytecode to run at a time. It’s not a problem for the vast majority of teams, however if you’re doing asynchronous looping like 254 and some other teams, this pretty severely limits the complexity, number, and frequency of said loops in Python.
  • Not officially supported by FIRST. However, quite a few teams use it, and from experience, are more than happy to help teach or debug.


  • JVM compliant: no RobotKotlin needed, it’s 100% compatible with Wpilibj and can call (and be called from) Java
  • Complete null safety except for when explicitly disabled. If you ever get a null pointer exception in Kotlin that isn’t caused by a bit of imported Java code, you might need to reevaluate your life.
  • Very low coding overhead, almost as fast and simple to write code in as Python
  • Fairly easy to teach
  • Amazing, easy to use asynchronous capabilities
  • Lambdas, lots of functional programming (if you want)
  • C#-like class extensions
  • Boilerplate reduction and code autogeneration
  • You can compile down to JavaScript (please for the love of all that is holy don’t do this for your robot)
  • Some pretty big paradigm shifts from Java that take a bit of getting used to (Objects instead of Classes, everything’s Final by default)
  • Less library support (not a real problem, you can import a Java library as if it’s a Kotlin one)
  • Less community support (though if you can’t figure out how to solve a problem in Kotlin though, just do it in Java and import it)

Personally, I’d recommend Python for every team not using a lot of asynchronous programming (e.g. 254’s loopers). I’d point those other teams towards Kotlin instead. And for those of us who insist on having crash-safe subsystems (cough 971 cough), C++ is always an option. There are really no huge upsides to using a 100% Java robot over using Kotlin, in my opinion.

Good post - I’m in agreement with pretty much everything Solomon wrote.

Well for the past couple years we used C++, but for this season we decided to make the switch to Java.

Here are the pros and cons that I found with each language.
-no VM
-Eclipse offers you no support and in some cases harms your progress
-Hard to debug due to this
-Hard to pick up the language as a whole
-Null Pointers just crash the code


  • Eclipse helps with syntax problems and never really is an issue
  • NullPointerException
  • Easier to learn
    -The VM
    -A little slow because of the JVM but not really an issue here in FRC

The main thing that made us want to switch was how Eclipse for C++ caused a lot of headaches among us programmers due to the amount of bugs the program itself had, but with Java, Eclipse is a lot more supportive of us coding instead of being the opposite. Overall, we love the switch!

YES Can Confirm

Just going for missing points and one needing adjustment:


  • Fastest to compile & deploy code


  • Easy to shoot yourself in the back


  • Uses interfaces rather than multiple inheritance
  • Garbage collection designed into language
  • VM enables some truly awesome debugging tools



  • Difficult to manage project (incompatible with Git, CVS, etc.)
  • Difficult to find mentors who know it (at least around here)

This has been said before in many other places here on CD, but the best programming language for your team is the one your programming mentor knows best.


  • You have somebody who knows it well to help you


  • You might be stuck with a language you personally dislike

As someone who’s spent a good number of years in each language, I guess I’ll put in some words.
I’ve tried to make my post as objective as I can.

Note: I don’t talk at length about “having mentors who know {x} language”, or “harder to learn”. FRC is a learning experience, don’t let your mentors lack of knowledge cripple your ability to learn something new. Furthermore, OP specifically asked for ‘ease of learning’ to not be discussed.

Commonly seen as the “most difficult” programming language, that is easy to “shoot yourself in the foot” with, C++ is really not as bad as many people talk it up to be. Sure, there’s more to be aware of, you can’t just hand out heap memory willy-nilly, but this is a caveat that comes with low-level programming. C++ will give you the best performance, efficiency, and teach some very important coding practices for those that want to go into mechatronics, embedded systems engineering, or other related fields.


  • Most resource efficient (both memory and CPU time, lending to faster speeds and lower RAM utilization)
  • Allow strict control over resources used
  • Allows for more advanced programming uses
  • Direct interface to the HAL, instead of going through JNI or equivalent (this improves a lot of WPILib << >> HAL crosstalk, mostly due to less symbol lookups and dynamic memory allocation/copying).
  • Can be written in a standard text editor without wanting to shoot yourself (see: java)
  • Provides a good start to those who wish to pursue embedded systems programming in industry, most of which is dominated by native code.
  • No special RoboRIO preparation required
  • Speedy code startup times


  • More prone to ‘silent errors’
  • Low-level system access gives some problems, such as pointer collisions
  • Object Orientation is often more difficult than it appears

Java is the most used language in the FRC community. Part of this success is related to its common use in schools, and its apparent ease of development. Although Java hogs memory and CPU time, most teams don’t require extra performance or efficiency.


  • Object Orientation is generally pretty straightforward and powerful
  • Garbage-collection makes it hard to allocate too much memory (although still entirely possible)
  • Excellent IDE support, excellent library support
  • Most FRC community projects are geared towards java
  • Typically used in the non-embedded software industry


  • RoboRIO must be further prepared with a JVM
  • WPILib << >> HAL crosstalk is inefficient, as is with other libraries such as the TalonSRX, due to the JNI.
  • The JVM takes a long time to start, and eats 70% of RoboRIO RAM right off the bat
  • Code execution time is not linear (i.e. the same block of code can vary greatly in execution time, depending on when garbage-collection is triggered)

LabVIEW is commonly seen as the outcast of the 3 official languages, being a proprietary visual language from National Instruments. As with many things, the loudest opinions on LabVIEW come from those who have no idea how it works or what it does. There are some benefits to LabVIEW, so let’s take a look.


  • Excellent debugging support, through highlight execution, front panels and probing
  • Highly parallel (control flow is entirely based on data)
  • Integrates directly with the HAL (making it faster than most would have you believe. All languages have a LabVIEW instance running in the background of the RoboRIO, lvrt)
  • Generally useful for students graduating from FLL to rapidly prototype
  • Very good support for signal processing and other such usages


  • Typically hard to read, and easy to end up with tangled wires
  • Not very flexible, for more advanced needs (such as vision, or non-dataflow oriented programming)
  • Lack of proper variable support can be troublesome
  • Very lackluster version-control support
  • It’s surprisingly easy to deploy code as a non start-up task (i.e. code will not run on reboot)
  • LabVIEW itself takes up a lot of space on the development computer

Our team used to do C++ but switched to Java a few years ago because FTC switched their platform to Android phones and Java is one of the languages offered. Since we have both FRC and FTC teams, this allows us to share a common robotics framework library.

Our team used to use Labview for the past few years but switched in 2016 to Java. We switched mainly because our school teaches Java to all students, and FTC switched to Java as well making the teaching process a lot easier.

How are code build/deployment times for the three main languages? I started this threadmany years ago and am curious if anything has changed. We used Java and it seemed like build and deploy times remained at about 30 seconds. Does Labview still take a very long time? I can imagine if it still takes over a minute to test code, it would be a fairly big con.



-Debugging tools are extremely extensive

-There are a lot of ways to comment, label, and add descriptions to your code

-It is very easy to tryout an algorithm on a PC using the UI them migrate it to the RIO after it has been debugged

-Extensive descriptions for every native function are readily available and most have built in examples

-As a result of the above it is very easy for someone with little or no experience with programming to learn.

Biggest con:

Relative to C++/java fewer people know it.


“LabVIEW is incompatible with git”

LabVIEW is totally compatible with git. We used it for our code this year. GitHub even lets initialize a new repo with a LabVIEW .gitignore file.


I like that you can deploy as non-startup to test new code without overwriting working code.

If it is well written and properly commented & labeled it can be at least as easy to understand whats going on as with C++/Java, especially to the layman. But then that’s the same with all languages.

I hate when teams choose a language because it’s what their mentor wants them to use. Yes, having a mentor that knows the language is helpful, but in the age of digital technology, your only help isn’t the person you can talk to face to face.

If a team wants to try a new language, expand their knowledge of computers and programming, I say let them. Don’t tell your students they can’t do something because you don’t know it very well. It’s a chance for both of you to learn.

The best programming language is the one that teaches the students something new.

I think this is a bit of a stretch. In context, compatibility with git isn’t the same thing as being able to use GitHub. LabView is generating binary files, which generally doesn’t work phenomenally with git. Human readable diffs aren’t really a thing with binary files and merges can get problematic quickly if any conflicts arise. LabView is great for a lot of things, but effectively teaching git version control probably isn’t one of them. You can still definitely learn git with LabView, but not nearly as fully as with Java or C++ in my opinion.

Also, helping someone remotely is hard with labview. With text based languages you can type out some example code. You can’t do that with labview.

LabVIEW does allow you to deploy without actually setting the program as a startup - this means that if you make a small change in one VI, only that VI effectively needs to be redeployed (it sees that all the other VIs are unchanged), and so it moves much quicker when you are testing stuff.

At competition though, when you do need to set the program as a startup each time, it takes much longer.

Very true. There is a useful feature called VI snippets, which allow you to share the code as an image, but also be able to drag the image right into the code and it’ll turn into actual code.

But that means I have to have labview installed, open it up, and create the code.

With python I can just type out what I need to in a few seconds. I can do it from any computer, including one that doesn’t have python installed.

Very true. I agree that that is one of the setbacks of LabVIEW. It’s rather difficult to communicate “this wire goes there, no not there, there.” I just wanted people to be aware of the feature that helps a little.

This is surprisingly not straight forward to answer. The first time you deploy on a given reboot, LabVIEW sends the entire program over the network and establishes a link to the robot for real-time debugging (I’m sure this is a gross over-simplification that someone more knowledgeable than me can correct). This takes a while, but without having ever timed it I’d guess it’s between 30-60 seconds*. After that, though, as long as you don’t reboot the roboRIO or computer, LabVIEW only needs to send the send the changed files and restart the code, which I’d say takes <10 seconds*. Quite good for rapid bug fixing.

It’s worth noting that this is a separate process from compiling and deploying as a startup program. While this adds to the overall deployment time from start to finish, it’s quite useful at competition; code can be freely tested without worrying about overwriting working code.

*Based on my own mental clock. May be inaccurate.