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.
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.
No, I'm referring to the "we're a massive enterprise and we don't make money by actually figuring out issues, so if service XYZ has troubles after 30 hours of uptime, then we'll restart it every 20 hours and problem solved" phenomenon.
Or the phenomenon where I piss blood explaining why having a p99 that is 30x worse than our p95 is maybe possibly a problem that should be looked at.
Or the phenomenon where concurrency exists, and so issues are no longer reliably reproducible, meaning everyone just throws their hands up and tries to ignore and downplay them as much as humanly possible. That is until a dickhead like me comes around, and does something like a scripted 300 restart cycle test overnight until a clustering resiliency defect finally reproduces, and i can capture enough debugging data that would never be possible on a live environment. All the while the product vendor is twiddling their thumbs, waiting for us to provide said data on a silver platter, because for some reason this completely stock issue doesn't reproduce on their end in a pretty much identical environment, or so they say.
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 :(
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.
There is a weird moment toward the end of the 1990s when Microsoft is trying to show their NT is a serious competitor in this space.
Traditionally this was a profitable niche, Microsoft would like to take a fat piece of that, and instead what happened is that Linux destroyed the profit margin. A million dollars overhead that would have kept a hungry UNIX® vendor alive on your project didn't turn into an extra million dollars on Microsoft's balance sheet, instead it evaporated because Linux is "free". And so then Microsoft lost interest.
Yeah, and one of the ways to show it was a serious OS for DoD projects was to have a POSIX subsystem, which had they kept it around, Linux would never have taken off on the PC, and there would be no need for WSL 40 years later.
The POSIX subsystem is a box checking exercise. The reason the box was there isn't satisfied but the box was checked and Microsoft hoped that's good enough. If you need "a Unix" and they give you NT and circle the stuff about POSIX you don't go "Oh, perfect" you ask them to fix the requirements document so that you can have an actual Unix next time.
WSL is Redmond going OK yeah, here you go, an actual Unix.
It was a requirement on government contract tenders. If you didn't support POSIX, you didn't get the contract and the government would have continued using SunOS or AIX or something instead of Windows NT. Remember that POSIX was designed to make these OSes somewhat interchangeable - they wouldn't order something they knew was incompatible with everything they already had.
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.
IBM mainframes added a UNIX subsystem in the 1990s, starting with UNIX for MVS, nowadays z/OS UNIX.
DEC's VAX/VMS became Open VMS when UNIX/POSIX support was added in the early 1990's as well.
Other mainframe systems added similar POSIX environments.
The way Windows NT OS linage works isn't something novel, it is how mainframes have introduced multiple OS personalities and virtualisation modes since the late 70's.
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.
> 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.
How do you know when they're finished though? It seems like you're need to have an additional channel or atomic boolean per goroutine for this, which just increases the amount of organizational burden.
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.
* Orthopaedic Knee Implants (75% of Global Supply)
* Acute Hospital Ventilators (50% of Global Supply)
* Contact Lenses (World Leader)
19 of the world's top 20 pharmaceutical companies operate manufacturing, R&D, or biopharma facilities in Ireland; this compromises over 50% of all physical goods exported from Ireland, totaling well over €100 billion annually. Needless to say it's also the pivotal manufacturing hub for high-demand GLP-1 weight-loss and diabetes treatments (like Mounjaro).
Ireland is among the top global exporters of antisera, blood fractions, and complex cell cultures, making it indispensable to global healthcare infrastructure.
Ireland is the absolute world leader in dairy science per capita, and produces roughly 10% to 15% of the entire world's infant milk formula, with estimates indicating that roughly one in ten to one in seven babies globally consume formula manufactured in the country.
That's an Island of less than 5 million people, 1/8th the size of Texas, that was basically bypassed by the Industrial Revolution and had no colonial benefit. Now extrapolate for a second and imagine what Germany is manufacturing.
I'm referring to the countries borders consisting of sea, not neighbouring countries. More to the point, all industries I'm referring to were established prior under the constraints of the stated population.
The population of the 26 counties only hit 5 million in 2021, in the midst of lockdown. It then surged massively with global instability, with a 2.2 per cent increase in 2022 alone with the first round of Ukrainian refugees forming the majority of the 117,000 added to the population count.
No, the exact opposite! A high percentage of ghost jobs indicates that there are very few actual jobs open in the field, which suggests an oversupply of workers.
if the listings are open for the reasons OP stated, then yes it does indicate a shortage. if companies hired all the SWEs they wanted they wouldn't still have the listings
Let's say I have 50 employees working for $100,000 each.
Why would I not want to replace 25 of them that are willing to work for $50,000 each if they are producing anywhere close to the same quality.
In a case like this always open job listings are a warning to others.
Also there is something called market sampling. Where you put up these job openings and look at the quality of applicants in relation to the employees you already have to ensure you're on the right track internally.
Warning: This company will replace your ass so far without regard to your actual abilities or their current profitability.
Companies do not have human rights. They are a pleasant fiction the population allows because it's more effective than not having said rules. We the people can revoke those rules the moment the meta-idea of corporations no longer serve the public good.
In the US at least we seemingly have come to believe the corporation is the ultimate organism and all rights should be sacrificed for its eternal cancerous growth.
Not every company is a hungry startup trying to hustle their way to a billion dollars. Businesses also value stability, and stable labor is a big factor in pretty much every other field.
You don't get stability by laying off workers every 2 years .
because the pie grows, and if you are in a competitive market which most businesses are in, you don't want to lose talent and market prestige to your competitors
> if companies hired all the SWEs they wanted they wouldn't still have the listings
I honestly can't tell if this a troll or not, but in case it isn't:
Because "number job openings" are used as a signal of company health, Ghost Jobs are far far more common than job listings which companies intend to hire from!
Is this true? some of the highest aura companies have very limited jobs open to signal exclusivity, or have such a high bar that they are in perpetual shortage
Big companies never hire all the SWEs they want, because there is always attrition. At a certain scale, there will always be people leaving and a constant need to backfill.
Not necessarily indicates any 1 thing; it can be fake job posts to signal growth, could be an extra picky hiring manager, even a decrepit company that forgot to close it.
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.
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?
If there were examples made of legal consequences I think that would at least change the behavior if not solve the problem. Maybe liability should rest with the company that owns the infrastructure running the AI. For most consumer situations that would be the companies developing the models.
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.
And in general, especially with something like C, the correspondence between the compiled code and source code isn’t very “lossy”. You don’t get one-to-one correspondence but it’s not too bad and you’re not introducing massive uncertainty by running it through a compiler. With LLMs though all bets are off… you’re not gonna know what you end up with
What you say is true, the comparison indeed doesn't hold.
But is it relevant? does it matter from a product perspective if LLMs are non-deterministic. You don't need to one shot the correct result, english is ambiguous and LLMs non-deterministic, but you can iterate.
If it's possible to iterate fast and cheap enough, even ambiguous language can produce the results you want, given enough iterations.
There are a lot of ifs and buts here, just a thought on the compiler argument.
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.
But from a broad market and product perspective, for most things you don't need to look at the code. If the product kinda does what it's supposed to.
For example, in my game projects I don't look at the CMakeLists anymore, or python scripts that move assets here and there, I can run my game and just see that it did what I expect it to do (renders assets etc).
Similar with frontend, I don't care that much what the code looks like anymore, mostly that the site looks and feels as I expect it, and the correct network calls are happening.
TLDR; I'm thinking there are levels to this, in some projects it matters, in others it doesn't, it's kinda two different things. Programming wasn't replaced, LLMs just brought a new paradigm of doing things on the side.
I'm just rambling at this point, my thoughts on this are not super clear, sorry for that :D
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
There is also a predictable relation between the input and output of a compiler w.r.t. the semantics of a programming language. Natural languages are ambiguous leaving room for the implementation to diverge that may not be obvious at first glance.
There are also plenty of things a compiler might not expose that end up being ambiguous. For example, C++ doesn't officially have a restrict keyword, so how can you express the fact that two memory regions never operlap and can be optimized? Unfortunately the reality is that if we had a language capable of truly expressing the programmer's intent we'd end up with a monster
reply