First glance at C# from JS perspective

My journey started with…

When I set out to create a project, my goal was to build a game that could potentially feature 3D elements, be interactive, and particularly played on mobile platforms. I also wanted to integrate AI into the game to add depth and complexity. Naturally, this led me to explore C#—a language commonly used in the Unity game engine. While I won’t dive into the specifics of Unity itself in this post, I do want to focus on why I chose C# and how it compares to JavaScript from my perspective as someone coming from a JavaScript background.

Why C#...

The primary reason I decided to use C# is that Unity, the game engine I chose, relies heavily on C# as its main programming language. While there are other languages you could potentially use in Unity, C# is by far the most widely supported and recommended. It's a modern, object-oriented programming language developed by Microsoft, and it's commonly used in a variety of applications, including desktop software, web applications (via ASP.NET), and—of course—games using Unity.
C# is part of the larger .NET ecosystem, which offers a huge library of resources and frameworks for building everything from small utilities to large-scale enterprise applications. The language itself was designed with simplicity, power, and type safety in mind. This makes it a versatile choice for many kinds of projects. But in this post, I want to focus particularly on the aspect of type safety and why it makes C# stand out, especially compared to JavaScript.

Why C# data type…

C# is a statically typed language, meaning that variable types (like int, bool, string) are defined at compile-time. Since C# is statically typed, the compiler can perform more optimization work ahead of time. Its type safety feature, with variable types being strictly defined, allows the compiler to catch many types of errors before the code is even run and helps the code be more maintainable. JavaScript, being dynamically typed, requires more runtime checks due to a process called type coercion, which adds overhead, especially in large or complex applications. This is part of the reason C# can be faster. However, the main performance edge of C# lies in compute-intensive and multithreaded tasks (like running different parts of the game in parallel).

JS type coercion:

let num = 5;
let str = "10";
console.log(num + str);  // Outputs "510" (string concatenation instead of numeric addition)
str = 10; // Assign a string to a variable and later assign a number to the same variable

Common C# declaration of value data type:

int x = 10; // Whole integer number
double pi = 3.14159; // Decimals 64-bit floating point, end with d but not necessary
float y  = 10.2f; // Decimals 32-bit floating point, have to end with f
decimal price = 19.99m; // 128-bit decimal, have to end with m, for precise monetary calculations or any financial stuff
bool isValid = true; //Boolean true or false
char grade = 'A'; //A single character, of 16-bit Unicode character
string name = "John"; //special case, is actually a reference type

As we know, in JavaScript, variables are declared with var, const, and let. Also, JavaScript has no distinction between int and float; it's just number. Therefore, C# doesn't have NaN. Additionally, in JavaScript, string is a primitive type (similar to a value type in C#), but in C#, it is a reference type.

In C#, value types cannot be null by default, but you can use nullable types to allow value types to be assigned null. null is allowed only for reference types (like string, object, and custom classes). By default, reference types are initialized to null. To enable value types to be nullable, you use the ? syntax (like int?, double?, bool?).

string name = null; // This is valid.
Person person = null; // This is also valid if 'Person' is a class.
int? number = null; // Explicitly allows null since nullable type is enabled
int number = null; // Error: Cannot assign null to a non-nullable value type

JavaScript does not have a concept of nullable types like C#; everything can technically be null or undefined.

In both languages, when dealing with reference types, any changes made to the data through one reference will affect all other references pointing to the same data in memory. However, C# is more strongly typed, and arrays are of fixed size unless you use collections like List<T>, while JavaScript arrays are more flexible and dynamic.
C# reference types: object, class, delegate, array.
JavaScript reference types: object, array, function.

C# Array (fixed size):

int[] numbers = new int[] { 1, 2, 3 };
numbers[3] = 4;  // Error: Index out of bounds because the array size is fixed

JS Array (dynamic size):

let numbers = [1, 2, 3];
numbers.push(4);  // Adds 4 to the end of the array, dynamically resizing it
console.log(numbers);  // [1, 2, 3, 4]

C# data conversion…

In C#, data conversion refers to the process of converting one data type to another, and it can be done in two main ways: implicit and explicit conversions.

• Implicit conversions are automatic when converting from smaller to larger types, or when there's no risk of data loss.
• Explicit conversions are done manually when there’s a risk of data loss (usually via casting).

C# also provides built-in Method for safe type conversions, especially when converting between types that might not automatically cast. Additionally, nullable types require extra handling to deal with null values. Proper data conversion is crucial to ensure data integrity, avoid runtime errors, and maintain performance when working with different data types in C#.

All in all, while JavaScript’s flexibility and dynamic nature make it great for quick prototyping and web development, C# has a clear performance edge when it comes to more complex or compute-intensive tasks. This is especially true in game development, where you may need to handle 3D graphics, AI, physics simulations, and other high-performance operations.
Remember to add your semicolons(;) to end every line of code in C#! I keep forgetting, but they’re strictly required in C#.
Here are a quick link to official documentation on Reserved keywords are words that the language uses, so they already have specific definitions that shouldn’t be rewritten

Up next: Guide to breaking down and understanding C# errors(coming soon…)