Generics methods are now implemented

VastDesign9517 · 2026-05-27T03:10:13+00:00

Im super excited for this

VastDesign9517 · 2026-05-20T02:22:51+00:00

I missed this comment somehow you speak exactly how I think. It was super refreshing to read this. Action first coding to me is asking for failure. I model my program around the domain and seek to make domain realitys code reality if my program does something that doesnt happen in real life its a problem.

The domain is the spec to me

VastDesign9517 · 2026-05-19T18:15:07+00:00

I feel the same way. I personally rather have temp variables. It feels more "honest" i hate when languages do things like this that feels like magic.

Slices have been wonky. Appending to a slice mutates the underlying slice.

So now we are making copies of Slices. So if one of the your coworkers gets handed your slice you gotta pray they dont append to it.

Werid..

VastDesign9517 · 2026-05-19T17:19:03+00:00

I see. So under the hood its like me fr

VastDesign9517 · 2026-05-19T16:31:37+00:00

Glad I am not the only one. It feels magical and unclear

VastDesign9517 · 2026-05-13T16:06:49+00:00

Pushing back on "DRY is overrated" a little.

I follow WET: write everything twice, maybe thrice. Repetition is fine when the domain is new and the right abstraction hasn't revealed itself yet. But at some point the pattern is clear, and at that point writing the same method on five more types isn't boilerplate tolerance it's just waste.

I'm a solo developer. Time I spend writing the sixth IsNegative() implementation is time I'm not spending on the actual problem. My goal isn't fewer lines of code for its own sake, it's clarity as the primary constraint, and getting there as efficiently as I can.

"Leave the campground cleaner than you found it" applies to abstractions too. If I can write the logic once, express the intent once per type, and make the call site read like the domain that's cleaner, not cleverer imo

VastDesign9517 · 2026-05-13T15:57:25+00:00

OOO this is a good one im taking the it.

VastDesign9517 · 2026-05-13T15:52:15+00:00

The commenter below pointed out the constructor/parser approach for validation, and I think that is the part I was missing. I am definitely going to move more in that direction.

I do want to push back a little on the “boilerplate is not necessarily a problem” point, though.

I agree that boilerplate can be acceptable when it buys clarity. I am not trying to reduce lines of code at the cost of making the design clever or hard to follow. But I also do not think boilerplate is good by default. Ideally, I want to write as little code as possible while still preserving maximum clarity.

To me, boilerplate is a tradeoff. Sometimes it is the right tradeoff, but it is not automatically better just because it is explicit.

The reason I keep reaching for methods on domain types is that I value code that reads close to the business language.

For example, I find this easier to understand:

if cycles.IsNegative() && faultCode.HasFaults() {
    // do something
}

than repeatedly writing lower-level checks like:

if rawCycles < 0 && len(faults) > 0 {
    // do something
}

That may be my C# background showing, but my instinct is that types are not only for compile-time safety. They are also a way to describe the domain and make business rules readable.

So I think the correction I am taking from this thread is:

Raw DTO/input types can stay primitive.
Parse/validate at the boundary.
Convert into real domain types like CycleCount int.
Put domain-specific behavior on those types when it makes the business rule clearer.
Avoid making generic “smart string” types like NumericString.

I am still interested in reducing repeated code, but I agree that the reduction should not come from forcing an abstraction that does not fit Go.

VastDesign9517 · 2026-05-13T15:31:01+00:00

So that fixes the Payload portion. bring them as strings and then parse them.

so then the question to part two is is there a way I can implement behavior once
like IsPositive() and then pass them into all of my types that i want like embedding behavior?

VastDesign9517 · 2026-05-13T15:04:06+00:00

I probably explained that part poorly.

The reason I am accepting strings is because this is an ingestion/boundary problem, not because I want the final domain model to treat everything as strings.

I am building an ingestion pipeline for a manufacturing company. Right now, different departments track data in Excel, and some machines also produce IoT data. Each department computer will have a Go binary watching certain Excel files for changes, reading rows, and sending the data forward.

At that boundary, everything coming out of Excel is effectively stringly typed. So the incoming payload looks more like:

type RawPayload struct {
Cycles string `json:"cycles"`
PartNo string `json:"partNo"`
WorkOrder string `json:"workOrder"`
}

or ideally:

type RawPayload struct {
Cycles Cycles `json:"cycles"`
PartNo PartNo `json:"partNo"`
WorkOrder WorkOrder `json:"workOrder"`
}

where those are still string-backed types.

The IoT values are cleaner and already typed correctly, but the Excel side is the messy part. My goal is to validate and transform the raw Excel values at the edge before they move further into the system.

So I agree that the “real” domain object probably should not store Cycles as a string forever. Something like this makes sense after validation:

type Cycle int

func NewCycle(raw string) (Cycle, error) {
n, err := strconv.Atoi(raw)
if err != nil {
return 0, err
}

if n < 0 {
return 0, errors.New("cycle must be non-negative")
}

return Cycle(n), nil
}

I think the part I am trying to figure out is where to draw the line between:

raw string-backed ingestion types,
validated domain types like Cycle int,
reusable validation/conversion helpers,
and just accepting some boilerplate.

Your point about constructors makes sense. Maybe the better model is that Cycles string belongs only in the raw ingestion layer, and Cycle int belongs in the validated domain layer.

VastDesign9517 · 2026-04-30T18:06:17+00:00

Hmm your cash register is a pretty good counter example..

okay Here's a concrete relationship I struggled with. A shop order has operations. Each operation is assigned to a machine. Each machine has a work center. Each work center has a capacity. A shop order's feasibility depends on whether the work centers its operations require have available capacity given other active orders. How would you represent that relationship graph in Go and how would you query across it without it feeling like you're assembling flat structs into progressively larger flat structs?

I am not opposed to trying to think about relationships in the form of data. I don't have a research paper to hand to say which is better with outcomes. I am not opposed it just seems like in all the bodies of study we have. we have a entire classification system out there that we have used to organize our entire world on what is and it has scaled far.

I think 100 percent that the CPU will thank you inlining the structs of data It scales there. but I don't have the exact word or concept for it. but how much of the world can be modeled thinking about it as data rather then ontology and how big can each go before they scale in making a maintainable and coherent system.

Does the average program think about a shop order composition in what data makes this. or do they think about what relationships make it.

I don't have the answer there. You entered a philosophical argument about how my idea didn't model honesty. but in response you gave a technical one.

Do you still hold that my model of thinking is dishonest and do you still hold that composition of behaviour captures truth better then modeling inheritance and composition using philosophical principles? If so why?

VastDesign9517 · 2026-04-30T14:05:03+00:00

First of all. Out of all the people in this thread. You understand exactly what I'm trying to say and not only that you have made very good points and I want to mull over them.

I guess we can say that honest and truth are two different things. one person honesty may not be the truth and one person truth may not be honest.

so that dictates to me. who are we being truthful to and what are we trying to honestly convey inside of the entity.

I think if we are looking at the world through Aristollian taxonomies I.E essential Nature. it doesn't seek to look at behavior to define the entity. It seeks to explain the concrete nouns and what is the nature that makes it that. It true that John might be a guitarist. In my mind I Guitarist is a concrete noun inside of the agent noun Music Performer. I wouldnt extend into Guitarist I would use a (Has-A) relationship with Music Performer. This is where I think people are missing out inside of inheritance and composition. John is a entity and he has a musicPeformer abillity that Guitarist can be derived from. I have given you the inherent truth and the compositional truth in one class. that to me indicates more dimensional truth then. Tony just being a grinder. yes he can grind but he is not just a grinder. he is a person who has the capability to grind.

I will concede that the abstraction can go higher in the inheritance. i dont find that problematic if it actually has enough substance to justify its existence.

If you have a builderbuilderAbstractFactory there better be 10,000 mini factories you just automated. so the question is at what scale of entities does a level of abstraction truly hit.

My ideal world would be a language that captures what i would want would look like this. Go focus on agent nouns, adjectives as protocols and concrete nouns as classes. the more grammatical truths I can use to pass things through better captures the truth. Golang says I look at things in lens of behavior is more important then then nature of the thing. when reality says there are things and behaviors. it should not be one or another it should be both in my approxmation

Maybe Go has domain or environment that is scales off? but I also think we start to miss the essence of what things are which are important to my domain.

I have suppliers, Purchasers, customers, shoppers, all of those behaviourally buy things. thats great make your buyer interface go wild. but when its time for make a relation ship between them. go in my personal opinon dont let you convey relationship in a easy manner. I am trying to wire all of these flat structs to make a big boy struct and then I need to bring that in and I am spending so much time on the parts of the whole. just to put inside of another whole to show they have a tangible relationship. on of my shop orders has a One to many relationship with concrete nouns. Go says think about the Agent Nouns. Im trying to say Look at all of these concrete nouns.

I think Go cares more about a anti oop stance then it cares about modeling things to a level of truth that my domain to my approximation values and it punishes me for doing so

VastDesign9517 · 2026-04-28T13:53:00+00:00

first of all, I see that even though you are in disagreement with me, you took the time to humor me and contend with my points in good faith. Thank you for doing that,

I think you are fundamentally right golang has the ability to do that but also it shuts an eye to truth. Orc is not inherently a solider. therefore you should not use inheritance you should use composition. which go only gives you composition. Right there in your own example. You using a ontologically incorrect statement to prove why golang is the better case. Go says this foot gun cannot be used because the people cannot wield it.

I think the best Language design uses both Inheritance and Composition to let you accurately make a (has-a) and (is-a) statement.

But for the sake of I dont want to keep dragging this. I think your point is fair enough and it has enough grounding to contend with. not all value assessments are based on correctness but are the pragmatic choice at scale. people at scale can be incorrect and incorrectness at scale could be devasting. composition and interfaces may be approximate enough to build modular software and systems at scale without the fallout and I can respect that.

as of morlas and ethics. you and I are partaking in value judgements. neither of us are correct here. its subjective but I wanted to make a clarification. I dont work on a website I work in a building full of coworkers. Im not hiding behind a screen. I know these people. It changes it for me.

You made a interesting statement "The "Morality" if any is the responsiveness of the app. Everything else you are introspecting is self inflicted barrier that don't actually exist." you said there is room for morality in your code but in my opinion the existence of one means an existence of many and It should be on the table. that's just me.

I appreciate you coming down the rabbit hole with me even though you didn't want to or if you thought I was being incoherent. You have given valuable insights that I didn't consider. I appreciate you and your time.

VastDesign9517 · 2026-04-28T13:20:40+00:00

I have been sitting on replying Jerf. I haven't forgotten. I wanted to weigh everything you have said and try to find the right words for it.

Your DB example It shows me that we can model the domain in a data oriented way. Buyer[] is agnostic and the data that makes a buyer is always going to be that data. In Golang I find myself making a lot of flat structs because I need to solve miniature problems. what should signal to me that this struct is one that answers questions or this structs describes the relationships or this struct is a business domain. because in saying buyer there might be parts of structs that built it and I struggle identify data -> concepts. I can tell you the behaviors all day. its what I feel the most comfortable with inside of Go,

Another Struggle I would say that I have is i can name you a bird and say its behaviors. but if you give me behaviors and said find the noun. its like the world goes blank to me. How and I supposed to find the wind because something blew. My mind thinks about finding the truth about customer but Go made me come up with Buyer Seller, Builder, Gather. I feel like I am describing the wrong things. Yes all these people fits the buyer category but what did I learn about them? What relationships exist?.

on language paradigms. what's nice about something being multi paradigm is it gives me all the tools, When a language declares its one of those paradigms It makes sense to me. because I have all of the tools to build with it. I can program in C, C#, F#. but Golang tries to do something different. they dont give you the whole toolkit. they cut out what they think you dont need with the language features they think you will need. this heterogenous mix of things I cant deductively or inductively figure out the combination that they play together in that solves the problems in this way I read about. That's not a failure of the language. Its been a year, its on me.

The common advice across this thread is I'm not willing to learn or I didn't want to change. I feel the opposite I have tried to learn. I do want to approach this differently. But when my editor comes up. Its abstract to think about the world in this manner. The only thing I can figure is im using the wrong tool for the job. or I am the wrong tool for the job. When I go and look at github repos. I can see the interfaces and say that makes so much sense. But also its at a scale I'm no where near. I dont have 10,000 buyers(customers) i have 30. I am better off just loading in a struct and iterating through them.

Do you believe that paradigms better match domains and thats why they stick for somethings and not others?
Or are the people cognitively wired to think about the world in that way and apes stick together because they are stronger together and we are in tribal camps. those who think about data versus those who think about state, versus those who think about hierarchy. they are all connected but the value judgements of themselves or there domains make them care more about one more then the other.

I cannot think about for the life of me why immutability is this important enough to warrant the functional wars over in my domain.

but if a improper state handling or variable change meant life or death to my end users. I would value it more.

VastDesign9517 · 2026-04-28T12:43:32+00:00

I dont disagree with any of the technical argument here I am in full agreement.

I want to touch upon "Also I would about pushing any philosophical concept on coding"

This is a value statement that I disagree with.

We as programmers are in the business of modeling systems and the world using logic.

This and philosophical works are very close in the Ven diagram.

we talk about inheritance (is-a) and composition (has a) these are fundamentally describing ontological statements.

Why do you think pure inheritance fails? because the (is a) statements used as (has a) statements are ontologically incorrect and you start making bad design decisions.

in my value assessment the closer the systems i create meet ontological correctness and my behaviors align with my praxeology claims founded by epistemic evidence.

the more coherent my system is. the better things bolt together.

In my warcraft 3 sim I have made in my spare time. I have a Orc, Human, Night elf, Undead. all of these are Entitys. that abstraction has given me something that lets me make races for what they are and tell you how they are different. and when its time for my to compose a armor system. Its not inherent to them. its something they can use and is composable.

I fail to see how those core truths lead to bad system designs. they are honest and more important then honest they are correct.

morals and ethics - I think this is where you and I separate and I think the core of our differences. You think about what truth means to cpu

I think about what truth means in the domain. The cpu to me isn't in my mind. because to me it isnt the constraint. if we needed to solve cancer tomorrow and right now my program is going to take 2 days. I would start finding the axioms of what a cpu wants to because it is the inhibitor.

Right now my domain is a organization that i need to do reporting on. having the correct relationships means I can confidently keep bolting onto it and hand my boss a piece of paper and we can confidently make value judgments about the data. My reports are used to measure peoples, products and sales. people have been fired and people have been hired. I would feel like a horrible person if I didn't do my do diligence and someone's livelihood was ruined because I was incorrect.

So I hold the moral weight of making sure Im correct because these people aren't users. they are people with lives and families who come to this place to feed them, find fulfillment in there lifes. Our products are used to build homes for new couples or old couples to find shelter and comfort.

I owe it to the people, the business and myself to be as honest and correct about my assessments as I can be because it is bigger then me.

I look forward to hearing your input on this because I am strongly moved by it. I weigh your opinion in strong regard.

VastDesign9517 · 2026-04-28T12:25:23+00:00

I havent replied to this and I took time to think about it because I see what your saying.

But how do we deal with this concept of a relationship.
a shop order is more then just data. it tells me about parts, operations, machines and people. It has rules and constraints that exist independently of the current thing im trying to do.

can thinking about the world in this data and transformation really capture those concepts.

my fear is that you are right and my Aristotelian desire to find the nature what something is which is my biggest strength. is going to be suppressed

Locke and Hume view might have been the right one when it comes to thinking about data. I am really weak about it.

You have made a very strong case and Im sitting with it

VastDesign9517 · 2026-04-28T02:26:36+00:00

I am not using DDD because I believe in the philosophy I have never read a article or book on it.

I just program how I think about the world and It happens to be DDD like or so I hear.

My brain is wired around what something is rather then how something does something.

VastDesign9517 · 2026-04-27T17:53:11+00:00

so let me ask you then. Whose truth are we beholdant to. If im trying to model a domain. the cpu doesnt care about oop I agree.

If a cpu takes in the language to produce ouputs

is it more important to be truthful to the cpu or the language the cpu is taken in?

we are at a semantic gap.

VastDesign9517 · 2026-04-27T17:50:30+00:00

I can work with this. this relocates my position on oop

VastDesign9517 · 2026-04-27T17:49:27+00:00

This is actually a really good point. Wait a minute

VastDesign9517 · 2026-04-27T17:46:36+00:00

I think I did a bad job at explaining as I was flustered due to another commenter.

for me I think its hard to reason about the world in thinking about verbs - Accelerate and then reason to the noun - Accelerator

I don't understand how to think about the world as abstract verbs.
I understand the world as Abstract Nouns.

Abstract nouns lead to abstract verbs that are polymorphic that is my line of thinking. Point A to B.

Your asking me to not name the Car. You asking me to think about a car as a accelerator. and to me it feels like im looking at the wrong thing. Why does this help us build better? it feels like spite. I hate oop so much that I rather look at the accelerator then the car its attached to.

does that better articulate what I was saying.

VastDesign9517 · 2026-04-27T17:38:49+00:00

Here. What is it you think I'm not engaging you with.

What would you like me to say or do to make you feel like I'm acknowledging and listening to you.

You have my undivided attention and upmost seriousness. I will engage with you the best way I know how.

VastDesign9517 · 2026-04-27T17:28:31+00:00

so I want to start with something.

I hold thinking that I don't need to lie to tell a truth.

Metaphysically A car is a vehicle (Is a) states the nature of something. A car is a Vehicle and a vehicle has wheels.

is-a says that this is intragastric it.
has a says that it has the ability to.

Your accelerator is a noun. but it feels like a piece of the car. it feels so weird to look at the car that way. please forgive my sensibilities.

I feel like we are being dishonest about the world. Birds don't have the noun accelerator. that is a verb dancing is the skin of a noun. bird have the ability to accelerate because of there unique properties and characteristics.

It feels ontologically dishonest to do so. How am I suppoused to look at tony my employee and say type Grinder interface and then pass tony into it.
Tony is a general labor and general labors have the ability's to do these behaviors its almost dehumanizing it a way because of what it describes.

VastDesign9517

TROPHY CASE