10 ms·

People always under-estimate the cost of properly learning a language. At any given time I tend to have a "main go-to language". I typically spend 2-4 years g

by bborud 2y ago

People always under-estimate the cost of properly learning a language. At any given time I tend to have a "main go-to language". I typically spend 2-4 years getting to the point where I can say I "know" a language. Then I try to stick to it long enough for the investment to pay off. Usually 8-10 years. A surprising number of people think this is a very long time. It isn't. This is typically the time it takes to understand enough of the language, the compiler, the runtime, the standard library, and idiomatic ways to do things. It is the time it takes to where you can start to meaningfully contribute to evolving how the language is used and meaningfully coach architects, programmers and system designers. It is also what you need to absorb novices into the organization and train them fast.

cube2222 2y ago
Agreed. Having a passing knowledge of many languages is of course easy (even being moderately productive with them, esp. with Copilot now), but knowing the ins and outs of a language and its ecosystem is a very nontrivial time investment. Thus, I'm mostly an anti-fan of the idea of polyglot environments.
oooyay 2y ago
By now I know three major languages: Go, Python, and Typescript. I know tradeoffs at-a-glance, I deeply understand the syntax and its various forms, the full array of tooling and what they do, and lastly (but maybe most importantly) I can estimate more accurately because I can architect in my head. I can work in a myriad of other languages. I may be able to do some of the things above in Java or Rust but not nearly to the degree to which I can in languages I know. I think the difference is I'm probably not going to be leading a Java project or producing anything really innovative at a code level. To me, more important than picking a hammer, is knowing a variety of hammers that are good at certain tasks. I don't focus on Rust or Java as much because, frankly, I can build most things that are pertinent to the constraints of my work environment with those tools and most people I encounter also know them. The other considerable factor I have is that most things I work on can be horizontally scaled so my need for Rust is very niche. With respect to Java, I have a lot of workarounds that are cleanly abstracted enough before I need its dynamism and subsequent mental overhead.
Klonoar 2y ago
It’s not just the time to understand those nuances, but to keep up with the pace of changes. There’s an aspect of navigating those in some languages (JS…) that can be time consuming depending on where it’s deployed.
- tengbretson 2y ago
  Not only is it the nuances and pace of changes, but theres also a temporal element of seeing cause and effect over time from within an ecosystem. Is there a way to just parachute in and learn how to judiciously use classes in JavaScript the way one would if they were out there assigning Thing.prototype.method = function () {}? Can Udemy give you the same a-ha moment learning Promises today that someone got when they were drowning in callback pyramids in their Express v3 app?
- bborud 2y ago
  I think JS is a degenerate case. The reason I stay as far away from JS/TS as possible is that everything seems sloppy and therefore people try to "fix" things by replacing them every N months. Indeed, when you see so many commenters advocating not bothering to learn a language deeply, you kind of get a taste for how prevalent the sloppiness mindset is. JS seems to attract a very high proportion of unskilled programmers. I would struggle to name a single project I have been involved in where the JS/TS based front-end hasn't been reimplemented multiple times, from what I can tell, because people get lost.
pjmlp 2y ago
Naturally one can't know all the languages of the world. Even so, I have done consulting since 1999, with a small 2 years pause in research, and have several languages that I keep switching, every couple of months when project reassignment takes place. The usual T-shape kind of consultant, know some stuff really well, and others good enough to deliver.
BiteCode_dev 2y ago
And then you have the ever changing ecosystem, that can take years so sort out on it's own and must be constantly studied. E.G: if you arrive in Python right now, numpy is in version 2 and polars is stable. uv is all the rage, pydantic gained so much perf it's not even funny, toml is part of the stdlib and textual is looking very good. Type hints are much better than 2 years ago, htmx is used a lot in the web department, fasthtml is having a moment in the light and pyscript got a platform. Is any of those information worth acting on? Should you ignore them all for the sake of productivity? Should you carefully evaluate each proposition? Now if you have to do that with rust and erlang as well, it's a lot of time you could spend on coding instead.
- otteromkram 2y ago
  IMHO, that's not part of learning the language. You don't really even need half of the packages you mentioned unless you don't know the language and, instead, rely upon third-party crutches.
  - dagw 2y ago
    Depends on what your goal is. If your primary purpose for learning python is to be able to use numpy and pandas, then you should probably start learning them from day 1. Learning how to inefficiently implement parts of pandas in pure python on an ad-hoc basis is a waste of time for most people compared to just spending that time learning how to efficiently use pandas.
- jaapz 2y ago
  Instead of constantly trying to keep up with everything in an ecosystem (which is simply impossible), just keep up with the stuff you are using to get your product working. Keep a side eye on the rest of the ecosystem to see if something neat is developing that you might use, but no need to study every hyped package coming out. In the end they are all tools to get something that works. We still use flask and it's been great all the way, and it still holds up really well, there's no reason to move to any of the other packages just because that's the next new shiny thing.
nemo1618 2y ago
One of the most important qualities of Go is that it is actually possible to fully understand the language -- in the sense that you never see a snippet of Go code and think "wtf, you can do that?" or "hang on, why does that work?" Getting to that point takes many years, to be sure. But the language is simple enough, and changes slowly enough, that it is not an unrealistic goal -- the way it would be in C++, or Rust, or just about any other mainstream language.
- tialaramex 2y ago
  > in the sense that you never see a snippet of Go code and think "wtf, you can do that?" or "hang on, why does that work?" I am extremely doubtful that this is true and would like evidence.
  - kylecazar 2y ago
    It's known for being a small and simple language.
    - kaba0 2y ago
      Just like Brainfuck.
  - monkeywork 2y ago
    kind of hard for someone to prove a negative - feel free to find some Go code that meets that definition.
    - shepherdjerred 2y ago
      I feel this way... very often. * Init functions * Top-level variables being shared between all files in a package * For-loop sharing (fixed in 1.22 [0]) * ldflags (this is more of build behavior, but it took me a while to figure out how some variables were being set [1]. Note: Go does embed some data by default, but an app I was working on introduced more metadata) * Go build directives prevent IDEs/linters from analyzing a file at all. E.g. if you edit a linux-only file on macOS, you get _zero_ help. I dunno, there are a lot of other weird, confusing things that Go does. It is less than most other languages, though. [0] https://go.dev/wiki/LoopvarExperiment https://go.dev/wiki/LoopvarExperiment [1] https://www.digitalocean.com/community/tutorials/using-ldflags-to-set-version-information-for-go-applications https://www.digitalocean.com/community/tutorials/using-ldfla...
georgeecollins 2y ago
I also think it is a good idea to learn a few very different languages when you are starting out so that you have a sense of the tradeoffs and the different ways things can be done. When I was in college they taught C and Lisp (I am dating myself) which seemed very different to me at the time but also useful in different ways. Close to the hardware, vs supporting objects, lambda functions, etc. Later I learned a number of other languages and now I try hard to avoid switching languages because of the lost productivity. Now if I were starting out I think I would try to focus on two different languages, but more modern ones. Maybe Rust and Python?
brightball 2y ago
This is actually how I feel about Ruby. Not full on Rails because there is a lot more to learn there which comes with the time investment (which is also worth it in many cases). But for most scripting work especially, just raw Ruby and maybe the Sequel library for a database just makes my productivity soar.
- jalopy 2y ago
  Do you have any open source examples (either your own or others) of simple Ruby + Sequel that are particularly elegant + productive that you could point to? Would love to see this. I agree Ruby is the most elegant and enjoyable language to develop in.
saghm 2y ago
> It is the time it takes to where you can start to meaningfully contribute to evolving how the language is used and meaningfully coach architects, programmers and system designers. It is also what you need to absorb novices into the organization and train them fast. I think these criteria in particular are much more than a lot of people mean when they say "learn a language", which would explain why their estimates are lower than yours. You're talking about expertise, whereas plenty of people are speaking of basic competency. This seems more like (natural) language semantics about what it means to "know" and the definition of "properly learn" than about the accuracy of people's estimates.
- bb88 2y ago
  2012: Python is Awesome! 2014: Python is a great language, but there are a few pitfalls 2016: Python is a good language with the right IDE, tooling, and process. The people are pretty cool though. 2018: I like python, but I wish more people used type annotations. 2020: You know, metaclasses are freaking awesome! They saved me so much work! 2022: Why can't people code the most obvious solution in python? 2024: Celery! Jesus H. Christ! What were you thinking?!
  - sph 2y ago
    2012: Python is Awesome! 2014: Python is a pain in the butt to manage packages and dependencies, how the hell am I gonna deploy this? It's still a mess 10 years later unless you live deep in the ecosystem and know what third-party solutions du jour to manage that complexity. At least we have Docker now. Also let's not forget the Python 3 migration fiasco that lasted ~2008-2018 and I still find myself porting libraries to this day. I haven't used Python in a personal project in 10 years because of these painful paper cuts .
    - andreif 2y ago
      Dependencies is a sign of weakness.
      - 2y ago
ramijames 2y ago
I don't think it is that long. Think of learning any spoken language. We expect that it takes AT LEAST ten years to be able to master it, and typically it takes much longer to meaningfully add to the compendium of literature. Usually we are talking about decades. It isn't just about the tool (speaking, writing) but being so fluent that you can successfully express yourself in a way that has impact. If you can do it in ten years with a software stack, I'd say that's pretty impressive.
irjustin 2y ago
ChatGPT accelerates this timeline significantly. As a senior programmer you can largely skip the "junior" phase of the learning, almost like pair programming with a very proficient junior programmer.
- pjmlp 2y ago
  I am fully convinced that programming language generation out of stuff like ChatGPT is an intermediate step on their evolution, just like early compiler adopters wouldn't trust compilers that wouldn't show the Assembly output. Eventually we will achieve another milestone in what it means to program computers, where tools like ChatGPT will directly produce executables, or perform actions, and only when asked it will produce something akin to source code for cross-checking.
- bborud 2y ago
  I disagree. ChatGPT is like pair programming with someone who is on drugs and tends to lie a lot. Co-Pilot is even worse as it constantly bombards you with poor suggestions and interrupts your flow when you should be left alone to think about the problem you are solving. What separates a senior developer from a junior is that the language is no longer a barrier so your spend most of your time thinking about the problem you are solving and how you balance requirements, take into account human elements, and try to think ahead without prematurely spending time on things you aren't going to need. Being shown a bunch of possible solutions to choose from doesn't help you develop the ability to think about problems and come up with better solutions. Yes, ChatGPT can occasionally help you when you need a nudge to pick a direction or you come across something you don't know anything about. But it is not a substitute for knowing stuff and it can't actually teach you how to think.
p0w3n3d 2y ago
I totally agree with you. Only after min 2 years of fully coding a viable production solution can one learn most of the pitfalls of given language. I would add frameworks which give another level of complexity and sometimes a framework is like a separate language.
lifthrasiir 2y ago
It takes forever to "properly learn" a language in my opinion, because it would mean the total emersion into the ecosystem and most prominent libraries built around that language as well, and they will be always moving targets even though the language itself might be static. Go is no exception, and in fact there are only a handful of languages that can be ever "properly learned" if we are strict about that. The trick is not to properly learn, but to know how to learn enough of anything you need and make the best use out of that.
Etheryte 2y ago
Agreed, there's such a wide knowledge gap between "I read about this language design choice online" and "I know this from first principles". Truly, thoroughly understanding the languages and tools you work with every day unlocks a deeper level of understanding that you can't substitute with anything else. It's what people often describe when they first learn Lisp, but the same actually holds for every language, tool, etc. There is tremendous value in depth. However, since there is considerable opportunity cost in choosing what you put your time and effort into, do be mindful of the tools you decide to acquire this amount of knowledge in.
_xiaz 2y ago
I believe people over-estimate the benefit of properly learning a language. 3-12 months seems to be sufficient for the specialisation benefits to outweigh the small hit to language competency. My strategy is to be a generalist superficially learning specialized languages.
- tmountain 2y ago
  Whatever time frames you apply, the only way to really learn a language is to use it. Reading a book, blog articles, and watching videos on YouTube won't give you the hands on experience necessary to internalize how everything works.
  - _xiaz 2y ago
    Of course. My methodology is usually this: Day 1: read the introduction of a book, set up editor and environment Day 2: (superficially) learn flow control and type system Day 3: practice with coding problems on codewars Day 4-7: reimplement one of my projects Week 2: read the second quarter of the book and continue with puzzles Week 3+: Just projects, maybe invest a day into tooling somewhere in between That is assuming 1-3 hour days
    - sunrunner 2y ago
      > read the second quarter of the book And then never get to the third and fourth quarters because the practise you get from actually typing stuff is far more valuable? :)
      - _xiaz 2y ago
        Exactly. There usually is some stuff about the deeper, darker corners of a language in the type of book I pick. I usually pick the authoritative book / advanced book. Think "Programming PHP", "The joy of clojure", "The C Programming Language", etc. I don't necessarily need to know all about performance optimization, the async model or non-html templating. Reading a technical book cover to cover feels wasteful imo
simiones 2y ago
I completely disagree. I have been successful in building a new project for my company with myself and the entire team being completely new to Go when we started. Did we have growing pains, and some sub-par decisions? Absolutely. Do we right better Go code today, 4 years later? Absolutely. Did this mean that the project was in any way significantly slowed down by our use of Go compared to the C# or Java we knew before after the first 1-2 months? No, not really. The ways in which Go fit better for our chosen domain completely made up for that (and this all despite my continued belief that Go as a language is inferior to Java and C#). Now, there are other languages where I'm sure that we would have had significant issues if we tried to adopt them. In particular, switching from the GC languages we were used to to a native memory language like C++ or Rust or C would have surely been a much bigger problem. The same would have probably been true if we had switched to a dynamic language. But generally, deep language proficiency has less value in my experience than general programming proficiency, and much less than relevant domain knowledge. I would hire a complete Go novice that had programmed in Python in our specific domain over someone who has worked in Go for a decade but has only passing domain knowledge any day.
m_a_g 2y ago
Here is the thing: many software engineers don't need to learn a language "properly." When you start a new job, there will almost always be an existing code base, and you'll have to make contributions to it. Pattern recognition will get you a long way before you need to dive deep into the language internals.
- rkangel 2y ago
  This is true, and it makes the people who do actually know the language in depth extra valuable.
  - lnenad 2y ago
    Only for situations where that knowledge is required.
  - tekknik 2y ago
    Not so much. I know quite a few languages very well, more than the average programmer, and more often than not a senior programmer overrides your recommendation and don’t know the language as well as you or some other red tape. What has never happened is getting an increase in pay for knowing a language well. So I share the sentiment that learning a language well is valuable. It’s not, and with the newer AI tools coming out there will soon be no reason to learn any language in depth.
    - sevensor 2y ago
      I think you have that exactly backwards. LLM-based tools do best on shallow-knowledge tasks. It’s depth where they struggle. Show me the syntax for constructing a lazy sequence in your language? LLM. Reason about its performance characteristics and interactions with other language features? Human, for the foreseeable future.
- bborud 2y ago
  You are mixing two things. Learning a language and learning a codebase. Those are not the same thing. Besides, you are also just talking about what happens during the first N months. Most companies I've worked for allow for time to learn the language(s) being used. Some of them will fire you if you can't show sufficient progress over time.
vouaobrasil 2y ago
That's true. I agree. Python is the only language I ever really learned to a deep level and properly, and it makes a huge difference! (And I'm still learning of course.)
machiaweliczny 2y ago
Using esoteric lang constructs is bad idea IMO. Makes software harder to read/port/maintain. It’s useful for some hack & high perf stuff but not typical apps.
- bborud 2y ago
  Agreed. But knowing a bit about how a language (and runtime) actually works can make a huge difference when you design stuff. For instance, I've seen lots of examples of people implementing LRU caches in Java, and then scratching their heads when performance drops because they have no idea how the GC works. Or complicating things immensely because they realize memory is tricky and then ending up with some complex pooling scheme that constantly breaks rather than realizing that often more naive code that exploits the low cost of ultra short-lived local objects. If you know what you are doing it becomes easier to choose solutions that are performant and understandable.
jamwt 2y ago
IME, engineers and "the discourse" when we argue on the Internet often conflate "ease of use" and "ease of learning". When we say "ease of use", we usually mean "ease of learning." If you're a hobbyist, yeah, you should heavily value "ease of learning." If you're a professional, the learning curve is worth it if the tool's every day leverage is very high once you're ramped up. Too many developers don't put those 3-4 months in, in part due to the over-emphasis on "ease of learning" in our discussions/evaluations of things. I was a part of a very large go project (https://news.ycombinator.com/item?id=11282948 https://news.ycombinator.com/item?id=11282948) and go-based company infra generally some years ago, and go is emblematic of the classic tool that is amazing at ease of learning, and quite mediocre at "ease of use" as time goes on. I personally end up resenting those tools because I feel tricked or condescended to. (This is a little silly, but emotions are silly.) I'd wager this is also why Rust is a perennial "most loved" winner in the surveys: it gets better as your relationship with it deepens, and it keeps its promises. Developers highly value integrity over trickery, and hard-earned but deep value feels like integrity and wins in the long run. (other examples: VIM, *nix, git)

by bborud 2y ago

cube2222 2y ago

Agreed. Having a passing knowledge of many languages is of course easy (even being moderately productive with them, esp. with Copilot now), but knowing the ins and outs of a language and its ecosystem is a very nontrivial time investment. Thus, I'm mostly an anti-fan of the idea of polyglot environments.

oooyay 2y ago

By now I know three major languages: Go, Python, and Typescript. I know tradeoffs at-a-glance, I deeply understand the syntax and its various forms, the full array of tooling and what they do, and lastly (but maybe most importantly) I can estimate more accurately because I can architect in my head. I can work in a myriad of other languages. I may be able to do some of the things above in Java or Rust but not nearly to the degree to which I can in languages I know. I think the difference is I'm probably not going to be leading a Java project or producing anything really innovative at a code level. To me, more important than picking a hammer, is knowing a variety of hammers that are good at certain tasks. I don't focus on Rust or Java as much because, frankly, I can build most things that are pertinent to the constraints of my work environment with those tools and most people I encounter also know them. The other considerable factor I have is that most things I work on can be horizontally scaled so my need for Rust is very niche. With respect to Java, I have a lot of workarounds that are cleanly abstracted enough before I need its dynamism and subsequent mental overhead.

Klonoar 2y ago

It’s not just the time to understand those nuances, but to keep up with the pace of changes. There’s an aspect of navigating those in some languages (JS…) that can be time consuming depending on where it’s deployed.

tengbretson 2y ago
Not only is it the nuances and pace of changes, but theres also a temporal element of seeing cause and effect over time from within an ecosystem. Is there a way to just parachute in and learn how to judiciously use classes in JavaScript the way one would if they were out there assigning Thing.prototype.method = function () {}? Can Udemy give you the same a-ha moment learning Promises today that someone got when they were drowning in callback pyramids in their Express v3 app?
bborud 2y ago
I think JS is a degenerate case. The reason I stay as far away from JS/TS as possible is that everything seems sloppy and therefore people try to "fix" things by replacing them every N months. Indeed, when you see so many commenters advocating not bothering to learn a language deeply, you kind of get a taste for how prevalent the sloppiness mindset is. JS seems to attract a very high proportion of unskilled programmers. I would struggle to name a single project I have been involved in where the JS/TS based front-end hasn't been reimplemented multiple times, from what I can tell, because people get lost.

pjmlp 2y ago

Naturally one can't know all the languages of the world. Even so, I have done consulting since 1999, with a small 2 years pause in research, and have several languages that I keep switching, every couple of months when project reassignment takes place. The usual T-shape kind of consultant, know some stuff really well, and others good enough to deliver.

BiteCode_dev 2y ago

And then you have the ever changing ecosystem, that can take years so sort out on it's own and must be constantly studied. E.G: if you arrive in Python right now, numpy is in version 2 and polars is stable. uv is all the rage, pydantic gained so much perf it's not even funny, toml is part of the stdlib and textual is looking very good. Type hints are much better than 2 years ago, htmx is used a lot in the web department, fasthtml is having a moment in the light and pyscript got a platform. Is any of those information worth acting on? Should you ignore them all for the sake of productivity? Should you carefully evaluate each proposition? Now if you have to do that with rust and erlang as well, it's a lot of time you could spend on coding instead.

otteromkram 2y ago
IMHO, that's not part of learning the language. You don't really even need half of the packages you mentioned unless you don't know the language and, instead, rely upon third-party crutches.
- dagw 2y ago
  Depends on what your goal is. If your primary purpose for learning python is to be able to use numpy and pandas, then you should probably start learning them from day 1. Learning how to inefficiently implement parts of pandas in pure python on an ad-hoc basis is a waste of time for most people compared to just spending that time learning how to efficiently use pandas.
jaapz 2y ago
Instead of constantly trying to keep up with everything in an ecosystem (which is simply impossible), just keep up with the stuff you are using to get your product working. Keep a side eye on the rest of the ecosystem to see if something neat is developing that you might use, but no need to study every hyped package coming out. In the end they are all tools to get something that works. We still use flask and it's been great all the way, and it still holds up really well, there's no reason to move to any of the other packages just because that's the next new shiny thing.

nemo1618 2y ago

One of the most important qualities of Go is that it is actually possible to fully understand the language -- in the sense that you never see a snippet of Go code and think "wtf, you can do that?" or "hang on, why does that work?" Getting to that point takes many years, to be sure. But the language is simple enough, and changes slowly enough, that it is not an unrealistic goal -- the way it would be in C++, or Rust, or just about any other mainstream language.

tialaramex 2y ago
> in the sense that you never see a snippet of Go code and think "wtf, you can do that?" or "hang on, why does that work?" I am extremely doubtful that this is true and would like evidence.
- kylecazar 2y ago
  It's known for being a small and simple language.
  - kaba0 2y ago
    Just like Brainfuck.
- monkeywork 2y ago
  kind of hard for someone to prove a negative - feel free to find some Go code that meets that definition.
  - shepherdjerred 2y ago
    I feel this way... very often. * Init functions * Top-level variables being shared between all files in a package * For-loop sharing (fixed in 1.22 [0]) * ldflags (this is more of build behavior, but it took me a while to figure out how some variables were being set [1]. Note: Go does embed some data by default, but an app I was working on introduced more metadata) * Go build directives prevent IDEs/linters from analyzing a file at all. E.g. if you edit a linux-only file on macOS, you get _zero_ help. I dunno, there are a lot of other weird, confusing things that Go does. It is less than most other languages, though. [0] https://go.dev/wiki/LoopvarExperiment https://go.dev/wiki/LoopvarExperiment [1] https://www.digitalocean.com/community/tutorials/using-ldflags-to-set-version-information-for-go-applications https://www.digitalocean.com/community/tutorials/using-ldfla...

georgeecollins 2y ago

I also think it is a good idea to learn a few very different languages when you are starting out so that you have a sense of the tradeoffs and the different ways things can be done. When I was in college they taught C and Lisp (I am dating myself) which seemed very different to me at the time but also useful in different ways. Close to the hardware, vs supporting objects, lambda functions, etc. Later I learned a number of other languages and now I try hard to avoid switching languages because of the lost productivity. Now if I were starting out I think I would try to focus on two different languages, but more modern ones. Maybe Rust and Python?

brightball 2y ago

This is actually how I feel about Ruby. Not full on Rails because there is a lot more to learn there which comes with the time investment (which is also worth it in many cases). But for most scripting work especially, just raw Ruby and maybe the Sequel library for a database just makes my productivity soar.

jalopy 2y ago
Do you have any open source examples (either your own or others) of simple Ruby + Sequel that are particularly elegant + productive that you could point to? Would love to see this. I agree Ruby is the most elegant and enjoyable language to develop in.

saghm 2y ago

> It is the time it takes to where you can start to meaningfully contribute to evolving how the language is used and meaningfully coach architects, programmers and system designers. It is also what you need to absorb novices into the organization and train them fast. I think these criteria in particular are much more than a lot of people mean when they say "learn a language", which would explain why their estimates are lower than yours. You're talking about expertise, whereas plenty of people are speaking of basic competency. This seems more like (natural) language semantics about what it means to "know" and the definition of "properly learn" than about the accuracy of people's estimates.

bb88 2y ago
2012: Python is Awesome! 2014: Python is a great language, but there are a few pitfalls 2016: Python is a good language with the right IDE, tooling, and process. The people are pretty cool though. 2018: I like python, but I wish more people used type annotations. 2020: You know, metaclasses are freaking awesome! They saved me so much work! 2022: Why can't people code the most obvious solution in python? 2024: Celery! Jesus H. Christ! What were you thinking?!
- sph 2y ago
  2012: Python is Awesome! 2014: Python is a pain in the butt to manage packages and dependencies, how the hell am I gonna deploy this? It's still a mess 10 years later unless you live deep in the ecosystem and know what third-party solutions du jour to manage that complexity. At least we have Docker now. Also let's not forget the Python 3 migration fiasco that lasted ~2008-2018 and I still find myself porting libraries to this day. I haven't used Python in a personal project in 10 years because of these painful paper cuts .
  - andreif 2y ago
    Dependencies is a sign of weakness.
    - 2y ago

ramijames 2y ago

I don't think it is that long. Think of learning any spoken language. We expect that it takes AT LEAST ten years to be able to master it, and typically it takes much longer to meaningfully add to the compendium of literature. Usually we are talking about decades. It isn't just about the tool (speaking, writing) but being so fluent that you can successfully express yourself in a way that has impact. If you can do it in ten years with a software stack, I'd say that's pretty impressive.

irjustin 2y ago

ChatGPT accelerates this timeline significantly. As a senior programmer you can largely skip the "junior" phase of the learning, almost like pair programming with a very proficient junior programmer.

pjmlp 2y ago
I am fully convinced that programming language generation out of stuff like ChatGPT is an intermediate step on their evolution, just like early compiler adopters wouldn't trust compilers that wouldn't show the Assembly output. Eventually we will achieve another milestone in what it means to program computers, where tools like ChatGPT will directly produce executables, or perform actions, and only when asked it will produce something akin to source code for cross-checking.
bborud 2y ago
I disagree. ChatGPT is like pair programming with someone who is on drugs and tends to lie a lot. Co-Pilot is even worse as it constantly bombards you with poor suggestions and interrupts your flow when you should be left alone to think about the problem you are solving. What separates a senior developer from a junior is that the language is no longer a barrier so your spend most of your time thinking about the problem you are solving and how you balance requirements, take into account human elements, and try to think ahead without prematurely spending time on things you aren't going to need. Being shown a bunch of possible solutions to choose from doesn't help you develop the ability to think about problems and come up with better solutions. Yes, ChatGPT can occasionally help you when you need a nudge to pick a direction or you come across something you don't know anything about. But it is not a substitute for knowing stuff and it can't actually teach you how to think.

p0w3n3d 2y ago

I totally agree with you. Only after min 2 years of fully coding a viable production solution can one learn most of the pitfalls of given language. I would add frameworks which give another level of complexity and sometimes a framework is like a separate language.

lifthrasiir 2y ago

It takes forever to "properly learn" a language in my opinion, because it would mean the total emersion into the ecosystem and most prominent libraries built around that language as well, and they will be always moving targets even though the language itself might be static. Go is no exception, and in fact there are only a handful of languages that can be ever "properly learned" if we are strict about that. The trick is not to properly learn, but to know how to learn enough of anything you need and make the best use out of that.

Etheryte 2y ago

Agreed, there's such a wide knowledge gap between "I read about this language design choice online" and "I know this from first principles". Truly, thoroughly understanding the languages and tools you work with every day unlocks a deeper level of understanding that you can't substitute with anything else. It's what people often describe when they first learn Lisp, but the same actually holds for every language, tool, etc. There is tremendous value in depth. However, since there is considerable opportunity cost in choosing what you put your time and effort into, do be mindful of the tools you decide to acquire this amount of knowledge in.

_xiaz 2y ago

I believe people over-estimate the benefit of properly learning a language. 3-12 months seems to be sufficient for the specialisation benefits to outweigh the small hit to language competency. My strategy is to be a generalist superficially learning specialized languages.

tmountain 2y ago
Whatever time frames you apply, the only way to really learn a language is to use it. Reading a book, blog articles, and watching videos on YouTube won't give you the hands on experience necessary to internalize how everything works.
- _xiaz 2y ago
  Of course. My methodology is usually this: Day 1: read the introduction of a book, set up editor and environment Day 2: (superficially) learn flow control and type system Day 3: practice with coding problems on codewars Day 4-7: reimplement one of my projects Week 2: read the second quarter of the book and continue with puzzles Week 3+: Just projects, maybe invest a day into tooling somewhere in between That is assuming 1-3 hour days
  - sunrunner 2y ago
    > read the second quarter of the book And then never get to the third and fourth quarters because the practise you get from actually typing stuff is far more valuable? :)
    - _xiaz 2y ago
      Exactly. There usually is some stuff about the deeper, darker corners of a language in the type of book I pick. I usually pick the authoritative book / advanced book. Think "Programming PHP", "The joy of clojure", "The C Programming Language", etc. I don't necessarily need to know all about performance optimization, the async model or non-html templating. Reading a technical book cover to cover feels wasteful imo

simiones 2y ago

I completely disagree. I have been successful in building a new project for my company with myself and the entire team being completely new to Go when we started. Did we have growing pains, and some sub-par decisions? Absolutely. Do we right better Go code today, 4 years later? Absolutely. Did this mean that the project was in any way significantly slowed down by our use of Go compared to the C# or Java we knew before after the first 1-2 months? No, not really. The ways in which Go fit better for our chosen domain completely made up for that (and this all despite my continued belief that Go as a language is inferior to Java and C#). Now, there are other languages where I'm sure that we would have had significant issues if we tried to adopt them. In particular, switching from the GC languages we were used to to a native memory language like C++ or Rust or C would have surely been a much bigger problem. The same would have probably been true if we had switched to a dynamic language. But generally, deep language proficiency has less value in my experience than general programming proficiency, and much less than relevant domain knowledge. I would hire a complete Go novice that had programmed in Python in our specific domain over someone who has worked in Go for a decade but has only passing domain knowledge any day.

m_a_g 2y ago

Here is the thing: many software engineers don't need to learn a language "properly." When you start a new job, there will almost always be an existing code base, and you'll have to make contributions to it. Pattern recognition will get you a long way before you need to dive deep into the language internals.

rkangel 2y ago
This is true, and it makes the people who do actually know the language in depth extra valuable.
- lnenad 2y ago
  Only for situations where that knowledge is required.
- tekknik 2y ago
  Not so much. I know quite a few languages very well, more than the average programmer, and more often than not a senior programmer overrides your recommendation and don’t know the language as well as you or some other red tape. What has never happened is getting an increase in pay for knowing a language well. So I share the sentiment that learning a language well is valuable. It’s not, and with the newer AI tools coming out there will soon be no reason to learn any language in depth.
  - sevensor 2y ago
    I think you have that exactly backwards. LLM-based tools do best on shallow-knowledge tasks. It’s depth where they struggle. Show me the syntax for constructing a lazy sequence in your language? LLM. Reason about its performance characteristics and interactions with other language features? Human, for the foreseeable future.
bborud 2y ago
You are mixing two things. Learning a language and learning a codebase. Those are not the same thing. Besides, you are also just talking about what happens during the first N months. Most companies I've worked for allow for time to learn the language(s) being used. Some of them will fire you if you can't show sufficient progress over time.

vouaobrasil 2y ago

That's true. I agree. Python is the only language I ever really learned to a deep level and properly, and it makes a huge difference! (And I'm still learning of course.)

machiaweliczny 2y ago

Using esoteric lang constructs is bad idea IMO. Makes software harder to read/port/maintain. It’s useful for some hack & high perf stuff but not typical apps.

bborud 2y ago
Agreed. But knowing a bit about how a language (and runtime) actually works can make a huge difference when you design stuff. For instance, I've seen lots of examples of people implementing LRU caches in Java, and then scratching their heads when performance drops because they have no idea how the GC works. Or complicating things immensely because they realize memory is tricky and then ending up with some complex pooling scheme that constantly breaks rather than realizing that often more naive code that exploits the low cost of ultra short-lived local objects. If you know what you are doing it becomes easier to choose solutions that are performant and understandable.

jamwt 2y ago

IME, engineers and "the discourse" when we argue on the Internet often conflate "ease of use" and "ease of learning". When we say "ease of use", we usually mean "ease of learning." If you're a hobbyist, yeah, you should heavily value "ease of learning." If you're a professional, the learning curve is worth it if the tool's every day leverage is very high once you're ramped up. Too many developers don't put those 3-4 months in, in part due to the over-emphasis on "ease of learning" in our discussions/evaluations of things. I was a part of a very large go project (https://news.ycombinator.com/item?id=11282948 https://news.ycombinator.com/item?id=11282948) and go-based company infra generally some years ago, and go is emblematic of the classic tool that is amazing at ease of learning, and quite mediocre at "ease of use" as time goes on. I personally end up resenting those tools because I feel tricked or condescended to. (This is a little silly, but emotions are silly.) I'd wager this is also why Rust is a perennial "most loved" winner in the surveys: it gets better as your relationship with it deepens, and it keeps its promises. Developers highly value integrity over trickery, and hard-earned but deep value feels like integrity and wins in the long run. (other examples: VIM, *nix, git)