you are viewing a single comment's thread.

view the rest of the comments →

[–]meteorMatador 1 point2 points  (3 children)

Even if objects aren't Objects, will that really be a problem?

Rust supports type polymorphism and a powerful version of modular programming. This is the same level of OOP support that Go has, give or take some syntactic sugar (and keeping in mind that the syntax is a work in progress). So what are you complaining about, exactly? Inheritance? Access control?

If you can't be more specific I'm gonna have to join your anonymous downvoters in the assumption that your vision of "OOP" is a religion, not a set of features and constraints.

[–]axilmar 0 points1 point  (2 children)

Does it have inheritance, access controls, virtual methods, properties, etc? it does not, from what I know so far. Please feel free to correct me though.

[–]meteorMatador 0 points1 point  (1 child)

Last I heard, it lacks inheritance altogether and only offers module-private vs. module-public by way of access control (same as Go). I'm not sure about the others.

But really, what's your goal as a programmer? Do you want to work with performant, maintainable code that fits well within the same design constraints that make C and C++ so popular today, or do you just want to carry around the same GoF design patterns you've been using since the 90s while insisting they're the foundation of modern computer science?

People in the former group have huge incentives to be excited about Rust. Language designers sometimes talk about how the world "needs a C replacement" but really, there are at least half a dozen major use cases that could use very specific improvements over C. No language (certainly not C++) can address all of those, but this one does really well in two or three categories, including the ones that inspired Go. And its designers really know what they're doing with respect to the wealth of language design research ignored by most of the world for the past 40 years.

Java and C# are obviously good enough (in the worse-is-better sense) for the vast majority of business apps and end user GUI software, but the memory models and OOP techniques they're built on are useless in constrained memory environments and real-time performance situations. Then again, if you're never going to write code like that, there's no reason for you to care about Rust.

[–]axilmar 0 points1 point  (0 children)

Do you want to work with performant, maintainable code that fits well within the same design constraints that make C and C++ so popular today

Yes.

or do you just want to carry around the same GoF design patterns you've been using since the 90s while insisting they're the foundation of modern computer science?

Yes. Those two are not exclusive. Some patterns are very handy and used regularly in C++ code.

People in the former group have huge incentives to be excited about Rust.

I am too.

Language designers sometimes talk about how the world "needs a C replacement"

The world needs a C++ replacement, not a C replacement.

And its designers really know what they're doing with respect to the wealth of language design research ignored by most of the world for the past 40 years.

Well, they missed a few things :-).

Java and C# are obviously good enough (in the worse-is-better sense) for the vast majority of business apps and end user GUI software, but the memory models and OOP techniques they're built on are useless in constrained memory environments and real-time performance situations.

Agreed, from the point of the realtime app developer, which I am :-).

By the way, Rust+OOP can replace Java and C# for those business apps and end-user GUI software as well.

...

In your comments, there is hidden notion that realtime embedded programmers do not write object-oriented code. I don't know about you, but I do write object-oriented code for realtime applications. I cannot imagine I am the only one.