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.

Back in the day, the argument was that compilers produce unreadable assembly, so people used to writing assembly were arguing against the use of compilers.

Compilers also had bugs, so we still had to debug the assembly to understand how to fix the problem. Nowadays, almost nobody has to resort to those steps, except of course compiler developers. But that is just a testament to the quality of compilers.

Comparing LLMs to compilers is a take I often see, but I am not sure the comparison quite holds. The problem is that LLMs are inherently non-deterministic, so we always get a different output on the same prompt.

Maybe if LLMs are powerful enough it won't matter. I doubt it but we will see.

This assumes that there is excess power at some point. This will soon become unrealistic: we either need power for data centers during the day or charging vehicles during the night.

The solution works only to keep a steady production of electricity, but if the demand would require full output all the time then these "mechanical batteries" don't help.

Not the OP but I guess the statement implied cultural and lingual unification which implies erasure of other cultures and languages. We do have to work on being understood across the cultural and lingual division but the differences should be celebrated and welcome, even if they do cause occasional misunderstandings.

I don't really understand what you mean... are you saying that the entire industry is parroting a fantasy that they all know is fake. So, everyone is faking to get more funds?

Unfortunately, I don't think that's true.

It seems our experiences are different.

Back then, when working with SVN, we had sites in various countries, with under provisioned VPNs between them. Loading up a single file history could take 15 minutes. I am not joking. Every single operation took ages, so really, any DVCS would have won in that situation, regardless of its approach to branches.

If the SVN server would sit in the same building then I guess the branching would have been the main selling point, but it was not the main selling point for us in that situation.

What I don't understand is, why not replace middle management, marketing, CTOs, CEOs and the like. Surely, LLMs are better at producing high quality looking slideware and vaporware than they are at producing software.

Heavy sarcasm here if it's not obvious. Of course I know why.

Not exactly decentralization but distribution was the main selling point.

In comparison to SVN and other non-DVCs git did not need to continuously talk to the central server for history, "branch" creations, unlocking/locking files before changes, etc.

Linus wanted a DVCS, but they wanted centralization and licenses were expensive, so he decided to launch the git initiative where he provided scaffolding and the rest came from contributions.

I agree with your criticism of "the good enough" and "done with taste" dichotomy.

I would like to comment on this, though:

> that only want simple, that finding the most blunt approach is the only way. It has felt tasteless. Anti-ambitious.

I am always aiming for simple. If it's simple, it's maintainable and can be easy to reason about. Doing that is hard work, though. I used to spend three iterations to achieve it: functions are simple, easy to reason about, properly named and composable.

It's the opposite of blunt, though, so it might be that you meant something else with the term "simple" :)

The future is Borg.

Well, yes.

You can't just not show up for work and call in sick. Within the same day you have to call your doctor and explain the symptoms and they have to start the paperwork for the sick leave. Even if it is for a day.

For a cold or a cough you would not get sick leave, though.

The sick leave has to go through the healthcare system. That said, there are doctors that would just blindly approve, but it's not exactly a norm.

A lot of those sick days are also childcare.

Possibly, although I have to say that I get PRs now where it's clear it's a miss by the LLM and was generated by a human who did not take the time to understand the subject matter.

In the past, a human producing humanslop would get a serious talking to, but nowadays it's apparently a valid excuse "well, an LLM generated it". This approach is placing a huge burden on the reviewers, much more so than in the past.

If it happened just once, yes.

How is 5m easy to achieve? Asking for a friend.

This story is so silly it must be true. Thank you, made me laugh out loud.