Forgot your password?
Close
typodupeerror
AI Programming

Is AI Impacting Which Programming Language Projects Use? (github.blog) 58

Posted by EditorDavid from the language-barriers dept.
"In August 2025, TypeScript surpassed both Python and JavaScript to become the most-used language on GitHub for the first time ever..." writes GitHub's senior developer advocate.

They point to this as proof that "AI isn't just speeding up coding. It's reshaping which languages, frameworks, and tools developers choose in the first place." Eighty percent of new developers on GitHub use Copilot within their first week. Those early exposures reset the baseline for what "easy" means. When AI handles boilerplate and error-prone syntax, the penalty for choosing powerful but complex languages disappears. Developers stop avoiding tools with high overhead and start picking based on utility instead.

The language adoption data shows this behavioral shift:

— TypeScript grew 66% year-over-year
— JavaScript grew 24%
— Shell scripting usage in AI-generated projects jumped 206%

That last one matters. We didn't suddenly love Bash. AI absorbed the friction that made shell scripting painful. So now we use the right tool for the job without the usual cost.
"When a task or process goes smoothly, your brain remembers," they point out. "Convenience captures attention. Reduced friction becomes a preference — and preferences at scale can shift ecosystems." And they offer these suggestions...
  • "AI performs better with strongly typed languages. Strongly typed languages give AI much clearer constraints..."
  • "Standardize before you scale. Document patterns. Publish template repositories. Make your architectural decisions explicit. AI tools will mirror whatever structures they see."
  • "Test AI-generated code harder, not less."

This discussion has been archived. No new comments can be posted.

Is AI Impacting Which Programming Language Projects Use? More

Is AI Impacting Which Programming Language Projects Use?

Comments Filter:

  • Interesting Summary (Score:2, Interesting)

    by Oddroot ( 4245189 )

    The style and presentation of the summary, presumably quoted from the "article" actually reads like AI-generated slop text itself. This would be very on-brand for the AI bros.

    • The claims also seem a bit sus. "Eighty percent of new developers on GitHub use Copilot within their first week." Is this the same statistic someone was debunking recently where anyone who had done something really basic (it might have been using the search facility?) was counted as "using Copilot"? A lot of organisations seem to be cautious about using code generated by AIs, or even imposing a blanket ban, so things must be very different in other parts of the industry if that 80% is also representative of

      • Microsoft is rebranding every one of their products "Copilot", so at this point it seems hard to avoid using it.

      • Re: Interesting Summary (Score:5, Interesting)

        by jlowery ( 47102 ) on Monday February 23, 2026 @10:36AM (#66005346)

        Any organization that imposes a blanket ban on AI tools will soon be left in the dust.

        To use a tautology, AI is good at what AI is good for: documentation, research, incremential coding, performance/storage tradeoff evaluation.

        It is not (yet) good at architecture design or efficiency, nor even following DRY principles. It is nonetheless really, really useful for what it does well.

        • it's also pretty awful at writing non-exploitable code, with security review representing a ton of time for organizations that have particular reason to care about that.

        • There's a difference between not using AI tools at all and not using code generated by AIs.

          The latter involves a lot of risks that aren't well understood yet -- some technical, some legal, some ethical -- and it's entirely possibly that some of those risks are going to blow up in the face of the gung-ho adopters with existential consequences for their businesses.

          I mostly work with clients in industries where quality matters. Think engineering applications where equipment going wrong destroys things or kills

    • Came here to say this.. the wording is 100% AI.

  • my experience too (Score:4, Insightful)

    by cjonslashdot ( 904508 ) on Monday February 23, 2026 @09:01AM (#66005206)

    "AI performs better with strongly typed languages. Strongly typed languages give AI much clearer constraints..."

    As Guido van Rossum, the creator of Python once wrote,

    "I've learned a painful lesson, that for small programs dynamic typing is great. For large programs, you have to have a more disciplined approach. And it helps if the language actually gives you that discipline, rather than telling you, 'Well, you can do whatever you want.'"

    • Re: (Score:3)

      by Tomahawk ( 1343 )
      It's one of the things I like about C -- it enforces these things, but still allows you to explicitly ignore them. It would be harder to write the Fast inverse square root [wikipedia.org] without it.

    • I won't argue with Guido van Rossum, but in my meagre experience, a Python project is "one thing", and so yes, stronger typing would likely be useful. However, a Javascript (or TS) project, in modern frameworks is a bit like loads of small projects. That is, each component of a page, or perhaps each page is like a separate project in a way - as such, the typing problem is much smaller, and so JS or TS will be fine there (and it's possible to mix the two).

      That said, AI is popularist. If TS is the predominant

      • Hi - thanks for this thoughtful response.

        I do like the flexibility of Javascript-like languages - e.g. that one can just add an attribute to any object. But one pays for that:

        I am working on a pure Javascript front end with a Java back end at the moment, and whenever I have to make changes to an object that needs to pass between the two, it is a real headache on the Javascript side - there is no compiler to find all the places where I used the object based on its old definition...

        So pros and cons.

      • There are two dimensions:
        strong < -- > weak typing
        static < -- > dynamic typing

        I think people should take more care not to mix them up constantly.

        Python is a strong but dynamic typed language.

        As a contra point: K&R C is a weak but static typed language.

        As we seem to have a fellow /. er who has no clue about languages, but thinks he is an expert, FORTH is an implicit static and strong typed language ... unless you have a weird extension :P

  • So like low-skill coders then? Figures.

  • Yeah like we all learn from our successes, rather than our failures.
    Unless they probably mean a dopamine hit, which is also not a good indicator of something being a good idea for using.
    This story and this summary reads like a hallucination party - no thanks.

  • Then why not tell the AI to write the code in highly optimized Assembly?

    • Re: (Score:3)

      by allo ( 1728082 )

      Because your compiler for a high level language does it better than you and AI combined.

  • Re: AI (Score:2, Insightful)

    by Motleypuss ( 10291831 )
    AI will touch a line of code of mine only after I'm dead, buried and eaten by a whole bunch of macro/micro-organisms far more worthwhile than AI will ever be to me. I might be getting a little long in the tooth, but predictive neural networks can't and won't surpass the human brain at programming for a long while yet.

  • It did not (Score:3, Insightful)

    by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Monday February 23, 2026 @10:11AM (#66005298) Homepage Journal

    AI absorbed the friction that made shell scripting painful.

    What friction? What pain? Shell scripting is easy, and if you don't understand or remember how to do something, you can trivially find the answer with google unless you are truly completely incompetent at determining which search terms to use. Or often, find the answer by studying scripts which are already on your system! Don't be fucking helpless, which is what AI will make you by doing it for you.

    Making things easier for package maintainers was one of the big excuses for adopting systemd. Now we have a whole new class of problem, problems with systemd. Meanwhile shell scripting is a core Unix[like] feature. If you don't understand it well enough to do init scripts, you aren't qualified to be a packager either.

    • Re: (Score:2)

      by allo ( 1728082 )

      It is easy until your paths are allowed to contain spaces. And then have fun escaping them with constructs like sed 's/\\\ \\\/\\\\ \\\\' to add the right level of escape characters required in later commands, which usually each eat one level of escape characters. That's usually the point to start using python (or perl if you really want to) instead of bash.

    • Having to google how to do things == friction.

  • Yes. With me it is. (Score:3)

    by Qbertino ( 265505 ) <moiraNO@SPAMmodparlor.com> on Monday February 23, 2026 @10:28AM (#66005324)

    I feel totally confident solving problems with PLs I wouldn't have touched with a ten-foot pole just a year back, due to AI.

    Example: The legacy application I am currently maintaining and replacing is totally borked with piles of spagetti-code and shitty, amateurish or simply non-existent architecture. However, I do have to add logic to this already unmaintainable system so I often just push larger portions of that logic further down into the DB and SQL.

    SQL _is_ turing complete, but actually developing applications using mostly or only SQL is reserved for very strange/special people still stuck in the 70ies mainframe era or something. Beyond some joins I would never do anything with this PL and move all more complex logic into the application layer.

    But with AI writing SQL I feel confident to do such a thing. I _can_ understand what the code does and fix smaller mistakes the AI makes, but actually looking up the syntax and writing it myself would be a complete waste of time and energy to me. With AI absolutely not. It is strange using this PL I normally wouldn't and in this specific scenario it is a stop-gap for reasons unrelated to the tech-stack, but the AI puts out solid code and even corrects my SQL quick-hacks for commits I did myself.

    For me the state of things right now is the following: Current AI is basically an API documentation you can talk to, with a premium expert attached. For all PLs that have enough documentation and demo-code available online and enough code-repos of functioning open-source projects for AIs to source information from, AI is a totally viable main programmer if you take your time to lead it well, hand-hold it along the way and double-check the code it generates and avoid any "vibe-coding" bullsh1t.

    I would totally feel confident in taking on projects and tasks with APIs or PLs I haven't used yet but am interested in and consider wide-spread enough for AI to know well. I've actually considered doing something like that, like some Rust CLI project or something, just to learn the PL along the way.

    And I expect all this AI progging to only improve even further, and quite quickly so.

    • Interesting post--I have also found that LLMs are extremely good at creating and optimizing queries and, as you mention, PL.

      I also am dealing with some legacy software. Many years ago I wrote a text file to SQL updater that keeps an SQL database in sync with the legacy application text file databases. With LLM I have created and moved some annoying chunks of logic into triggers, a couple of GENERATED columns, etc. I am reasonably good at SQL. I always spent way more time working on triggers than I probably

    • Yep, I recently launched into my first Vue.js website, though my strength has never been front end programming. With AI, the learning curve was dramatically shortened. Not only am I know able to write Vue.js code myself, but I was able to get the project up and running in about 1/3 the time.

      Also, I'm very experienced with SQL, but when it comes to getting data out of JSON or XML fields in SQL, the syntax is *especially* arcane and difficult. AI is a lifesaver with these.

  • ....is that people will hopefully use less Python and stop using those bullshit "It makes me more productive excuses."....when they meant to say "I don't know how to use any other language". If you code for fun?...play with whatever toy you like...when you do this professionally, keep scripting languages out of programs that are meant to scale and do real work. A fuckton of Python has to be rewritten every goddamn year. Some student or intern writes a cool app...it gets users and then it has to be rewritt

  • WTF... (Score:3)

    by Junta ( 36770 ) on Monday February 23, 2026 @02:09PM (#66005850)

    We didn't suddenly love Bash. AI absorbed the friction that made shell scripting painful. So now we use the right tool for the job without the usual cost.

    This is a huge 'wtf' statement. People use shell scripting because it is low friction, but shell scripting sucks for scaling up complexity and maintenance. If you said to me 'LLMs let people take their quick and dirty shell scripts and port them to something that has more reasonable syntax for complex structures', ok, that sounds plausible and a good idea.

    If a shell script is so complex you *need* an LLM to do it for you, it *probably* shouldn't be a shell script.

    (Frustrated due to a certain team I've worked with refusing to move beyond shell scripting and having just the most unmanageable ball of crap, and they frequently have to ask others to debug the mess they made because they no longer understand their own scripting)

    • (Frustrated due to a certain team I've worked with refusing to move beyond shell scripting and having just the most unmanageable ball of crap, and they frequently have to ask others to debug the mess they made because they no longer understand their own scripting)

      They should learn to write comments, then. The more I had to learn to write some code, the more comments I write, even if it's in a shell script. Then when I go back and look at it later, whether to maintain it or as an example for another script, it makes sense to me. Honestly though I almost never have to write comments in shell scripts as they're usually quite easy to understand, it's perl scripts where they are really important. Practically everything in a shell script is something I might actually do i

      • Re: (Score:2)

        by Junta ( 36770 )

        Comments only do so much, the syntax for shell scripts to do complex things just gets ugly.

        Shell syntax is optimized for running commands, but that leaves fitting other tasks into very obtuse syntax. You also have no sane way of managing namespace. It is *capable* of a lot, but other languages are just more sophisticated at scaling complexity, at the expense of being super tedious for "just run some commands". LLM offloads tedium so a 'script-level' description can be formed into a more structured progra

        • If it's too complicated for Bourne then I use Perl. If it's too complicated for Perl, then sure, it's too complicated for a script :)

          Though in all seriousness complexity is seldom a reason to not use a script, because performance is a reason before you get there.

          • Re: (Score:2)

            by Junta ( 36770 )

            Scripts are usually poor performance for the fork/exec that you usually do.

            The scripts get really scary when they manage to avoid the fork/exec subcommands and manage to do almost everything in the script primitives themselves.

            Would much rather see a perl or python script than the monstrosities I have seen...

            Though I will confess conversely I hate seeing hundreds of lines of python that could have been a quick readable 6 line script (performance permitting, as you point out).

            • Scripts are usually poor performance for the fork/exec that you usually do.

              Thing is, process creation is cheap on Unix, and there's no doubt already a shell in memory somewhere, plus modern computers are just stupid fast so it's only gotten more viable. I mean yeah we're wasting a lot of cycles, but my moderately-good-for-last-generation PC is a ridiculous monster of computing ability compared to the first machines I ran Unix on, which were in turn a few times faster than the first machines which ran Unix and had much faster storage. And shell scripts would mostly run in completel

Slashdot Top Deals

Diplomacy is the art of saying "nice doggy" until you can find a rock.

Close