yeah, we always joked among my left-leaning friends who were cool with any sort of gender expression or style, pierced and tatted, didn't really judge drug use or aggressive music, didn't value respect for authority that our kids were do their edgelord rebellion phase by being regressive conservatives, and I don't doubt that happens.
Ultimately, "what will make people like my mom unreasonably mad?" is a compelling thing for some young people (and some older! I know boomers who seem to like MAGA in part because it pisses people off who they view as stuffy and stuck up).
I respect "we're going to try not to add features until we have to and have a plan that we like" as an approach to a practical language, vs "we're going to plan to support everything normal modern languages have".
It isn't the best approach to language design in theory, but they did try to build a language that isn't impossible to change, and to be fair the mix of language features they chose didn't have any good more successful examples to borrow from, so waiting for enough practical experience to make the relevant trade-offs on practical grounds isn't the bare naivety that some people seem to take it as.
I totally get that. Java is my favorite language for exactly that reason. They are a deliberate "late mover language" and adopt what other languages have proven right.
But looking at how adamant Go used to be on the whole "No Generics" stance and the path and the troubles they are having... it all seemes so preventable?
Does it? It was only preventable by not releasing Go, which isn't exactly the greatest of solutions.
As you know from when Go was first broadcast to the world, they hadn't figured out how to make generics fit[1]. It is not like they weren't trying. Ian Lance Taylor is regarded for beginning work on generics before anyone outside of Google had even heard of Go. "In short: not yet"
What was surprising is that after Go was released as an open source project, nobody across the whole wide world ever came up with a workable solution. You can sense the optimism in that original announcement that later turned to "Go might never get generics" dispair. As you'll recall, it finally took convincing Philip Wadler (of Haskell and Java generics fame) to help. Without that lucky break, which almost certainly never would have happened if Go was still some basement project used by nobody, Go probably still wouldn't have generics.
More like no one on the world was able to change their mind, and then they had to ask help to someone that could already have provided help before Go released 1.0 version.
"They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been
well-served to spend more time with CLU and C++ concepts earlier."
Quite right. If the Go team somehow magically had the right technical background Go would have had generics earlier, but they didn't and weren't going to magically get it, so we're back to the only preventable way was to not release it at all.
But one would think that of the billions of people in the world that someone outside of the Go team would have had that familiarity to quickly change that, but no proposals came from that direction for over a decade and a lot of begging. I suppose those who had the chops were too busy constantly posting on HN about how Go doesn't have generics to lend their expertise. Priorities.
It's great to reflect back in hindsight about where you failed, but it's always easy to see where you failed after someone else finally shows you the way. The simple fact that the Go team did not have the technical capability to be able to add generics at the time remains. Being able to create a relatively popular programming language (or set of popular programming languages for some of them) certainly does not imply that you are a programming language expert. There may even be an inverse correlation. Those who show to be programming language gods appear most likely to end up creating esoteric languages that end up on the pile of languages that remain unknown and unused.
Go is basically a mix between Oberon-2 and Limbo, which we all know where they landed on the adoption curve.
Without the adoption success of Docker and Kubernetes adding wind to Go's sails, Go would have landed on the island.
They were not lacking in skills, rather politics, and there is a public talk from Rob Pike where he mentions even the Go 1.18 generics would not have landed if it was for him.
> Go is basically a mix between Oberon-2 and Limbo, which we all know where they landed on the adoption curve.
Exactly. You might say that Wirth, Mössenböck, and Winterbottom had some programming language chops, bringing some new ideas to the world, which is in line with the observation that those with programming language skills end up creating languages nobody uses. In fairness, Pike was involved in Limbo, but his only claim to fame was pressuring Winterbottom to add garbage collection to Alef, thus Limbo.
> Without the adoption success of Docker and Kubernetes adding wind to Go's sails, Go would have landed on the island.
Fun story, but no. Those projects chose Go because Go had already gained traction and was thought, in that moment in time, that it was going to be the way of the future.
It is true that Docker is often credited as the first major success story, but Hugo, etcd, InfluxDB, etc. were all released around the same time, never mind the long list of projects that never gained popularity. The language was already being widely used by the time Docker showed up. Go didn't need a major success story to get on the radar. It had Google's marketing power behind it, or at least that's why most believe it was able to become popular without having any breakouts to its name.
> They were not lacking in skills, rather politics
These are not separable concepts. Politics are the result of lack of skill.
Really wearing the team's t-shirt there, Go was barely proven on the language adoption battlefield when Go heads preverted the direction Docker and Kubernetes were going, it wasn't even 1.0.
Lots of languages are full of dead projects that never gained notoriety.
In fact, YouTube downloader which is another "success" only happened, because once again, it was a gopher that forced a RIG, it was working perfectly fine.
> Go was barely proven on the language adoption battlefield when Go heads preverted the direction Docker and Kubernetes were going, it wasn't even 1.0.
Exactly. All these projects chose Go many years before anyone, outside of Docker, had heard of Docker. This idea that Go was some kind of underground language until Docker and Kubernetes arrived at which point everyone jumped on the bandwagon is simply not true. Go was already quite popular by the time Docker was released, as evidenced by a whole lot of other projects that became popular themselves being released at the same time. Those projects wouldn't have been able to have been released when they did if they waited for Docker's success to jump on the Go bandwagon.
> Lots of languages are full of dead projects that never gained notoriety.
No there aren't. Not where the language is on the heap of languages nobody has ever heard of. Oberon-2 and Limbo didn't fail because they never found their "Docker", they failed because nobody used them in the first place.
> it finally took convincing Philip Wadler (of Haskell and Java generics fame) to help. Without that lucky break [...] Go probably still wouldn't have generics.
Small correction, I think:
My understanding is the core Go team was already well on its way to doing generics before Philip Wadler became involved, though he and his colleagues were later very helpful.
From Wadler's "Featherweight Go" paper [1] (the first draft of which seems to have been uploaded to arxiv.org circa May 2020):
Recently, the Go team mooted a design to extend Go with generics [Taylor and Griesemer 2019], and Rob Pike wrote Wadler to ask: Would you be interested in helping us get polymorphism right [...]
and:
It took us several tries over many months to formalise it correctly.
Well before that, doing generics was one of the main focuses in the GopherCon keynotes/announcements in 2017 and 2018 by Russ Cox [2].
The August 2018 generics design [3][4] was very detailed, and my recollection is most people in the Go community at that point believed the core Go team was going to make generics happen, even if the team and community were still iterating on the exact design.
Of course, that design improved over time, including thanks to Wadler and crew, but I think it would be overstating things to say that probably nothing would have happened without Wadler.
Go without generics was ok. I say that as a fan of generics in other languages.
There is room for languages with simpler feature sets.
It takes a strong leader (and the good and bad that comes with that) to continue to deny features. Go had that. Does it still? (I genuinely don't know.)
I'm not sure what Go's value proposition is now.
Developers can't pick it up in a week, as it used to be. Maybe that's okay too, since Go already has critical mass.
Go value proposition for me, when developing with Claude code: 1) fast compilation times, faster iterations, 2) user friendly to install, one single binary per platform, 3) feels safer than JavaScript/typescript, which have too many npm vulnerabilities. Go comes with more functionality included, less need to use 3rd party libraries.
I don't think any of the new additions to the library have seriously made the learning curve more difficult. I suspect that most projects don't use templates at all.
There have always been parts of the standard library I'm not familiar with. when I read code that uses it, I just go read the documentation. Now the standard library is just larger.
> Go without generics was ok. I say that as a fan of generics in other languages.
Well kinda. I found it very annoying every time you want to print a sorted map which keys are strings that you could not abstract the operation. It felt like paying a stupidity tax. (And I quite like go. It’s the only language where write once run everywhere actually works. Cross compiling for all targets is as easy as creating a local binary)
I don’t feel like the learning curve has shifted dramatically for mainstream development. Besides generics—which tend to not show up that often in app code even now—I can’t think of any substantial language change since I Iearned it in 2014. (Well, modules, but that’s more tooling.) Where I do see the shock is jumping to def of a std lib function and landing in indecipherable type soup.
Go never was "no generics". It had generics rusted in from the get-go, but never implemented them as it was a complex feature and one that made the compiler slower. Im glad they waited. Compare to PHP, where every feature is bolted on and then you end up supporting it forever.
A very common trap I find myself falling into is forgetting that there's a difference between the language, and the most common compiler/interpreter implementation.
It's a very practical simplification since 99% of the time, that's what we use. 'It's in the language, we just don't use it' does sound like copeful technicality, until it isn't and it's an actually impactful difference.
The problem is that when you don’t have a cohesive picture of how things fit from the outside, it becomes really hard to evolve the language in a way that makes sense and doesn’t break existing code. Data storage and languages share this unique property that the past impacts your decisions and what makes is possible in the future in a way pure logic doesn’t struggle with.
And this is -exactly- one of the reasons they didn't accept or continue with a sane proposal for more ergonomic error handling. I like go, but this was the one thing that I kept feeling like I was wasting so much time dealing with.
While the proposed slightly reduced the token count, saving the average typist approximately 1 second of time if they don't have an autocomplete editor that types it for them, it doesn't change anything about the mental model where the real time is actually spent, so is it really sane?
Worse, it is dependent on the error type, but errors are not always of the error type. Not even Go's own standard library consistently returns errors using the error type, never mind all the other crazy things you find in the wild.
That doesn't sound sane at all.
It is true that Go not having any real kind of superpositions or side channels makes stealing popular ideas from other languages impossible (it already has both well-known error handling methods that do not depend on those properties). But a sane proposal would be designed with that in mind.
Reducing syntactic noise is about legibility, not writing ease. The error boilerplate as it exists interrupts the actual logic and makes most of your code read as sad paths that might never execute.
Of course if you want something less specific to errors, we already have do-notation as an excellent example to look at. And you can't say that's more complex for users than what they did with iterators.
> The error boilerplate as it exists interrupts the actual logic and makes most of your code read as sad paths that might never execute.
Yes! You have to think through and account for edge cases. "Might not" is the same as "might." Those branches might execute.
I have been on many projects over 25 years of software development. Projects that take error handling seriously tend to be better all around. Happy-path coding is naive.
In the overwhelming majority of cases, you want to trivially send the error up the stack to be handled, so you don't want to incur the noise in the middle of your business logic (and indeed doing so obscures the times when error handling is non-trivial!). e.g. Scala handles all error cases with compile time checking (in fact it tends to take error handling much more seriously), but you don't have to write (or read) the trivial case.
> In the overwhelming majority of cases, you want to trivially send the error up the stack to be handled
There is no case where you would ever trivially send the error up the stack.
First, if your function doesn't have any meaningful information to add, you need to seriously question why the function exists. It is almost certainly not adding anything of value and the function that originally produces the error can just as well be called directly. No need to trivially pass an error when the useless "middleman" function doesn't exist.
Second, even if you still decide that a function that doesn't have worthwhile information is still worthwhile having, if you pass someone else's error straight through then you become forever coupled to the implementation of someone else. If you, for example, pass a SQLite error and then later decide you want to use Postgres, now you have to emulate SQLite errors every time Postgres produces an error, bringing you back to square one while also having one hell of a confusing API. Unless you hate other programmers and are purposely trying to make their life a living hell, the only sensible approach is to produce new error values at each step so that you can maintain stable sentinels/types.
A good language solution for errors might make it look like you are trivially passing an error up the stack while using some other method to attach the necessary metadata, like we see in some other languages, but nobody has yet figured out how to make that fit into Go. It is generally agreed upon that Go would greatly benefit from this, but until someone rolls up their sleeves and solves it...
Functions exist first to give names to conceptual blocks, and should generally be defined by "level of abstraction." i.e. you give a name to some task that then perhaps calls some low level data validation or manipulation functions which can return errors. Your business process might not care which task had an error, so it just bubbles up to the higher level coordinator (e.g. a handler just returning errors to a router).
You do not need to have new wrappers at every level. That's what interfaces are for. e.g. if all you're going to do is retry up to N times and log, and you don't need special handling, you just call String() or whatever. But you still want libraries to return domain errors so that you can handle them if you need to, or for tests, etc. And you can have some layer in the middle to make like SQLError or DatabaseError.
Right I'm saying Scala does exactly that, and has libraries that e.g. propagate stack traces across fibres automatically and invisibly. There's prior art to observe. It's not some mysterious unsolved problem.
> Functions exist first to give names to conceptual tasks
Right, and conceptual tasks will almost always have information that is usefully attached to an error. There are exceptions, but even in those exceptions you still have to ensure you don't leak implementation details, so you still cannot trivially pass the error through.
> Your business process might not care which task had an error
That's true, but you would never write upstream functions with the business process in mind. That is for the downstream functions to determine. Doing so would couple an upstream function to the business process, making it difficult (maybe even impossible) to use again when the next business process wants to reuse it, which would be complete insanity. A function is written to provide what makes the function useful for the sake of the function itself. It is up to the caller to decide what facets of that are useful for the business process being implemented downstream.
> You do not need to have new wrappers at every level.
You absolutely do need them. The language can work to hide that they are being created, but that does not preclude the necessity of them. This is most definitely a solved problem in other languages, but it remains that nobody has figured out how to take those ideas and apply them in Go. What was done in another language cannot be lifted wholesale and simply dropped into Go. The world is not quite so simple. It remains an unsolved problem in Go.
And understandably so. Who has time to work on solving the problem when there are comments on HN complaining that nobody has solved it yet to be made?
> In the overwhelming majority of cases, you want to trivially send the error up the stack to be handled
Maybe so, but for JVM languages, this "trivially" includes a stack trace. Go doesn't offer that for normal errors and there was no clear path to getting it. The need for contextual clues when debugging, and the community and then stdlib settling on error-wrapping as the way to do it, makes "simply return err" not a sane default anymore.
That's just pointing out another layer of noise Go introduces. Here again in Scala, you can get stack traces for free with no extra syntax with value-based errors. There are already solutions for doing these things that have been used in anger for many years.
In a language that takes error handling seriously, you have domain types for errors, type checking for exhaustive error handling, and you get info like a stack trace out of the box.
Ignoring the stack trace matter, which is explored in the sibling thread, it seems to me you're really taking issue with two of Go's language design choices that aren't specifically about errors: structural typing and the lack of proper discriminated unions.
There is nothing special about an error in Go, and there is no type hierarchy to anchor them against anyway. An error can be a struct{} carrying no value at all, or simple integer with no way to carry context, etc. Error-wrapping is the solution that has been devised to work within these constraints, but there's no obvious way to compose that with the various ideas around reducing boilerplate. For a point of comparison, Rust's anyhow crate was able to square this circle by adding a blanket trait impl for Context, but Go has no equivalent for that. (Also, Rust's ? operator is implemented using unstable components, allowing the details to evolve even while the feature itself is usable in stable Rust, something which also has no equivalent in Go).
As to the lack of discriminated unions, I agree wholeheartedly. There have been some proposals recently to get them into the language, with various levels of conservatism and cohesion with the rest of the language, but a lot of them are faltering on the "every type must have a well defined zero value" issue (yet another design decision that doesn't necessarily have anything to do with errors).
As an aside, the "every type must have a zero value" is another level of insanity akin to pi must be 3: tempting to want it to be true but disastrously wrong. You're basically making known good practice (RAII/make invalid states unrepresentable) impossible, especially when you combine it with the lack of if-expressions. It also breaks parametric reasoning since now a function `() => a` exists.
I had to argue about this years ago with a coding standard pushing to define local variables at the top of functions and zero initialize them in C. Why default to null pointers or worse (invalid ints/structures) when you could make use of uninitialized variables be a compiler error instead!?
Every value must have a zero value was congruent with the dynamic languages of the time, which is signifiant as Go was designed to "feel like a dynamic language" that was able to handle production scale (i.e. something that could handle Google-sized loads). There is a good possibility that Go wouldn't have even had a static type system if they had figured out how to make dynamic typing fast.
That may seem out of place in the world you live in, but Go was created in a world where Python, Ruby, and Javascript were the languages all the cool kids were using. Go was intended to be the language for C++ programmers who had to use C++ for performance reasons but wished they could use Python instead.
Insanity, perhaps, but Go was designed to solve a problem for the world it lived in. You don't get to choose your circumstances. For those living in paradise, they can use the languages designed for their world.
Technically, Java has the same rule, it's just that all user-defined types are reference types, and so the zero value for them is always spelled "null". I'm not sure how Scala pretends otherwise, but I have worked with Kotlin, and non-nullable object fields and method arguments are always a bit of a lie, since the underlying JVM machinery permits, and defaults to, null. (Despite the original authors of Go being unfamiliar with Java, they do seem to have settled on a number of the same decisions.)
Personally, I'm fine with discriminated unions always allowing "nil" in Go, since IMO the most sensible way to implement them anyway is as a special case of interfaces. Not everyone feels the same way, though.
> Go doesn't offer that for normal errors and there was no clear path to getting it.
It does offer that for normal errors if you pass those errors via exceptions. Although you're right that using exceptions for error handling is pretty weird and generally avoided in Go, much to the chagrin of Java developers.
The Upspin experiment, which eventually shaped the error additions that did make it into Go, showed a clear path to getting it in errors themselves, but it also revealed that nobody actually uses them when available. The research found that even with stack traces attached, developers didn't bother looking at them. Thus why that bit didn't make it into Go.
Yes, I don't think stack traces are a silver bullet. They tell you the path taken through the code, but rarely do they tell you why that path was taken. I don't know what Scala stack traces look like specifically, but I've done my fair share of parsing Java stack traces, and they usually just get you in the vicinity of the problem without really telling you the cause. This was best illustrated with the standard exception that was thrown when a hostname failed to resolve, where the message did not contain the hostname. This one was solvable (and did get solved AFAIK), but in a lot of other cases, the relevant context is not available at the depth where the exception is thrown, necessitating exception-wrapping.
> Reducing syntactic noise is about legibility, not writing ease.
Exactly, which said proposal does nothing to improve upon. Despite the reduction in characters it looks exactly the same as the traditional way, offering no way to improve how one think about errors. That proposal was clearly thrown out there just to try and appease the "Go doesn't have error handling" crowd without any thought into what would actually make the language better. The goal may be noble, but that particular proposal was rightfully abandoned.
> The error boilerplate as it exists interrupts the actual logic
Huh? No matter what logic you throw at the problem, there is no escaping that error handling is part of the actual logic. And it is, by far, the most important piece of the logic. Engineering is all about dealing with failure modes.
I'll grant you that there is a category of problems known as scripting tasks where error states simply can mean letting the program crash and allowing the user to clean up afterwards, but Go is clearly not trying to be a scripting language.
I agree the ? proposal seems bad, which is why I didn't speak directly to it (but gave do notation as an example of a better solution that addresses the concern about special syntax for `error` specifically). Just the idea that explicit if err! = nil return err everywhere is somehow useful.
My experience with high level banking and low-level networking applications is that the default path for error handling is that you want to bubble up to central handlers the vast majority of the time. There's a reason why exceptions are a popular language feature; they're just hard to make work with fibres. With scripting you often don't want to handle errors at all. Just set -euo.
We seemingly have very different experiences with rent.
All rent I've paid was agreed upon prior to me being charged it, and guns were never involved.
The people I rented from did the work of owning/managing the building and providing it for my use. Maybe this isn't a noble way to earn money, but I found it to be a really useful service, and it seems not dramatically different than most services I pay for (how much incremental work is Netflix doing for my behalf? what work is the bank doing to earn my loan?).
Indentured servants agreed to be indentured servants. At gunpoint. It's literally illegal not to pay rent. They will put you in jail if you don't sign a rental contract. Consent under duress is not consent.
This is hyperbolicly dramatic. Nobody will put you in jail of you don't sign a contract. And if you don't pay rent it's a beach of contract and civil matter. It can be very hard to force people to pay rent if they're not paying. All you can do is kick them out, eventually ,there is no jail.
Your dramatic post makes it seem like the cops can kick down your door to get rent. That's simply not true.
You're either homeless or you have a domicile somehow. So, many people enter into leases or rental agreements. Then they pay rent to maintain that home.
If you don't pay rent, you don't get arrested, but the constable is actually a law enforcement officer, and the constable is the #1 official who is involved in evictions, so yes, they will "kick down your door" to dislodge you from a place where you haven't paid rent.
And then what do you do, when you're homeless and on the streets? In most urban centers, it's illegal to sleep outdoors or trespass ("urban camping" laws), and so the homeless are often subject to arrest or sanctions because of the nature of their plight.
So the only logical response here is to get housed, pay rent, and keep paying, just to stay on the legal side of things. Ask me how I know.
That's so true - the land-owning class believe that society should continue paying them lots of money if that land is to be put to use. Don't get me started on landlords and their passive income requirements.
Yes, society owes a social contract where if you work you can afford to live and have a roof over your head, food to eat, and clothes that aren't Temu plastic rags of worse quality than dystopian sci-fi fiction 'clothes issued to people on basic'.
It also seems like the value of quality tutoring that doesn't primarily function as social/class signaling goes down as tools capable of automating high quality intellectual work are more widely available.
It depends on outcome again: is the value of tutoring the social class elevation, or is it in the outcome of becoming more skilled and knowledgable?
There's also the deeper philosophical question of what is the meaning of life, and if there's inherent value in learning outside of what remunerative advantages you reap from it.
100%. I think there are some clear distinctions between AI training and human learning in practice that compound this. Humans learning requires individual investment and doesn't scale that efficiently.
If someone invests the time to consume all of my published work and learn from it, I feel good about that. That feels like impact, especially if we interact and even more if I help them. They can perhaps reproduce anything I could've done, and that's cool.
If someone trains a machine on my work and it means you can get the benefit of my labor without knowing me, interacting with my work or understanding it, or really any effort beyond some GPUs, that feels bad.
And, it's much more of a risk to me, if that means anything.
> If someone invests the time to consume all of my published work and learn from it, I feel good about that.
Agreed. My goal, my moral compass, is to live in a world populated by thriving happy people. I love teaching people new things and am happy to work hard to that end and sacrifice some amount of financial compensation. (For example, both of my books can be read online for free.)
I couldn't possibly care less about some giant matrix of floats sitting in a GPU somewhere getting tuned to better emulate some desired behavior. I simply have no moral imperative to enrich machines or their billionaire owners.
If it doesn't work, it's an annoyance and you have to argue with it.
If it does work, it's one more case where maybe with the right MCP plumbing and/or a slightly better model you might not be needed as part of this process.
Feels a bit lose-lose.
I suspect that lots of developers who are sour on relying on AI significantly _would_ agree with most of this, but see the result of that logic leading to (as the article notes) "the skill of writing and reading code is obsolete, and it's our job to make software engineering increasingly entirely automated" and really don't like that outcome so they try to find a way to reject it.
"The skillset you've spend decades developing and expected to continue having a career selling? The parts of it that aren't high level product management and systems architecture are quickly becoming irrelevant, and it's your job to speed that process along" isn't an easy pill to swallow.
You are essentially making a character attack on anyone who disagrees with this article. You dismiss outright reasonable objections you have not heard and instead you presume fear and loathing are the only possible motivations to disagree.
Certainly not my intention. Some of my post is projection: I don't like the implications of the AI enthusiast stance, and I know I want "actually, AI can't fully take over the task of programming" to be true even though my recent experience with uses it to handle even moderately complex implementation has been quite successful.
I've also seen the opposition narrow in scope but not firmness over the last year from some coworkers while watching others outsource nearly all of their actual code interaction, and I think some of the difference is how invested they are in the craft of programming vs being able to ship something.
So, if you like the part AI is expected to take over and see it as part of your value, it makes sense that your threshold are higher for accepting that outcome as accurate. Seems like typical psychology rather than an attack.
If one is not writing code your ability to read code will degrade quickly and be reduced to a basic sanity check as to whether you need to add more constraints (prompts, tests, etc.). Anyone who thinks they can read code without writing code at a level needed to understand what is going on (for anything non-trivial) is fooling themselves.
Yep. I'd say it's an order of magnitude more effort to read code you haven't written too, compared to reading code you wrote. So there is approximately zero chance the people using AI to generate code are reading it at a level where they actually understand it, or else they would lose all of their supposed productivity gains.
Anecdotally, lots of people in SF tech hate AI too. _Most_ people out of tech do.
But, enough of the people in tech have their future tied to AI that there are lot of vocal boosters.
It is not at all my experience working in local government (that is, in close contact with everybody else paying attention to local government) that non-tech people hate AI. It seems rather the opposite.
Managers everywhere love the idea of AI because it means they can replace expensive and inefficient human workers with cheap automation.
Among actual people (i.e. not managers) there seems to be a bit of a generation gap - my younger friends (Gen Z) are almost disturbingly enthusiastic about entrusting their every thought and action to ChatGPT; my older friends (young millennials and up) find it odious.
The median age of people working local politics is probably 55, and I've met more people (non-family, that is) over 70 doing this than in anything else, and all of them are (a) using AI for stuff and (b) psyched to see any new application of AI being put to use (for instance, a year or so ago, I used 4o to classify every minute spent in our village meetings according to broad subjects).
Or, drive through Worth and Bridgeview in IL, where all the middle eastern people in Chicago live, and notice all the AI billboards. Not billboards for AI, just, billboards obviously made with GenAI.
I think it's just not true that non-tech people are especially opposed to AI.
> The median age of people working local politics is probably 55, and I've met more people (non-family, that is) over 70 doing this than in anything else, and all of them are (a) using AI for stuff and (b) psyched to see any new application of AI being put to use
That seems more like a canary than anything. This is the demographic that doesn't even know which tech company they're talking to in congress. That's not the demographic in touch with tech. They have gotten more excited about even dumber stuff.
For people under 50, it's a wildly common insult to say something seems AI generated. They are disillusioned with the content slop filling the internet, the fact that 50% of the internet is bots, and their future job prospects.
The only people I've seen liking AI art, like fake cat videos, are people over 50. Not that they don't matter, but they are not the driver of what's popular or sustainable.
Mangers should realize that the thing AI might be best at is to replace them. Most of my managers don't understand the people they are managing and don't understand what the people they are managing are actually building. They job is to get a question from management that their reports can answer, format that answer for their boss and send the email. They job is to be the leader in a meeting to make sure it stays on track, not understand the content. AI can do all that shit without a problem.
I live in a medium-sized British town of 100,000 people or so. It may be a slightly more creative town than most — lots of arts and music and a really surprisingly cool music scene — but I can tell you that AI pleases (almost) nobody.
I think actually a lot about it is the sort of crass, unthinking, default-American-college-student manner about the way ChatGPT speaks. It's so American and we can feel it. But AI generated art and music is hugely unpopular, AI chatbots replacing real customer service is something we loathe.
Generally speaking I would say that AI feels like something that is being done to us by a handful of powerful Americans we profoundly distrust (and for good reason: they are untrustworthy and we can see through their bullshit).
I can tell you that this is so different to the way the internet was initially received even by older people. But again, perhaps this is in part due to our changing perspectives on America. It felt like an exciting thing to be part of, and it helped in the media that the Web was the brainchild of a British person (even if twenty years later that same media would have liked to pretend he wasn't at a European research institution when he did it).
The feeling about AI is more like the feeling we have about what the internet eventually did to our culture: destroying our high streets. We know what is coming will not be good for what makes us us.
I don't doubt that many love it. I'm just going based on SF non-tech people I know, who largely see it as the thing vaguely mentioned on every billboard and bus stop, the chatbot every tech company seems to be trying to wedge into every app, and the thing that makes misleading content on social media and enables cheating on school projects. But, sometimes it is good at summarizing videos and such. I probably have a biased sample of people who don't really try to make productive use of AI.
I can imagine reasons why non-tech people in SF would hate all tech. I work in tech and living in the middle of that was a big part of why I was in such a hurry to get out of there.
Frankly, tech deserves its bad reputation in SF (and worldwide, really).
One look at the dystopian billboards bragging about trying to replace humans with AI should make any sane human angry at what tech has done. Or the rising rents due to an influx of people working on mostly useless AI startups, 90% of which won't be around in 5 years. Or even how poorly many in tech behave in public and how poorly they treat service workers. That's just the tip of the iceberg, and just in SF alone.
I say all this as someone living in SF and working in tech. As a whole, we've brought the hate upon ourselves, and we deserve it.
There's a long list of things that have "replaced" humans all the way back to the ox drawn plow. It's not sane to be angry at any of those steps along the way. GenAI will likely not be any different.
It is absolutely sane to be angry at people's livelihoods being destroyed and most aspects of life being worsened just so a handful of multi-billionaires that already control society can become even richer.
Non-technical people that I know have rapidly embraced it as "better google where i don't have to do as much work to answer questions." This is in a non-work context so i don't know how much those people are using it to do their day job writing emails or whatever. A lot of these people are tech-using boomers - they already adjusted to Google/the internet, they don't know how it works, they just are like "oh, the internet got even better."
There's maybe a slow trend towards "that's not true, you should know better than to trust AI for that sort of question" in discussions when someone says something like "I asked AI how [xyz was done]" but it's definitely not enough yet to keep anyone from going to it as their first option for answering a question.
Anyone involved in government procurement loves AI, irrespective of what it even is, for the simple fact that they get to pointedly ask every single tech vendor for evidence that they have "leveraged efficiency gains from AI" in the form of a lower bid.
At least, that's my wife's experience working on a contract with a state government at a big tech vendor.
EDIT: Removed part of my post that pissed people off for some reason. shrug
It makes a lot of sense that someone casually coming in to use chatgpt for 30 minutes a week doesn't have any reason to think more deeply about what using that tool 'means' or where it came from. Honestly, they shouldn't have to think about it.
It’s one of those “people hate noticing AI-generated stuff, but everyone and their mom is using ChatGPT to make their works easier”. There are a lot of vocal boosters and vocal anti-boosters, but the general population is using it in a Google fashion and move on. Not everyone is thinking about AI-apocalypse every day.
Personally, I’m in-between the opinions. I hate when I’m consuming AI-generated stuff, but can see the use for myself for work or asking bunch of not-so-important questions to get general idea of stuff.
Most of my FB contacts are not in tech. It is overwhelming viewed as a negative by them. To be clearer: I'm counting anyone who posts AI-generated pictures on FB as implicitly being pro-AI; if we neglect this portion the only non-negative posts about AI would be highly qualified "in some special cases it is useful" statements.
> enough of the people in tech have their future tied to AI that there are lot of vocal boosters
That's the presumption. There's no data on whether this is actually true or not. Most rational examinations show that it most likely isn't. The progress of the technology is simply too slow and no exponential growth is on the horizon.
What’s so striking to me is these “vocal boosters” almost preach like televangelists the moment the subject comes up. It’s very crypto-esque (not a hot take at all I know). I’m just tired of watching these people shout down folks asking legitimate questions pertaining to matters like health and safety.
Health and safety seems irrelevant to me. I complain about cars, I point out "obscure" facts like that they are a major cause of lung related health problems for innocent bystanders, I don't actually ride in cars on any regular basis, I use them less in fact than I use AI. There were people at the car's introduction who made all the points I would make today.
The world is not at all about fairness of benefits and impacts to all people it is about a populist mass and what amuses them and makes their life convenient, hopefully without attending the relevant funerals themselves.
Honestly I don’t really know what to say to that, other than it seems rather relevant to me. I don’t really know what to elaborate on given we disagree on such a fundamental level.
Do you think the industry will stop because of your concern? If for example, AI does what it says on the box but causes goiters for prompt jockeys do you think the industry will stop then or offshore the role of AI jockey?
It's lovely that you care about health, but I have no idea why you think you are relevant to a society that is very much willing to risk extinction to avoid the slightest upset or delay to consumer convenience measured progress.
From my PoV you are trolling with virtue signalling and thought terminating memes.. You don't want to discuss why every(?) technological introduction so far has ignored priorities such as your sentiments and any devil's adovocate must be the devil..
The members of HN are actually a pretty strongly biased sample towards people who get the omelet when the eggs get broken.
No not the devil, but years ago I stopped finding it funny or useful when people "played" the part of devil's advocate because we all know that the vast majority of the time it's just a convenient way to be contrarian without ever being held accountable for the opinions espoused in the process. It also tends to distract people from the actual discussion at hand.
People not being assholes and having opinions is not "trolling with virtue signaling". Even where people do virtue signal, it is significant improvement over "vice signaling" which you seem to be doing and expecting others to do.
I have an “enabling suicidal ideation” concern for starters.
To be honest I’m kind of surprised I need to explain what this means so my guess is you’re just baiting/being opaque, but I’ll give you the benefit of the doubt and answer your question taken at face value: There have been plenty of high profile incidents in the news over the past year or two, as well as multiple behavioral health studies showing that we need to think critically about how these systems are deployed. If you are unable to find them I’ll locate them for you and link them, but I don’t want to get bogged down in “source wars.” So please look first (search “AI psychosis” to start) and then hit me up if you really can’t find anything.
I am not against the use of LLM’s, but like social media and other technologies before it, we need to actually think about the societal implications. We make this mistake time and time again.
You're being needlessly prescriptive with language here. I am taking about health and safety writ large. I don't appreciate the game you're playing and it's why these discussions rarely go anywhere. It can't all be flippant retorts and needling words. I am clearly saying that we need to as a society be willing to discuss the possible issues with LLM's and make informed decisions about how we want this technology to exist in our lives.
If you don't care about that so be it - just say it out loud then. But I do not feel like getting bogged down in justifying why we should even discuss it as we circle what this is really about.
All the Ai companies are taking those concerns seriously though. Every major chat service has guardrails in place that shutdown sessions which appear to be violating such content restrictions.
If your concerns are things like AI psychosis, then I think it is fair to say that the tradeoffs are not yet clear enough to call this. There are benefits and bad consequences for every new technology. Some are a net positive on the balance, others are not. If we outlawed every new technology because someone, somewhere was hurt, nothing would ever be approved for general use.
I would disagree. Luddite, to me, is a negative and pejorative label because history has shown Ned Ludd and his followers to have been a short-sighted, self-sabotaging reactionary movement.
I think the same thing of the precautionary movements today, including the AI skeptic position you are advocating for here. The comparison is valid, and it is negative and pejorative because history is on the side of advancing technology.
That’s fair. The bad behavior in the name of AI definitely isn’t limited to Seattle. I think the difference in SF is that there are people doing legitimately useful stuff with AI
I think this comment (and TFA) is really just painting with too broad of strokes. Of course there are going to be people in tech hubs that are very pro-AI, either because they are working with it directly and have had legitimately positive experiences or because they work with it and they begrudgingly see the writing on that wall for what it means for software professionals.
I can assure you, living in Seattle I still encounter a lot a AI boosters just as much as I encounter AI haters/skeptics
Strangely I've found the only people who are super excited about AI are executive level boomers. My mom loves AI and uses it to do her job, which of course has poor results. All the younger people I know hate AI. Perhaps it's also a generational dofference.
Yeah, it makes sense that going from a decade or so where SWE was one of the best possible career paths if you have any aptitude to a period where tech cos were staffing up aggressively (I recall reading ~60% growth), there's gonna be a hangover.
The educational pipeline probably still has a few years of oversupply to work through, and all of the people laid off post covid still need to work.
Even in a world where AI being able to automate some of the key skills required for SWE has no negative impact on employment, we'd expect a few more years of rough job prospects.
reply