What you’re objectively missing when using UnityScript instead than C#

I just wrote a blog post about this argument (Unity: what you’re objectively missing when using UnityScript instead than C#), and I thought I'd mention it here.

I tried to keep it objective: it just wants to be a list of what's truly different between C# and UnityScript (coding preferences and styles apart), and of what you can achieve with C# but not with UnityScript. If any UnityScript/C# user thinks I forgot something (which I probably did), or mis-wrote something else, please let me know, since I'd like it to be truly objective and rather complete (its purpose is not to "show that US sucks" or something like that, but just to be informative).

That said, I would be very curious to know if somewhere there is a similar list of Boo VS C#. Boo fascinates me, though I know nothing of it, and I know that it can at least do one thing that C# can't (breaking out of an anonymous delegate).

 

"Goto"

WTF? That's number 2 on your list?

Not generics?
Not events?
Not optional named parameters?
Not the billion and one resources in and on C#?
Not nullable syntax?
Not the ability to write applications outside of unity easily [console, web, services, forms, silverlight, photon server etc?]?
Not Visual Studio support?
Not anonymous types?
Not cool object collection initializers.
Not implicit arrays?
Not really cool features like dynamic and async [albeit we have to wait for unity to update before using them]?
Not properties [esp. auto properties]

How about defining interfaces and operator overloading [as I've not seen US do this yet]?

Hell... why not partial classes? Not common in U3D... but a ton better than 'goto'.


/RAGE!

 

Please note that's not a list of one's C# knowledge or love: it's a list about what you can do with C# and not with UnityScript, and as I mentioned it's non-comprehensive and in need of expansion (I only posted what I'm sure UnityScript can't do - but I don't use it anymore so my memory lags there).

That said, as far as I know:
- US allows generics
- US can implement events
- You're right about optional parameters: will add it to the list
- Resources are not exactly the point
- Didn't know US didn't support nullable types. Will add it.
- Writing code outside of Unity is clearly not the point, nor is the IDE (I love Visual Studio, but it costs a lot)
- Ow, US has no anonymous types nor object/collection initializers? Will check it out and add it
- Implicit arrays are syntactic sugar: not the point again
- Since dynamic and async are not yet available, who cares?
- Forgot about auto properties and operator overloading not available in US: another thing to add
- Partial classes are evil, on my opinion

/BUCKET-OF-WATER?

 

Exactly... but goto is [IMO] about 20th or 30th of things you can do in C# not in US, not 2nd!

- US allows generics

Nope - you can only consume, you can't create - see third post [by yours truly].

- US can implement events

Linky?

- You're right about optional parameters: will add it to the list

And named parameters. And params.

- Resources are not exactly the point

Though it's the biggest [or second biggest] real world difference in productivity, usability etc. It rates higher than VS IMO.

- Writing code outside of Unity is clearly not the point, nor is the IDE (I love Visual Studio, but it costs a lot)

Writing games should be the point - and lots of my game related code is written outside of Unity. Furthermore Visual Studio Express is free and more than adequate for most uses - particularly compared to say mono dev.

- Implicit arrays are syntactic sugar: not the point again

Yes and no. Yes they ain't a biggy... but I'd still rank 'em higher than goto

- Since dynamic and async are not yet available, who cares?

I do, since I use them when writing my games... see 'code outside of unity'. Again, this is in contrast to goto.

- Partial classes are evil, on my opinion

And goto isn't?

 

My impression of advanced (?) languages is that they are for advanced programmers. I much prefer Unity Script and always will. I don't need fancy whatever-it-was-you-called-it features that takes more learning curve to learn and understand. I was simple. I want coding to be quick and easy. I don't want extraneous syntax. I don't think of myself as an expert programmer and I don't want an expert's programming language.

 

Its pretty cool that VS Express is free, but I do miss some of the Refactoring tools that come with standard. That you can just download XNA and start developing for DirectX I find really useful compared to say Oracle Java.

 

If you don't need 'em don't use 'em. When you do need 'em...

US has *plenty* of extraneous syntax compared to well written C# code. Take generics - to write a generic class [or function] in US you either have to write a new class for every type... or use casting all over the place. Neither are efficient or friendly. To use generics you have to use the 'dot' syntax, and be careful to place the right number of spaces to avoid the compiler misidentifying the '>' [or is it '<'] as an operator IIRC.

How about some of the best tools resources on the planet... that just happen to be noob, intermediate, advanced and expert friendly? In terms of real world advantages this is far beyond some language features IMO.

Now, not trying to say you can't use US - just that there's a heck of a lot more on the table than some expert syntax for experts.

 

I don't really understand what you were saying there. Are you saying you can't do

Code (csharp):

1.  
2. var myList : List.<String> = new List.<String>();
3.  

? Because you definitely can

 

Try implement List.<T>() - you can't do it. Which makes a whole categories of problems much harder - the only saving grace is some basics have already been implemented in .NET so it doesn't smack you in the face as hard as it would otherwise, more bites at your ankles.

 

Well yes, you can implement "events" in US. I've done it, but its ugly and not very efficient.

When I first began programming, I heard all this nonsense about "this language is better because it forces you to use proper techniques" (usually referring to implicit and explicit variables. That reasoning never sat well with me, as my belief is, "if it works, then it was done properly".

I started with US then moved to C#. Honestly, the difference is barely noticeable. The only real perk I've found is the fact that, with C#, you can move much further outside of Unity's normal functionality. So as a programmer, you'll have a much broader experience. If you have no intention of using anything other than Unity though, then it makes no difference.

 

​

 

Get a regular job anywhere in the world?

 

@Jvil if you want entertainment just go pm Tiles and say I said something.

 

I recently moved from US to C#...still learning, but must say Visual Studio is waaaay better than MonoDevelop. Also, like npsf3000 said, US has no List.<T>(), which I am finding quite useful, now that I am using C#. Besides, you can do stuff outside Unity with C#. So, yeah. C# > US.

 

Autocomplete in MonoDevelop (I develop on a Mac, surely wish I was able to use VS).

 

Haha, yes. Having to re-type "Transform" every single time because MonoDevelop kept switching it to "FollowTransform"(Which I can't even find in the API...) was extremely annoying. And time-wasting.

 

I find it extremely unfriendly to call for me here. Not that i expect anything useful from you anyways.

 

OK, I'll bite. Why do I want a list of T's, when UnityScript does seem to be capable of making regular Lists? What is its benefit?

 

I recently converted my current project from US to C#, and I found there is hardly any difference when converting in that direction. Besides obvious MINOR syntax changes. Generally, only the function declarations and variable declarations needed to be updated. The main game code remained (mostly) the same between the two languages.

So, not to fan the flame, then why ever choose US? You can't *really* say because it is easier, since both are VERY similar. C# has more features of course, the point of this thread.

Maybe we need a list of what US offers that C# doesn't, otherwise I don't really see why somebody would choose US (honest question, didn't want it to sound 'flamey'!)

To recommend to a noob to use US over C# isn't really good advice in my opinion, since C# is *almost* as difficult to learn as US, but with added benefits. You don't *have* to learn/use the more advanced features of C#, but they are there when you are ready.

[Edit] Just an FYI, the reason I decided to switch to C# is because I found out is has a 'GOTO' command! Finally I can start jumping to exact spots in my code, no more advanced and fancy code blocks to get in the way! ha!

 

UnityScript Lists (Arrays) are very similar to List<T>s. However, if you want to add an element to a US array, you have to re-size the array manually. List<T>, however, automatically re-sizes itself. No extra code needed. A default List<T> can hold 16 elements. However, if you add 17 elements, for example, the amount of elements the List<T> allows is automatically doubled, to 32. With a US array, you would have to manually set the size of the array to 32.

 

Yeah... and US can do that too. Try this as a .js file.

Code (csharp):

1.  
2. import System.Collections.Generic;
3. var someNumbers = new List.<int>();
4.  
5. function Start () {
6.     someNumbers.Add(1);
7.     someNumbers.Add(23);
8.     someNumbers.Add(456);
9.     someNumbers[1] = 789;
10. }
11.  

EDIT: I guess this is why Generics weren't in lzitmee's original list?

 

Why is that a lot people feel the need to convince others that what they believe is better than what others believe? It seems like a waste of time to me.

 

Interesting. Well, I am not the most knowledgeable in this area...still learning. I guess that may be why generics weren't on the list...

 

Well, since i was this nice invited, here we go again.

When they are really so similar, why should i use C# then as long as i am fine with JS? It does the job.

Because it is nevertheless easier to understand for some folks, including me. For somebody who comes from Javascript anyways. That`s the whole point of having different languages. It shortens the learning curve alot when you can build on top of what you already know. And "more features" to do the same job can also be a negative thing. Especially when this "more features" are not needed, and just leads to confusion. I think i have already said in other threads what i think about the C# lametta.

I don`t need a list. JS does the job for me. That`s all i need to know. In case JS doesn`t do the job anymore then it`s time to rethink. You have reached this point. Fine. I still haven`t. Why are you not simply fine with that too?

I still disagree. I tested both languages when i started to use Unity, and went on with JS because it was easier for me to understand. So there`s minimum one person that can tell you from personal experience that C# is in fact harder to learn.

I don`t recommend anything. My personal advice was and is that everybody should test the languages to find out what fits best for himself. And not got dictated by a handful language nazis that tries to hijack this forum here by hundrets of answers long discussions until the opponent is finally quiet, handbagging everybody down that doesn`t share their opinion.

Just to remind: you can do the very same game with all three available languages. There is no game that runs or looks any better because it`s made with C#.They all do their job. And that´s what counts. Not some obscure feature comparison lists.

 

The OP has a very good reason for posting this thread. In the interest of it being even easier to accomplish what I want when I program, I would definitely be interested in what US has that C# and Boo don't, and vice verse. Not to hate on any language, but to find out if it is really better for my needs. If a particular tool better meets my needs than others...why wouldn't I want to know, and to use that tool?

And some people won't use this cpu, or that graphics card, or this language. And it has nothing to do with how well that product serves, but a whole lot to do with "I'll never use anything made by company X".

 

Nothing to say against comparison. As told, i am a very strong fan of building your own opinion. But such threads here are usually packed with nonsense and obscure arguments. And sooner or later they always mutates into "C# is god, let`s kill JS" threads. And when you look at the initial posting and follow the link to the blog, then you can see a very biased opinion. This article is everything but objective.

This debate around C# and JS goes since years. And since years without any real conclusion. Just the bashing and methods gots harder meanwhile. Which should tell you enough already.

 

ROFL.
That's all I'm contributing to this thread.

 

See what i mean?

 

@Tiles, you mentioned "Because it is nevertheless easier to understand for some folks" regarding US.
I guess that's the part I don't understand. I really didn't find that in my experience, but to each his own. (Ha, which is really the point you're trying to make I take it!) No need to explain further why C# is harder, I can find a few reasons why it would appear to be, but to me it was just different, not more difficult. (Mainly that you had to cast to the proper data type more frequently, a little daunting to a noob perhaps, but quickly adapted).

And so far this thread is flame free, no 'C# is God' yet. I agree with the OP's intention, I would like an unobjective discussion listing the differences. No emotions. Just list facts. No debate. (This should also include why JS is better than C# is some circumstances). And 'better' is always subjective.

I originally started with C# years ago before stepping away from Unity. The reason I choose US this time around is because I have a few nephews that wanted to get involved (one is a C# programmer already) and thought it may be easier to get everybody up to speed with Unity quicker. To be fair, my circumstances didn't require me to return to C# recently, it was just a bunch of smaller issues, mainly I wanted to use VS, and not MonoDevelop.

 

This was my takeaway. I was already used to #pragma strict using US so moving to C# was really easy - coroutines were probably the biggest change. Don't see a reason to ever go back to US.

 

I use US, but I recognize that C# overall has more benefits. The only obvious reasons I can see that would lead someone to choose US are:

1. If they, like me, came from a programming language very similar. I used to use Flash, and my Actionscript 2 knowledge was very similar to the way that UnityScript worked.

2. Overall, Unityscript seems quicker to write. If I go to most any page in Unity's documentation, I can see what the code would look like in "Javascript" and C#. The Javascript one is shorter nearly every time. I don't have to let Unity know that Update is a Monobehaviour. I don't have to let Unity know that I'm "using UnityEngine" (honestly, what else would I be using?). Because of the way Unity interprets Javascript, it assumes some things are always true for me, and for any code I've made so far, they always are.

Does this compare to izitmee's list? Probably not. But Unityscript is what I learned, and I haven't yet needed to switch.

EDIT: I suppose I should mention that there is one benefit to C# that will likely get me to finally switch: Unity 4's new official video tutorials will all be made assuming that you're using C#. Seeing C# being used in practice within Unity so much will probably push me over the edge.

 

You don`t need to undestand it. Just accept it. What´s oh so easy and obvious for you can be the hardest thing for somebody else. And what`s ultramegahard for you can be the easiest thing for him. That`s the way it is. People are simply different.

Indeed

I got already poked again twice here in a very decent manner, the first poke without even being involved in the thread.

 

I'll repeat my original argument (made months ago in a similar thread).

Both languages are nearly identical, and both can accomplish the exact same thing. They also are both converted by Unity at runtime anyway, so the differences become even small in the finished product. They are the same!

Conclusion: Use C#. At least then, you can be an elitist and act like you're better than everyone else

...seriously, I've used both. The warm fuzzy feeling is my only reason for choosing C#.

 

Honestly..... I don't give a crap which one is "better".

And I'm sick of these damn post that "prove" that one is better, and keep telling me I'm missing out, it's not like ive seen a post like this before 1000 times.

I chose UnityScript..... Get over it
[/rant]

Not AImed at OP

 

Did you forget Namespaces in your list? I don't believe that US supports those, but I'm not sure if that changes in Unity4 or not.

Edit: Nope, you got that. Sorry, somehow missed it on the list.

 

If you can get it to work for you, cool.

I will say this much:

I made my first game entirely in JavityScript. Late in the project I started having issues with a few third party code (Prime31's mostly.) When I started porting to Android I found it easier to port every single line of code to C# than to work around these issues.

Fact is, the best for-sale plugins (Prime31 ) are made in C# so I decided to go C# going forward. I also realized how amazing the autocomplete was in C# mode.

Also, the gained experience got me a BIG raise and promotion at work.

 

Why the facts about what tools and resources C# has that US hasn't is taken by a lot of US users as a personal attack? Nobody cares what language you use.

1. US is a less strongly typed language than C#, so it allows more implicit casts and conversions. Without #pragma strict a variable can completely change its type on the fly (sometimes it can do so even with #pragma strict.)

2. Implicit implementation for classes derived from MonoBehaviour. It doesn't save any key presses but still is a feature.

3. ...?

 

Very true. The only time I've ever seen the question of which language someone uses brought up is in these conversations about which one people prefer. When actually working on a project, people rarely care (unless they've already begun a project in one language or another).

 

I have had to use CS for this project right now and have seen some loss of functionality...

 

The funniest part is that the title isn't a question.

 

Simple example: Let's us write down a simple object pool - say for GameObjects. This is a fairly common piece of code in games because instantiating and creating objects is a lot less efficient than reusing them.

Code (csharp):

1.  
2. public class GameObjectPool
3. {
4.     Stack<GameObject> store = new Stack<GameObject>();
5.  
6.     public int MaxStored = 100;
7.     public Func<GameObject> CreateLogic;
8.     public Func<GameObject, GameObject> SaveLogic;
9.  
10.     public GameObject Get()
11.     {
12.         if (store.Count > 0) return store.Pop();
13.         else if (CreateLogic != null) return CreateLogic();
14.         return null;
15.     }
16.  
17.     public void Save(GameObject go)
18.     {
19.         if (store.Count < MaxStored)
20.         {
21.             if (SaveLogic != null) go = SaveLogic(go);
22.             store.Push(go);
23.         }
24.         else /*Destroy(go)*/;
25.     }
26. }
27.  

Used Like:

Code (csharp):

1.  
2. var pool = new GameObjectPool
3. {
4.     MaxStored = 10,
5.     CreateLogic = () => new GameObject(),
6.     SaveLogic = x => x
7. };
8.  
9. var go = pool.Get();
10. //use go
11. pool.Save(go);
12.  

Now, what happened when we realize we need an object pool for other things? How about int's [trying to reuse positions], components, textures so on and so forth?

Do we write out a bunch of pools?

Code (csharp):

1.  
2. public class IntPool
3. {
4.     Stack<int> store = new Stack<int>();
5.  
6.     public int MaxStored = 100;
7.     public Func<int> CreateLogic;
8.     public Func<int, int> SaveLogic;
9.  
10.     public int Get()
11.     {
12.         if (store.Count > 0) return store.Pop();
13.         else if (CreateLogic != null) return CreateLogic();
14.         return 0;
15.     }
16.  
17.     public void Save(int go)
18.     {
19.         if (store.Count < MaxStored)
20.         {
21.             if (SaveLogic != null) go = SaveLogic(go);
22.             store.Push(go);
23.         }
24.         else /*Destroy(go)*/;
25.     }
26. }
27.  

?

Or do we just use 'object'?

Code (csharp):

1.  
2. public class ObjectPool
3. {
4.     Stack<object> store = new Stack<object>();
5.  
6.     public int MaxStored = 100;
7.     public Func<object> CreateLogic;
8.     public Func<object, object> SaveLogic;
9.  
10.     public object Get()
11.     {
12.         if (store.Count > 0) return store.Pop();
13.         else if (CreateLogic != null) return CreateLogic();
14.         return null;
15.     }
16.  
17.     public void Save(object go)
18.     {
19.         if (store.Count < MaxStored)
20.         {
21.             if (SaveLogic != null) go = SaveLogic(go);
22.             store.Push(go);
23.         }
24.         else /*Destroy(go)*/;
25.     }
26. }

Which isn't needs inelegant and inefficient casting for use:

Code (csharp):

1.  
2. var pool2 = new ObjectPool
3. {
4.     MaxStored = 10,
5.     CreateLogic = () => 0,
6.     SaveLogic = x =>  (int)x - 1
7. };
8.  
9. var myInt = (int)(pool2.Get() ?? 0);
10. //use int
11. pool2.Save(myInt);
12.  

Or we can use use a generic pool - that *just works*.

Code (csharp):

1.  
2. public class GenericPool<T>
3. {
4.     Stack<T> store = new Stack<T>();
5.  
6.     public int MaxStored = 100;
7.     public Func<T> CreateLogic;
8.     public Func<T, T> SaveLogic;
9.     public Action<T> DestroyLogic;
10.  
11.     public T Get()
12.     {
13.         if (store.Count > 0) return store.Pop();
14.         else if (CreateLogic != null) return CreateLogic();
15.         return default(T);
16.     }
17.  
18.     public void Save(T item)
19.     {
20.         if (store.Count < MaxStored)
21.         {
22.             if (SaveLogic != null) item = SaveLogic(item);
23.             store.Push(item);
24.         }
25.         else if (DestroyLogic != null) DestroyLogic(item);
26.     }
27. }
28.  
29. ...
30.  
31. var goPool = new GenericPool<GameObject>()
32. {
33.     MaxStored = 10,
34.     CreateLogic = () => new GameObject(),
35.     SaveLogic = x => x,
36.     DestroyLogic = x => Destroy(x)
37. };
38.  
39. var intPool = new GenericPool<int>()
40. {
41.     MaxStored = 10,
42.     CreateLogic = () => 0,
43.     SaveLogic = x => --x,
44. };
45.  
46. /*etc*/
47.  

 

And yet you felt the need to participate in the discussion that I invited you to?

 

Just to tell you that you did an unfriendly act. As usual. I will not be quiet just because you want me to.

 

Thanks to all the posters that tried to keep this thread purely informative. It would be cool if we managed to go only that way and avoid a "language XXX is the only true one" war

I suppose we all can agree that C# is a more mature language, simply because it's older and has more features. That doesn't mean it's the best one though, and there's no reason in trying to convince someone to change his programming language of choice. As many posters pointed out, it depends on one's needs/habits/interests, plus some things that might look like a con to a C# user (like implicit implementations and imports) actually are a pro to a UnityScript user (that's why I didn't write those in that list). Not to mention that some C# user will actually use C# in a rather similar way to UnityScript, while those additional features are useful only if you plan to actually use them one day.

I just thought it would be interesting - also because a friend asked me - to point out some of the objective additional features that C# has. As a simple list, to keep it free of personal opinions. Information, if objective, is always a good thing, I believe, and allows people to choose better.

 

I still think your list is highly biased. Not so much because you write it biased, but because such a pure feature comparison list gives a completely wrong picture. What your list doesn`t take into account are the cons of C#. Like that you need to write more text to do the same. This simply falls off the table. And what your list doesn`t take into account is that you don`t need 99.99% of all this extra C# features to make the usual games in Unity. Unity is not a C# ide. It`s a game engine, with a specialized field of use. Games.

 

@Tiles: I understand your point, and maybe I should've added the word "features" to the title. Will try to change the introduction to make things more clear.

I didn't take into account the "more text to do the same" thing, because that's more of a subjective/style thing (some things are shorter to write in C# than in US - like declarations - and viceversa).

About those features, 100% of them can actually be very useful to do games, especially if they are complex ones (I actually use them all even in simple games), that's up to the developer's choice. I suppose that from reading those features one will be allowed to choose that "it's an interesting feature, I want to try using that", or "I don't need nor care about it at all", which is kind of the point.

 

Have a look at the scripting reference. And compare the code snippets. C# snippets are around 1/10 more text in general. Objective.

The same can be said for a butterbread. But i don`t need it to make my game. I could bet that even most of the hardcore C# users here rarely makes use of those listed features. Which is my point. This stuff is mostly not needed for the games that usually gets done in Unity.

I can see your intention. But you may have noticed that the community has beaten to death with C# vs JS threads in the past months and years. Without result. This thread will just again put oil on the fire. The thread title is already highly suggestive, suggesting to me that i miss something. But i miss exactly nothing.

There is no objective C# vs JS comparison possible. Because you cannot divide the pure C# from outside of Unity away from the C# that is needed for making a game in Unity. Which you must do so that your comparison is of any use.

 

But as I mentioned, declarations - and non-strictly-related Unity stuff, that you still can use in your game - are usually shorter in C#. Personally, I find C# scripting quicker/shorter than US. You don't, and that's why it's subjective (also depends on your coding style)

If you're talking cooking let's talk cooking You don't need sour cream to cook steak. But you might want to use it for some steak recipes. The same goes for those additional features. You don't need them to make a game, but you might need them to make certain types of games (I'm not a hardcore C# user, but I use all those features all the time, except LINQ and goto - which obviously doesn't make me better than you or anybody else, in case it needs to be pointed out). And as such I believe the thread title is correct. I'm not saying you need sour cream: I'm just pointing out that you CAN have it, in case you want to use it.

I think It's objective to say that C# has some features - and can do some stuff - that US doesn't, and it's interesting to know what are those features. I avoided mentioning stuff that C# can do but that is not related to games/Unity development, because it's a strict game-development-with-Unity feature list

 

Except C# users report using less LOC to do similar things - and have provided plenty of examples of this in the past.

Define 'need'?

I use ~80%+ of the mentioned additional 'features' in game dev on a regular basis. So there's certainly use cases for 'em. Therefor you are 'objectively missing them' as per the article title. How important/valuable these features are for the reader to decide.

I'm sorry for rudely inviting you into this discussion... while at the same time asking you to be quiet and not participate?