Discussion Is C# becoming complex, bloated, or syntactically incomprehensible?

Where the discussion first started
https://forum.unity.com/threads/unity-future-net-development-status.1092205/page-35#post-8978257

For example... Is this feature really needed?

 

It's not becoming all this, it already is.

I don't understand why people like C# so much.

 

No. The core of C# is simple and easy to use.

Advanced features are optional for advanced users. Don't like them? Don't use them.

 

What alternative do you propose?
I find it's the perfect middleground between memory-controlling and performant but very shoot-in-the-foot prone C++ and super easy to prototype languages like Python and Javascript which break down in large projects due to lack of type safety.
Personally I'd have been happy with Java too.

It is a valid argument against that, that at some point you'll stumble across code on Github or by a team mate where the features are being used.

For the most part we are talking about syntactic sugar though. Not too hard to learn. It's not like they introduce new coding paradigms etc. I remember how I struggled (as a student) for a while when Java introduced programming via streams.

 

This mindset is how C++ has ended up being the mess it is.

 

Nah, from todays viewpoint C++ was flawed from the beginning by putting that much responsibility on the user (like all other languages of that time) and since then everything is covering holes.
Rust shows how it can be done with a modern approach.

 

No, C++ ended up being that mess by being thoughtlessly tacked on to C. It was a mess from the beginning. The enhancements since have just been to try to stem the tide of that madness.

 

Do I need to propose an alternative to not understand why people actively like C#, as opposed to, say, just accept it as a necessary evil? I don't have a viable alternative for Windows either and yet I also would not understand someone saying they like it.

 

C# has been showing signs of bloat for a while. It is a mature language that keeps getting new features.

Some people love Lambdas. Others find them hard to read. Thankfully ECS has now reduced their usage.

 

Really? I actually *love* lambdas why would they ever be hard to read?

The syntax is kinda weird, yes, but only if you don’t understand that they are supposed to be “methods”

That’s how it was for me anyways…

 

Lambdas are loved by some. Just like var is loved. Both are totally unnecessary and make code harder to read. Almost always used excessively by junior devs.

 

At one point I thought the same thing then I decided to try using them and discovered that it wasn't actually hindering my ability to understand the code. If I look back at all the times I was hindered it was just my own inexperience and a lack of a proper IDE.

 

The thing you are missing is that there is a big difference between understanding your own code and other people's code.

 

My biggest problem with lambdas is the easy (and fairly hidden) way to ramp up allocation and hinder performance significantly. I like to use lambdas for static things but not for dynamic things. But no readability issue for me.

 

My biggest problem with other peoples code is not that they use syntactic sugar. It's that they approach things in bizarre ways, they poorly name their variables and methods, they format in odd ways (opening and closing braces that aren't on a newline), they don't properly abstract, and so on.

 

Fair enough but I can almost never immediate understand other programmers lambdas/LINQ.

 

Yeah some languages have what I call "syntactic diabetes"... I'm all in for new features that allow the language to express things that where impossible before or required very complex and feeble "hacks" (default interface implementations), but I'm quite ascetic when it comes to just reducing the amount of lines of code.

I'm also not a fan of features that are included just to satisfy the hardcore "functional" guys that go explicitly against OOP. Don't take me wrong though, I think "non-extremist" / rational "functional programming" is really good for a lot of things.

 

The C#, C++ or whoever committee people have to justify their existence somehow. MOAR features!

 

Kind of off-topic, but I'm curious how LLM based tools will affect the languages we use. Will they allow languages to have more types of syntax for expressiveness? Or will they cause people not to care about verbosity since you can "code generate" it as much as possible?

Back on topic, I think this type of aliasing is nice to have in a language. However, in other languages, types are more ergonomic, and aliasing comes automatically. To set an alias you just use

Alias = Type

. I think this is because they have clear and concise definitions between type definitions and runtime types. Specifically, I'm thinking of the language Zig, where you have type definitions existing during comptime code, and languages where the definition of "Type" is the more mathematical definition (like in Haskell). All of these features just seem like patches to try and fix all the symptoms of C# having a poorly defined "Type".

 

In the long run I cannot wait until I can switch to Rust. Closure are so much better then lambda. C# is rapidly becoming a kind of Script Kiddie garbage collected language. Look at Rust it actually makes sense rather then trying to hide everything with syntactic sugar.

The behavior of a closure is part of its type.

https://medium.com/coding-rust/best-explanation-of-closure-in-rust-2b20210eba53

 

Yeah this - I started in the early days and so stick with the basics but have enjoyed things that make Properties easier to use for instance!!
But then you get a junior who writes all kinds of weird code which shows they know every part of the language, but they actually produce some very hard to understand code and can easily over-complicate things.

Maybe a simpler language makes for simpler, more widely understandable code.
I love C#, but if I join a big team I can imagine I may hate a lot of new ways being implemented.

back to C?!

 

Because it is awesome. (exaggeration was intentional)

But I do agree it becomes more bloated and is not perfect.
I pity people that are starting to learn it right now, with all the features added.

May I ask why you don't like it "so much."

Lambdas are very useful for linq and searches, filtering etc. And I do love them for this use.

"var" got its obvious uses related to linq, so it is totally necessary in some cases.
In some companies var is the main "type" for all local variables. (I do not approve)
Personally I try not to use it when I cannot determine type of the variable from looking at the code.

 

You almost make it sound like the people who have been using it for years know what every feature is, but I can tell you right now I don't know half of the features that have come out since I started using it back around the time that generics were released.

I'm slowly picking up new features when I need them but I'm not going out of my way to learn them and I haven't been held back by this choice yet so I don't think a beginner will have any real trouble unless they're planning to join a company and even then they should be able to pick it up as they go.

Alternatively you can have your IDE set to show the type. Here's a screenshot from Rider (by default it shows it if it isn't explicit but it can be made to always do it). Visual Studio and Visual Studio Code can do it too.

 

I got it configured so when I press and hold "ctr" it shows the type, otherwise it is to much on the screen for me all the time.

Problem is when you got the code on the repository, code review is problematic when you don't know the type and have to jump around files to know what is going on.
Good type name is part of the code explanation, it is important to have it visible to some degree.

 

For where C++ is currently very common like embedded software, industrial automatization (my day job), high performance infrastructure etc. I'm entirely with you.
However the non-engine part of games? No no, it would be terrible to do in Unity what we currently do with C#, with Rust instead. Rust is neat but it still forces you to think about memory. With that it would be far slower to develop games with!
A garbage collected language is exactly what you need for 80% of the perceivable game mechanics and for the last 20% where performance is everything you have Jobs or DOTS in Unity.

 

They've definitely made some mistakes in the past, if anyone remembers the dynamic keyword.

We're some what insulated from questionable releases as Unity's C# is fairly behind modern C# still. That and they seem to be creating their own functionality with HPC#. It's probably the right choice, C# for game Devs is going to require different tools.

There is probably a difference between the language that an engine is written in, and the language to build games inside that engine.

It's challenging, we want a high performance language, but also something that is easy to prototype in and beginner friendly...

 

What kind of mistake is dynamic keyword ?

 

The one which turns C# into Javascript.

The dynamic type helps you to circumvent the compiler and allow you to call non-existent methods for example without compiler error (the compiler will assume they will exist during run-time) and postpone the exception to run time (among other things).
In a majorly statically typed language this is an abomination. (And I like Javascript...)

Well, in summary, C# is considered a statically typed language, but it has

var

, which resolves types at compile time and it has

dynamic

which resolves type in run time.

 

I wonder how much of this is actual bloat vs devs entrenched in their ways and unwilling to learn new features. The best part is that none of this is mandatory unlike say Godot's domain specific GDScript 2.0, which introduced a bunch of breaking changes in Godot 4.0. Your C# code is practically evergreen at this point.

 

With great power comes ... (you know what).

You don't use "dynamic" for normal programming but it is definitely not a mistake.

 

Lambas were definitely a bit confusing when I was new to C#. Once I got the hang of them, then yeah they're quite useful.

I agree with what some folks have said before in that most of C#'s features are optional and can be completely ignored if so desired.

And C# is full of weird features I think most of us forget about. Who remembers/uses local methods? (I do sometimes)

 

C++ is extremely common in game dev outside of Unity. In fact, it is the industry standard even Unreal switched to C++. Most game libraries are also written in C++. I don't advocate C++ after all I am a C# dev. But you have to recognize this reality.

After using Unity ECS full-time for the last three years it has become clear to me that in the long run, Rust is the best option. HPC# suffers from significant limitations. If you look at the ECS source code it is very arcane and messy. It also have many bugs and development by Unity has been slow because of this.

Our next game will be 90% HPC# and 10% C#. However, in the long run, say 10 years I fully expect to be using Rust. It is just better for larger ambitious games. It is true that HPC# can indeed be written in user space in such a way that user code is simple. Just don't look behind the curtains. In any case, HPC# is very limited and I feel like we have just outgrown it. It fills an unhappy medium that is not going to appeal to either simple games or very complex games.

 

Yeah but for very specific usecases which simply are usecases the (web backend) industry needs (mainly interfacing with unchangeable code in other languages).
You won't find it in any beginner tutorials, so no worry that someone will be misguided by its existence, I'd say.

Exactly.
Another example would be the "unsafe" keyword (albeit that one is occasionally useful for us: To extend functionality regarding Unity's native containers).

Why are these weird? o:
In Python they are very common to use (probably because of their very limited lambdas (single statement only)).

One gotta differentiate between Engine code and gameplay code!
Pretty much all major engines that are open to the public do support a form of scripting language for gameplay even if the backend is C++. UE has blueprint.

 

You need to understand how the game industry works. The people doing scripting are often not programmers. You have many other roles that do not exist in the indie space. For the most part "features" are programmed in C++. Stuff like path finding, networking etc. No, people are not programming most gameplay in scripting languages. The fact is scripting languages have overtime been dying out in the game industry. Stuff like cut screens and dialog are scripted.

Proprietary engines are very common, in terms of dollars earned they must represent the majority. Unity has a different focus and market segment. It is hard to even categorize Unity games as being in the same industry.

 

Mistake is most likely too harsh of a word, but it's not used commonly among C# developers.

I recall I was making a Blender Parser for Unity, and an existing code base used the dynamic keyword extensively, which wasn't compatible with IL2CPP and took some effort to remove it.

 

It's a mistake that exists to make it easier to work with another mistake known as Microsoft's COM APIs.

https://stackoverflow.com/questions/2690623/what-is-the-dynamic-type-in-c-sharp-4-0-used-for

 

YES.

it is C++ typedef. Incredibly useful.

C# has no include files, so you can't make a global typedef as is. You'd have to redeclare for each file.

For example, you can implement a dialect, write a library for it and then swap the underlying data type.

global using Vec3f = Vector3

, then swap it with your own struct.

If the talk was about records, then also yes. It allows a quick short declaration of data you'd be tempted to stuff into a tuple.

 

Yes? This is a good and useful feature. The idea that just because you can't think of a use case immediately or don't understand it very well doesn't mean it's "not needed." Also, this "bloat" doesn't have any real negative impact on performance either.

This is just a complaint that there's "too much stuff" in a language that has to cover a lot of bases because it's used in multiple different disciplines.

 

Unpopular opinion: If you need a proper IDE to be able to understand a language, it is probably not a good language. For me, I want a language I can open in vim or notepad and still understand it easily.

 

You won't be able to work efficiently without an ide these days. In any language. You'll have something like 20x times slowdown. However, vim is arguably an ide. A very lightweight one.

The original commit was speaking about lambdas though. Those are perfectly understandable without an IDE

doStuff(arg, (x, y) => x + y, tmp => initArg(tmp));

You need to understand their logic, though.
https://forum.unity.com/threads/sol...istener-events-in-batch.1137421/#post-7309777

 

With this mindset you simply loose a lot of opportunity to make the language really useful.
Furthermore, many people code Python (which has is not typesafe) in Notepad++, so somehow it's possible

 

Lots of great things added in recent years. Like record structs and the with keyword

 

Yes those were great, but dynamics... **shudder**

 

Reflection using typeof(MyType).GetMethods...Invoke can be better yes because it will show up when looking for references of the type.

 

Dont forget Spans with massive perf improvement and none nullable reference type declarations

 

I recently used unsafe features to interface C# with C to expose APIs to Swift in Unity, and I appreciate the fact that C# is versatile that it allows to selectively be low level without having to having to marshal everything between the language borders. It's a feature not for the majority, but yet does not even make its presence known unless people deliberately looking for it. That goes for the most of the other C# feature as well, unless you use Rider or Visual Studio with analyzers turned on which they will let you know for sure that your code is ancient.

 

Indeed anything involving vim tends to be an unpopular opinion. Like @neginfinity said though vim can be an IDE and with plugins can have syntax highlighting, code completion, etc.

 

It makes sense to know vim basics, as it is often preinstalled everywhere. I suspect it might even be... actually, lemme check that.

...

You know, I just connected through ssh to my vacuum cleaner.

It has vim installed in it.

So, here you go.

 

I use local methods quite frequently to replace lamdas. I read long ago they had better performance (probably only tied to a certain version of .net/mono) and I find them more comfortable to read/debug than inline lambdas. I do agree they look weird.
The problem with lambdas is, they are syntactic sugar and as such they should add more convivence than harm to be "a good feature". Unfortunately, although they can be quite convenient, it is really, really easy to make a mess out of them, creating code that's hard to read and even harder to debug. (horrible 1 character variable names, nested lambdas, lots of important lines of code cramped between a call to another method that in turn was "fluent" and is tailed with further calls, etc,etc,etc,etc, *shudders*

I'm not saying they were a mistake, I'm just illustrating an example of what syntactic sugar can do.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

People, remember u are mixing in the discussion features that add real expressiveness (let the language do something it wasn't possible before) and features that are only syntactic sugar to express something that's already possible but in a shorter and supposedly more convenient way.

I think this distinction is fundamental. I can swallow any bitter pill for the sake of real expressiveness but I'm a lot more picky when it comes to just syntactic sugar.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The argument of "optionality" is quite moot in my opinion because almost nobody lives/works/codes in total isolation. If there's a language feature out there, u are bound to find it in a piece of code u need/want to use. (It's a new Murphy's law(?))

 

The reason is because they get lowered into actual methods!