awesome_dude

So far AI has been a (genuinely) massive improvement for...

Search

It's reading my requests more clearly than (for example) Google's search input ever did, and it's got (some) understanding of how close the result (or fragments of results) are to what I want.

I can ask it about things I know about, and it can answer with strategies I hadn't thought of.

HOWEVER - I still need to understand the results AND AI can overreach - it can say (figuratively) "Oh you are searching for Event handling, therefore I will write a orchestration saga" - which, if I am not across, can get us both in trouble.

Further, we KNOW that AI has no (real) understanding of the responses - it's just token adjacency - and it fails basic logic tests

Current AI is just awesome natural language processing, but it's still got a ways to go to where I would say "It can replace people"

Edit: LLMs demonstrate (almost perfectly) the difference between correlation and causality. LLMs identify correlative patterns, but the job still needs (us) to make the causative judgments.

It's this that always makes me laugh - right wing people demanding people act like teams, and work for the common good...

When FAANG were over hiring, nobody was being given 4 day weeks, instead AIUI, people were just given meaningless work to waste their time with.

Employers have two modes, waste peoples time, or sack them

> In a few years, there will be hardware capable of running frontier models good enough for most things at accessible prices for even tiny companies.

I was going to say - the models are just going to keep growing at a pace exceeding the pace of hardware pricing/availability

But then I realised that, far more likely, there will be a plateau reached (again) where nobody is seeing gain, and at that point hardware will catch up

Have a look at the top of the files generated by protoc bud ;)

It's not in the git commit, it's in the files themselves - is that what you want for AI instead?

To be fair I've never used Laravel - but I do have a memory of code generators/scaffolders inserting files that made clear they were responsible for work

/*

* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).

* Do not edit the class manually.

*/

Which part of this is sympathetic?

> This is unrealistic. You seem to have moved to Go as an alternative, but I know because I've seen the complaints that Go doesn't satisfy that standard either.

It's a dig - you completely ignore the valid complaints about Python to instead focus on what you think will provoke me.

The problem (for you) was, from the very start, I bought up the pain points with Go.

I feel that pain to my soul - I was once threatened with disciplinary action for putting comments in my code

This timestamps proudly bought to you by the people at Acme - where time stands still.

Get your timestamp today!

I know this is a bit off tangent - but can you please convey that point to every damned dev/team that ends up with a freaking ".vscode" directory in their repo

When a paper is submitted to a reputable publication references are demanded.

You have to let people know where your ideas are supported, or even come from.

To do anything else is plagiarism.

AI isn't a co-contributer - but it should be referenced - just like a link to a Stack Overflow comment when that's the source of code.

Having AI referenced in the commit is (IMO) best practice - but only co-contributer attributes are available (for now)

I explictly say that NO dependency management is without problems, AND call out Go's attempts in my OP.

You came barrelling because your favorite tool is mentioned, and then, when you realize that it deserves the criticism you try and play that?

Maybe, just maybe, take an objective look at the real problem (dependency management) and recognise that, as stated, nobody has solved it.

> what I (and probably most of us virtualenv users) are saying is that there's a pretty broad swathe of projects where you don't encounter them.

Zero. The required number of problems needs to be zero - hence my OP

> I guess if you have a hard dependency on a particular version of python, it's going to be harder, but... why?

The bigger question is - why doesn't 3.9 compile and run 3.8

Further, in what world is targeting a specific runtime version in an enterprise production environment "niche"?

When you are deploying to managed corporate infrastructure, AWS Lambda runtimes, or strict Docker base images, you don't just get to loosely target "whatever Python version happens to be on the developer's laptop." You target an exact runtime version (e.g., Python 3.10) because language syntax, standard library features, and performance characteristics change between minor releases.

The fact that Python forces the developer to manually manage isolated directory symlinks (venvs) just to prevent local environment contamination — and that minor runtime mismatches can completely derail a standard onboarding experience — is a structural UX failure.

One compiler (gcc) - and it doesn't do it by default

Go has go vet - baked in and runs by default

I tire of your bad faith ignorance.

Funny - you said Go was worse - now you're saying Go's the same...

No - go.sum alerts you to the change - it doesn't prevent it.

replace directives are ok, but you need to look at why workspaces were invented to get an idea of their shortcomings (hint: people used to have a replace directive locally that they would accidentally push and that would break other peoples builds)

I don't think you understand the term "pinning"

go mod tidy will update your go modules whenever it feels it needs to and there's nothing you can do to stop it.

The workaround is vendoring, where you control the versions in a cache.

I used Python for a decade (professionally), gave up on it once I started using Go (professionally) in earnest - about 8 or 9 years ago.

I never liked virtual envs, having to remember where they were, what their names were, and what was installed into each one was a pain point for me.

This weekend I was trying to learn some AWS stuffs, and I cloned the official repo of example code which was Python. I followed the directions exactly and ... boom Python versioning issues... inside the freaking venv

Who needs that?

Why do I need to spend the better part of a couple of hours debugging a versioning problem? (FTR The problem turned out to be the repo was hardcoded to 3.8 and my local Python was 3.9.. or something along those lines - you are welcome to correct me, but that's what I remember of a painful waste of my time)

With Go I have backward compatibility guarantees - usually (there have been instances in the past where the backward guarantee have been broken AND the build process got broken hard for modules, with the claim that it was external and therefore not subject to the same guarantees)

> I see this sentiment a lot, and it doesn't match my experience at all.

My old HCI professor used to tell me - if users are complaining (or producing workarounds like post-it notes on their monitors) - regardless of how clean or elegant you think the system is - it's not.

You're saying you see people complain about it a lot - therefore it's a genuine problem.

Yeah - I assumed so - which makes the GP post... bizarre

Regardless of language - if you find a good, clear answer - blog the hang out of it - I for one have been searching for the right way to manage this, and it's not (yet) clearer - other than what I've said so far

Yeah - but that's the same as my final point - you have to know who is supposed to manage the error/log - all the way up (and down) the call graph

edit: I've just finished debugging a multi system chain - FE -> SNS -> SQS -> Lambda -> DynamoDB -> Lambda -> Webhook -> My poor code

My code has multiple layers - and I was trying to find where in the very long chain of calls the data was being mangled

It turned out that there was an unlogged error, which was mismanaged by a caller - there's no shade here - the caller was handling the error how it was designed to, but by not logging that there was an error - it took a minute to understand.

Not rust specific, and most certainly not a criticism of you - but I hate when people call a lib that errors, then just bubble that error up.

I mean the error is supposed to be tailored to the audience - I guess what you are saying is that you handle the error by saying "I called foo with X, Y, Z, and got this error back" in the logs - which your caller then also does - producing a log message of

ERROR: I called Foo with X Y and Z and got error: Die MF die

followed by

ERROR: I called Bar with X Y Z and a and got error: ERROR: I called Foo with X Y and Z and got error: Die MF die mf (still fool)

And so on and so forth.

If the counter is - don't log, that's fine, but you have to know where in the call graph that error state was reported to the logs

I think one of the key problems too is that a system level dependency is managed by people dedicated to ensuring the chaotic nature of the package they are responsible for conforms to the way the OS they are maintaining for has proscribed.

There's no real way to do that at a language level - we cannot have "Go has determined the package you are trying to fix has not met the versioning requirements proscribed so you cannot submit the patch to fix it"

What language dependencies do is what OSes would think of as "unofficial versioning" that is, an OS will let you install and run an unofficial version of some lib (we've all been there, right, multiple versions of some core library because one doesn't work with whatever you are trying to install), but they will not manage it at all.

Linters are available to catch you before you compile - with Go

Generally speaking there has to be a mechanism for optional handling of return values, in Go you can ignore everything (ew), you can use placeholders `_`, or you can explicitly handle things - my preference.

If you say "Well in C you have to handle the returns - I am not across C enough to comment, but I will ask you - Does C actually force you, or does it allow you to say "ok I will put some variables in to catch the returns, but I will never actually use those variables" - because that's very much the same as Go with the placeholder approach

edit: I am told the following is possible in C

trySomething(); // Assumes that the author of trySomething has not annotated the function as a `nodiscard`

(void)trySomething(); // Casts the return(s) to void, telling the compiler to ignore the non-handling

int dummy = trySomething(); // assign to a variable that's never used again

I welcome correction

Package management is the bane of nearly every language/technology

Nobody has "solved" it, and I don't think that there will ever be one (never say never, though, right?)

For Go we rely on developers of libraries to adhere to the semver versioning scheme accurately, and we cannot "pin" versions (a personal bugbear of mine)

There is a couple of workarounds - using SHAs not unlike the git commit hash to provide a pseudo version, and, vendoring (which is a cache of known dependencies - which brings with it cache management problems)

I had the misfortune of having to use Python with a virtual env on the weekend - it did not end well, and reminded me why I migrated away from Python.

Look at Perl (cpan) Java (maven, gradle) Ruby (gems) Go (dep, glide, vgo, modules) Rust (cargo) Node (npm, yarn, etc)

OSes too Redhat (yum, rpm, etc) Debian (apt) Ubuntu (snap - god why????)

And so on

Conversely - we tell people who are speaking in public to "Show confidence" - or in job interviews "Hire people who are confident"

We've also pushed back "The more a person knows, the less confident they are" - Dunning Kruger - often used to dismiss over confident people - points out that people are really confident, at first, then that confidence drops away, markedly, but it rebuilds (slowly).

That last rise in confidence is what (I believe) people use as a heuristic on the likely level of knowledge possessed by the speaker (AI or human)

Most engineers know, though, that overconfident people are toxic - the difference between arrogance and genuine confidence in the answer is incredibly difficult to define.

Yeah - I don't know /why/ but, as I say, I've been guilty of that myself, very recently, despite knowing it's a shockingly poor guide when left to its own devices.

Maybe because when it's right it actually expands my knowledge - there have been genuine instances where it's gone - something to the effect of - "Yo, there's this other idea for approaching the problem" which has turned out to be exactly what I was looking for?

AI uses a high confidence tone - likely because its training data is heavy on authoritative texts/reference books.

And it does get people into a lot of trouble.

I have got into trouble with it when it is extremely confident about something I am not very familiar with (as recently as two weeks ago with Claude). I have also had long drawn out "arguments" when I have known it's wrong based on my experience and intuition, and it has steadfastly refused to take my point (last week)

I have learnt to ask it why it was doing something that has turned out to be incorrect, as a post-mortem, and it's all apologetic and subservient and "never going to do that again" (but still does as soon as the context window shifts [eg. run git commands, or, yesterday, kept telling me to use commands that were explicitly communicated to Claude as not being available, and completely wrong - I was shifting from one tech stack to another and Claude kept telling me the original commands, not the new ones])

I'm expecting Claude to be a better search engine - I have spent literal years (if not decades) knowing that asking the right question is what's required to get the right answer, and LLM's natural language processing is what's supposed to make that easier than using Google or grep, or even Stack Overflow - but the reality is that I still have to be on my toes, especially when I am drifting into territory I am unfamiliar with.

Just FTR conservatives aren't the only ones on the Right

https://informationisbeautiful.net/visualizations/left-vs-ri...

Humans have always appealed to emotion - as part of their logical process.

Fear (emotion) is used (advantageously) to force us to check that something isn't going to break us

In this instance fear is being used to ensure that yt-dlp is not exposed to (genuine) concerns about the quality of bun that is openly being built making use of tools we as a whole know is problematic.

I agree with you that the statements are a bit over the top (that's an emotional response to their statements btw) and that (eventually) you would /hope/ that bun gets to a point where it's got some genuine reliability from a users perspective.

Edit: I see your edit to explain that the issue is ideology - but unfortunately (perhaps) that's not an improved stance - ideology has to guide us when we just don't know - it's a heuristic.