VB.Net and C# both belong to the ".Net" family of languages, and the things you can do with them in Rhino/Grasshopper are nearly 100% equivalent. Grasshopper itself was written in a combination of VB.Net and C#. Some advantages/comments, in no particular order:

Performance - VB.Net and C# scripts tend to execute faster because they are "Just-in-time" compiled as opposed to interpreted.

Autocomplete - both VB.Net and C# have rich autocomplete functionality in their respective script editor components - significantly more so than the python editor. This can be helpful for beginners since you can "hunt" for methods and properties by just typing a "." after an object name and looking at the list of available methods/properties.

Native Component development - If you eventually want to develop GHA assemblies/plug-ins for grasshopper, as of Rhino 5 you will have to use one of these two languages. However, there are plans to introduce python-based plugins in Rhino 6. Even so, the resources around plug-in development are very rich in the C# and VB.Net environments (with c# seeming to be the more popular of the two).

"Strong Typing" - VB.net to some degree, and C# especially, are less "forgiving" languages than python - they require you to know about the data type of the objects you're operating on. This can sometimes result in more verbose code - as you explicitly convert from type to type - but it also promotes good programming practice and helps make errors more understandable.

.Net ecosystem - using a .Net language means you have access to the thousands of libraries publicly available, and the process of referencing these libraries and making use of them is comparatively straightforward relative to python. More on this in the following section.

Resources/Support - At least as of 2012, VB and C# turned up more results on this forum than python, and I think you'll find slightly more expert-level coders in those languages able to help you here.

Which one between the two? C# or VB.Net? - Personally, I greatly prefer C# - I find it to be cleaner and clearer to use. I also have some programming background in C++/Java/Processing so I found the "C family" approach to be more familiar. As David and Damian point out in some of the posts linked above, C# is more popular than either python or VB.net in the rest of the coding world. However, if you are learning without any prior programming experience you may find VB.net to be a bit easier to learn.

Python

Python is, without a doubt, a beautiful and elegant language, which is probably more than can be said for VB.Net/C#. It is very popular with beginner coders, and its syntax is more readily understandable.

Syntax - Python is beautiful to read and write. Its syntax is very clear and free of extraneous punctuation (for example the ";" line endings in c#). It has many very nice language features that make common tasks more concise, like its loop syntax, list comprehensions, list "map" and "filter."

Multiple ways to talk to Rhino/Grasshopper - Python enables two general approaches to interacting with the Rhino/Grasshopper environment: RhinoCommon and RhinoScriptSyntax. If you have prior experience with Rhinoscript, you may find RhinoScriptSyntax to be preferable - it adapts many of the methods you're familiar with to the python language, and simplifies some tasks. A word of caution though - working with Rhinoscriptsyntax can introduce a performance hit relative to RhinoCommon operations. C# and VB.net by contrast can only work with RhinoCommon.

"Goodies" - The Python environment in Grasshopper has some "special features" that the other languages lack. In particular, the "GHPythonLib" library enables the ability to call most Grasshopper components from within your code, and the ability to easily enable parallel processing to improve performance. (A word of caution though - these two features do not seem to "play well" with each other, there may be bugs causing memory leaks that result in increasingly worse performance with each execution).

Cross-Platform - Unlike C#/VB.net, Python can be used natively in Rhino for Windows and Rhino for Mac.

Direct scripting in Rhino - You can also use Python directly in the Rhino environment without the need for Grasshopper if you desire, using the Rhino Python editor.

IronPython / Ecosystem issues - one frustration / potential downside to working with Python for Rhino/GH is that though there is a vast, amazing ecosystem of external libraries for Python, getting these to install/work properly in the Rhino/GH environment can be a real pain - largely because the language is actually "IronPython," a version of python designed to work closely with the .Net ecosystem. Many popular libraries like numpy and scipy are very challenging to get working in Rhino/GH.

Scripting in other programs - Especially in the AEC industry, Python is a popular scripting language for other applications. Tools like Revit, Dynamo, Blender, and ArcGIS all offer their own Python scripting interface - so learning Python in Rhino/GH can give you a leg up in eventually scripting in these other programs.

Python's Stock is Rising - there are currently a number of efforts to improve the "status" of python within the Rhino/GH ecosystem. The python editor in Rhino 6 has a number of improvements, not least of which is the ability to "compile" add-ons for Grasshopper written in python. I'm sure Giulio can speak to other upcoming improvements.

I hope this summary helps you find the right option for you. Ultimately you can't go wrong; concepts from any of the available scripting languages will make it much easier to learn the next one. In my day to day work I use a combination of both C# and python, where appropriate, and I love them both.

I hope others will feel welcome to chime in on this FAQ and add their own thoughts about advantages/disadvantages of these various options! If you have time, read through some of the other posts linked to at the beginning - there's lots of additional great information there.

Replies to This Discussion

Excellent article Andrew - when I started customizing my own GH components I chose C# on the assumption it would give me better performance. It was a steep learning curve at first but there are a lot of resources out there.

The nice surprise with C# for me was a relatively painless entry into the world of JavaScript. Although very different under the hood, the syntax is familiar. I am finding the ability to leverage the many open source JavaScript resources out there invaluable. I have come across other GH users finding novel ways to link JavaScript to GH. Flux is making that easier with the new JavaScript SDK (C# also). An example of the novel options it can provide here: https://goo.gl/NP5QCE

I teach people coding in Python, because that's the easiest language to get people who haven't coded before up and running and producing usable scripts quickly, but I personally tend to use either VB or C# and would recommend those instead to anybody who's in it for the long haul and is willing to put in a bit more effort up-front, because those languages are ultimately a bit more powerful in terms of what you can do with them. Even if Python plugins become available that's probably not a task I would choose to use that language for - the features that make VB and C# feel a bit more complicated and restrictive than Python really start to make sense when you start developing bigger, more complicated, multi-file projects.

On the VB.NET vs C# front: underneath they are essentially the same language, the differences are largely cosmetic so it's down to whichever form of syntax you like the best. VB will be slightly easier to pick up if you've done any scripting before in Rhinoscript or VBA in Excel etc. As noted, C# will be more familiar to people with C/C++/Java/Javascript backgrounds. I use both and both are great languages - I slightly prefer C# to write because it's marginally more compact, but VB.NET to read because it's more english-like so there's less translation effort needed.

Of course, learning any one of these languages will put you 75% of the way towards being able to use one of the others, so it doesn't really matter all that much which one you choose first. The key criteria in real life is usually whatever language your friends and colleagues are using, not only because it makes it easier to get help but also because it boosts productivity if you can share and reuse code, and when some hiccup in a script comes to light the day before a deadline it's an excellent idea to have somebody else on hand who stands a chance of understanding and fixing the code in case the original author isn't around.

I really like Paul's approach of learning the one language that "your colleagues" are using, and working under the assumption that this way you will be able to get more help and be able to collaborate better. +1

Just like everyone else has said, Python is a great "entry" language to learn, and once you get that, you will be able to transition to any other language with relative ease. I personally use both (python and C#) because I can use Python components to test an idea out really quickly without need to compile anything and then when I am comfortable with it, I usually transition my components to a library that was written in C# (I do most of my work in Dynamo/Revit environment but don't think that matters here in context of the conversation).

Excellent notes from Andrew! Great tips from Anthony, Paul, and Konrad. Thank you all for sharing your experience. I would like to add something to this thread.

Dear Reader,

While it is good to start with a language that you find easier to learn by following a tutorial series or reading a book, if you are in for the long haul, things typically won’t end there. You will soon realize that finishing an introductory course on a language will not completely enable you to contribute in terms of development of tools if that’s what your aim is. For example, you’ll really need to understand object oriented programming if you want to work with an already established group. You need to learn and understand the API of tools that you want to contribute to. You might also encounter the need to use external libraries for the language you are using. All of this will require you to read and understand a lot of documentation. If there’s no good documentation, you’ll need the skills to read and learn from someone else’s code if they have done something similar. All these processes can be very mind bending and therefore, the keys will always be patience and perseverance.

Start out with a language, but be open-minded to learn and accept other languages and technologies too. All the people who have contributed to this thread before me have experience in more than one language. I hope you realize by now why did they not end after learning one language.

Paul’s made a brilliant point. While it will not cut down on the work you’ll have to put in to learn things, it will invariably add some luck in difficult situations. If you are the first one in your circle and don’t have friends and colleagues with such skills, I recommend you find online communities and groups. That would help a lot.

Thanks for great insight! I have a question: What are the main differences using the built-in GH script editor compared to compiling in Visual Studio (except for the improved IDE in VS already mentioned)? I'm thinking of performance, import of external libraries, access to frameworks and I/O, etc.
Many thanks,
Martin

- Easier to reuse in different definitions or share with others as a plugin (you can wrap up scripts in user objects, but I find that to be a bit less neat).

- You can use external libraries etc. with scripting components, but Visual Studio does make this a bit easier to manage.

- You can add more in the way of documentation to the component (i.e. tooltips, Help documentation etc.)

- Much less buggy than the script editor (i.e. it won't delete your type arguments *every single f*%#ing time* you try to instantiate a new generic object...)

- You have ultimate power and can do pretty much whatever you want. (Cue ominous thunder...)

There are however a few disadvantages:

- You need to write your code, compile it, install it and then run it in Grasshopper - it's not as immediate as the write-try loop you have with scripting components. (You can make certain minor changes to the code while debugging, but more major ones will mean having to shut down, re-compile and re-run).

- You need to write a couple of extra functions to populate your inputs/outputs, declare a GUID etc. You also need to extract your inputs in a slightly more complicated way. The script component takes care of all this stuff for you.

- Other people who open your definitions will need to have the plugin installed as well or those components won't work - it's not embedded in the definition itself like a script is.

I tend to grit my teeth and put up with the awful script editor if I'm just writing short scripts that are specific to that particular definition or if I'm in the early stages of writing a new tool and just want to experiment. I'll switch to VS if it's becoming something larger and more complicated or that I might want to reuse or share. Excluding the input/output parts, the bulk of the code is going to be the same no matter what you're using, so it's not too much of a commitment to go from one to the other.