> Instead of a trait, just make a type that implements the generic behavior you want, and then write a function to convert your data-type into your trait-type

> Instead of a trait, just make a type that implements the generic behavior you want, and then write a function to convert your data-type into your trait-type Well, yeah, obviously, when you have a single implementation of a trait/interface, then you can do away with this additional indirection, sure. But what if I have vastly different types implementing the same trait and I want to collect them all in a single list? > If you need some data-type specific logic, then pass around functions as necessary (usually from your conversion function). That... basically amounts to manually bundling values of the concrete type together with the implementation of trait and then passing them around together (also manually), isn't it? I mean, on one hand I get the message: you don't really need any fancy type systems, having integers and bytes and arrays of integers and arrays of bytes for types, ability to declare constants, global and local variables, and functions (not closures) is quite enough already to implement anything. Structs then can be emulated either as short integer arrays of fixed lengths, or with SoA approach: all enums are just integers, and pointers are also but an integer index in some globally known array so yeah, there is nothing much else you need to store in a struct's field. But let me tell you, programming this way is not very pleasant if you've spent majority of your life writing Python or Haskell. Having common patterns of data and code organization baked straight into the language is nice.