Can you explain please why is that ? btw I'm coming from a JS/Node background, but I worked with C and C++ before (mainly school projects, nothing serious).
Go is not an OOP language, you get the dot notation on structs and that's pretty much it.
Rust is all about advanced OOP and very fussy static type checking.
That said, IMHO, Go to me feels more like a replacement for Node more than a replacement for C.
I saw a few examples of Rust code with a good amount of generics sprinkled in and given what (seemed to me) the parent comment was suggesting, I assumed that was the case.
That said, I remember reading in the docs about many usually OOP related concepts like RAII, boxing/unboxing, operator overloading, the aforementioned generics.
You mostly don't care about these things in Go. Can we agree that Rust is a bit more OOP oriented than Go at least?
- Parametric polymorpism isn't OOP, pretty much every halfway-decent language has it (including Haskell, which is as functional as they come).
- Boxing in Rust isn't what you think it is - it's just heap allocation (more like malloc than the monstrosity that is boxing in Java).
- Again, operator overloading isn't OOP either. Seriously, is it that hard to believe that "you get to use + and - with your own types" is an expectation independent of any paradigm?
> I must have gotten the wrong idea.
Yes. Go and Rust are both very far from what most people would consider "OOP".
Funcional can be considered an alternative vs imperative and declarative, and usually languages are a mix of the three. And any of these 3 style can support OOP.
BTW, plenty of half-decent languages don't have generics.
If you don't know, please don't muddy the waters.
Except the first release of node was May 2009 and the first announcement of golang November 2009. Node was also first showcased in November 2009.
So for me golang cannot be seen as a replacement for node just from chronological order. Also their design goals at the time seems very different.
That, at least for me, feels not as much the "obvious" choice for C programs.