My answer is if you want to code as a hobby -- yes; if you want to code as a job -- no. The reason I say this isn't that corporations won't still need some people with coding skills even in a world where all or most code is generated by AI, it's that the number of jobs is such that there isn't room for new people to enter the industry. Many jobs are being lost and few new jobs are being created. A new person could focus their efforts on something else, such as an apprenticeship to become an electrician, which would be much more likely to pay off and much more lucrative. It looks like manual dexterity will be the hardest thing for AI to automate, so a job that combines human cognitive skill with manual dexterity, such as being an electrician, is probably a much smarter way to go than learning to code, if one's goal is making money. Do you all think I am out of line in saying this?
I'm inclined to agree with Casey Muratori who suggests we think of coding like playing guitar. Should you learn to play the guitar in 2026? Very few people can make a living playing guitar. It's not impossible -- even in the age of synthesized guitars and now AI generated music, there are still superstar rock stars who make a living playing guitar -- but it's a very small fraction of people who can play the guitar. If you want to make a living playing guitar, then you probably shouldn't learn it. On the other hand, if you want to play the guitar for its own sake, as a hobby, then yes, you should learn it.
I've been programming in PHP since 2002 and Go since 2011. At work I work primarily with two large PHP codebases, 1 about ~half a million lines of code, and the other about ~3 million lines of code. I'm porting PHP code to Go and writing some new code, like cron jobs, in Go. There's about 55,000 lines of Go code at this point.
What I have learned in this time is: Go is a very good, very high quality, very well designed language. PHP is a terrible, terrible, terrible language -- at least if your mission is creating highly reliable software. If your goal is rapid prototyping of the visual appearance of a webpage, PHP is good for that -- that's what it was originally invented for, back in the 1990s, and it's still the best language for that specific use case.
In PHP, if you are looking at a line of code, it's impossible to tell what happens if an error occurs. There's an error_reporting level that can be changed anywhere else in the codebase at any time. So an error might be thrown in the user's face, or not -- depending on the error_reporting level and what the error is. This can also interact with output buffering. (I guess if the "@" sign is present, at least then you know output of an error message is suppressed.) There's a error_handler function that could be set. Oh but it gets worse! Even if you have the entire codebase and can scour every line of code, and trace every possible execution path, you still can't tell what will happen if an error occurs at the line of code you are looking at -- because there are php.ini settings that come into play!
This is without even mentioning the try/catch exception handling system, which PHP also has, and that you think is such a good thing. So if an error happens on the line you are looking at, execution may switch to somewhere above you in the call stack. But (at least in theory) if you have the complete source code, you can figure out all the places where that might be.
This is an absolute nightmare if you care about reliability. The worst thing you could possibly have in a programming language if you care about reliability is to be unable to tell what happens when an error occurs and reason about the program's behavior.
Contrast this with Go. In Go, I can know what happens if an error occurs because it's rightthere. There's an "if err != nil {..." block that tells me exactly what happens.
By porting code to Go, I've been able to increase the reliability tremendously. The thing about go, is that using Go doesn't automatically give you reliability -- you have to learn the techniques and tools in Go that give you reliability. But once you do that, the quality of software you can produce is vastly higher.
I've spent the last decade or so learning this. Learning how to structure the code to make maximum use of the compiler's static type checking to catch errors. Making use of the static analysis tools that catch errors. Using a combination of errcheck and staticcheck (mentioned elsewhere in this discussion), you can guarantee every err return value is actually checked and handled. So the oft-cited language flaw of Go allowing you to forget to handle errors becomes a non-issue. Go has built-in support for unit tests and the excellent polymorphism system makes tests easier to make than in PHP. And, getting back to the topic at hand, in Go, I created my own system for handling the err values that get returned so junk errors created by hackers trying to find security vulnerabilities on our server get filtered out, while actual errors that I need to fix get logged and brought swiftly to my attention. Can you do something similar in PHP? In theory, perhaps, but we are to afraid of breaking things to try to massively refactor our ~2 million lines of PHP code in order to do that. So we have various log files and database entries that get clogged with errors, and sometimes we notice errors that we need to fix, but usually we don't. Usually we don't know anything is wrong until we get customer complaints on the Help Desk.
Anyway, I'm glad the Go team rejected the idea of changing Go's error handling. Is Go's error handling verbose, tedious, and repetitive? Yes. But it's also unambiguous and gives you total control over how your program responds when an error occurs, which is exactly what you want if you want to write software with the maximum reliability.
Don't just take my word for it. Notice how lots of "cloud infrastructure" is written in Go. Kubernetes is written in Go, Docker is written in Go, Terraform is written in Go, etc.
Yes, I know some people, like Facebook, have managed to write decently reliable code in PHP. But I suspect Facebook has thrown massive amounts of dollars and people at the problem. Various other PHP projects, like certain website creation systems that shall not be named, have a reputation for being buggy.
Sorry, I couldn't let you say PHP has better error handling without a response. It may be "better" for having more compact, prettier looking code. But it's not better for writing actually reliable software. If you want to write actually reliable software, Go is way better.
Wow, this is an amazing idea! I wish I had time to contribute but I'm maxed out. I love Go and I always tell people (everybody who will listen) that one should always use a statically typed, strongly typed language for production code.
I'm going to challenge the premise of the question and say no one should be "comfortable" writing concurrent Go code.
Maybe no one should be comfortable writing concurrent code, period. Concurrent code is hard to reason about, and when bugs occur, they are hard to reproduce and debug.
When I first discovered Go's concurrency model, I thought, "This is great! It has a nice message-passing system in the form of channels that people can use to write reliable concurrent code."
But as I got into it, I realized, no, not so fast. Go does provide a message-passing system, but it does nothing to prevent you from sharing memory between your goroutines, inviting all the problems such as race conditions and data corruption that that entails. Furthermore, if you don't design your goroutines such that when you represent them as a graph, the graph is acyclic, then you have potential deadlocks when your program runs. And you might think it's not hard to design the system so there are no cycles, but even something as simple as two goroutines where one sends a message to the other and the other wants to send a message back -- boom! you've got a cycle. And any time you have cycles in your graph, you have to think long and hard about where to add buffering to your channels and how much.
I remember reading somewhere that in Go, people use concurrency 12x more than in other languages. I was pretty horrified by that! The makers of Go made concurrency easy -- maybe too easy. People use it everywhere.
I have not yet had the time to look into Rust and its borrow-checking system, so before you ask I can't comment on that. What I can say for the moment is that the Go programming language is exceptionally well-designed and well implemented in just about every regard except its concurrency model. The concurrency model makes concurrency easy but does not make it safe. It is dangerous in Go and you have to be ultra-ultra-careful when you write concurrent code in Go.
My unpopular opinion, which is less unpopular than it used to be, is that object-oriented programming is a bad idea -- in particular, inheritance -- and the Go programming language demonstrates that you can write everything you need without object-oriented programming. I learned in school that a language is "object oriented" if it has inheritance, encapsulation, and polymorphism. Some years ago, I was feeling like giant class libraries were very complex and asked if that complexity is really necessary? And embarked on an experiment to see if I could stop using object-oriented programming and do everything with regular functions. I discovered in short order I needed polymorphism, and that objects were the easiest way to do that. Encapsulation is nice to have. But amazingly, I never came across a scenario where I needed inheritance. Shortly thereafter I discovered the Go programming language, which does not have inheritance at all, though it does have polymorphism (through the inheritance keyword) and encapsulation (via control of exports at package boundaries). It's not just me: powerful software like Kubernetes has been written in Go. The lack of inheritance doesn't get in your way and in fact enables polymorphism to work the way it would in an ideal world. The decision to leave out inheritance was really bold on the part of the Go language designers and it is my favorite "feature" of the language.
The first thing that came to mind to me was "AI researcher". After all, if you're one of the people advancing the AI models that automate everyone else's job, your job isn't going to automated.
I'm inclined to agree with Casey Muratori who suggests we think of coding like playing guitar. Should you learn to play the guitar in 2026? Very few people can make a living playing guitar. It's not impossible -- even in the age of synthesized guitars and now AI generated music, there are still superstar rock stars who make a living playing guitar -- but it's a very small fraction of people who can play the guitar. If you want to make a living playing guitar, then you probably shouldn't learn it. On the other hand, if you want to play the guitar for its own sake, as a hobby, then yes, you should learn it.