C# is an excellent language with an great ecosystem and lots of jobs available. Also, if you ever want to go a bit more functional, F# is excellent.
My personal reason for avoiding it is purely political: I don't trust Microsoft. I try to not rely on languages that are controlled by a single monopolistic corporations. Considering the recent case of the golang compiler planning on getting telemetry, I feel validated in that decision.
As for game development, I think the game engine of choice will already dictate what one should learn.
Unity is still king of casual and mobile games, so if that is your niche, learning C# is a no-brainer. Plus Godot has decent C# support now, if you ever need to change horses.
As for more complex 3d games, Unreal 5 is just insanely good. Nanite and Lumen offer tremendous improvements in both development experience and end result. Here learning some C++ is advised but funny enough, there are actually Nim bindings as well. If you don't mind getting into somewhat untested waters, Nim might be a very good choice here.
After the significant push-back it seems like are considering doing only opt-in telemetry[1] which would be acceptable.
So not that bad for now but who knows. Once telemetry is in place, they might try to change it to opt-out at a later date when less push-back is expected. Still setting a problematic precedent and shows why corporate control about a programming language might become problematic.
but i do like how nim programs consistently have few lines of code than the same program in really most other languages which seems like a good thing
Interesting take.. I could share some codeGolf languages that you might like to play with in that case!
That said there are a few fallacies in the comments also that bother me a bit. Specifically the assumption that 'once its closer to C its automatically more performant.'
Wild comments too like : `Nim runs on many more platforms than C#`
Without being specific this claim is just weird..
beware though that usually the people who wrote the benchmarks might not be experts on Nim
So you need to be an expert to benchmark it.. Red flag.
I didn't get why fewer lines of code is better. I don't choose rust because its "shorter", far from it, if anything I choose rust because its very verbose with its syntax, but that syntax conveys a lot of information.
Another comment in the above thread mentioned that "c-like performance is easily reachable with c2nim, or inline assembly" well then thats not really the performance of nim is it, thats the performance of assembly ...
This is a pretty dumb/blunt justification, but there is _some_ truth to it: The number of bugs in a program correlates roughly to the number of lines in that program, irrespective of language. Ergo, if some language lets you accomplish your goal in 30% fewer lines, you will have 30% fewer bugs.
The huge caveats are at a minimum that you're writing the code idiomatically (ie not putting your entire program on a single line), that it also strongly depends on developer proficiency with the language (likely lower for a newer language like nim), whether the problem you're solving is well understood, etc
There is a lot of data showing less lines of codes correlates with less bugs.
I don't know if that works cross languages, like a language that requires annotations to help ensure correctness requires more lines thus does it correlate with fewer bugs than python? don't know.
There have been a few studies showing that bugs-per-line-of-code is pretty consistent from language to language. So, if you can reduce the number of lines needed, you reduce the number of bugs.
I'd bet rust is an outlier in that, a lot of languages require more code to do the same things, as a result of being simpler langs (lua). a lot of langs are very easy to shoot yourself with, more lines means more oppurtinity to shoot yourself.
In rust though, that 30 line python script probably takes 45 lines to write now. But those 15 lines aren't wasted or because of longer logic, rather those lines are used to convey type information
its not "more lines = more bugs" as it is "most languages don't put more lines to good use"
If I'm benchmarking (not perf testing) a language with some nuances I'm not too familiar with, I would stick some simple implementations of core workings. If those simple tasks are `supposed` to be done a `special` way, then I'm already not interested.
Why should I need to learn semi-workarounds just to achieve the basics.
You can write fast or slow code in any language, typically people who understand the language very well are the ones who can write performant code, regardless of language. All those benchmark games out there for dozens of languages are proof of that.
I currently use C# for most of my work. I would love to use Nim, as I like its design, its simplicity, its performance and the fact that it doesn't enforce OOP, but here are the problems:
Template metaprogramming facilities have a reputation for being a very powerful tool if used judiciously. If overused, they can lead to over-complexity though. And a template system that is as easy to use as D's might encourage overuse.
Presumably you're only asking about statically typed languages, right? Otherwise Julia, and every Lisp come to mind. Especially compared to Lisp all other languages are inferior when it comes to meta programming.
I have the opposite stance. Visual Studio is my primary dislike in working with C#. It's mighty, I'll give it that. The debugging experience is strong. But it's slow, sluggish, components or itself crash sporadically; the extension ecosystem isn't great.
Working with containers/docker is a bit painful, too: as with all things Microsoft, there are layers of indirection to just make it work™. While it does, it's wonderful. Almost inevitably however, one runs into edge cases that are impossible to solve, because the config you need hasn't been surfaced to the GUI. That's where I prefer more 'hackable' IDEs like VSCode. In these situations, it might just allow you to drop a line of bash into some JSON config. Simple and works, no GUI work from the devs required.
One my of favorite pet peeves is running unit tests in parallel from inside VS, using the GUI/shortcuts. The setting for running unit tests in parallel is a nested setting, only accessible via GUI. Running unit tests in sequence is incredibly slow in our case (and when would you ever want unit tests _not_ run in parallel?). The setting is then stored somewhere in the `.vs/` directory, in _binary files_. You cannot version control them, and `git clean` regularly knocks that directory out, wiping the setting. Annoying, but not annoying enough to do anything about!
I agree with you around VS and I use it all the time. The problem is that Rider for example is the same. I've had the chance to do a project with Rider recently and I have to say performance-wise both VS and Rider are just slow and prone to crashes and random errors. It's true they offer immense power. Debugging and profiling is unmatched in both IDEs. However, what I'd like is a more modular approach in both of them where I can disable certain things to take a load off the dev experience. I'm not sure if their architecture would allow for such a change, but I'd love to see it.
I'm back to my usual VSCode setup now for .NET/C# work, but there even though I have more than 50 extensions, they are all enabled on per-project basis so the experience is pretty light. I still have to boot up VS/Rider from time to time, but it won't be my first choice.
F# is a great language, but it somewhat waters down its strengths to bolt it to a giant hulking lump of C++ full of mutable state. Interacting with an impure api means throwing out many of the advantages of (mostly) pure programming.
There's one area where Nim is better than most alternatives, especially those with a separate required runtime, and that is binary size. I write quick scripts and daemons with Nim, knowing that they won't take up space on my disk or in RAM.
Stupid question of the week that came to me after reading this: is there any language that compiles to dot net intermediate language, so it runs on do net like C# but with a different syntax like Nim? There are advantages and disadvantages, I am just curious if anyone wanted to go this way.
Comments
C# is an excellent language with an great ecosystem and lots of jobs available. Also, if you ever want to go a bit more functional, F# is excellent.
My personal reason for avoiding it is purely political: I don't trust Microsoft. I try to not rely on languages that are controlled by a single monopolistic corporations. Considering the recent case of the golang compiler planning on getting telemetry, I feel validated in that decision.
As for game development, I think the game engine of choice will already dictate what one should learn.
Unity is still king of casual and mobile games, so if that is your niche, learning C# is a no-brainer. Plus Godot has decent C# support now, if you ever need to change horses.
As for more complex 3d games, Unreal 5 is just insanely good. Nanite and Lumen offer tremendous improvements in both development experience and end result. Here learning some C++ is advised but funny enough, there are actually Nim bindings as well. If you don't mind getting into somewhat untested waters, Nim might be a very good choice here.
Not trying to change your politics. People hate Microsoft for many reasons.
C# has an ECMA standard (334).
I.E. it has a public specification.
Some versions also have an ISO Standard.
https://www.ecma-international.org/publications-and-standard...
Only languages or frameworks too? Because there aren't many which aren't controlled by a single entity. Sometimes it is just not that obvious.
When those corporations not put the money into the work, even free beer C and C++ compilers suffer, see clang current state of ISO support.
Is this for certain? I thought this was still in the discussion phase.
I should have phrased that as "planning to".
After the significant push-back it seems like are considering doing only opt-in telemetry[1] which would be acceptable.
So not that bad for now but who knows. Once telemetry is in place, they might try to change it to opt-out at a later date when less push-back is expected. Still setting a problematic precedent and shows why corporate control about a programming language might become problematic.
[1] https://research.swtch.com/telemetry-opt-in
There are literally millions of professional developers using C#. Any problem you run into has a solution documented online.
Languages like Nim are a good choice for developers who need the adrenaline rush of dealing with complicated problems alone.
One problem with the c#/dotnet ecosystem is there are too many answers online for different versions
c#, records, EF6, EF core, EF7, net4.8, net standard, net core, net6, webforms, blazor, web api, web mvc, razor, identity core, legacy, UI, dotnet cli, visual studio, vscode, nuget, CMD, powershell...
Most of the time the answers are interchangable. There are a few exceptions but then you just look for "Specific problem .Net6" for example.
I bet you I'll love any library in Node.js or the ecosystem itself. That's significantly worse.
What is better, too many options or barely any?
For an experienced c#/.net it is OK, but new developers might get confused and go learn another language
Nim looks very clean. But I am not sure it is ready for complex production work
you listed 3 versions of C# in that list, and they are all as similar as versions of any other language are.
It's more or less true for Java... but in my experience, less true for c#.
Damn, didn't know C# can solve the halting problem.
Of course it can, this simple feature has been in Visual Studio Enterprise for more than a year.
Interesting take.. I could share some codeGolf languages that you might like to play with in that case!
That said there are a few fallacies in the comments also that bother me a bit. Specifically the assumption that 'once its closer to C its automatically more performant.'
Wild comments too like : `Nim runs on many more platforms than C#`
Without being specific this claim is just weird..
So you need to be an expert to benchmark it.. Red flag.
I didn't get why fewer lines of code is better. I don't choose rust because its "shorter", far from it, if anything I choose rust because its very verbose with its syntax, but that syntax conveys a lot of information.
Another comment in the above thread mentioned that "c-like performance is easily reachable with c2nim, or inline assembly" well then thats not really the performance of nim is it, thats the performance of assembly ...
This is a pretty dumb/blunt justification, but there is _some_ truth to it: The number of bugs in a program correlates roughly to the number of lines in that program, irrespective of language. Ergo, if some language lets you accomplish your goal in 30% fewer lines, you will have 30% fewer bugs.
The huge caveats are at a minimum that you're writing the code idiomatically (ie not putting your entire program on a single line), that it also strongly depends on developer proficiency with the language (likely lower for a newer language like nim), whether the problem you're solving is well understood, etc
There is a lot of data showing less lines of codes correlates with less bugs. I don't know if that works cross languages, like a language that requires annotations to help ensure correctness requires more lines thus does it correlate with fewer bugs than python? don't know.
but nim and C# have similar levels of safety
There have been a few studies showing that bugs-per-line-of-code is pretty consistent from language to language. So, if you can reduce the number of lines needed, you reduce the number of bugs.
There are also surely diminishing returns
I'd bet rust is an outlier in that, a lot of languages require more code to do the same things, as a result of being simpler langs (lua). a lot of langs are very easy to shoot yourself with, more lines means more oppurtinity to shoot yourself.
In rust though, that 30 line python script probably takes 45 lines to write now. But those 15 lines aren't wasted or because of longer logic, rather those lines are used to convey type information
its not "more lines = more bugs" as it is "most languages don't put more lines to good use"
I would find it easier to believe if 1. there was a sample, 2. you claimed that the extra 15 lines are just {} indentation. Btw here is the same build script in nim https://github.com/planetis-m/raylib-game-template/blob/mast... and in python https://gist.github.com/planetis-m/a437db724185215910a59c3b3... Which is shorter/more readable?
Note I could have used f-strings for both, I just don't like how they are rendered in my editor.
Correlation is not causation.
E.g. more cells means more cancer per 100k cells, right? Incorrect. Different species have different rates of cancer.
Not an expert, but your comparisons need to be apples-to-apples. An expert-tuned C# impl v a naive Nim impl isn't a good benchmark.
If I'm benchmarking (not perf testing) a language with some nuances I'm not too familiar with, I would stick some simple implementations of core workings. If those simple tasks are `supposed` to be done a `special` way, then I'm already not interested.
Why should I need to learn semi-workarounds just to achieve the basics.
How many algorithms don't benefit from optimisations you think?
Of course, but this is not the point of a benchmark test though - Mainly because as above you want that Apples to Apples comparison.
I think I might not have explained my position too well.
You can write fast or slow code in any language, typically people who understand the language very well are the ones who can write performant code, regardless of language. All those benchmark games out there for dozens of languages are proof of that.
I currently use C# for most of my work. I would love to use Nim, as I like its design, its simplicity, its performance and the fact that it doesn't enforce OOP, but here are the problems:
-not enough libraries
-not enough frameworks
-not enough support
Classic chicken and egg
Also known as Crossing the Chasm: https://bootcamp.uxdesign.cc/book-summary-crossing-the-chasm...
above 3 boils down to - not enough enterprise backing
Does Nim really have no competition in the meta programming space? I assumed Haskell would do well there?
Also zig, meta programming is one of its key features from what I understand.
D too. D templates are dangerously easy to use.
Why dangerous?
Template metaprogramming facilities have a reputation for being a very powerful tool if used judiciously. If overused, they can lead to over-complexity though. And a template system that is as easy to use as D's might encourage overuse.
Presumably you're only asking about statically typed languages, right? Otherwise Julia, and every Lisp come to mind. Especially compared to Lisp all other languages are inferior when it comes to meta programming.
ruby is notorious/famous for monkeypatching everything and the simplicity of creating DSLs
swift and kotlin are slowly getting there.
My main reason for using C# is that's it's nice enough but Visual Studio feels amazing.
I have the opposite stance. Visual Studio is my primary dislike in working with C#. It's mighty, I'll give it that. The debugging experience is strong. But it's slow, sluggish, components or itself crash sporadically; the extension ecosystem isn't great.
Working with containers/docker is a bit painful, too: as with all things Microsoft, there are layers of indirection to just make it work™. While it does, it's wonderful. Almost inevitably however, one runs into edge cases that are impossible to solve, because the config you need hasn't been surfaced to the GUI. That's where I prefer more 'hackable' IDEs like VSCode. In these situations, it might just allow you to drop a line of bash into some JSON config. Simple and works, no GUI work from the devs required.
One my of favorite pet peeves is running unit tests in parallel from inside VS, using the GUI/shortcuts. The setting for running unit tests in parallel is a nested setting, only accessible via GUI. Running unit tests in sequence is incredibly slow in our case (and when would you ever want unit tests _not_ run in parallel?). The setting is then stored somewhere in the `.vs/` directory, in _binary files_. You cannot version control them, and `git clean` regularly knocks that directory out, wiping the setting. Annoying, but not annoying enough to do anything about!
I agree with you around VS and I use it all the time. The problem is that Rider for example is the same. I've had the chance to do a project with Rider recently and I have to say performance-wise both VS and Rider are just slow and prone to crashes and random errors. It's true they offer immense power. Debugging and profiling is unmatched in both IDEs. However, what I'd like is a more modular approach in both of them where I can disable certain things to take a load off the dev experience. I'm not sure if their architecture would allow for such a change, but I'd love to see it.
I'm back to my usual VSCode setup now for .NET/C# work, but there even though I have more than 50 extensions, they are all enabled on per-project basis so the experience is pretty light. I still have to boot up VS/Rider from time to time, but it won't be my first choice.
For game dev? Use C#. It’s got all the bindings to the engines and other such things you’ll need.
You can use F#, but this implores that we get more engines if all they are compatible with is Microsoft .NET.
F# is a great language, but it somewhat waters down its strengths to bolt it to a giant hulking lump of C++ full of mutable state. Interacting with an impure api means throwing out many of the advantages of (mostly) pure programming.
And even then, don't forget that from .NET team's point of view, F# is a community language that gets to be on .NET SDK.
There's one area where Nim is better than most alternatives, especially those with a separate required runtime, and that is binary size. I write quick scripts and daemons with Nim, knowing that they won't take up space on my disk or in RAM.
(in Nim presumably)
Can anyone say why?
I didn't realize you can mix Nim an Assembler like this:
https://github.com/mratsim/constantine/blob/1cb6c3d/constant...
Stupid question of the week that came to me after reading this: is there any language that compiles to dot net intermediate language, so it runs on do net like C# but with a different syntax like Nim? There are advantages and disadvantages, I am just curious if anyone wanted to go this way.
Take a look at F#
F# is also Microsoft, is it? I am thinking about third parties that want to use the dot net ecosystem with their own languages.
F#?
Also, this might be an interesting read: https://mode80.github.io/7-langs-in-12-months.html