This is not true, if the programmer cares, it can be compiled to native.
In case of not compiling a native, C# is executed in a context that to call it virtual machine is excessive.
The processors are multicore. I currently see it easier to take advantage of several processors with powerful tools, C # has them
It really seems like you're getting hanged up on silly things. I'm not 100% sure what you're talking about though.
Your JS example in Nim:
import json
var example = %*{
"name": "Victor", "value": 10
}
example["newvalor"] = %"hi"
It's not difficult.
Nim is almost competitive with the expressiveness of dynamic languages like Python despite being a compiled language. I'll bet that it can do everything C# can and perhaps more.
You will also do better if you start your questions with "how to do xyz in Nim" than saying "C# can do it but Nim doesn't look like it can".
var example={name:”Victor”, value: 10} var property=”Color”
example[property]=”Red”
// example is {name:”victor”, value:10, Color: “Red”}
The type of example{"Victor", 10} is not the same as the example{"Victor", 10. "Red"} I know JS is dynamically typed and allows stupid things but I'd actually be disappointed if C# allows it. (Then again, C# sucks too).
Any sane programmer would create a class that inherits from typeof example and has an extra field called color instead of shadowing the previous variable. That's what I would do back when I was using C# back in .NET 3.5 days. On top of that Nim also lets you create an object variant. It's not rocket science.
Even disregarding Nim, I see no reason for C# to exist, other than the fact that you want to stay within the false walled garden of Microsoft vendor lock-in. C# is bland, underwhelming, slow, verbose, massively-overrated pile of garbage that thinks it's "a better Java" while being no where near as portable than Java. You might as well be using modern C++ and actually come up with useable, portable applications with better performance for what it's worth.
C# is functional
No, LinQ doesn't mean C# is functional. It's an overrated library used to give you a glimpse of declarative programming. And it has some major issues. https://blog.ielliott.io/why-LINQ-is-broken/
Sorry for that rant, C# gives me PTSD, I hate it more than I like Nim. It has nothing to do with OP.
My phrase "I met a Nim by Godot Engine. I met Godot by C# The object of the present thread is not war, of truth. Thanks for the answers"
It is easy to see that there is no destructive intention
I write with C ++ simple calculations and loops, the same in JavaScript and the performance of C ++ is only 2.5X on JavaScript in the latest version of V8 (Chrome engine). Chrome and now Firefox compile JavaScript very well.
The performance of .NET Core is somewhat better than what is said on the page.
Despite everything the page says with its nuances is true. So I think you're right.
"What you are suffering from is familiarity bias. You have a bias towards something that you are familiar with. This is normal."
Yes, the same thing happened to me when I went from Assembly and Visual Basic to C #
The same thing happened to me when I went to JavaScript.
There is a time of adaptation
"C # is really a good language and the CLR is a good VM"
In this I differ, it can be compiled directly, there are examples of this. The one that has windows can see it for example paint.net compiles the code of the machine
In Net Core it is not correct to call it VM. This is a mistake
Thanks for the answers. What matters to me now is that I'm seeing what can be in Nim as well as in other languages, with the advantages of speed and simplicity, which is a matter of learning Nim.
We have to regret that Nim is very unknown, it is not hostility on my part.
I did not even want to start studying Nim if I did not have the certainty that I could be useful.
When I learn a bit about Nim, I'll come back here.
Thank you all
Wow guys, you are overreacting.
My opinion is that C# is very powerful in object-orientation, far powerful than Nim. However I think that OO is a flawed paradigm in many cases.
When you have a hammer everything looks like a nail
This is a very interesting rant about OO
Now regarding your cases.
Case 1, use proc overloading
type
A = object
B = object
C = object
ABC = A or B or C
proc hello(input: ABC) = echo "hello"
Regarding your second example.
This is a JS dictionary/map, the way to do it in Nim is via the tables module or critbit trees (for strings it's more efficient) if values have all the same type (Nim is statically compiled afterall), or like @dom96, use the JSON module for variant types.
Just for completeness sake:
# EXAMPLE A
type
A = ref object of RootRef
B = ref object of A
C = ref object of A
method hello*(a: A): int {.base.} = 1
method hello*(b: B, param: RootRef): int {.base.} = 2
method hello*(c: C): int = 3
var
a = A()
b = B()
c = C()
echo b.hello(nil)
echo c.hello()
a = b
echo a.hello()
a = c
echo a.hello()
Apart from the performance comparisons (which can always turn out either way, C# is not a slug) the real differences are in the completely different designs. C# tends to follow language trends, start with OO, then add more FP, then add more sugar.
Nim doesn't follow trends as much, Nim is about a macro system that give you DSLs so that code can be compressed and adapt to the problem domain. This forum here is written in Nim, the frontend uses a DSL to describe the HTML trees called Karax, the backend a DSL for HTTP requests called Jester and ideally the SQL queries would also be produced by a DSL like Ormin (but as of now, Ormin is not considered stable enough for this task). That's a complete different approach to build software than what C# offers, even if you compile C# to native code and to JavaScript.
@victor_js I just wanted to say welcome! We're excited you're here. I'm happy that you decided Nim is worth learning! It really is a very cool language.
Some features of C# will be different in Nim. It's always ok to ask questions. If you need help, let us know.
As other people have shown, we have a solution for these issues :)
Nim is a bit unconventional. Object Oriented Programming is a well known model, and C# uses it a lot. In Nim, you use object instead of class. Nim has a keyword called method that can be used to have polymorphism like you have in C#. Nim developers do not use object orientation as much as C# developers. However, Nim is still very powerful. As you code in Nim more, I think you might feel more comfortable with the design. :)
You said that you didn't like that Go doesn't have generic types. Luckily, Nim has full generics! That is a major difference between Go and Nim culture. We love generic programming here at Nim. We love reusing our code! The Table I suggested is an example of a generic type.
Finally, I wanted to show a way to do dynamic dispatch in Nim. As I said, one way is to use method. For an example of that, see Arrrrrrrrr's answer.
There is another way to do it: instead of having per-class polymorphism, have per-instance polymorphism. It is a different way of thinking, and it isn't always the most efficient, but it's super flexible. You could use this to implement signals, for example. Here's your example:
type
# This is an object.
# In Nim objects are closest
# to classes in C#. The object
# is called Dynamic.
Dynamic = object of RootObj
# This is a closure. It can be
# used to get dynamic behavior!
helloProc: proc(self: Dynamic)
# These are functions. In Nim,
# we usually call functions
# procedures. In C# and Java
# they are called methods.
# The base hello method for Dynamic.
# Other constructors could
# override it.
proc helloA(self: Dynamic) =
echo 1
# This procedure could override
# helloA.
proc helloB(self: Dynamic) =
echo 2
# This is another procedure
# that could be used to override
# helloA.
proc helloC(self: Dynamic) =
echo 3
# This procedure is our
# base class constructor.
proc initDynamicA(): Dynamic =
# We pick an implementation of
# hello **at runtime** :)
result = Dynamic(helloProc: helloA)
# This is another constructor.
# **It produces an object
# with different behavior**
proc initDynamicB(): Dynamic =
# We choose a different
# implementation this time.
result = Dynamic(helloProc: helloB)
# This is the third constructor.
# It creates a new object with
# behavior C.
proc initDynamicC(): Dynamic =
# The implementation proc is
# helloC for this constructor.
result = Dynamic(helloProc: helloC)
# This procedure is just convenient.
# It calls the closure.
proc hello(self: Dynamic) =
self.helloProc(self)
# This is the beginning of #
# our main program. #
# We want an Dynamic instance.
# It could have any behavior:
# A (the base behavior), B, or C.
var objectA = initDynamicA()
# Let's see what the base class
# does by itself.
objectA.hello() # outputs "1"
# Let's assign a new behavior to
# the object. It will still be
# of type Dynamic, but it can
# do something more than the base
# class.
var objectB = initDynamicB()
objectB.hello() # outputs "2"
objectA = objectB # objectA now has "C" behavior
objectA.hello() # TADA: outputs "2"
# So we can change the behavior
# that a Dynamic has. This is
# different from C#, because
# it happens per instance and
# uses a closure.
# It's still polymorphic though.
# Let's assign a "C" Dynamic to our
# objectA and see what happens.
var objectC = initDynamicC()
objectC.hello() # outputs "3" as expected
objectA = objectC # assign objectA "C" behavior
objectA.hello() # works: outputs "3"
This is indeed different from C#, it works more like JavaScript. For a more C# solution, use @Arrrrrrrrr's example with method.
Wow, this has been really long! I hope I helped get you started with and excited about Nim. We're always happy to have you here. Cheers :)
C# Array Vs. List
An Array (System.Array) is fixed in size once it is allocated. You can't add items to it or remove items from it. Also, all the elements must be the same type. As a result, it is type safe, and is also the most efficient of the three, both in terms of memory and performance.
Use c# array when you are dealing with data that is:
fixed in size, or unlikely to grow much suitably large (more than 10, 50, 100 elements, depending on the algorithm) you will be doing lots of indexing into it, i.e. you know you will often want the third element, or the fifth, or whatever.
A List<> leverages generics; it is essentially a type-safe version of ArrayList. This means there is no boxing or unboxing (which improves performance) and if you attempt to add an item of the wrong type it'll generate a compile-time error.
Use a c# list for:
variable length data lists that are mostly used as a stack or a queue or need to be iterated in its entirety when you do not want to write an expression to derive the ultimate array size for the declaration and you do not want to wastefully pick a large number
Although this thread is rather old I'll answer anyway because certain attitudes and questions come up again and again. It might be useful to have something to link to instead of saying it again and again.
Front-up: My first gut reaction to the OP was "Oh well, if he likes C# so much, why doesn't he just stick to it and be done". In other words: We are not salesmen, we love Nim and we are certainly happy if new users join but we are not salesmen. If you feel that language XYZ is so much better than Nim then simply stick to it. Simple as that. In fact, you might be perfectly right in thinking that XYZ is better than Nim - for you.
There simply is no best language. A language may be the right thing for many users and a broad spectrum of problems but no language is generally the best.
In my case (brutally compressed: reliable and safe software) I used Ada for quite some years and was almost quite happy. In fact I've said a lot of good things about Ada (and still do). But there were those "buts". Nim addresses those. Well noted, Nim is not "better than Ada". It just happens to offer a better trade-off for me. At least as of today Ada is (still) better in certain aspects but those are largely about "paranoid safety levels" (like real formal verifiability) and some things like much,much better docu (well, existing for decades that's not astonishing).
I usually do not need those "paranoid safety levels". Software is almost never unsafe or insecure because AES-128 was used instead of AES-256 or because it breaks after having ca. 2 billion users (due to signed int32), etc. Nope, stuff breaks due to factors like creepily lousy code, utterly lacking design (and care), pressure by management demanding features, features, features, and inept languages (often (ab)used by inept developers).
Nim addresses those issues to a large degree. And - that's very important - it makes it easy, natural, and comfortable for the developer to write considerably less buggy code. And by "considerably" I mean something in the range of 80% to 95% less bugs. In other words: Creating something like Heartbleed (SSL) was almost inevitable with the C code base. Creating Heartbleed using Nim would need a serious level of carelessness or ill will.
Two other points that are relevant for quite many are:
Nim runs on quite many architectures and OSs. Unlike C# whose non-Windows support were ugly siblings and afterthoughts Nim wasn't designed for any particular architecture or OS.
Nim offers the full feature set that is needed for many applications today. Support for both multithreading and async/await as well as for immutable variables come to mind as well as many (seemingly or factually) smaller things like defer or a really, really nice C interface or the fact that one can target javascript (and end up with something that is not crappy).