#OOP in rust argument

36 messages · Page 1 of 1 (latest)

nocturne sparrow
#

let's move here

quaint ospreyBOT
sour jackal
#

traits are fine, ok? Just don't use them to emulate OOP (inheritance).

earnest coral
#

Yet a lot of libraries do that rustOk

#

That's exactly my problem

#

Why I even bothered about it

sand kernel
#

oop = more human centric way of thinking about things. Code is made for humans otherwise just use an AI to optimise it

heady gull
#

I think, possibly, this opinion that traits are often used to mimic OOP might come from a misinterpretation of the fundamental role of traits in rust. If you've never used traits with generics in rust, then you've not seen what I'm fairly confident is their primary motivating use case

#

And so you instead see, "oh, it is an interface" or "oh, it inherited these methods" without seeing how these are surface-level judgements hiding the depth of expressivity traits bring

acoustic crystal
#

I like to see Rust as better and more modern C - but with all of it's freedom in what you are doing

Rust has all of the freedoms of C (most of them, ignore SB and friends, but also more, thanks to no type based strict aliasing), it's just that those freedoms are usually gated because they are very dangerous and you rarely need them. But if you do, they are available. Not having all the freedom by default is good.

heady gull
#

Something possibly useful to consider is the several distinct meanings of freedom.
One is a negative freedom. Freedom from. Eg, freedom from constraints and limitations, or freedom from compile-time checks, or freedom from runtime errors.
One is a positive freedom. Freedom to. Eg freedom to combine things, freedom to express constraints and requirements, freedom to share access to data, freedom to call any method on any type.
Both sides give a different set of perspectives. And within each, there are conflicting freedoms.

#

Some freedoms that rust provides and removes:

  • freedom to express constraints and requirements (removing your freedom from constraints)
  • freedom from many classes of runtime error (by removing your freedom from compile-time checks)
#

Worded differently: by removing some of your freedom in one area (eg freedom to compile and run arbitrary incomplete or unsafe code), you are gaining freedom in another (eg freedom from entire classes of runtime errors)

acoustic crystal
#

freedom from having to think about the safety of safety code

ornate crow
#

You could argue that ownership is human-centric, for example, because the concept exists in the real world

acoustic crystal
#

rust is very human centric because just like in the human world, undefined behavior gets eliminated by an angry wyvern

frosty wasp
#

I think the main point was that when thinking in objects, it's extremely easy to split functionality wrong at the start, and when you get further into the project and start needing to change things, it either becomes a horrible mess or is very difficult to refactor

frosty wasp
heady gull
# frosty wasp I think the main point was that when thinking in objects, it's extremely easy to...

I like traits (compared to OO) as a solution to that, because with traits, not needing to worry about splitting your behaviour by inheritance hierarchies, and not needing to make something inheritable whenever you define new behaviour, means you have more freedom to just (eg) make a single-method trait when you need to use some behaviour in a generic context, or add behaviour to a foreign type, which is very easy to refactor later if you need to change it

ivory raven
#

oop cool

summer monolith
#

@earnest coral To be fair, I don't think rust is that great a fit for your problem or the way you work which is perfectly fine. I recommended V in the other thread because that stripped-down, as close to the metal thinking as possible seems like it would be really great for embedded in general and for you specifically. A language that operates exactly as the computer "thinks" rust is not: it is riddled with abstractions and syntactic sugar that is quite removed from as much. Rust is good for someone like myself: I've reasonable expertise in my problem domain and use case, but have little interest (as of yet, at least) in fashioning close to the metal optimizations ore reasoning about my work in that way. It doesn't help me very much at all, and would actually prove a hinderance most likely. Accepting this allows me to lean on compiler-magic features like the trait system or all the list comprehensions which are involved in roughly 90% of what I'm doing day to day - by that I mean it would not be possible for me to elegantly and safely express my intent without them. At the same time, if what you want is a better C/low level Go, V, checked C, zig etc are all better for you and some are quite safe. Rust just isn't the language for you, the community isn't looking for a better C per se, and efforts to steer the language into that abstraction-free direction just aren't going to be received well as it is functionally the antithesis of rust's mission as a language: to drag userland dopes like myself down to low level.

earnest coral
summer monolith
#

Of course 😊

ornate crow
#

-v

shy thunderBOT
#

The developers of the V programming language have been accused of false promises and poor design decisions. For an overview valid from June 2019 to December 2020, see https://christine.website/blog/series/v.

summer monolith
#

I've no personal experience with the language nor am committed to it, also why I recommended a look at the couple of alternatives listed. Just an example 🙂

acoustic crystal
earnest coral
acoustic crystal
#

you'll get used to it well

earnest coral
native coral
#

I've watched it several times before

sour jackal
#

Funnily enough, that video is fine with a little OOP, just not as the one way to do things.
He's fine with using objects when it's an obvious abstraction (eg: a queue class).