Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Programming

Rust Growing Fastest, But JavaScript Reigns Supreme (thenewstack.io) 55

Posted by EditorDavid from the race-conditions dept.
"Rust is the fastest-growing programming language, with its developer community doubling in size over the past two years," writes The New Stack, "yet JavaScript remains the most popular language with 25.2 million active developers, according to the results of a recent survey." The 26th edition of SlashData's Developer Nation survey showed that the Rust community doubled its number of users over the past two years — from two million in the first quarter of 2022 to four million in the first quarter of 2024 — and by 33% in the last 12 months alone. The SlashData report covers the first quarter of 2024. "Rust has developed a passionate community that advocates for it as a memory-safe language which can provide great performance, but cybersecurity concerns may lead to an even greater increase," the report said. "The USA and its international partners have made the case in the last six months for adopting memory-safe languages...."

"JavaScript's dominant position is unlikely to change anytime soon, with its developer population increasing by 4M developers over the last 12 months, with a growth rate in line with the global developer population growth," the report said. The strength of the JavaScript community is fueled by the widespread use of the language across all types of development projects, with at least 25% of developers in every project type using it, the report said. "Even in development areas not commonly associated with the language, such as on-device coding for IoT projects, JavaScript still sees considerable adoption," SlashData said.

Also, coming in strong, Python has overtaken Java as the second most popular language, driven by the interest in machine learning and AI. The battle between Python and Java shows Python with 18.2 million developers in Q1 2024 compared to Java's 17.7 million. This comes about after Python added more than 2.1 million net new developers to its community over the last 12 months, compared to Java which only increased by 1.2 million developers... Following behind Java there is a six-million-developer gap to the next largest community, which is C++ with 11.4 million developers, closely trailed by C# with 10.2 million and PHP with 9.8 million. Languages with the smallest communities include Objective-C with 2.7 million developers, Ruby with 2.5 million, and Lua with 1.8 million. Meanwhile, the Go language saw its developer population grow by 10% over the last year. It had previously outpaced the global developer population growth, growing by 5Y% over the past two years, from three million in Q1 2022 to 4.7 million in Q1 2024.
"TNS analyst Lawrence Hecht has a few different takeaways. He notes that with the exceptions of Rust, Go and JavaScript, the other major programming languages all grew slower than the total developer population, which SlashData says increased 39% over the last two years alone."

Rust Growing Fastest, But JavaScript Reigns Supreme More | Reply

Rust Growing Fastest, But JavaScript Reigns Supreme

Comments Filter:

  • Rust Growing Fastest (Score:2, Offtopic)

    by PPH ( 736903 )

    Some Naval Jelly and a wire brush should take care of that.

    • I heard Rust never sleeps, though.

  • Probably the first time in ages I started learning the language of the day and didn't hate everything.

    • Re: (Score:1)

      by znrt ( 2424692 )

      if you had said "and didn't hate anything" i would say that that's just a common symptom of fanboyism.

      since you said "didn't hate everything" i would assume that you have no clue about programming languages whatsoever. or you are just talking trash. either way, why do you think anybody should be interested in knowing?

      • The most important thing is getting first post on Slashdot.
        An act so incredible it opens membership to elite social clubs like the GNAA.

        But this is supposed to be the part where you argue with me or we wank over rust being the new C or we make jokes about programming socks.

    • Re: (Score:1)

      by jythie ( 914043 )
      Rust itself, like all research languages, is pretty good. The problem is the rust community.

      • Putting on my pretty pink programming socks!
        They got the little toes in em.

      • Re: (Score:3, Informative)

        by christoban ( 3028573 )

        The Rust community is extremely helpful. Not sure what you're talking about.

      • Re: (Score:3, Informative)

        by ArmoredDragon ( 3450605 )

        The community is one of the best things about rust. I've never found one person that doesn't try to be helpful, even the compiler developers go out of their way to make it easy to understand exactly why your code doesn't compile in as plain English as you can get, even drawing little diagrams in the compiler output and giving you "you probably meant to do this..." directions in the actual compiler output.

        Meanwhile, look at the C++ community. Each and every single one of them swears they're the only develope

        • Re: (Score:2)

          by jythie ( 914043 )
          I did not say they were unhelpful or unfriendly, only that they were a problem. Rust is a social filter, it is all about verifying OTHER people's code is up to YOUR standards... in other words, it makes sure your community is only the 'right' kind of people. They are great as long as you are praising them, their way, and trying to find your place within their social order.
    • Yep. It just feels so connected to the compiled code and the hardware.

  • What we need... (Score:5, Interesting)

    by jd ( 1658 ) <imipak@ya h o o .com> on Saturday June 08, 2024 @05:55PM (#64534103) Homepage Journal

    ...is not a popularity contest between languages, but rather a full survey of what is out there, which languages are specified in a way that'll link to other languages (and which ones), which use cases are best solved by each language and what the costs are for those solutions (eg: expected defect density, typical relative code size, typical relative code performance, typical relative code complexity, typical code implementation time, typical relative memory consumption, ease of testing, and typical relative power consumption for those ideal use cases).

    In the case of C alone, we've various C standards, plus the SILK extensions for parallelism bought out by Intel, plus the C variants: Verifiable C, Unified Parallel C, Objective C, C++, Aspect-Oriented C++, Functional C++, D, Zig, plus everything else on Wikipedia's list: https://en.m.wikipedia.org/wik... [wikipedia.org]

    But there's lots of obscure stuff too - Nim, Lua, Eiffel, Oberon, SPARK, and so on.

    Once we've a proper catalogue of what exists, and there's a LOT out there, then we can sensibly talk about what languages simply don't make any sense to use, no matter which metric you consider important, regardless of its popularity.

    We already know workplaces aren't going to consider usefulness, only cost of hiring someone with the right skill set, but such a map would be helpful for those developing new tools outside the commercial sector.

    For example, yes, Rust is the only language that can officially bind to the Linux kernel, but if you're developing performant, robust, out-of-tree modules that can link to the kernel, what are your choices?

    Are there language that would actually perform better than C, given that modern instruction sets and CPU architectures are so advanced and C can't describe constructs that could take full advantage of them? (I'm thinking here of the case of OpenZFS, which is slow and resource-hungry - is the filesystem written in the wrong language for the job?)

    Equally, are there languages that could bind to C that'd be far more robust and reliable? There's lots of C libraries out there that emphasise size for the embedded world, but there's plenty of mission-critical spaces where size is less important than the code not crashing. A safety-critical-suitable libc, even if not written in C, would get used.

    But nobody can attempt any of this if we don't know what's out there, what it is ideally used for, when, when it should not be used, and what it'll typically bind to.

    • No moderator points for me today, so I'll just add a few thoughts to a quality post.

      To build on the problems with compiling C for modern architectures, the C language in its simplicity doesn't give a modern compiler a lot of information to work with. I know of optimizations done in Ada that build on reasoning from the type model, to pick better representations, do pocket optimizations where a weakly typed language might have to worry about numerical situations that can't happen, etc. (Ada happens to be th

      • Re: (Score:2)

        by jd ( 1658 )

        Oh, absolutely, and even in the Ada world, you've at least two languages (Ada itself and the SPARK subset that includes additional verification tools).

        But because SPARK is a subset, as a novice to Ada compilers (even though I'm perfectly knowledgeable on coding in it), I can't tell you how, or even if, that limits the optimisations performed in Ada or whether the restricted functionality actually enables further optimisations to take place.

        I know Ada is energy-hungry, because there was a table published rec

        • I remember a discussion on Ada compiler 'middle end' data flow optimizations that were possible using type information. SPARK compilers as a proper subset of Ada can take full advantage of optimizations Ada can support. It would be possible for a SPARK compiler to use information in the annotations, but I don't know if that's done.

          A table on 'power consumption by language' strikes me as bizarre, but OK. I'm sure Python did terrible there as an interpreted language. The other question for something like

        • Oh, and an anecdote about Ada95 and SPARK. We did an experiment on 'incremental formal methods' where we used SPARK to implement much of the TCP protocol, but went into conventional Ada95 when we needed features not supported by SPARK. Now by conventional metrics, my productivity was terrible. I spent a week learning about Ada95 Asynchronous Transfer of Control, and wrote 5 lines of code to implement the timeout provision in TCP. Our "control" was a developer with experience implementing protocols. He

    • Re: (Score:2)

      by znrt ( 2424692 )

      ...is not a popularity contest between languages

      this is just gossip, you are taking it way too seriously. it creates articles in tech outlets and blog entries of companies that have nothing better to show, it is business and excellent clickbait for slashdot because these threads tend to accumulate lots of replies, many of them funny which means that the usual forumites are having a good time crap-posting the popularity contest. what's not to like?

      but rather a full survey of what is out there, which languages are specified in a way that'll link to other languages (and which ones), which use cases are best solved by each language and what the costs are for those solutions

      oh, you're really serious! why do we need that? isn't that supposed to be already part of the experience of

      • Re: (Score:2)

        by jd ( 1658 )

        Software engineers tend to specialise in a few tools and ignore everything outside their niche. I'm extremely unusual in that I know many computer languages of different types and different generations, and multiple operating systems. And even I can't tell you how they compare.

        I'm seasoned (having started in 1978) but I cannot tell you which language is appropriate in which circumstance, nor can I tell you which languages are specified to be ABI-compatible.

        There was a recent survey of energy cost for a hand

        • Re: (Score:2)

          by znrt ( 2424692 )

          you are citing many wildly different parameters, from energy efficiency to abi or os compatibility, and you are comparing compiled to bytecode languages to databases and crypto libraries and hardware. i don't really see the utility of such a wide spectrum inventory which would be quite costly to maintain. every example you cited in the end narrows down to a few specific options with very specific requirements, what they have in common is that they can change wildly form use case to use case, and that the op

          • Re: (Score:2)

            by jd ( 1658 )

            That's because the parameters are wildly varying. If you're wanting to describe a system, you can't limit yourself to a narrow subset of parameters because the entire objective is to choose something that describes the problem you're trying to solve and not describe the political prejudices.

            No, the parameters should be fairly consistent.

            Defect density, for example, will be a direct function of the number of lines of code needed, the clarity of those lines (ie: how easily you can see the solution space), the

      • Re: (Score:2)

        by caseih ( 160668 )

        Don't forget Circle. [circle-lang.org] It's the closest to conventional C++ of all the variants. Been around for about 8 years now, but recently got all the Rust safety features. Unlike Rust, though, you opt into the safety, not out. But for doing incremental improvements and rewrites to existing C++ code, this just might be the way to go. Nearly all the rust safety features are implemented. Pretty interesting stuff. Of course C++ is already a wildly complex language and this adds complexity to that, but not overly so

    • Re:What we need... (Score:4, Insightful)

      by phantomfive ( 622387 ) on Saturday June 08, 2024 @07:18PM (#64534251) Journal
      Popularity matters a lot. If you use an obscure language, you'll have trouble hiring people.

      Javascript is a trash language, but it's hard to escape using it.

      • Re: (Score:2)

        by jd ( 1658 )

        Reliance on popularity is why most software out there is written using completely the wrong tools for the job.

        I've been in this field a long time, and the only time I have had any confidence in what was used was when NASA asked me to research the options beforehand and publish a white paper detailing what they were and the pros and cons of using each.

        Outside of that, I can say with confidence that corporations have typically decided on language for reasons of cost/ease of hiring, and not because the languag

        • For most tasks, library support matters more than the language. If you want to do neural networks, you're using Python because that's where the libraries are. If you want to do graphics, it doesn't matter how performant Ada is, you're going to use C++, because that's where the graphics libraries are.

          I'm not happy about it, but the reality is most modern languages are adequate and the libraries are how you choose the language. I'm not happy about it because I always end up using inferior languages.

          • Re: (Score:2)

            by jd ( 1658 )

            That doesn't matter nearly as much as you think.

            For example, Java has complete access to C++ libraries via the JNI.

            https://amadoruavs.medium.com/... [medium.com]

            Python can talk to C and C++, so programs in either language can work with Python libraries and vice versa.

            Fortran can also intetoperate with C/C++, so it automatically follows that a shim layer is sufficient to get Python or Java to intetoperate with Fortran. Does such a shim exist? It's not documented and, with Freshmeat long extinct, it's not trivial to find

            • All your examples are being able to use C or C++ from other languages. Yes, but where is a decent web framework in C++?

            • FFI interfaces suck. You have to convert types from one language to another and make all sorts compromises in order to get it working well. FFI interfaces are fast but they are neither easy nor safe. Just look at all the security issues with Java when they were offloading much of their functionality via JNI calls and those underlying libraries were not secure. I tried using JNI when I had to interface with some hardware. It worked, but would have been easier to just write in C. Using JNI requires usi

      • Hire good programmers and teach them the language you use on this project.

        The one hard-and-fast rule I had in hiring is "every developer must demonstrate proficiency in 2 -different- languages. C/C++ counts as -1-." The more languages you learn, the more ways you learn how to think about the problem and its solution.

        • You can do that, but a lot of programmers are unwilling to learn a new, obscure language because it will somewhat limit their career prospects in the future.

          So using an obscure language makes it harder to hire people.

          • Well, people like that are not the kind of people I'd want to hire.

            Your mileage/experience may vary, of course.

            • Yes of course, we all want to hire the best programmers in the world. But that's not the choice, the choice is to hire what is available or do nothing. (Or do it yourself if it's a small project).

    • I was once at a talk with Bjarne Stroustrup in Frankfurt/Germany. Around 1993 or so.
      He finished his talk with something like:
      Programmers should keep learning more programming languages.
      And humans should keep learning several natural languages.

      The rest of the talk I have completely forgotten.

      • Re: (Score:2)

        by jd ( 1658 )

        The more we learn about the brain, the better the natural language advice sounds. Polyglots have greater resistence to the effects of ageing and greater mental capacity when all else is equal.

        It's sound programming advice, too. Most programming languages have a relatively narrow window of where they're ideally suited. Ones that don't will be ok for many things but won't be great at any of them.

  • Everyone has one, even people with phones and such.
    Rust you have to install.

    • Re: (Score:2)

      by evanh ( 627108 )

      Sort of. JIT for JS only clicks in when the source is crafted as if it were a compiled language. Half the language has to be stripped out or it don't compile. It may as well be another language.

  • They're very popular, especially in developing countries

  • I'll take the one with sour cream and tomatoes.

  • For when you're too "challenged" to actually be an actual developer!

    Seriously. One of these is a compiled solution, the other enables the kludging together of garbage kludges... and we're excited!

  • Rust is still a long way from JS. Although I’m new to programming, I already know a lot. I started with computer science help, I found https://edubirdie.com/computer-science-help [edubirdie.com] for this. Then I found courses and a job. Now I’m slowly understanding Rust, I feel it will come in handy.

Slashdot Top Deals

"What a wonder is USENET; such wholesale production of conjecture from such a trifling investment in fact." -- Carl S. Gutekunst

Close