You say that the optimal state of society is for everyone to apply programming and logic etc. but the obvious final result of these developments is that no one will.
Maybe the artform will be lost, but surely humanity will inherently be more 'logical' and systems driven afterwards?
Maybe using writing as an analogy is flawed, but most of humanity having 'writing' as a core skill did enable many other things, even if oral storytelling cultures suffered at its hand.
At its core, tech is all about breaking through inefficiencies and barriers. Does it matter if people can't code python if people demand government systems be frictionless in the year 2500?
Being able to program isn't the end game of critical thinking. Programming languages are just a way of representing the processes. The thinking underneath was always more important, and there's now technically more time freed up to focus on that.
Billions of people now have access to tools which will aid them in reasoning through complex problems without needing a $100k CS degree. Of course some people are using LLMs to get recipe inspiration, but others are now empowered to do things which were impossible for them before.
I personally think the alarm ringers are mainly the privileged elite who are scared of their moats beyond filled in. LLMs have effectively broken down the gates of access to knowledge. In a diverse world, having more people being empowered to do more things has to be a net positive.
I've come across lots of novel uses, though. I've seen non-technical people in law, education, hr, all spin up interesting projects/workflows which have helped their jobs/lives. The most interesting was a teacher who's dropped powerpoint, and is creating interactive lesson experiences; mainly presenting the content through popular games and creating engaging activities to apply the content. A recent one was a mock UN summit presented like a game of Civ with territory mechanics. Absolutely zero tech background, just curiosity.
Once people get over a few hurdles, things like:
>tech's too confusing
>$20 is a lot of money to spend on a subscription
>AI is just a fancy search engine
>AI will do all the work for me
You start unlocking a fair bit of creativity in people. I mean, all this is brand new stuff even for tech-savvy people. It'll take a while for the genuinely useful uses to dissipate out into the maasses.
Not everything has to be a billion dollar business.
Funny how all these dynamically typed languages are gradually becoming typed, but none of the statically typed languages are gradually becoming untyped.
Not really, the `any` type doesn't let you perform any operation on it with runtime dispatch like dynamic typing does. Moving logic into json isn't a language feature.
You keep posting that. Do you understand the difference between that and "we anticipate that Go will never add generic methods"? What they actually said shows epistemic humility and recognizes that they might change their mind.
Hi! I'm a human being that is trying to understand the world and make friends along the way. I see you are too! Pleased to meet you.
You asked the question
> Where did "they" say "we" didn't need generics?
And I (re)posted a quote from them, which sounds to me like, at the time, they believed that "we" Go users didn't need generics.
They may have changed their mind, which is totally fine! But I do think it sounds like the person you were replying to wasn't commenting in bad faith or misunderstanding or fighting a straw man as you posted. Seems like a reasonable interpretation of what the Go devs had said at one point. To each his own though!
Hi! If you want people to think you are a human, you should not mistake one of them for an entirely different one, and you should not refer to yourself in the third person.
The OP didn't mention generics or generic methods :) They referred to something that was added, after the Go team didn't anticipate adding it. Sounds like a fair point to me!
> “What do you think? There was a man who had two sons. He went to the first and said, ‘Son, go and work today in the vineyard.’ “ ‘I will not,’ he answered, but later he changed his mind and went. “Then the father went to the other son and said the same thing. He answered, ‘I will, sir,’ but he did not go. “Which of the two did what his father wanted?” “The first,” they answered. Jesus said to them, “Truly I tell you, the tax collectors and the prostitutes and the Go language maintainers are entering the kingdom of God ahead of you.
Whether they made a good decision or not, or changed their mind or not, is beside the point (I think they did, and they did!). I was merely replying to the claim that
> They didn't say they never wanted to do generics, but that they did want to take their time and do them right.
Is anyone actually mad about this, or do people just bring it up to stir the pot? Who cares what the FAQ says? They've worked out a way to add it easily in a backwards compatible way that can solve some problems. They had not identified this solution at the time they wrote the FAQ, and Go has been perfectly usable without this feature for 16 years.
What’s the correction? The two claims are not in conflict. Saying “we don’t expect to ever add X” is not equivalent to “we never wanted to add X.” It simply means that they didn’t think it would happen, which can coexist with an underlying willingness to consider it if a suitable approach appeared.
Clearly we don’t need this feature. Just because the Go team decides to implement a feature doesn’t imply that they must think that the language needs the feature. You’re searching for contradictions where none exist.
Most programming language features are not strictly needed. They’re just quality of life improvements that are on balance a good addition to the language.
Sure, but if you take that view, everything above assembly is a QOL improvement and we really don't need anything. That definition is pretty useless though.
We care that time and time again, when anyone ever brings up a criticism of the language, they’re told that everything is just fine and it’s not a problem and we just don’t get the Go Philosophy. There’s not a problem, stop trying to make Go like every other language, and changing things would make the language more complicated and worse.
Then when the language is inevitably changed for the better, resolving the complaint, suddenly it was always going to happen and it was just a matter of getting the details right.
Every other language community I can think of is more than willing to acknowledge the shortcomings of their language. “Yeah, this kind of sucks in principle but it’s not something that gets in the way in practice” is a fine perspective. So is “this was a tradeoff; we went in this direction and these are the resulting downsides”. But the golang community practically trips over themselves to constantly argue that obvious shortcomings in the language are actually a good thing and we just don’t get it.
Nobody is saying the language shouldn’t improve. We’ve all been begging the language to improve. But we’re also tired of the constant, obvious, and shameless gaslighting from the community whenever things do get better. You aren’t going to like the comparison, but it’s extremely Trumpian.
Yeah, I worked with a guy in the late 2010s - one of the most painful people I've ever worked with - who would tell anyone that would listen that Go (as it was in 2018) was the perfect programming language - it had all the features you'd ever need - no more, no less. It doesn't need generics, the package management story is fine etc. Thankfully he's been out of my life for a long time now but I believe he's still writing Go, and I bet that he's telling anyone that will listen that Go (as it is in 2026) is the perfect programming language and that its implementation of generics was necessary and perfect etc.
He wasn't the only one but he certainly took it to the extreme.
This is an outlier. The Go team and community never endorsed that. In fact, their position has always been the opposite. To give just one example, see [1].
I think it’s pretty clear this post was a response to the clear dogma within the community.
> But we need help from everyone. Remember that none of the decisions in Go are infallible; they’re just our best attempts at the time we made them, not wisdom received on stone tablets.
But they haven’t added generic methods, really. This change just lets you use method syntax in cases where you could have used a function. It’s a pretty conservative change that I think a lot of people here are misunderstanding. Actual generic methods wouldn’t really make sense (for the same reason that you have similar restrictions on dynamic trait implementations in Rust).
There's a critical difference between "we don't think we will add it" (what you quoted) and "we won't add it because we think you don't need it" (what OP claims)
"In Minecraft" doesn't mean what it used to. When somebody wrote an 8-bit CPU literally "in Minecraft" it used to be badass. Now it's just a game addon.
Can't they just compete in separate categories? People have been making high-level computer mods years before even ComputerCraft, RedPower, or OpenComputers existed. And people will continue to make pure-redstone computers far into the future. Neither category is replacing the other :)
Can't speak to how everyone else is using it but at my job we run all of our unit tests under Fil-C as part of CI, in addition to the UBASAN, TSAN, and Valgrind pipelines we already had for them.
> Geography. Jeffrey Sachs and others have long argued that geography is destiny: landlocked, tropical, distant-from-markets countries face structural penalties through transport costs, disease burden, and weak agricultural conditions. Malawi has all three. Sure, but the empirical literature pegs the landlocked penalty at about 1% of annual growth. This is meaningful over decades, not enough to close a gap this large in per-capita income. Rwanda is more landlocked than Malawi and has grown faster. Uzbekistan is double-landlocked and has roughly tripled per-capita income since 2000.
The issue for me is that I seem to really "page out" parts of my life that aren't relevant to the situation I'm in. If I were to sincerely answer the "how are you" question, I would have to pause for ten or twenty seconds to think about how I am, which obviously doesn't fit the interaction. Any tips on how to avoid this? I'm a chronic over-preparer and I've tried to equip myself with answers to every conceivable question and that's just exhausting, so I've wanted to avoid that.
I think the answer is practice, for a few reasons. One is obvious: conversation is a skill. Just like a novice chess player can spend 5 seconds figuring out which squares the knight can move to while an intermediate player spots a fork to force trading a strong bishop or exposing an overworked queen, exposure to similar situations rewires your brain to work faster in those situations.
Another reason, though, is to me one of the main benefits of social interaction in the first place: The brain rewiring also makes you think about what other people would think, want to hear, say to you, etc, even when they're not around. That sure can give you better answers in conversations, but more importantly, I think this is just genuinely a nice way for the brain to be. In the same way that dogs are happy playing fetch, humans are happy living with other people in mind. Maybe because it feels like not everything is your responsibility, or that you worry less about what you should be doing, or that you look forward to laughing about disasters later... I'm not entirely sure. Whatever it is, it's nicer than the alternative.
I may suggest to answer genuinely about how you are instead of "how is life" — yes, my life is hard because of many ongoing family health issues, but I might still be OK in the moment. Or sleepy from a bad night of sleep, or hungry because I skipped breakfast. Or happy because I got my favourite parking spot. Or had a nice meal....
Say "I'm about to have coffee, so that's good :-) "
Alternately, instead of trying to prepare for every possible answer, you can constrain the possible replies significantly by being the one who asks the question in the first place. "How's your day going?" is only ever going to get some variation of "good" or "bad". You only need to respond with "great to hear that", or "sorrt to hear that, hope it improves soon". That's it.
reply