Can someone explain why nearly everyone prefers C# to JavaScript these days?

*Sorry if I get snarky; C# has me pissed.

So I started using Unity about 7 years ago. Back then a large part of the community still used JavaScript, and it wasn't looked down upon at all really. Hell, some people still used Boo.

My only prior experience with coding at the time was some basic Python, and since the general consensus was that JavaScript was easier than C#, I went with that and continue to use it to this day.

But I've noticed more and more that C# has become the standard, and after constantly getting bitched at just for the fact that I still use JS, I've been making an effort to switch to C#.

And man, have I ever been more pissed and confused. "It's pretty similar" they said. "You'll like it way better" they said. "It's not harder to use they said".

Well, it's different as hell, I don't like it better, and it's hard as S***. I can't just modify a rotation if I want to. I have to put an 'f' after a float value, seemingly for the hell of it. I have to type weird S*** in front of my function names.

At this point when I get an error (which is often) I just type weird S*** I've seen in other C# scripts until the damn thing works. C# has like 10x more syntax than JS and that syntax is not easy to internalize.

So as a genuine question, why does nearly everyone prefer C#? How is it objectively better than JavaScript? What can C# do that JS can't?

I honestly do want to switch but it's hard to justify spending hours and hours just learning the language when I could be bending time and space with JavaScript.

TL;DR: Been using JS for years, I want to switch to C# because it's becoming the standard, but I don't understand why.

 

Sorry, I can't tell you why it's more common, only that it is (appears so to me on the forums). I've never learned JS (or UnityScript), but I can read most of it, when people write out examples here.
From what I've seen, yes there are some differences, but I guess because I knew C# first, maybe I was used to the 'f' suffix and the return types for functions (even from C).
I am glad that a lot of people use C#, as helping on the forums is easier to convey code and be sure I understand what's written That probably is just me, though, and not everyone.

Some of what you wrote is just part of learning.. for example "weird stuff" you have to do differently - you just get used to that. Some of what you wrote just sounded like venting

Anyways, if you continue to learn C#. Good luck.. Hopefully it works out for you.

 

Ironically enough, what pisses you off with all these "weird S***" is one of the biggest reasons why people like C#: It's strongly typed.

There's a lot less guesswork involved in knowing what types of data to pass to functions, what kind of data (if any) you're receiving from functions, etc. You can just look at a function signature without having to read its code to know what kind of data is expected. And you get an error immediately instead of trying to run with buggy code only to have it fail later on.

If you're working solo, then by all means keep using Javascript if that's what you're familiar with. However, as you noted, with C# being the standard and if you want to get hired by a company using Unity, you're probably expected to know C#. Support is also an issue if people spend less time on writing Javascript snippets.

 

Part of it is just familiarity for me. I do .net programming, and I did c# in that over VB. Part of it is for reasons I hate when c# programmers lazily use "var" when declaring variables vs explicitly stating the data type. I like clarity. I like some structure to what I do. I'm not entirely certain why.. I guess it's just what I'm used to. I like knowing what kind of data something else is expecting to be fed.

I am a software developer for my real job, so I've worked with a lot of languages.. some high level some low. I wouldn't say c# is my favorite yet, but I'm also not a seasoned c# vet, by any means. I always hated JavaScript when doing web programming as I found it a bugger to troubleshoot . My bias against JS has found its way to unity just based on that (I actually haven't even LOOKED at anything other than C# in Unity).

Lastly, at work I am starting to do more and more c# / .net work , so for me , it's natural to want to do c# in Unity. I have to do some JS too, but not enough to invest any time into doing it more. JS *feels* sloppy to me.. c# feels more structured (sorry to overuse that word here)! But that is personal preference as to why I like c# more.

 

Javascript is an interpreted language. loosely typed and was originally designed to dynamically change XML documents in a Netscape browser. It was never meant to be any more than that, but it quickly gained popularity (so its well known), its supported nearly everywhere and its quick to set up and go.

C# is a compiled language. strongly typed and designed to be nearly as powerful as C++ but with less dangerous tools that would blow up your PC. C# has a lot more tools under its belt so naturally its far more powerful in many aspects.

Interpreted languages try to comprehend the code on-the-fly which takes time, they also won't notice a bug in the code till they crash right into it. Compiled languages proofread the written code, flag all the potential problems and then convert it into lightning fast Machine language.

Javascript has the benefit of not being as strict nor needing a recompile of the entire library so its faster to iterate on and prototype with. C# is far more stable and far faster to run and more platforms will perform more reliably under C# code.

 

This is what I keep hearing, but no one ever explains what C# can do that JS can't.

 

This is part of my reason for preferring C# too. Good stuff.

 

There are a bunch of reasons the community has gone this way.

On the hard facts of the language

• C# is strongly typed. UnityScript is strongly typed but pretends to be dynamically typed. In practice this means that understanding typing in UnityScript is actually harder then it is in C#. It doesn't behave precisely like a strongly typed language or a dynamically typed language.
• C# requires explicit class declarations, UnityScript does not. Again, it means understanding exactly what is going on is harder in UnityScript.
• In general UnityScript has a lot of syntatic sugar. It makes the language less verbose, but it means that figuring out exactly what is happening at any given point it difficult.

On the soft facts of the language

• UnityScript has virtually no documentation anywhere. Figuring out how to do anything advanced in the language is painful. While it technically has the same capacity as C#, in practice the language is much more limited.
• All of Unity's learn material is in C#.
• UnityScript support and examples in the docs often lag significantly behind C#.
• There is only a couple of active community users who can use the language, making getting support difficult.

On the world in general

• UnityScript has not support outside of Unity. C# has extensive documentation and libraries. You can find an example of practically anything in C# with a quick google search
• UnityScript is not JavaScript, its not even vaguely close. So exactly zero of the external resources for JavaScript work in any fashion.
• External computer science and programming courses teach C#. People use C# in regular jobs. So for most users, UnityScript is the extra language to waste time learning.

I'm sure there are more things that I have missed, but that should give you a general idea as to why the community has switched almost exclusively to C#.

 

Guys, wrong language. JavaScript as used in web programming has literally no relationship with UnityScript. The only reason they share a name is because someone in the early days of Unity thought it would be cool to market the engine to existing web developers. Turns out they lied.

UnityScript is simply C# with a lot of syntatic sugar. Specifically:

• Class declarations are implicit
• Variable types are implicit
• Method return types are implicit
• Coroutines are implicit

Once you get your head around the typing, it requires significantly less typing then C#.

On the other hand the implicit typing is prone to errors. Its also very easy to shoot yourself in the foot performance wise by accidentally boxing an int or similar.

 

I cannot emphasize enough how important this was to me. I have 20 years worth of code in both C++ and C# dlls, which were developed for other games and applications. I'm able to link them into my Unity project.

Not to mention various APIs like OpenCV, CGAL, etc. which weren't written for Unity, but you can link them in regardless.

 

Tell Unity that.

Granted, they're still not the same language, but the intent definitely was to adopt a Javascript-like syntax to woo people over, so it's an easy confusion to make.

EDIT: Also just remembered that if you right-clicked on the project panel, you can choose to create either a C# or "Javascript" script.

 

I've never used UnitScript at all, so had no idea it was any different than JS, but like Pete said, even Unity calls it JS... hard habit to break I did catch that you noted why it was called JS from the start though.

 

I think one reason is that, a few years ago, mobile devices started needing #pragma strict (something like that) That meant a few of the nice shortcuts it had over C# fell off.

Beyond that, C# is a very, very common general purpose language; whereas JavaScript (which is really UnityScript) is a special language written by Unity. The documentation and support wasn't that good. As Unity became more popular, it was easy to tell new users to read one of the hundreds of C# books. Then if you have more Qs, microsoft has a giant C# site (not saying the books or the site are good, but they seem pretty impressive if you don't know.)

A third reason is maybe that the people helping for free tend to be programmers, who tend to prefer C#. For example, I've never bothered to learn unityscript so can't help people with it. Over the years Unity Answers just drifted into C# questions getting answered and Unityscript ones not.

But what you're writing is very common. Simple scripting languages like Unity/Java script are a real thing (they are usually even simpler.) Traditional game engines required them for most things and didn't make game programmers learn all that other stuff. Unity is just built differently where you can switch between.

 

I want to stick up for the OP here. My memory (5+ years ago?) is that more examples were originally written in unityscript. Sometimes you'd find it also in C#, sometimes not. The non-manual sections, like "how to use prefabs" had everything in unityscript. Back then, you got the strong message you were supposed to use JS, but could use C# if you really, really wanted to.

Funny story: originally javascript was named actionscript. They put the "java" in front to make people think it was like Java, which was really hot back then. So adding a "java" prefix for fun is traditional.

 

Totally agree with you there. A lot of the old stuff was all driving towards UnityScript instead of C#.

In general it sucks to have a technology you've grown to be familiar with pulled from under you. Especially when its pulled by the same people that drove you to use it in the first place.

I think that may be part of the problem. UnityScript is almost as complex as C#. You pretty much need to be a programmer to use it, you can't throw it at your artists or designers. So it fills the same niche as C#. Having two products that do identical things is normally recipe for one to die.

 

As a developer who used to use WinForms, Silverlight, and WPF, I have absolutely no idea what you're talking about!

(Granted, WPF isn't technically dead, but its status is pretty hazy these days...)

Still, live and learn. Literally. My suggestion to the OP is don't feel frustrated if your current language/framework/API/whatever is no longer supported. All the knowledge and techniques you learned can still apply to the next language going forward, and you'll get faster at hitting the ground running. It's a cycle that will continue to repeat itself over the years.

 

Because the JS in Unity isn't JS. It's 'UnityScript', and it's officially going away - so get on the C# train before you get left behind.

 

Easier is subjective... I find JS/UnityScript harder to write because so much of it is implicit. I don't mind a little implicit (I use var/anonymous typing/etc in C#), but JS/US has it through the roof. Also can be scaled over time...

JS/US - easy to pick up, hard to master
C# - harder than JS/US to pick up, easier to master (note, I state harder in relative terms... it is easier still than other languages that exist)

Unity started out the gate as being a 'beginner' friendly game engine. They developed JS/Unityscript as a way to lure novices with familiarity to javascript to the fray.

Since then Unity has started showing up more and more in use by pros, and Unity wanted to give those pros tools that they may like more. Pros are often coming from a C/C++ background, so C# is for one easier to learn that JS/US, and also C/C++ is so NOT implicit... that the magic strings and the sort that are everywhere in early versions of Unity had to be updated. C# had these things built in... like generics and the sort. Unityscrypt had to tack them in in weird ways, and weird syntax... and still doesn't fully support them.

generic classes - feature unityscript does not have that C# does

Yes you can access generic classes with the syntax:

Code (csharp):

1. var lst:List.<string> = new List.<string>();

Or access generic functions:

Code (csharp):

1. var t = GetComponent.<Transform>();

You can not declare generic classes in Unityscript (correct me if I'm wrong, for as long as I've known it doesn't, the documentation says it doesn't, and I tested what I'd presume the syntax would be if it did).

Read more on generics:
https://unity3d.com/learn/tutorials/topics/scripting/generics

In the grand scheme of things... it sort of is similar. Unityscript is inspired by Javascript which is inspired by C/C++. It is considered a C-like language.

C# is inspired by C++ and Java (Java also being inspired by C++). It too is considered a C-like language.

They definitely have more in common, than say C# and Lisp-likes (Clojure, Scheme), or BASIC-like languages, or Haskell, or many other unrelated languages.

But yes, they're also different.

Jumping from C# to UnityScript (or vice versa) is like jumping from Spanish to Romanian. They're both romance languages, but they're different enough that you're not going to do it over night. But if you know one, you're going to recognize a lot about the other.

But it's not like jumping from English to Cantonese, which have NOTHING in common except maybe a handful of loan words that arrived in their language in the very recent history... and even those sound weird as all heck in Cantonese.

Well I don't know how anyone can say that truthfully... what you like is subjective to you.

Honestly it's not harder to use.... it is harder to learn from the get go. As I said before JS-easy to pickup, harder to master.

Yes, they have syntactical differences.

rotation is returned as a struct from a property, so it's a copy not a reference. Unityscript syntax sugars this... but yes, you must copy it out and write it back in.

The 'f' in my opinion is very important in my book as I like strong typed values. What's the difference between these?

Code (csharp):

1.  
2. var a = 1;
3. var b = 1.0;
4. var c = 1.0d;
5. var d = 1.0f;
6.  

First is an int, a 32-bit value that holds signed whole numbers.

Second and third are doubles, a 64-bit floating point number that can stored signed values, infinity, NaN. In C# that is, and in C# a fractional number with out a type signifier defaults to double.

Fourth is a float, a 32-bit floating point number that can stored signed values, infinity, NaN. Unity uses floats (for various reasons), so we need to force type everything floats.

This typing is VERY important... as each type has specific behaviours to them. Such has how int can't be easily divided without losing information, while floats/doubles are prone to float error.

That "weird S***" is the type declaration of what the method returns if it returns anything (not all methods are functions, but functions are methods). If the method returns nothing (making it NOT a function) its return type is declared 'void', this signifies the method doesn't return anything. So if you see 'void', it doesn't return a value.

Most of the time it's not that weird... int, string, float, Component, GameObject... these are just the types that the function returns.

The very weird one you might see often is IEnumerator for Coroutines. This is because coroutines are implemented using the iterator functionality found in C#:
https://msdn.microsoft.com/en-us/library/65zzykke(v=vs.100).aspx

Note... iterators were designed to create functions that can be treated as collections and looped over in a foreach loop. The foreach loop can loop over anything that is an IEnumerable...

Code (csharp):

1.  
2. foreach(object o in lst)
3. {
4.     //your code
5. }
6.  

Is actually syntax sugar for:

Code (csharp):

1.  
2. IEnumerator e = lst.GetEnumerator();
3. object o;
4. while(e.MoveNext())
5. {
6.     o = e.Current;
7.     //your code
8. }
9.  

That 'GetEnumerator' returns an IEnumerator... so really an IEnumerator is just something that can be iterated... or enumerated.

Unity just expanded on the idea and said "what if we loop the IEnumerator once per frame... and call it a Coroutine".

Unityscript of course implicitly defines all this. To turn a function into an iterator function you just include a 'yield' statement somewhere in the function. Thing is... how do you KNOW it's a Coroutine? You have to dig into the method and look for a yield statement. C# on the other hand has a big red flag of a return type screaming "hey, 99% chance I'm a coroutine since I'm an iterator function".

While we're on iterators and looping...

linq - feature unityscript does not have that C# does

Though you can access the linq namespace, you do not get the linq syntax in unityscript.

Code (csharp):

1.  
2. var set = from x in lst where x > 0 orderby x select x;
3.  

It may not be something you want, and some may argue that it can be costly on the GC if used to frequently... but damn do I love it in the moments I need it.
https://docs.microsoft.com/en-us/do...guide/concepts/linq/getting-started-with-linq

This is just growing pains... you don't know the language, nor what the "weird S***" is, so you're just jamming into places and crossing your fingers. You need to learn the syntax and what each statement/keyword/thing means. Like the return type of a method.

It's more a robust, it's more pro-friendly, it's strongly typed, it has massive amounts of documentation, it's a language most programmers coming from outside of Unity are familiar with or is close enough to another language they've used that they can pick it up.

Sure it's not first time programmers friendly (though it is my first language.... welll, technically not. I did right fortran, cobol, and basic way back in middle school... but I wouldn't really say that inspired me to become a programmer and it really was just for class in school and/or to write punters on AOL).

Last I checked Unity wasn't obsoleting Unityscript. They just aren't really adding new features to it.

Someone else correct me if I'm wrong.

If you truly really don't want to learn another language... then don't.

Here's the thing though... I want to put a caveat on that.

Do you consider yourself a programmer or a game designer who uses Unity?

Programmer - learn multiple languages, it's just what you have to do. I know 20+ languages... I'm a programmer with 10 years experience.

Game Designer who works in Unity - if you don't really program a lot, and all you do is use Unity to make games. OK... fine, you don't really need to learn another language. You're not a programmer. BUT you'll be restricted to Unityscript and Unity from then on...

Hopefully that all explains it a little more (combined with other posts).

If you've been using JS for yearsssss... you said what, 7 years? Well... if you take programming at all serious, you should be learning some other languages by now.

 

Good answer @lordofduct . I especially like your take on learning new languages.

I've been programming since I was probably 12... in Basic back then. Basic on my TI99/4A, which should date me nicely. I'm 42 now, just to put a number on it. There was a big gap from there where I didn't do much coding, or anything really relevant, really. Then around 28 or so, I went back to school for 2 years in a computer programming course. I've learned a lot of languages over the years.. Assembler (ungh!), Turbo Pascal (also ungh!), C++, to name a few... database scripting (Oracle PL/SQL / SQL Server / MySQL), PHP, C# and many others. I've forgotten more than I know, for sure.

Sometimes when I'm doing something like web design, I like PHP for slapping something together, quick and dirty... other times, I love the structure (and the compiler being able to tell me what I've done wrong) of something like c#. It kind of depends on the task. I could probably work with one language all day every day, but unfortunately technology doesn't work that way. That's how you get to be the dinosaur in my corporation that only knows one thing.. the obsolete technology.. and the company is trying it's best to justify reasons to keep you on, but really can't. And then you're sitting in your cubicle complaining about everything. Not that I have any of those guys at my work, or anything.

Of course, not everyone does programming professionally, but for those of us that do, we tend to be constantly evolving. There are times where my dislike for change kicks in, and I hate having to learn something new, but it tends to always work out in the end, and I end up liking what I end up doing next.

 

Before I start I must declare my position: I am a bit of a C# fanboy but dont get confused, I did in fact start with UnityScript back when I first started using Unity 4 ish years ago.

I found C# super easy to pick up even without having nearly any prior programming knowledge as I had only used UnityScript for a couple of months and that was all my programming background prior. I think the syntax is clean and the verbosity of C# makes it super easy to read.

Not to mention that recently, support for UnityScript has been a bit lacking both with language features and documentation or tutorials on using the language, I should mention, that i do not think this is necessarily a bad thing, having a single 'main' supported language could help speed up development of Unity as the work can be more focused. This does not mean that UnityScript would be forgotten as any language which compile to IL can be used within Unity.

I think this one worries me a little more than the rest. Although C# has a simple syntax IMHO I understand it takes time to learn. However, all of the logic you learn from developing can be used cross languages. Because of this, you should only be getting syntax errors, which should be trivial to fix, given some simple error reading skills.

Well it makes sense no? In a strongly typed language just a number '5' would define an int so adding an f seems logical to define a float. Note I think there is also a d for defining a double.

Just my 2 cents.

 

There's several depending integer and real literals:
integer literals:
https://msdn.microsoft.com/en-us/library/aa664674(v=vs.71).aspx

U or u - uint
L or l - long
UL, Ul, ul, lu, variations there of - ulong

real literals:
https://msdn.microsoft.com/en-us/library/aa691085(v=vs.71).aspx

F or f - float
D or d - double
M or m - decimal (the m comes from 'money' since decimal type is usually used for money and the standard comes from vb where the type is actually called Money)

All others are contextual (though VB recently added byte)... usually from the type that it is setting to, the size the number literal actually requires, and what type best works arithmetically in that moment.

 

Regarding the whole "I need to put an f" thing. I have gotten used to it, but I can't say I'm really a fan of that, but I guess you can't have your cake and eat it too, as they say. But we've declared our variable a float, I'm not sure why we need to declare our data as a float too... if I wanted it as an integer, I'd either store it as an integer, or do something to lop off the digits. Just my 2 cents on that. I'm sure there's a good reason, but I just find it a little unnecessary. Small price to pay for the rest of the benefits of the language though. As I mentioned, I DO prefer strongly typed and hate ambiguity... but, it's just my variable knows it's a float already, so float something = 10.1 should not confuse anyone into not knowing if I want 10.1 there or 10.

 

Yeah, that can be annoying.

It works fine with: float a = 5;, but not float a = 5.1;

Since they're constant literals, you'd think the compiler would contextually get it. But yeah, it's a result of the fact .Net prefers doubles to float, but unity prefers floats to doubles.

 

Coming from someone who has released a few games in unity js and in c#, here are a few reasons to use C# over Unity's JS.

1. JS is harder to bug fix than C#. This applies to large projects. This is because JS hides a lot of things. It still does them, but it just hides it from you.

2. C# and JS cannot coexist in the same project without complications if they need to call each other

3. Unity's own code is C# for a lot of stuff from networking to UI. If you want to modify these open-sourced parts of Unity (and C# has been internally used in the editor since day 1) you'll need to git gud at C#.

4. JS is really Boo with syntax sugar. It will basically make your compile times much longer than if you were just using a C# project.

5. You get access to an entire internet's worth of C# Code. There is no available Unity JS code that will work, because it's not javascript. It's Unityscript called javascript. It's not compatible. You are willingly training yourself into a dead end which leads me to...

6. Unity javascript is dying and most likely will just be removed the way Boo has been (depreciated). C# however is backed by billions of dollars.


If you are a hobbyist, it doesn't actually matter if you use JS or C#

 

Also don't forget that most things on the asset store are in c# now. I don't think there is much unityscript stuff on there. So if you get an asset with the source code included, it's most likely in c#.

But agreed, if you don't plan to work with others or get a job developing in Unity, doesn't really matter what you use.

 

My understanding is that the reason there is no implicit conversion of double to float is that you could potentially lose data because of the difference in precision. So C# forces you to be explicit about it.

 

yes, it's a downcast

it's why I say it's a constant literal though, the compiler should be able to figure out that it doesn't need to be a cast, and that it is implicitly a float.

I had wrote out a longer post explaining the casting and how downcast causes an overflow. But I figure cstooch would know all that and I'd just be preaching to the choir. So I redacted it to that.

 

Code (csharp):

1. float a = 3.14159265358979323846;

Is that a float or a double? True, the compiler could figure it out and give you the error if the constant requires more precision that fits in the float, but it feels like an potentially confusing inconsistency. Maybe a warning would be a better choice if it's not clearly obvious.

 

that was sort of cstooch's point

give me a warning when it can't work

I get the logic... just you know, it's a luxury one dreams of.

 

Case in point...

Code (csharp):

1. int x = 14343432414321431431243214;

implicitly an int, but too large... so you get an exception.

 

Yeah @lordofduct, head nod to your last two posts. Either way though, like I said, not at all a big deal.. just something I'm not too fond of.

 

I'd be curious to know if you can do similar things with Unity's flavor of JS as you can with actual JS. I used to hate JS, but at this point, at least for web applications, it's pretty much like having control of the compiler and having syntax tree access to dynamically compose objects. Granted most of that isn't performant enough for a game. But there are a handful of fast operations I'd be interested in checking out. Generally though, I prefer C#, for Unity anyway.

Does anyone know if UnityScript can do something like this without requiring type annotations?:

 

Pretty much no. UnityScript is basically C# with a bit of syntatic sugar. If you can't do it in C#, you can't do it in UnityScript.

 

can you help me to implement CGAL in unity3d. A basic example is enough. I am struggling to include CGAL in unity3d.
Thanks,

 

Hi can you help me to integrate cgal with unity . Basic example is enough. Thanks

 

Don't kick open this old thread to ask about something essentially unrelated. Please start a new thread with an appropriate title.

 

Use PM as well