Honestly we are headed towards a disturbing height of inefficiency in software. Look at software today, 1000x less efficient than what we had in the 90s. Do businesses care? No, they focus on value. The average user is too stupid to care, even though all their RAM is being sucked up and their computer feels like shit.
The only thing that's keeping us from that hell is the "correct" part. The code is not going to be properly tested or consistent, making it impractical for anything substantial right now.
I don't know how the web does it. There are so many cool things being added. How do they keep the spec manageable? What if someone wanted to build a compliant web browser from the ground up?
That's not a concern of the people writing the spec, but Ladybird is making an admirable go of it. You can shed a lot of complexity by only focusing on the modern standards, and Ladybird has helped fix several bugs in the standards themselves.
There was a good reminder in the Hanselminutes interview with Shaundai Person about blogging for yourself. It was a while since I listened so I'm fuzzy on the details - all I remember is that I enjoyed the interview and there was some relevance to this topic.
Also, blogs are no doubt a major source of AI training, so maybe more worth than before.
I prefer stack traces in errors. It's gives so much more automatically so you don't have to worry about manual annotation. Stack traces and debug logs are the way to go. I like to use panics for exceptional conditions just for the convenient escape with the stack trace.
I think most of those are Instagram shoving it in your face. Yeah I'm a "Threads user", but only because of the inline feed in Instagram. I'm annoyed when there is a notification blip but it turns out to be Threads spam.
the shitstorms usually have a community behind it. Even if it sucks, it's supported and will be maintained to a point of it "working." If someone writes their own thing, chances are they won't go the extra mile and build a community for it. Then, when it comes to maintaining it later, it might grow untenable, especially if the original "tinkerer" has moved on.
This would be great if things like open source were more supported in the "real" world. Unfortunately, you're describing exactly why a community means nothing in this situation unless the community is giving back to the project. When the "original tinkerer" moves on, everything depending on that project breaks when everything else changes around it.
> It’s very similar to thread-local storage. We know how bad of an idea thread-local storage is. Non-flexible, complicates usage, composition, testing.
I kind of do wish we had goroutine local storage though :) Passing down the context of the request everywhere is ugly.
I like explicit over implicit. I will take passing down context (in the sense of the concept, not the specific Go implementation) explicitly everywhere over implicit ("put it somewhere and I'll trust I can [probably, hopefully] get it back later") any day of the week.
I've seen plenty of issues in Java codebases where there was an assumption some item was in the Thread Local storage (e.g. to add some context to a log statement or metric) and it just wasn't there (mostly because code switched to a different thread, sometimes due to a "refactor" where stuff was renamed in one place but not in another).
Most recently ive been bit by this with datadog. The Python version does some monkeypatching to inject trace info. The go version you need to inject the trace info explicitly. While the latter takes more setup, it was much easier to understand what was going on and to debug when we ran into issues.
Sounds very familiar. I was a Java developer for a long time, and in that ecosystem adding a library to your project can be enough for code to be activated and run. There are plenty of libraries where the idea is: just include it, magic stuff will happen, and everything works! That is, until it doesn't work. And then you have to try and debug all this magic stuff of how Java automatically loads classes, how these classes are created and run, and what they do. Didn't happen very often, but when it happened usually a full week was wasted with this.
I really prefer spending a bit more time to set it up myself (and learn something about what I'm using in the process) and knowing how it works, than all the implicit magic.
This is why I avoid Python. I started doing Go after looking for few solutions written and Python and I couldn’t use it.
Some magic values inside objects of recursive depth changing dynamically at the runtime. After working for some time with functional languages and languages with non-mutable structures I’m afraid of such features today.
Context is nice because it’s explicit. Even function header spills the detail. `GetXFromName(context.Context, string)` already says that this call will do some IO/remote call and might never return or be subject of cancellation.
Context's spread just like exceptions do, the moment you introduce one it flies up and down all the functions to get where it needs to be. I can't help but think that local storage and operations for Go just like Threads have in Java would be a cleaner solution to the problem.
The only thing that's keeping us from that hell is the "correct" part. The code is not going to be properly tested or consistent, making it impractical for anything substantial right now.