Ask HN: Is it still worth learning a new programming language?
I have been writing Python code for a few years now. But I feel like LLMs can write much better code than me. I used to keep myself updated with newer technology. But now I am loosing interest. I was interested in learning Rust. But I don't find any motivation now since I can just vibe code with Rust. Any thoughts in that?
If you don’t know the language better than the LLM, you can’t notice when it’s making terrible decisions. Use the LLM to accelerate your ramp-up and make you more productive while learning, but it’s not a replacement for learning.
For the longest time, I wanted to really dive deep into lower-level learning (e.g. C, Assembly, HDL, chips). LLMs temporarily killed my motivation to continue learning C. I wanted to build a clipboard history similar to windows 11, but for a Linux-based OS. Prompted ChatGPT for the code, and it spit some out. It was pretty bad, nowhere near a finished project. I deleted the LLM code and started anew.
I remembered why I wanted to learn this stuff. It's not for money, or to look cool.
It's for the fascination I have for computing.
How do electrons flow through a wire? How do the chips within a computer direct that flow to produce an image on a screen? These questions are mind-blowing for me. I don't think LLMs can kill this fascination. Although, for web programming, sure. I always hated front-end programming, and now I don't really have to do it (I don't have the same fascination for the why of such tech). So will I ever learn a new front-end framework? Most likely not.
LLMs can write. Often with more clarity than I can. But I still like to write, because writing is thinking. And I want to hone my thinking about the problem.
The same can be said about coding. Code to think and explore a problem. See how different languages help you approach a problem. Get a deeper understanding about a topic by coding.
Only Juniors can think that.
You can "vibe code" with Rust? And who is doing the reviews?
Verifying requisites, performance, security?
You must know the language very well to have a senior level.
Agreed. There's no way someone can vibe code production-quality code today...
Interestingly as AI models are becoming "more competent" I'm finding more and more issues with AI generated code in the project I work on...
Whenever AI is used by a more junior dev (or a senior dev who simply can't be assed) you always find strange patterns which a senior would never have done...
Typically the code works, but there might be subtle security issues or just unusual coding patterns where it appears an LLM has written slop, and instead of taking a step back and reconsidering its approach when errors crop up, LLMs tend to just add layers of complexity to patch over its slop.
These problems obviously compound if left unchecked.
I actually prefer how things were last year when coding models were less competent because at least if a problem was hard enough they'd get nowhere. Today they're good enough to keep hacking until the slop it writes is just about working.
In regards to OPs question though, I suspect there's less point in playing around with different technologies to get some basic understanding of how they work today (LLMs can do this). But if you want to be able to guide LLMs towards good solutions and ensure the code being produced in the era of AI is good, then having engineers with a deep understanding of the technologies they're using is very important.
I found myself losing interest but for different reasons. A different magic tool besides LLMs that promised to solve problems I never had, but which has become necessary as most job adverts called for it.
Reactive.
Not just React itself, but the paradigm, so also SwiftUI.
I never had a problem with "massive ViewControllers", the magic that's supposed to glue it all together is just a little bit fragile and hard to debug when it does break, and the syntactic sugar (at least for SwiftUI) is just self-similar enough for me to keep mixing it up.
But learning new languages? Nah, I'm currently learning/getting experience with JavaScript and ruby by code-reviewing LLM output.
LLM's are far from perfect, any production grade code must go through a human inspection unless it's a tiny ad hoc app. This means that you need to be familiar with the languiage and the environment to get good quality code.
If you don't actually want to write code there's no reason to learn anything. The question is, if LLMs can write much better code than you, what does your employer need you for?
Your employer needs you because writing code was never the hardest part of programming and software engineering in general. The hardest part is managing expectations, responsibilities, cross-team communication, multi-domain expertise, corporate bureaucracy and pushing back against unnecessary requirements and constraints. None of which LLMs can solve, and are especially terrible at pushing back.
I agree. I remember once the full especification I got was
> Enough
After talking for 4 hours and 3 coffe cups, I got enough corner cases and main case to understand what they wanted. 1 week later I got a list of criteria that can be programmed. 5 years later most of the unusual but anoying rought corners were fixed. We still had a button to aprove manually the weird cases.
I find the premise reasonable, though I do have an observation.
The current AI hype may have placed us in a filter bubble or echo chamber, shaping our conclusions. These highly specialized algorithms can nudge or reward us for thinking in specific ways.
Regarding programming languages, there is immense value in understanding internal primitives.
As example, consider concurrency primitives. Different languages provide different levels of abstraction: high-level library support in Python, the event loop structure in JavaScript, compiler-level implementations in Rust and C++, runtime-intrinsic mechanisms in Go and Java, and virtual machine intrinsics, such as Erlang.
By viewing languages through this lens, you recognize that each implements these primitives differently, allowing you to choose the most effective tool for the job.
If your goal is to assess the short-term economic value of a technology, your logic is understandable. However, learning new languages and tools remains worthwhile. When AI agents begin invoking these tools on the fly, you may not know if a specific choice is the most effective one. Without this knowledge, you will have some gaps to challenge the AI's decision.
In the long run, making the effort to master these concepts yields far greater value as a software engineer. It enables you to understand the rationale behind applying a precise tool to a precise task.
There are valid arguments supporting various perspectives on this. However, while any approach can be useful, this discussion highlights the need for wisdom: the awareness of one's own biases. As I noted earlier, filter bubbles can distort judgment. Continuously questioning your conclusions helps ensure you move toward the best outcomes. I hope you find this recommendation useful.
I remembered why I wanted to learn this stuff. It's not for money, or to look cool.
It's for the fascination I have for computing.
How do electrons flow through a wire? How do the chips within a computer direct that flow to produce an image on a screen? These questions are mind-blowing for me. I don't think LLMs can kill this fascination. Although, for web programming, sure. I always hated front-end programming, and now I don't really have to do it (I don't have the same fascination for the why of such tech). So will I ever learn a new front-end framework? Most likely not.
The same can be said about coding. Code to think and explore a problem. See how different languages help you approach a problem. Get a deeper understanding about a topic by coding.
Interestingly as AI models are becoming "more competent" I'm finding more and more issues with AI generated code in the project I work on...
Whenever AI is used by a more junior dev (or a senior dev who simply can't be assed) you always find strange patterns which a senior would never have done...
Typically the code works, but there might be subtle security issues or just unusual coding patterns where it appears an LLM has written slop, and instead of taking a step back and reconsidering its approach when errors crop up, LLMs tend to just add layers of complexity to patch over its slop.
These problems obviously compound if left unchecked.
I actually prefer how things were last year when coding models were less competent because at least if a problem was hard enough they'd get nowhere. Today they're good enough to keep hacking until the slop it writes is just about working.
In regards to OPs question though, I suspect there's less point in playing around with different technologies to get some basic understanding of how they work today (LLMs can do this). But if you want to be able to guide LLMs towards good solutions and ensure the code being produced in the era of AI is good, then having engineers with a deep understanding of the technologies they're using is very important.
Reactive.
Not just React itself, but the paradigm, so also SwiftUI.
I never had a problem with "massive ViewControllers", the magic that's supposed to glue it all together is just a little bit fragile and hard to debug when it does break, and the syntactic sugar (at least for SwiftUI) is just self-similar enough for me to keep mixing it up.
But learning new languages? Nah, I'm currently learning/getting experience with JavaScript and ruby by code-reviewing LLM output.
> Enough
After talking for 4 hours and 3 coffe cups, I got enough corner cases and main case to understand what they wanted. 1 week later I got a list of criteria that can be programmed. 5 years later most of the unusual but anoying rought corners were fixed. We still had a button to aprove manually the weird cases.
The current AI hype may have placed us in a filter bubble or echo chamber, shaping our conclusions. These highly specialized algorithms can nudge or reward us for thinking in specific ways.
Regarding programming languages, there is immense value in understanding internal primitives.
As example, consider concurrency primitives. Different languages provide different levels of abstraction: high-level library support in Python, the event loop structure in JavaScript, compiler-level implementations in Rust and C++, runtime-intrinsic mechanisms in Go and Java, and virtual machine intrinsics, such as Erlang.
By viewing languages through this lens, you recognize that each implements these primitives differently, allowing you to choose the most effective tool for the job.
If your goal is to assess the short-term economic value of a technology, your logic is understandable. However, learning new languages and tools remains worthwhile. When AI agents begin invoking these tools on the fly, you may not know if a specific choice is the most effective one. Without this knowledge, you will have some gaps to challenge the AI's decision.
In the long run, making the effort to master these concepts yields far greater value as a software engineer. It enables you to understand the rationale behind applying a precise tool to a precise task.
There are valid arguments supporting various perspectives on this. However, while any approach can be useful, this discussion highlights the need for wisdom: the awareness of one's own biases. As I noted earlier, filter bubbles can distort judgment. Continuously questioning your conclusions helps ensure you move toward the best outcomes. I hope you find this recommendation useful.