ZealousIdeal

which is why the majority of the startups fail and then a lucky unicorn comes and funds the next cycle. look at how many poor ideas got massive investment on the bet of payout; so many blockchain companies and none solved a real world problem. lots of potential investment in things that could have greatly helped many more people in the world, but instead invested into a technology looking for a problem.

crux of the problem is the SV model is completely broken and leads to these cycles. wish it were more about sustainable progression and not rapid half-baked innovation to achieve paydays for greedy founders/investors

disagree. k8s is written in it just fine. plus, tons of other modern large applications in enterprise settings

After just 30 minutes I've crafted an Apple Crumble Mudslide. My job is done.

I agree such patterns are indicative of systemic issues. In my experiences, those process issues emit their own structured behavioral patterns. In your example, the "." commit is now a convention that indicates a specific process happened. I am not certain what the costs of fixing the root problem are, though I'd anticipate they could be expensive and difficult at this point given the time commitment to restructure the repo and automate the scss=>css. Whereas the expense of an esoteric "." commit appears relatively cheap given the need of a human to untangle the mess which cannot be automated away (without a redesign).

Oh, one other exception as others already pointed out, conference talks are also very good. Though I think they miss the heart of your question (I could be wrong).

Given the extremely large spectrum of "technical content" available for someone to focus on, can you provide more detailed examples of what would be higher quality technical content in your opinion?

BTW, I'm not disagreeing with you at all as I too agree. I'm just wondering what things you also see as missing.

I find most user content is focused on the introductory level, which makes sense if you are attempting to appeal to the largest audiences for income (so not faulting anyone). I often see content on data engineering but most just define "data engineering" and at most talk about things high level Hadoop, Spark, etc. and do not provide any examples/patterns of working with data that is even close to representative to what I do in my day job. The same is true many other technical disciplines too. With a couple notable exceptions on some security topics (such as demonstrating certain exploits), and some hardware topics -- such as Ben Eater's great work (https://eater.net/)

I enjoyed Benno Rice's talk, "What UNIX Cost Us". I think he provides some examples of where the simple interface breaks down when compared to other systems (i.e. Windows, macOS) take on it.

Best post of 2020 by far.

While generics will allow for such to occur, IMO if the "idiomatic style" is to only leverage it for specific patterns then it should not really hurt general readability for the most used frameworks/libraries. There will, of course, be some tradeoffs that authors will make, but overall I'm hoping it enhances readability, especially for the code my team and I write at least. Looking at the proposal, there is a lot of practical debate about naming, consistency with bytes methods, etc. and such honest debate keeps me optimistic.

This is one of its biggest advantages to me as well. I have had to support many production systems, written in varieties of languages, over my tenure and in my experiences the systems that live the longest are those that are the most readable by new team members; people transition in and out and its important for them to learn quickly. And while a person's language experience matters to some degree, it is more the underlying domain that takes the most time. Languages that simplify on the number of solution patterns and focus on key ones being "idiomatic" helps to lower the mental load someone has to overcome to learning that domain. If you know C, Java, JS, etc. you can pretty quickly figure out how to read Go, and that matters.

Is Go perfect at this? No. I too would love to see some higher level functions exist for to help reduce boilerplate. For example, this proposal: https://github.com/golang/go/issues/45955 to add Filter, Map, etc. to slices. That seems like a practical set of functions to add to minimize boilerplate while at the same time not breaking away from simple idioms.