Rant: Ownership Semantics and Economics

Reply to Jon Blow's Rant: • Rant: Entity systems a...
Email: [e-mail]
GitHub: github.com/gingerBill/Odin
Patreon: / gingerbill
Twitter: / thegingerbill
KZbin: / gingergames

[@gideonunger7284]

i like how when i have my curser in the video there are 3 overlaying yt progress bars on screen.

[@jamesmantooth7364]

As you said, "There are no solutions, only trade-offs". Are there any language trade-offs a person could appreciate, without experiencing a kind of Stockholm Syndrome? Great work. Odin looks great and I like the trade-offs. It reminds me a lot of Zig and Jai.

[@elsolem]

This vid is 5 years old and still relevant and that's so wild

[@AinurEru]

@gingerBill About propagation, the problem that is being targeted is that multiple callers up the stack may want to know that something they assumed would work actually didn't, because they may want to do something different/extra in such cases. Is not about having the source of the problem evade it's responsibility for cleaning up after itself. It should still do that with or without propagating anything (with either exceptions or errors). If it allocated a reasource, and then something wrong happened, it should clean it. But the caller assumes that whatever it was asked to do was completed successfully, unless being told otherwise by some means. And that caller can be multiple levels of calls up the stack. There's no way of avoiding the need for propagation of information of failure. Is the same in any social system with people, say the Army: If a squad failed their mission, multiple levels up the command chain would want to know about it, because that is knowledge that affects their descisions. The remining soldiers of the squad may still be required to "clean up their mess" regardless, that's an orthogonal issue.

[@josephsmith5110]

As far as I can tell, Rust's error handling, in principle, works the same way as Odin's. The '?' operator is just syntactic sugar. A function can only use the '?' operator on an expression Result if the function returns Result with E that has the same type. This means you are still very explicit about where the error can occur and who handles it.

[@GingerGames]

You can do something similar to Rust's system in Odin if you want however. But Odin is not having a bias any way. You can do it any way you want. Multiple results, discriminated unions, error codes, etc. Errors are just values and nothing special.

[@josephsmith5110]

@@GingerGames Yes, but you could also just pass tuples or any other type in Rust. Result is just an enum (which is what Rust calls tagged unions) you could easily declare yourself. The only special thing about Result is the syntactic sugar operator '?'. That's the only biased thing about Result. I am more inclined to agree with your critique of error handling in Zig, because in that language, a function does not even specify the type of the error it returns and you are forced to use special syntax to handle it, as far as I can tell. But in Rust, even with the Result type, it behaves like any other enum and your error is a regular value and could be of any arbitrary type like i32 or ().

[@GingerGames]

@@josephsmith5110 the difference is that Odin supports multiple return values, which is similar to tuples but not as a first class data type. This is because tuples are rarely, if ever, required in practice as a first class data type. But more generally, Rust's error handling is very generic still. Odin allows you to choose whatever is best for the problem at hand. I don't think there needs to be a holistic solution.

[@josephsmith5110]

@@GingerGames On tuples vs. multiple return values, I think I prefer tuples because they are more dynamic. Multiple return values, from my current understanding, are just tuples you have to destructure immediately. Rust also allows you to do errors however you like, but the Result type is a pretty good solution. I was actually quite skeptical of it until I understood that it really did nothing special and nothing you could not implement yourself other than remove some boilerplate for common cases.

[@GingerGames]

@@josephsmith5110 I'll ask, why benefits do tuples bring over a struct? I can literally think of none. Multiple return values are extremely useful, and having them be "self destructing second class tuples" internally means you can do a few cool things with them that tuples cannot do.

[@flamendless]

What's the recommended game framework for practicing and learning Odin? (Aside from sdl2 or raylib if possible)

[@Beefster09]

I think the borrow checker would make more sense if it applied ownership to threads/tasks instead of function scope or struct scope

[@user-sn9dy5sq1q]

I mean... it does, isn't it?

[@AinurEru]

@gingerBill the "problem being solved" here is the same social problem of assigning responsibilities between people that coordinate/collaborate on the same task or set of tasks, so that nobody steps of othere's toes, on the one hand, and on the other no repsonsibility gets left "orphaned" (intentionally or otherwise). Is about ensuring that at any given point in time, there is precicely 1 person/agent responsible of a thing being collaborated on - exactly one, not two, not three and not zero - and about also ensuring that at any given point in time all collaborators are in-sync about who is responsible for what. That is what Rust is trying to solve with the borrow checker, and C++ with RAII. And I agree that "deffer" is a supperior approach to either of those.

[@GingerGames]

From my research. It does appear that the problem is not the idea of responsibility dependencies but the orientation around objects itself. It's technically just a form of OOP but instead of a type hierarchy, it now has a hierarchy of responsibility, and typically a hierarchy of lifetimes too. The problem is that coupling responsibility and lifetimes together causes a lot of problems too. I'll need to do an updated video on the topic.

[@AinurEru]

@@GingerGames Yes, I also think that the coupling of resource allocation with object lifetime is the source of many problem in OOP with the RAII paradigm. But move-semantics is being used outside that coupling - within the lifetime of objects that need to coordinate responsibility. Is not just about lifetime, and so is not just about that problematic coupling. In Rust even long lived objects may transfer ownership across each other, maybe even back and forth - without ever ending their lfetime. Move semantics is often used to acheive the same thing. Is a generic mechanism across any function, not exclussive to constructors, so not exclussive to that lifetime coupling.

[@julkiewicz]

@@AinurEru I am of opinion that ownership, borrowing as a coordination mechanism are completely unrelated to OOP. Ultimately it's the CPU thread that can really own anything or borrow anything. When one talks about an object A owning some of its constituent parts B and C it's really a shorthand for saying "when a CPU thread assumes ownership of object A it'll automatically assume ownership of B and C". That part is optional. You could have a completely procedural programming with no object orientation, a much simpler resource structure and still use the same ownership / borrowing model just fine.

[@AinurEru]

@@julkiewicz Not sure how OOP or CPU Threading got into this - None of them are related : I deliberately avoided any mention of computers at all in that comment, because that's not what this is about. After code is compiled, none of these things exist. Programming languages are tools for more than just converting code into executable instructions, there's an entire social aspect to them embedded in their semantics that serves zero purpose for runtime exectuion and is purely targeting human social interactions - take the 'private' vs. 'public' keywords in many languages as an example - this is a "beurocratization" of the development process, and has it's uses precisely where beurocracy does in human social systems. "Ownership" as such is a human construct, existing in the "social space", not in computers (nor anywhere else for that matter). Same for the notion of "Borrowing" as a human socail organisational tool. So this here is just that - for the purpose of multiple humans coordinating around human responsibilities in a large system - "who owns what responsibility". Since software is written in a human constructed langauge, with formal socially agreed upon semantics, compilers can be used as tools in that social space to enforce human social aggreaments. For example, if a part of a system is the responsibility of a group of developers and not another group, that group "owns" the responsibility of managing that system's memory use and allocation. That is the guiding principle behind "ownership semantics", and "borrow checking" as a tooled extension of that.

[@julkiewicz]

I think this is backwards: people came up with ownership and borrowing first as abstract, mathematical concepts. In fact I think "borrowing" is a more recently coined name. Some brands of smart pointers that are similar have been around in C++ for a very long time. One might not like it because of all the limitations, but it's definitely been around. Then, at some point, someone came up with this neat analogy that uses words that are familiar and make it sound a bit less abstract. So then trying to portray it like this has been inspired by economics seems weird? I mean it isn't, it's an afterthought if anything. My opinion is that if you made a survey of Rust developers and asked them whether they think this is from economics the predominant response would be "whaat??"

[@GingerGames]

I was not making the point that an affine substructural type system (move semantics) comes from economics. I was making the analogy that the structure of a programme like this has similar thought patterns and that there may even be an inverse correlation to people who prefer one system in real life to how they prefer it in their software architecture. The origins of ownership/move semantics is a different thing entirely.

[@xealit]

"They are trying to apply a market idea to programs, when a program is more like a family" - that probably depends on the size of the program? But at the same time, a large scale program probably should be done in Erlang style, i.e. by passing messages between indeed independent agents.

[@xealit]

Exceptions are not so much about handling 1 function call and its result, it's about handling a context where many procedures are done, and each can fail in some different ways because the context can unexpectedly fail. Like when you connect to something over the network, then each line of your code can hit a "network connection failure". It's just practical to concentrate handling of these exceptions in one place, instead of on each line of your code. To throw in a real hardware behavior example, an interrupt is probably a sort of exception in CPUs. You need to make a handler procedure for that. The same with process signals and other _external_ events, where it's not you who "made the mess". It's just an exceptional situation, where an assumption of your program environment broke or changed.

[@ManuelBTC21]

Uhh, quoting Thomas Sowell, I'm a fan already.

[@lilyscarlet2584]

same

[@robrick9361]

14:45 I get that this is an older video but I don't understand how you can speak about something which such confidence and be completely wrong. What you just described is how C++ worked before C++11. This meant that if you created a heavy object like std::vector in a function and returned it you would have to make a copy and hope the compiler did the optimization. Move semantics just formalized this. If a variable is about to go out of scope and it holds resources, why make a deep copy? Better and faster to just steal its pointer or handle. So I don't understand your complaints in regards to C++.

[@michaelkohlhaas4427]

*More rants, please!*

[@xealit]

A programmer quoting Thomas Sowell? Huh? 😮

[@johnjackson9767]

A Sowell reader? My, Ginger Bill, you do know the way to a boy's heart.

[@gregandark8571]

Your audio is low.

[@jackkensik7002]

nice

[@kristupasantanavicius9093]

Hey Bill, what problem is your language trying to solve?

[@GingerGames]

I am trying to make a tool to solve the problems I personally have.

[@alexpyattaev]

This mindset is exactly why multitgreading is a first class citizen in Rust, while Odin relies on programmer "getting it right". Same issue plagues Zig and Jai, and noone seems to care. Sure SIMD is important, but using all of the cores is, arguably, equally as important, and much harder to address with decent codegen in the compiler backend.

[@GingerGames]

This is not true. Multithreading is not a first class citizen Rust. The way that Rust achieves what it does is through its ownership and lifetime semantics of which Odin, Zig, nor Jai have, and for very good reasons. SIMD is orthogonal to "multithreading" and a different thing entirely. They are achieving different things for different reasons.

[@alexpyattaev]

You are confirming my statement that SIMD and threading are not the same. Which is exactly why lack of proper threadsafety consideration in programming languages is sad. Saying that Rust got threadsafety "by accident" is incorrect too. Borrow checker was designed primarily for threadsafety, as in a single thread it is largely redundant.

[@GingerGames]

​@@alexpyattaev Firstly, you just stated things. I stated that they were orthogonal because they are different things and hypothetically focusing on one does not interfere with the other. Secondly, your history of why the "borrow checker" was designed for is ahistoric and just wrong. Affine substructural type systems have their uses beyond multithreading and most people use them beyond that too. Rust's borrow checker is not the only way to handle ownership semantics either, but let's not get too much into the technical weeds in the middle of a KZbin comment. Thirdly, "just" adding ownership semantics doesn't make multithreading any easier, and you still have all of the actually hard problems still such as synchronization, communication, scheduling, use of data structures, hardware considerations, etc. None of these are even related to ownership semantics. Fourthly, if you used Go instead of Rust as the example of a language that has "first class citizen support for multithreading" then you would have had a decent point. However, Go's approach heavily relies upon garbage collection and a very heavy runtime in order to achieve its "goroutines" (i.e. N:M green threads). And you didn't mention Go, only Rust so you're point has little merit as I have stated before. Fifthly, this video is about how the ideas of ownership semantics are a specific conceptionalization of a problem, and completely orthogonal to multithreading. How the parent-original video dealt with multithreading problems was by getting around Rust's ownership semantics system entirely and using a more flat system was much more beneficial than the typical Rust approach. The way that languages such as Odin, Zig, and Jai tend to be written will be much more in the style of the conclusion of the parent-original video.

[@alexpyattaev]

I had no intention to upset you, was just hoping that people would focus a bit more on the sheer pain of writing correct code with multithreading in mind. If I am wrong about the purpose of the ownership model in Rust please let me know where I can read about the true history, I was going off a presentation by one of their community people on rustconf, so chances are it was a bit doctored for PR. PS: go would not make a good comparison as it is a GC mess rather than a proper systems language, so how threading is done there could never work "as is" in Odin. And, as far as I know, shared access to containers across threads is "tricky" in Go.

[@GingerGames]

@@alexpyattaev To be clear, I was not upset, more confused. The reason many of the new systems-level languages are not "focusing" on multithreading is that simple multithreading problems don't need language features and the hard multithreading problems have yet to be solved still. Go does a good job but as you correctly point out, it requires GC. And this is case with many multithreading/concurrency models, they assume some form of automatic memory management. Multithreading is a hard problem and no one really has any decent approaches to it yet which have proven themselves. Even Rust's approach due to the consequences of ownership semantics doesn't really solve much in terms of actual performance and distribution of work. It's just solving the problem of "ownership", and that's it.

[@user-ov5nd1fb7s]

Couple of things i found very wrong in this commentary. 1. You implied that bjarne stroustrup doesn't know how computers work. The guy was working along with Ken Thompson and Dennis Ritchie in Bell Labs. Honestly, its very disrespectful. 2. You basically talked about the borrow checker and how it doesn't work, for 20 minutes and didn't show a single example of it not working. What do you mean, not working? The borrow checker was designed to prevent bugs like double free, use after free, dangling pointers etc. It does prevent those bugs, hense it is working. If you think those bugs are not worth fixing, you should have clarified that. Or if you think having a GC is a better option while sacrificing performance. And let me ask you a question, do you think software written in your language won't have those bugs? If you say yes, you are either dishonest or delusional. Do you think the NSA are idiots by using Rust , for its security/performance properties? Or the linux, windows kernels? I want you to layout your case in practical terms. Wha exactly doesn't work in Rust?

[@lilyscarlet2584]

its syntax for one is horrendous. not to mention the fact that safety comes with baggage. just become a better programmer. safety is important to a point but it comes from knowing the system you are working with not programming with training wheels. all you need is pointers which are far simpler than references because im literally passing an address. i dont need to know a million different weird type indirections. the thing is its not that rust etc doesnt work its just unnecessary and its a sort of brainwashing. kind of like alot of things today. the issue is we have too many soydevs who dont care about the product its just a job and getting paid. we need more competent programmers who arent like oh i dont need to know how computers work to program or understand memory. the fact its even possible to write programs without knowing i think is a huge downfall. the real issue is humans being lazy not the lack of safety in languages. we have beyond too much abstraction and bloat today because of this horrible ideology. we have way too much garbage software like discord and minecraft and youtube and everything. what we need is to change this culture and fight it like casey is doing.

[@lilyscarlet2584]

also for the record c++ isnt bad because it doesnt implement oop right its bad because it does it at all. its like socialism and why it always fails yet people keep trying to say we just didnt have the right form of it. its the same in programming the correct language holds the user responsible and doesnt take responsibility for programmer incompetence by assuming things or trying to correct itself.

[@user-ov5nd1fb7s]

@@lilyscarlet2584 you are wrong on many levels. I am going to point out just a few because I don't have all day. 1 - you yourself have written all those bugs I mentioned and you will continue to write them, unless you are writing only trivial software. 2 - there are many programmers much smarter than you who find value in using Rust. The reason is you can have 2 pieces of well written software but when there is no contract on who handles memory it eventually becomes a problem. To solve this problem, apis written in Rust describe memory ownership. The only other way to solve it, without Rust, is if you rewrite all software and handle memory in your style and everybody else needs to do the same. Since you don't realize this, it tells me you are not a professional programmer.

[@user-ov5nd1fb7s]

@@lilyscarlet2584 even if the C++ language is not ideal for the current programming environment, you shouldn't be disrespectful to one of the people who was part of defining our field. Do you think you would have done better in coming up with a language and predicting how it will be used 50 years after?

[@lilyscarlet2584]

@@user-ov5nd1fb7s yeah i do actually. c is still better than c++ because it doesnt support what c++ does.

Stockholm syndrome? Mmm nope. It's more like an addiction to a good thing. It's like exercise, hard at first, but with time, you know it's good for you, and you can't quit.

[@gasquakestudios]

Why do you follow Jon so closely?

[@GingerGames]

Because I am developing Odin and I have a huge interesting Jai, both from a usability standpoint and from a research standpoint regarding programming languages. I follow many languages closely, not just Jai.

[@gasquakestudios]

I have never heard of anyone in the Rust community talk about Rust mimicking an economic system. Am I missing something or are you building a straw man?

[@GingerGames]

No. This is not a strawman but it is an observation. This is a meta-argument about where does this concept of ownership semantics comes from in the first place. Why do you think someone thought that the concept would be a good idea to add to any language in the first place, not just Rust?

[@AinurEru]

@@GingerGames I think you just got hung up to much on the terminology, I think that "ownership" in programming should be termed "responsibility". If you listen to Bjarn Strustrup (or however the f#k you spell his name...) was saying, he was actually talking about responsibility quite clearly - when he talked about RAII he said: "Who does the delete?" That's asking "who is responsible for freeing the resource?" not "who owns it?". You're right on the money (no pun intended) with the "familly" analogy, no parent "owns" their children, but they ARE responsible for them. If you think about what people typically call "transfer of ownership" of memory/resources as actually jsut a "transfer of responsibility", it starts making a whole lot more sense. Just ignore the term "owns" any time you hear/read it, and substitute in your mind with "responsible for", and you'll see what I mean. Is all about coordination of responsibility across multiple users of "resources" (which I agree is also a bad term...). Somehow C++ ended up with by far the worst definitions in the software industry... Anyway, the other term is "move" - obviously is not about "copying memory to another place then freeing the source" - because everybody knows that's dumb, expensibe and pointless, so nobody does that. Is again a case of improper term. Is again about transfer of responsibility - that's what a ""move"" of a unique pointer is. Is a way of one part of the program to give it's responsibility of releasing a resource to another part of the program. Is also incidentally about avoiding copying the resource itself, by having a layer of indirection, copying a pointer to the resource instead (then "deleting" the source - a.k.a: how memory actually "moves" in real computers - but only of an adress instead of the actual thing).

[@GingerGames]

@@AinurEru I do now refer to move/ownership semantics as "object based responsibility dependency". Ownership is the wrong term as you correctly point out. This video was quite unstructured and I wanted to just get my thoughts out as soon as I could. I have now thought about this a lot more and can explain what I had a hunch about much clearer.

[@random_bit]

A failure to articulate a position or argument is still a failure. Complaining about a philosophy simply because you disagree with the terminology is best summarized as pedantic. From your own words, you categorize Borrow-Checker as an economic solution to the issue of memory management/responsibility. Yet, you fail to outline why exactly you think it's a bad solution outside of "oh it's a one by one allocation/deallocation of memory where we usually go for batching". This just leads me to believe you much rather use a GC, because you're literally describing a garbage collector to say why you don't like a run-time less language 🤷 You say : "there has to be a better solution we just haven't found it" Yeah, and there's an entire sector of problems called NP in CS that I could refer to you as well then to see if you don't like them. Then simply put, Rust is not meant for you and it never was. It's a Systems/Embedded Level language, it doesn't have a mission to provide a runtime. Yes, the static analysis gets in the way a lot and other people coming into the language dont like that, but guess what, from your own admission, just because things are dogma in a field doesn't make them right. BC tells you off the bat that you can't violate the Readers/Writer(Dinning Philosophers') problem unless you opt into that behavior via "unsafe" (you know the literal workaround for the BC that you're complaining about). The person in the Game design talk quite literally outlines why the OOP solution simply won't work in the long term due to uncaught Race Conditions. Is it annoying? Yes, designing a system that takes that into account upfront is annoying, but it is the correct starting position in a parallel, concurrent system. The point Rust makes is that you will have reproducible behavior(otherwise called non-UB) irrespective of it being multi-threaded or not, it doesn't guarantee that you don't f-up business/domain logic, it never said so, Jon literally strawman-ed that in his video. Jon's main point is that he dislikes that the Borrow Checker stops someone from doing a stupid choice upfront and 6months later trying to reproduce a race condition bug that happened on a delivered game with no stack-traces. Your real complaint is that Rust limits the freedom of expression of the programmer and what they can do with memory. Which I will concede immédiately, yes it does so and that's undeniable. That's what we call a trade-off in engineering, there is no perfect solution for anything. To which I argue, you have 'unsafe' to do whatever you can do in C/C++. Again BC is not Rust, it is an add-on for Rust's type-system and you can easily opt-out of it if you really want to. Again, if you don't like it and you fail to provide a counterexample or solution then your entire position is summarized as 'emotional' lacking any substance.

[@etodemerzel2627]

@@random_bit So, what you're saying is Steve Klabnik is wrong in his 'You can't "turn off the borrow checker" in Rust' article?

[@_xeere]

It seems strange to apply “You make the mess, you clean it up.” to both memory and error handling. Those things aren't particularly related. I also notice that you say in the article that you will not enforce your idea of correctness on others (you said you'll let people blow there own foot off, and don't want to stop them writing the code they want), yet you also enforce your ideas about error handling, going so far as so say you hate this way of doing things and don't want to encourage it. This seems blatantly hypocritical. It is the classic programmer trap of espousing only the benefits and neglecting the costs, which is especially funny considering you have or_return doing the same things that you criticise Rust and Go for (you actually have some of the same snippets in the Odin docs as the ones you call bad design in Go). You don't like the idea of propagation, but on some level you understand that it is necessary. A lot of the ways you describe Odin are similarly shallow, just vague assertions against or for your opinions. Your critique of others here hinges on their dogma and lack of understanding, but is this just an exercise in projection?

[@GingerGames]

Two things: This is an old video and a rant. My views may have changed in that time. Regarding or_return, my criticism is error value propagation across library boundaries AND type degeneration. The latter encourages the former. There is no base error type in Odin as there is in Go, and there is no magical type inference for all error values like in Rust, therefore there isn't the same type degeneracy problem. I'm not being hypocritical but two things: my views have evolved and matured; my view is not that simple.

[@_xeere]

@@GingerGames You say you aren't going to impose your views of programming on the users of Odin like other languages do, you then impose your views of error handling onto the users of Odin. You say you trust the programmer not to blow their own foot off, then you say you don't have operator or implicit procedure overloading because you think they have more cost than value, i.e. you think the programmer will hurt them self with these things. That seems like hypocrisy to me, and it's coming from a video entitled: “Odin Programming Language: An Introduction”, so you can hardly blame me for thinking these views are representative.

[@GingerGames]

@@_xeere Odin still has no concept of an error value. There is still no enforcement of any kind anywhere. You have a large toolset to allow you to do whatever you want. You can use multiple return values, enums, discriminated unions, a bit ol' struct, maybe types, whatever you want. `or_return` isn't even necessary just for error handling, I use it for early returning in certain mathematical cases which are not errors. Odin doesn't have implicit procedure overloading because it doesn't actually work with the package system. It would only work in a language with one global scope such as C++. As for operator overloading, please read the FAQ. Not having a feature is not the same as "I don't want programmers to hurt themselves". I don't want a behemoth of a language that is C++. You do realise you can just ask me why certain things are the way they are?-rather than assume I must be a "hypocrite" and you need to prove it in your fury.

[@_xeere]

@@GingerGames I have assumed nothing, only listened, and I do not need to ask what you have told me. These are things which you have said in your videos and notably in the FAQ you just linked. You say operator overloading is “very easily abused”. That is an example of not trusting the programmer to use it properly, and so it is logically inconsistent with your claim that Odin is a language that trusts the programmer. It is the same for exceptions, which you think are harmful but many people do not. Through language design, these ways of programming are discouraged, programmers are not trusted to do these things. You undoubtedly limit the scope of what is possible simply because you disagree with it. I am not convinced that this is anything other than imposing your views onto the users. Despite this you have said: “I am not trying to be enforce an idea of what how I think you should be programming”, and you have also made a whole rant about other people trying to do that. If you omit these vapid philosophies (trust, responsibility, the billion ways of saying that you won't do bad things) and instead focus on what makes good code (as you admit to doing in some cases), the decisions you have made become much easier to justify because they are based on intuitions which are mostly correct. For instance this in this video if you took blow's point about the borrow checker, you would effectively have: “It can't be used in these cases, you just have to circumvent it and be worse off than you would be otherwise.” which is valid and salient criticism. Yet instead you talk about economics as if that makes a lick of sense in relation to programming. I see these sorts things so often used to try and justify programming decisions and they annoy me to no end.

[@GingerGames]

@@_xeere "I have assumed nothing, only listened, and I do not need to ask what you have told me." That's the definition of assuming what someone means, and you have misunderstood what I have said by quite a bit. "I am not trying to be enforce an idea of what how I think you should be programming" Is not equivalent to: "I will put every single feature that has ever existed into a language" There are limits to what you can put into a language. As for the operator overloading, it can be easily abused but there are a few reasons it doesn't exist in Odin and it isn't just because it is "easily abused". The main reason is that for 99%+ of use cases people want operator overloading, Odin already provides native support for that functionality (array types, hash map, array programming, matrices, complex numbers, and quaternions). The other reason is that to add such a feature in a language such as Odin would require something like a trait system which is a rabbit hole of a feature I did not want to have to go down. "I am not convinced that this is anything other than imposing your views onto the users." That is literally impossible not to do in terms of designing anything, let alone a programming language. When you design a tool, you are making value judgements about how something ought to be used. How you want to use that tool is up to you and Odin is a lot less restrictive than many languages out there. P.S. You do understand what a "rant" is right? And that this was a complete stream of thought? P.P.S. And that "Economics is the science which studies human behaviour as a relationship between ends and scarce means which have alternative uses" or sometimes defined as the "Study of Human Purposeful Action", therefore it is applicable to any field of that nature, especially programming.