in rust I can add some functions to, say, an array / vector of specific types

specifically, I want to add a function to draw a chart on an array of some time and values

but I can only do this if I make a trait / interface first, and add the trait / interface to the array-type thingy

which is strange to me
why can't I just implement it without the trait?
it just doesn't want you to be able to add functions to a data type you didn't make

I mean I think it's cool I can just add functions to random data types will-nilly like this
but why must I define a stupid trait
I'm not going to be using generics over that trait anyway 🤷
and yet, I must make the trait...

  • 1
    can you not just make a function that takes the array as a parameter orrr?...
    (Don't know rust, genuine question)
  • 0
    @SoldierOfCode you can, but it will bite you right back later on
  • 0
  • 0
    @SoldierOfCode it's like typescript in that if you don't "class" it, the language complains even if your code is solid
  • 1
    Reason is pretty straightforward:
    It's for consistency and maintainability.

    Sounds a bit ass backwards, but get this:

    You now implement it for a regular array of Type T etc.

    You think, nice good enough.

    Then you realize that, you probably want to have this for a slice aswell. Different impl, same functionality.
    What about a vec? or a ref to a vec? An iterator?

    What if you now realize you need a function that would take any of these, no matter what it is by (you guessed it) trait? Everything's already set up, and you don't need to go through the pain of rewriting everything and adjusting all the (potentially slightly different) functions to do the same thing.

    I agree it feels slightly weird, but it makes a ton of sense long term.
  • 5
    @thebiochemic hmm, interesting. That's also what we generaly call "over-engineering" when you make your code super re-usable and generic, took you more time, is less readable, harder to debug, yet in the end you really just ended up using it once for one type in one or two places.

    I used rust briefly and I liked it, though this is the first time I hear about this philosophy and not sure what I think about this "preventive over-engineering" idea that it proposes
  • 1
    @Hazarth Fair.

    The issue is, when your software is growing and changing, so are your problems. And you want to be prepared. In the realworld stuff gets extended and adapted all the time.

    For some small program, that only does one tiny task and nothing more (where it's probably easier to rewrite it anyways), you would not use this pattern or use something different altogether like python, since like you said, it would be "over-engineering". In every other scenario (like backwards-compatability of libraries for example), only this is appropriate to keep the API consistent.

    As others have stated, you don't need to do it that way, and can just go with a simple function that takes the array as a parameter (as in most other languages).

    Or create (or probably just use an existing) Macro, which is getting optimized away anyways (As you probably would in C/C++ too).
  • 2
    @SoldierOfCode yeah I just made a random function in the end

    idk man I haven't grown all the way into rust yet to know how I prefer to organize things

    *fumes, confuses self, struggles with systems*

    I do wanna explore more of the rust-specific things though so I know where I can get use out of them, reeee!
  • 0
    @jestdotty oh yeah to be fair, working with floats in rust is kinda a pain, so i agree haha 😂
Add Comment