prerok

Well, it has not even reached 0.1.0, so the language is still in early development phase. But it has interesting properties, so I would recommend experimenting with it.

In my country we call the general middle school (the one that results in no specific professional qualification, i.e. a prep for university) a gymnasium. Physical education is only a small part of it, so it's interesting that we continue to name it thus and has the same origin as a gym.

Actually, I think we are in agreement, just saying things slightly differently.

I feel your pain and have had the same sort of issues. I once spent 3 months on a hard to reproduce issue to prove it was the closed source software from a vendor that was at fault.

Bugs have definitely been present since the start.

However, since we moved away from waterfall (not that I really miss it), systems are not that carefully designed anymore. Even if at the start the system is well designed, careless additions start creeping in and before you know it there are bottlenecks and race conditions everywhere. I think this was caused by the "move fast and break things" and the reduction of QA teams.

In other words, if it works in my small and non-representative environment, ship it. If it breaks, someone will tell us and we will fix it. I don't like this either, but yeah, it's been like this for a while now.

Latest development is IMO moving even more in this same direction, so it's getting worse rather than getting better :(

Are you referring to "move fast and break things"?

If so, it's definitely newish for those of us who started programming twenty+ years ago. Back then waterfall was the way to develop applications. Once it was burned to CDs or DVDs, that was it. We could not afford shipping broken things.

Ever since internet became ubiquitous we moved to on-the-fly patching for installed software and fast deployment cycles on cloud.

That said, the lack of forethought in design and backward compatibility is nowadays definitely on the rise and occurs likely on an order of magnitude more often.

Most apps don't have it, so you might not be used to it, but have you never wished that you could undo the changes you made after you restarted the program?

Moreover, the vim history tracking is amazingly advanced. It's almost like a mini version control system. I highly recommend getting to know it.

Indeed. We use waitgroup. But... I guess it has to be used anyway, if you want to ensure that all started goroutines really did exit cleanly.

That's way way later. UNIXes were the ones running in 70s and 80s. WindowsNT and Linux only later came to take a slice and, still later on, Linux won the day. How anyone would consider UNIX "niche" is beyond me.

Sorry, what? Most of data centers were running a UNIX operating system back in the day. What operating system do you think they were running?

The easiest way to deal with receiving from a channel is using range over it in a separate goroutine. The for range finishes only when the channel was closed and all values were read.

Of course, that won't work if you want to receive from several channels in the same goroutine. For that you can use select with receive assigning to two values and the second one is set to false if channel is closed.

So, I never really had issues on receive side, I agree with the send side, though. The solution I used when sending from multiple goroutines is to wait for the senders to be finished in the "main" goroutine and only the close the channels.

But yeah, it does require some thought to be put into how this is all organized.

It's actually the other way around. All we have is money that we stole from the colonies.

If the car companies actually go down the drain I have no clue what products of note we would still be producing that would continue to bring money in. So, I think our goose is cooked here in Europe.

I agree with that, just responding to the parent who wrote that their company keeps the hiring listed. So, in their case it's true but in other cases it is not.

I agree, I should have written a bit more, apologies.

That's fair but still indicates shortage, no?

I also don't like the term misalignment because it sounds innocuous but is in fact much more serious.

However, I have to say I also do not appreciate comparison that is continuously drawn with coworkers. As you say, it's a question of accountability but when the main agent will maliciously instruct the sub agents, whose fault is it then?

Yes, the person running this crap is at fault, not the CEO that's shoving it down their throat and definitely not the company that produced the AI.

Sorry for the rant, but seriously, if a person's goals do not align with the team's or company's we part ways. What do we do with AI? Stop using it?

The trouble, as I see it, is that we still have to look at the code before we run it. Even if it is a one-shot script. And it's just because you never know if there isn't some "rm -rf ${undefined_variable}/" lurking somewhere in there. And if I have to check it then I would very much like it to be readable.

I mean, I do get your point, sometimes it does not matter. Sometimes we could just YOLO it. But... if that then causes a big problem, even if at only 1% of the time, then I don't want to risk it. But that may just be me. YMMV

I think it matters, because nowadays we don't look at assembly any more. I mean, I don't recall the last time I was tracking down a compiler bug but it's definitely been more than 15 years ago.

We do have to look at the LLMs' output, though, and, as you already pointed out, iterate to get the correct results. What this means is that the output must still be readable, must be analyzed by someone and I don't see it going away any time soon.

The problem is that the analysis is not cheap. Sometimes, with boilerplate, it is easy, but many times it is not and that's where we get only slight gains by using LLMs.