mukunda_johnson

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?

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.

Pretty neat. I would have expected it to take a bit longer, but I suppose the optimizing step is the real magic in a compiler.

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.

No doubt the most errors in my SQL syntax when writing migrations is the extra comma.

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.

> 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 prefer light mode for most things, but use dark mode anyway to save battery on an OLED Screen :)

I don't think so. If you find otherwise (without any stupid MX/forwarding magic), let me know! Silly that the price keeps going up when I'm basically only using their spam filter.

No idea about Youtube accounts.

Those kinds of puzzles are part of the CCAT test (annoying test for "cognitive aptitude") and I used this trick.

In Doom, < and > are strafe, and it works here too.

TIL that Conway's game is turing complete. Wow.

Wait a minute, this isn't an AI article...

Deciphering patterns in natural language is more complex than these puzzles. If you train your AI to solve these puzzles, we end up in the same spot. The difficulty of solving would be with creating training data for a foreign medium. The "tokens" are the grids and squares instead of words (for words, we have the internet of words, solving that).

If we're inferring the answers of the block patterns from minimal or no additional training, it's very impressive, but how much time have they had to work on O3 after sharing puzzle data with O1? Seems there's some room for questionable antics!

Honestly I'm concerned how hacked up o3 is to secure a high benchmark score.

I always smell foul play from Sam. I'd bet they are doing something silly to inflate the benchmark score. Not saying they are, but Sam is the type of guy to put a literal dumb human in the API loop and score "just as high as a human would."

I'm surprised this is well defined behavior.

I usually use Echo which does have an error to return from handlers, but I don't think it's necessarily the wrong thing unless you're writing a library. I used to avoid panics with the same mindset that they aren't supposed to be used like exceptions, but I've found that panics are a clean way to handle a bulk of error cases that are "log and retreat", centralizing the process with some syntactic sugar to not have to check err != nil everywhere. More of my thoughts here if any are curious: https://blog.mukunda.com/cat/2022/dont-be-afraid-to-panic.tx...

I think one thing that could help if the codebase wants to avoid regular panics is more syntactic sugar to help error bubbling, like Rust has.

Adding error checks everywhere when you don't care about them is one of the ugliest things about Go.

What I do is have a utility package that lets me panic on most errors, so I can recover in a generalized handler.

x, err := doathing()

Catch(err, "didn't do the thing")

The majority of error handling is "the operation failed, so cancel the request." Sure there are places where the error matters and you can divert course, but that is far from the majority of cases.

Who knows what the future holds? As a SWE you are expected to adapt and use modern technology. Always learning is a part of the job. Look at all the new things to build with, frameworks being updated/changes, etc. Making things easier.

LLMs will make things easier, but it's easy to disagree that they will threaten a developer's future with these reasons in mind:

* Developers should not be reinventing the wheel constantly. LLMs can't work very well on subjects they have no info on (proprietary work).

* The quality is going to get worse over time with the internet being slopped up with the mass disregard for quality content. We are at a peak right now. Adding more parameters isn't going to make the models better. It's just going to make them better at plagiarism.

* Consistency - a good codebase has a lot of consistency to avoid errors. LLMs can produce good coding examples, but they will not have much regard for your how -your- project is currently written. Introducing inconsistency makes maintenance more difficult, let alone the bugs that might slip in and wreak havoc later.

Agree, some domains are a big gray area. I used it to understand some accounting jargon while diagnosing a software issue, but anything that is not very commonplace is littered with misinformation, so you have to doublecheck. I find it more useful to gain a direction or lead on a topic rather than answers directly.

Of course many executives don't deal with the obscure stuff day to day (e.g. regular stuff people actually get paid to deal with) and think that LLMs can turn anyone into a superhero overnight :) The amount of times we were told that we were "putting our heads in the sand" regarding the advantages of AI was very annoying.

Are people getting paid to promote Kagi in here too? Like, you have to log in to use it. Already that makes it worse than Google.

I like that--generally I agree that LLMs inflating text is not adding value, but it is a great point that LLMs can help bridge language barriers.

I said the same thing to a previous company before I was let go. Confused why they were butchering their business strategy in favor of a gold rush.

The main benefit of LLMs was already abundantly clear: literally just chat with it in day to day work when you can. Ask it questions about accounting, other domains it knows, etc. That's like up to 10-20% performance increase on tasks if you align OK.

Still, they were in search of a unicorn, and it was really tiring to be asked regularly how AI could help my workflows. They were not even spending a real budget on discovering "groundbreaking" use cases, meanwhile hounding us to shove a RAG-bot into every product they owned.

The only thing that made sense was that it was a marketing strategy to promote visibility, but they would not acknowledge that or tell us that directly (but still--it was not their business strategy to get NEW customers).