If we had stopped reiterating on the wheel our cars would drive on wooden logs.

But if you release a wheel today, same as any other wheel you can already buy, don't expect much fanfare.

Also if I'd dive into how F1 wheels are made, I'd expect I learn stuff that is fascinating and far from boring.

I think straight duplication is quite unlikely. You even say it's inevitable. Which is also confusing. Most code written is probably quite unremarkable, yet useful. Usefulness is a dominating factor, wow has a lot of depends.

Is it? There are many different people selling wheels that are all pretty much indistinguishable from one another. The first one no doubt brought the 'wow'. But when the second person showed up with the same thing, what 'wow' would there be?

Our entire system of trade assumes that duplication occurs as an intrinsic piece, with the only defining difference in that duplication is the effort to make the same thing for cheaper. Otherwise known as competition. Are you suggesting that doesn't happen?

That's fair. But if you aren't offering a perfect clone, then you're offering something novel that will 'wow' your customers, no? The market will never take interest in what you are selling if there is no 'wow' factor.

> Which I think is unusual.

You make a fair point that unreasonable terms on intellectual property laws has made it much more unusual than it should be, but isn't unusual historically, and shouldn't be unusual given our system of trade that assumes that clones will be produced. It's the only way most people can participate in the economy (and why they currently feel left out; but that's another topic for another day).

AI often doesn't do things your way, but if your doing something for yourself you usually care more about the goal than the technicalities. Also AI working on a hobby code base is less prone to overcomplication since it basically copies what you've wrote yourself.

In terms of productivity it's having something of a mixed effect. It gives me very clear ideas and direction but at the same time everything just feels done afterwards. All that's left is actually executing the tasks which is... Boring.

I'm not sure I trust ChatGPT to do it for me like an agent. The examples it gives me are never quite right. It's probably a lot better at generating frontend javascript code than programming language interpreter code.

Is this some sort of unwritten agreement? When I was setting up my sponsor page, I explored the sponsor pages of other users for ideas. I don't think there were many sponsorship tiers with special features. Some people offered advertising space on the README, others offered access to an exclusive Discord channel, most just thanked the sponsor.

I'm still new at this so I wouldn't know. I only ever had one sponsor. Happened organically after my work was independently posted here on HN once.

Edit: https://pocketbase.io/faq/

Look at the bottom, just an example how sponsors/donors may affect you.

Assuming to everything allocates on the heap, will solve this specific confusion.

My understanding is that C will let you crash quite fast if the stack becomes too large, go will dynamically grow the stack as needed. So it's possible to think you're working on the heap, but you are actually threshing the runtime with expensive stack grow calls. Go certainly tries to be smart about it with various strategies, but a rapid stack grow rate will have it's cost.

Depends what you mean by “large”. As of 1.24 Go will put slices several KB into the stack frame:

    make([]byte, 65536)

    make([]byte, 65537)

Interestingly arrays have a different limit: they respect MaxStackVarSize, which was lowered from 10MB to 128 KB in 1.24.

If you use indexed slice literals gc does not even check and you can create megabyte-sized slices on the stack.

  // -smallframes
  // ir.MaxStackVarSize = 64 * 1024
  // ir.MaxImplicitStackVarSize = 16 * 1024
  a := [64 * 1024 +1]byte{}
  b := make([]byte, 0, 16 * 1024 +1)
  // default
  // MaxStackVarSize = int64(128 * 1024)
  // MaxImplicitStackVarSize = int64(64 * 1024)
  c := [128 * 1024 +1]byte{}
  d := make([]byte, 0, 64 * 1024 +1)

  test/test.go:36:2: moved to heap: c

    []byte{N: 0}

And creates an on-stack slice whose size is only limited by Go's 1GB limit on individual stack frames: https://godbolt.org/z/rKzo8jre6 https://godbolt.org/z/don99e9cn

Interesting, [...] syntax works here as expected. So escape analysis simply doesn't look at the element list.

The initial stack size seems to be 2kb, a more on a few systems. So far I understand you can allocate a large local i.e. 8kb, that doesn't escape and grow the stack immediately. (Of course that adds up if you have a chain of calls with smaller allocs). So recursion is certainly not the only concern.

I am pretty sure the escape analysis doesn't affect the initial stack size. Escape analysis does determine where an allocation lives. So if your allocation is lower then what escape analysis considers heap and bigger then the initial stack size, the stack needs to grow.

What I am certain about, is that I have runtime.newstack calls accounting for +20% of my benchmark times (go testing). My code is quite shallow (3-4 calls deep) and anything of size should be on the heap (global/preallocated) and the code has zero allocations. I don't use goroutines either, it might me I still make a mistake or it's the overhead from the testing benchmark. But this obviously doesn't seem to be anything super unusual.

The thought model complicates the process of writing new code, "what pattern do i need here?" and the perception of existing code, "oh this is pattern X, why isn't that communicated clearly?". The truth is that design patterns are at best stagnant in quality and quantity over time (GoF is over 30 years old!), but the quantity and quality of problems is infinite.

I've thought in patterns quite some time in my early career. With my colleague back then everything was an pattern and we were kind of in sync with that approach. But it quickly falls apart if you have peers that are less try hard on it. You can spend days, weeks, months to study design patterns and then have to explain it to someone in 5 minutes that simply doesn't care. I can't blame anyone to not care, so that has to be accounted for.

I think the common language argument is tempting, but also too stressed. Good and useful programming knowledge is bound by reality. An integer is a indisputable thing that is always useful. A "singleton" is just a fancy rephrasing of "global state".

Say I build a tool that makes it easier for me to drive a nail and call it a "Naildriver". If I show it to a colleague, they may be able to tell me "oh, this is generally called a hammer!". Maybe they will even tell me how I may improve my hammer, because they happen to like to learn about hammers in their free time. Or maybe now that they said it's a known concept, I will enjoy reading about hammers online (doesn't mean I will now read the entire encyclopedia of tools).

The fact that there is a name for the concept ("it's called a hammer") does not say you have to know the word. It's just useful to have a word for it, because then we can reference it in discussions and share knowledge about it more easily.

To keep in your analogy, if you have a 3KG naildriver with a 2m handle you'll quickly find out that driving nails into a drywall with that leaves you with no wall. And that it's a bad idea to use a "Naildriver" to drive these "spiralled-slothead-nails" (aka screws) into wood.

But with a common language, such as design patterns, you can easily learn where they are good, what their limits are, in what cases other patterns fit better, and what pitfalls to avoid and so on.

If I search the web for "why is it so hard for my naildriver to drive in spiralled-slothead-nails" I'll get zero results. But when I search for "why is it hard to hammer in a screw" I'll get good results. May sound like a silly example, but for me that sillyness illustrates how obvious designpatters should be.

And it doesn't mean at all that everybody should learn the whole encyclopedia of tools by heart. But having it formalised somewhere is useful: as soon as someone tells me "what you're trying to do sounds like this design pattern", I can start searching and reading about it.

Of course if that someone tells me "you suck, you should know that there is a design pattern for that because you should read about design patterns every night before you go to sleep", it will be different :-).

I think Julian Assange once said he would refer to things in discussion just as "Tomato" (or similar), in discussion to have a shortcut for something unnamed with some meaning. We do this all day in programming, we give a complex component a name and it means a lot more then just the actual word. The problem is that this specific meaning is often not universal, it's contextual.

If you take a hammer, an integer and design patterns, the latter is the least universal thing. They depend on domain, context and conventions, and can change quite a lot depending on the language. Removing hammers and integers from the world would cause collapse, removing design patterns would do almost nothing.

I guess the active celebration of design patterns as a catalogue of general wisdom is my primary issue here. I'd welcome any project/team/company that maintains a catalogue of their individual "patterns". But a universal source of truth has too much bible flavor to me. (Oh it also dictates OOP by default which renders it's inherent "wisdom" completely useless in many languages)

But formalising concepts with words makes sense. If your company maintains a catalogue of their patterns, and someone happens to know that this specific pattern is usually called a "singleton", I would find it weird to call it a tomato.

Some patterns have different names in different contexts or languages, and that's fine. I don't find it weird to have a discussion around "in this language there is this pattern that they call X, does that ring a bell for you working on that other language? The idea is [...]", and maybe the answer is "yep we have it too" or "oh, we call that Y, but that's pretty similar".

I've had some debates with junior devs who really wanted to enforce their newly-learned patterns, and my experience there is that passed a certain point, there is no convincing anymore: if they really insist about overengineering something with their newly-learned concept and the hierarchy doesn't allow me to prevent them from doing it, anyway they will do it. So instead of fighting I just let them, and if it turns out to be a waste of time in the end... well that's not my problem: I was not in a position to prevent it in the first place.

It's not only patterns though: some juniors have a way to try to use every exciting framework or library or tool they just discovered.

Probably a bad habit trying to stop them, they need to learn walking before they can sprint. The question is always how to put limits on them? I say it's overengineered, they say it's modern code and I am old. So what do you do if they send you a PR that is just plain wrong? I mean it seems like you delay the conflict from upfront design/planning to pull requests.

* Functional teams (established companies): enough seniors are here to tell the juniors when they are wrong, and the juniors naturally accept the criticism because it's expected in that environment.

* Dysfunctional teams (startups): most devs are juniors anyway, there is no clear hierarchy, managers are still at their first job so they have never seen a functioning team or had a competent manager themselves.

In the second case, there was absolutely no way I could win an argument: the "high energy kids with big egos" never believed me, I was the "old guy" as you mention. I remember an example where the "kid" failed and gave up with their "right" way after 3 months and I solved it in 3 days, exactly how I had suggested they did it in the first place. Next discussion, nothing had changed, they still knew better.

I can't really blame them, because the whole environment was like this. Everybody was always right, knew better, etc, even though it was their first job.

What I've learned is to protect myself and move away from that. Either by changing job, or by changing project. In startups I have been pretty successful at saying "I can help with this project if we do it this way, but if we do it that way, I can't help and I will work on something else". Of course it meant that I could not work on the most exciting project, but they made a mess out of them, so all in all I feel it was better working on my boring, stable, maintainable components.

I think once you have spent enough time in a software space, nothing is really new under the sun. That's why I think the GoF has aged well (controversial opinion I know!).