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.
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 ...
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
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
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"
E.g. more cells means more cancer per 100k cells, right? Incorrect. Different species have different rates of cancer.
Why should I need to learn semi-workarounds just to achieve the basics.
Languages like Nim are a good choice for developers who need the adrenaline rush of dealing with complicated problems alone.
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...
Nim looks very clean. But I am not sure it is ready for complex production work
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.
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.
Is this for certain? I thought this was still in the discussion phase.
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.
-not enough libraries
-not enough frameworks
-not enough support
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'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.
(in Nim presumably)
Can anyone say why?
https://github.com/mratsim/constantine/blob/1cb6c3d/constant...
