It's more or less the same for me. I do dread the impact of AI on certain fields -- e.g. let's say you want to contribute to an OSS by reading the source code, GitHub issues, and making patches, but now people swarm the repo with AI so all those low hanging fruits are gone. This of course should NOT impact your decision to continue your work, but it probably does impact your morale.
For me, I'm more interested in learning the internals of systems (How do locks work, and why do we need them? How does VFS work?) and making experimental implementations in learning OSes (for sure I don't have the technical skills to implement the ideas in production OSes). AI helps by being a very good search engine, but other than that it doesn't help much, as I completely block code generation from an AI agent. Everything is discussion only.
> Still, I doubt that it's possible to significantly speed up human learning. The bottleneck is hardly the teachers nor the materials, but how fast a human brain can absorb new knowledge.
I completely agree with it. LLM might be able to 10x the number of PRs, and maybe that is actually is fine for the company because it doesn't care too much about verifications and such. It just wants to ship something that works. But individuals still learn at approximately the same speed. My brain still needs to hit some walls, scream at itself and assimilate the failure and success of my past, to actually learn something new. LLM does help by serving as a very good search engine if I can't Google it easily, but no more than that.
I'm also very happy that OP said "I don't know" a few times.
That was kind of the original idea of RISC. Expose simple instructions that could be implemented without microcode. Push the complexity into the program instead of the microcode. Instead of writing a memory-to-memory add instruction that decomposes into load, load, add, store microcode, you directly write the load, load, add, store.
This didn’t quite work out in the long term since hardware evolves faster than ISAs. Today’s “maps directly to the hardware” instruction is tomorrow’s “we add more hardware and play tricks to make this faster.” You explode all of the physical registers as logical registers, then a few years later you double the physical registers count and do clever mapping to extract more speed.
My favorite is the MIPS branch delay slot. Instead of complicated branch prediction to hide latency, expose the pipeline directly to the programmer. And then a couple of hardware generations down the line, the pipeline becomes much longer and more complicated and the CPU is back to playing tricks to hide latency, and the weird branch delay slot remains as essentially a vestige of bygone days.
2. Feed it with reverse engineering research of such assets;
3. Ask it to use C++ and SDL2/3 to write a game engine to draw maps, generate enemies, make cities and shops. It doesn't have to be faithful to the game, just something passable is good enough;
Does it make sense to give the troops special phones instead of their own? I always find it weird that soldiers can take their own phones into the base.
Most of what goes on on most bases is as unsecret as it gets. The rooms where sensitive things happen have security measures in place and they keep you from bringing your phone in there. Usually a little locker is provided where you store your phone while you are inside the protected area. In some very sensitive places there may be additional active and passive measures but usually people with access to those areas police themselves.
Like a lot of data collection, the meta data gets you pretty far. The who's and where's can be hoovered up with tracking data buys and essentially get you a nice list of who has access to certain areas, which can be used for targeting individuals.
I'm an amateur of C and knows nothing about Zig, so I'm not sure if this is equivalent to a C Union. But shouldn't we leave these kinds of problems to the programmers, not the language designers? Or did I miss anything?
> We have a tagged union, which can hold either A or B. We initialize the union as A, take a pointer to its internals, overwrite the original with B, and then use the pointer. The pointer is still typed as A, but the bytes it points to now belong to B: a type confusion.
C's union (and the one in Rust or C++) is a kind of user defined type that's literally just either A or B. It does not know whether it's an A or a B, ensuring you achieve type safety (not using it as an A when it was actually a B or vice versa) is your job as programmer. It's size is thus MAX(size_of(A), size_of(B))
[This is a big part of why writing to Rust's union is safe, storing either an A or a B is fine, there's no safety problem, only reading the union has potential issues and thus needs an unsafe super power]
But your quote was about a tagged union, which is a common idea found in more modern languages and which you could implement by hand in C easily enough (though it is tedious to work with). The tagged union also has a field (we can think of it as an enumeration and I believe in Zig that's always exactly what it is) which says either A or B, so we can check that field and know if it's an A or a B. This type is slightly bigger, to make space for that enumeration field‡
So in your quote the problem is that from a type safety POV it was crucial to set that field to B, not just write a B where the A was and hope.
‡ One of the important ideas in Rust is that we can avoid having this extra field in some cases yet deliver the same behaviour as if it existed - and that makes an important size / efficiency difference to our program, this is called "Niche optimization" and to some extent a C++ program could do it "by hand" using specialization and indeed a C programmer could write lots of horrible macros to enforce this style in their C, I would not recommend that.
I kinda think this is the story of "Oh someone wrote a screen editor -- that's the 10th time I heard from other people".
Like, if you write a text editor nowadays, my thoughts would probably NOT be too different, except that 1) I wouldn't speak out, and 2) I'd congratulate you, for real, because this world doesn't give ordinary people good time.
Yeah, my thought when seeing the title of this post was "everyone should build their own text editor". You can start with a couple of hundred lines of code. Not everyone will be happy using their own editor for very long, but it's surprising how little code you can get away with when it's your own and the (many) bugs left in it at any point are the ones that don't annoy you enough for you to spend time on.
My own is absolutely full of bugs and missing features, and probably a real pain to everyone else (to my knowledge only one other person has actually tried to seriously use it - I mostly discourage other users), but that's okay: It has the features I care about, some of which are entirely useless to everyone else. It started because I realised my Emacs config was big enough that I could write an editor in fewer lines.
Yeah, I think it's good to dogfood one's own program. It's just...we are so short of time. We are not the lucky few who could actually pull it off, lol.
If average Google programmers are too stupid to program in C++, what kind of qualities are needed to get good at programming in C++? Like 140+ IQ? Or one needs to really sit down, think through, slow down, which is against the "velocity"?
He's also wrong; the average Google programmer was more than capable of producing good C++ and Google's C++ tooling and standardization was excellent.
Source: worked there.
That's not to say that C++ is a good or appropriate language or that the codebase wouldn't have been better served by another language. But "stupidity" was never the problem. And Go is not the "another language" I think fits the bill (and in fact was barely used at Google when I was there)
I don't even know what actual production systems Pike ever worked on, before being given carte blanche to go off and make a new programming language to supposedly fit that niche?
In any case, Go is an insulting language to work in, which is not surprising since its origin story seems to involve insults.
Thanks for sharing. Do you mind to share a bit more about your observation and experience with C++ in Google? I'm just curious what kind of guidelines and practices produce better C++ code, because I have used C++ in my side projects, but I found it difficult to command -- it was always like handling a lot of dishes without breaking any -- that's why I talked about IQ.
And when you said "before being given carte blanche to go off and make a new programming language to supposedly fit that niche?", did you mean that (https://go.dev/talks/2012/splash.article#TOC_4) is not justified? I'm just curious.
C++ at Google is highly restricted to fit to a very normative style guide. And there was strong leadership while I was there to help define what sane defaults might look like (Titus Winters FTW). And then there was a lot of efforts into build system and static analysis tools to help enforce that. And then on top of that a very strong foundational set of libraries on which things were built that were also built quite well.
Again, I have real problems with C++. And always have. These days I'm a Rust developer. (Which I have my own criticisms of...)
But two things: Google developers are actually better than average, which is why Pike's comment seems so offensive in context. And C++ is the tool that Google already had, so sensible engineering is at least partially investing in incrementally improvement, not rewrite the world.
As for the article you linked to: I don't disagree with all of the conclusions in there. But I disagree with the hubris of "we need a new language" for an organization at the scale at which Google operate(d).
And also I think it smells suspiciously like "I have a hammer and need a nail"; by which I mean some smart engineer who (rightfully and properly) enjoys programming language design (or some other neato CS thing) ... and is annoyed and bored by the actually-existing boring protobuf shuttling work at Google ... gets carte blanche to build A New Hammer [which usually looks almost exactly like the things they personally have built before] and then goes hunting for nails for it. Which is honestly I think backwards to a healthy engineering culture, and is also a phenomenon I saw too many times at Google (I think Dart and Flutter and Fuchsia had similar cultural problems).
The job of a software engineer is to solve the organization's problems. I don't rule out that neat new tools might be needed sometimes to do that. I sure as hell would love to build those tools. But I want to put the problem first, not the tool.
I also disagree strongly with many of the fundamental design choices that went into Go from day one. Most odiously: Its error handling, its naming scheme (touched on in that article), and its lack of parametrized types (since fixed). Other things (packaging, etc) in that document I strongly agree with but they're relatively uncontroversial.
Also, when I first looked at Go I was like "ok, you say you built a language specifically for Google's needs but it just looks like you reheated Limbo [his previous language]."
Thanks for sharing! I'm not really good enough to make the right call, but I get your points. So you would prefer someone in Google to build custom tools or introduce features into the C++ language and compilers to fix those issues, not to create a new language. Either way, this is so above my head :D that I can only listen and learn.
FWIW that is exactly what happened, to some degree.
And I'm not opposed to language change, I just didn't see why they needed to create a new language instead of adopting something the industry was already working on. They could have thrown their weight behind Rust, for example, in the early days.
The specific compromises inside Go seem on the whole quite idiosyncratic and led by Rob Pike's personal biases. And it was sold as "Google's language" when in fact Google wasn't really using it for most of that time (they are in fact adopting it a lot more now)
I think he worked on Sawmill, where he developed a language that looks superficially a bit like Go called Sawzall. Sawzall seems to have been open sourced at some point.
It's got some common syntax similarities like using `a := b` to mean creating a new local variable of inferred type.
Cities in the tropics at high altitude far from the sea like Bogotá, Medellín, maybe even Mexico City.
Maybe some moderately increased risk of extreme rainfall causing localised flooding, mudslides etc, but Bogotá in particular has an incredibly mild climate year round, and you're at 2600m so you aren't too worried about sea level risk.
As far as I'm aware basically no risk from hurricanes, tornados or anything like that. Biggest risk is earthquakes which is nothing to do with climate change and can be mitigated.
In fact Bogotá is a bit chilly so might be nice if it was slightly warmer.
For some reason people assume that climate change means you need to move closer to the poles, but moving to higher elevation is much better
Yeah but then you have drug cartels and corresponding violence, kidnappings etc. Questionable healthcare, nothing social. Its nice for a short visit for some, but long term? You wanna live behind a fancy fence?
Plus its malaric jungle, so mosquitos can kill you day(dengue ones) and night.
Thats not a definition of move to a better place by any means, unless you come from say Bangladesh.
The average value of homes in safe parts of Canada has risen significantly. E.g. Vancouver is devastatingly expensive, while nearby Abbotsford and Richmond are floodplains and reclaimed marsh, respectively, and are cheap. Sometimes uninsurable, but cheap.
The market will price us all out of the safest places and indeed arguably already has. Expect housing values to continue to diverge. A dry hovel is superior to the mightiest of flooded manses, but a home in a dry, safe metropolis, with enough water for all?
Literally invaluable. It will be priced accordingly.
Everybody is saying that the Great Lakes region is a climate haven, but it's intensely vulnerable to both polar vortex events coming down from Canada and wet-bulb heat waves coming up from the Gulf of Mexico. The middle of America is flat; there is no natural barrier to stop a frigid or sweltering airmass from moving in. This has already happened multiple times within just the last few years.
In terms of death toll, a power outage during a severe deep freeze (with subzero temperatures and -50 wind chills) or a wet bulb event has a far greater lethality potential than wildfires. The most deadly wildfire in California history was the Camp fire that leveled the town of Paradise; it caused 85 deaths. The Oakland Hills firestorm of 1989, immortalized in SimCity and several made-for-TV movies, only caused 25 deaths. By contrast, the 1995 Chicago heat wave caused 740 fatalities, and even the 2024 polar vortex event that barely made headlines killed more people (90) than the Camp Fire.
(Also note the low absolute numbers of even very severe, headline-grabbing natural disasters in developed countries. And that good construction can mitigate almost all of them. You are probably better off, in strict actuarial terms, by settling in a place where you can make a lot of money and then using it to prepare your home for disaster than by settling in a place that is cheaper but where you can't afford the latest building technology.)
I think they have their fair share of snow storms during the winter because of the vortex coming from the West. The vortex goes down from Alaska because the mountains block it, and then it turns east and goes straight to the lake area.
I live in Montreal, but sometimes I see bitter weathers in Toronto during the winter. Ofc we have our share of pain, but I'm fine with snow -- raining is a huge problem in recent years -- I'm installing a French Drain right now, and hopefully it offers enough protection. However, my house is sitting on top of clay, so that could be a big issue.
Somewhat more concerning is that tornado frequency is increasing at a ferocious rate, though most are relatively minor (EF-0 / EF-1).
The total for 2026 to date is 207 ground tracks (as of 27 Aug 2026). The previous full year record was 142, and the historical average (again full-year) is closer to 50.
This has knock-on effects to insurance as well as raising home and landscaping repair (downed trees, etc.).
Flash-flooding is also an increasing concern, though unlike Nepal, water channels tend to be largely flat. Urban creeks, local rivers, retention ponds, and low-lying locations (underpasses, local low spots) may experience flooding, though generally flow strength is low. Basement flooding is the most likely risk.
reply