In my experience, there's no such thing as cpp ecosystem...
What there are, are many little ecosystems that revolve around various subsets of the giant language called C++. And they tend to range from quite fun to use to living nightmares/walking zombies...
For eg, if you just stick to Qt/C++/QML ecosystem for making GUI/Embedded apps, the libraries are quite good, the developer tooling is quite nice, you never even leave your IDE. Infact it is nicer than what Rust has to offer for GUI today. However, if you want to make webapps/services with C++, my experience has been death by thousand cuts. I have heard similar stories from developers coming from Windows/VC++. For a lot of them, cross platform portability isn't a thing to worry about. A lot of them just store compiled dlls and header files of their dependencies in their repos etc...
That’s a silly conclusion to draw. Plenty of high profile, well-known, expert C++ developers have made similar recommendations in recent years and are even working on alternate languages.
Totally agree, my comment certainly was provocative but OP mentioned that he "still want to learn it anyway because so much stuff is built with c++ and also because i just want to" after he got discouraged to learn C++. And I think with that in mind he should just start learning C++ and make his own experience with the language.
As a young lisp-weenie I have done my fair share of C++ bashing that I now regret so maybe it is just the arrogance of youth but still I kind of feel sad about the toxic attitudes in certain system programming languages communities (looking at you Rust) against the "competition".
If nothing else, C++ is worth a look for its excellent libraries that will not be replaced anytime soon.
It is great to see that the Nim community is more pragmatic and level-headed.
> 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.
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.
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.
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 ...
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"
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.
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.
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.
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:
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.
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.
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.
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.
70 comments
[ 4.7 ms ] story [ 67.7 ms ] threadLanguages 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
CPP ecosystem is far from being sane in compare to e.g Rust.
You change company and you have to relearn all boring tools
And until it gets bootstrapped, it will have a dependency on C++ compiler infrastructure.
For eg, if you just stick to Qt/C++/QML ecosystem for making GUI/Embedded apps, the libraries are quite good, the developer tooling is quite nice, you never even leave your IDE. Infact it is nicer than what Rust has to offer for GUI today. However, if you want to make webapps/services with C++, my experience has been death by thousand cuts. I have heard similar stories from developers coming from Windows/VC++. For a lot of them, cross platform portability isn't a thing to worry about. A lot of them just store compiled dlls and header files of their dependencies in their repos etc...
allthough... i can see reasons to avoid c++ in favour of other (systems) plangs but ultimately you will use whatever the team uses :D
If nothing else, C++ is worth a look for its excellent libraries that will not be replaced anytime soon.
It is great to see that the Nim community is more pragmatic and level-headed.
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.
Why should I need to learn semi-workarounds just to achieve the basics.
I think I might not have explained my position too well.
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 ...
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"
Note I could have used f-strings for both, I just don't like how they are rendered in my editor.
E.g. more cells means more cancer per 100k cells, right? Incorrect. Different species have different rates of cancer.
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
-not enough libraries
-not enough frameworks
-not enough support
https://github.com/mratsim/constantine/blob/1cb6c3d/constant...
(in Nim presumably)
Can anyone say why?
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.
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.
[1] https://research.swtch.com/telemetry-opt-in
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.
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.