Compared with the popular Rust and Go, why are Java and C making slow progress at the tool level?

The 2022 Stack Overflow Developer Survey results have been officially announced. Every time this time, developers have a lot of words to complain or praise, and so does developer Adam Gordon Bell. Bell’s focus is on the most popular and least popular programming languages. Let’s take a brief look at the survey results:

Rust, Typescript, Python, Go, C#, Kotlin, JavaScript

Ruby, C++, Java, PHP, C

Why some languages ​​are popular and some are hated

In the last developer survey, Bell mentioned that when people love a new programming language, they are more or less biased, that the new language should be used for new projects and the old language should be used for Develop old projects. But this clearly ignores another reality: the language tools themselves are constantly improving. So Bell wrote an article to make his point and attribute the reason why programming languages ​​are liked to instrumental development.

Take Go and Rust as an example, the industry debate about the two has never stopped, but the developer tools for the two languages ​​are very similar in experience: they are both very modern, whether it is testing, fuzzing, packaging or verification, they are all The corresponding best tool standard package can be provided. Bell believes that the biggest difference between Go and Rust from the languages ​​on the unpopular list is not the syntax details, but the tooling options and ecosystem. This is how they both make it to the list of the most loved languages.

Bell believes that the tooling and developer experience for programming languages ​​are improving over time, but that improvement is more pronounced in new languages. In general, new languages ​​are adopted and standardized more quickly after innovations emerge, ultimately providing results that outperform established languages. With the accumulation of such increments, the once trump card language will appear outdated and rotten.

“Why can’t we be friends?”

The netizen ” crashorbit ” pointed out the problems in the actual development. “Most people who work on systems are short-term contractors who don’t understand what the problem is and leave soon after delivering a poorly tested system. Version control, automated testing, documentation updates, Release engineering and the rest of the expected system development life cycle.”

Middle managers don’t understand systems engineering, and senior managers are more interested in “getting” things done than having sustainable systems engineering practices, Crashorbit said. “Frankly, it’s hard to tell the difference between a well-designed information system and a system that basically works but fails ‘when the wind blows’.”

The number of people working in “software jobs” grows by a few percent every year. Most of them work in very vertical environments, often writing spreadsheets or cluttered applications on their desktops. Some people write “scripts” that just do simple things. Or use “machine learning” tools they don’t understand to produce misleading results.

“We create instant legacy this way. No modularity, no revision control, no deployment strategy, and no disaster recovery plan. The developers are long gone, let alone the systems engineers. That’s what I call ‘traditional resistance’ I mean, that’s why the industry is so slow,” Crashorbit said.

Developer “fuddlesworth” says his company is “stuck” with React 16 because core UI components across the company are tested with Enzyme, and thousands of tests are changed once the transition occurs. “We can no longer update any components based on React, so no bug fixes, new features, performance improvements, etc.”

Developer “alexiooo98” argues that better tools are certainly very welcome, but that alone doesn’t fully explain why some languages ​​are loved and others are feared. For example, (modern) PHP has great tools, but it’s scary. Python’s package manager environment is very confusing, yet Python is very popular.

Below is a detailed description of the differences in programming language development from Bell’s paper, translated and with minor changes that don’t change the meaning. Note that the innovations mentioned below have nothing to do with the syntax or semantics of the language.

standard library

I’m not sure if that’s a good or bad thing, but extending the standard library does allow developers to enjoy a lot of out-of-the-box functionality in PHP, Python, and Go without having to install any third-party libraries. Most of them come with json, http clients and servers, and even database access mechanisms.

—Amir Saeid

The so-called standard library is the common content library that comes with the language. C has libc, C++ has libcpp, but compared with today’s common built-in “battery” standard libraries, the first two libraries are pitifully small.

I can’t remember exactly, but Python, born in 1991, seems to be the first programming language to really have an extensive standard library. Java 1.0 (1996) also came with an extension to the standard library (the Java Class library), and other languages ​​followed suit.

This convenient way of delivering tools without building your own and without touching third-party dependencies is a boon to developers around the world.

The best in the standard library: GoLang

Most modern languages ​​(excluding JavaScript) now ship with rich standard libraries. However, Go’s emphasis on the standard library remains unparalleled, with its promise of backwards compatibility, and a strong focus on performance and a polished implementation. Because of this, Go developers are far more dependent on the standard library than other communities, and generally pay more attention to the standard library.

Third Party Toolkit Libraries

Just as the standard library was taking shape, the World Wide Web began to take off rapidly. It turns out that the Internet is indeed an excellent set of collaboration platforms.

What if our needs cannot be met in the standard library and we have to build new functionality ourselves? Perl popularized the concept of a global toolkit collection through CPAN, and everything has changed since then. To be fair, anyone who has used CPAN and contributed to it can feel its game-changing significance.

CPAN was launched in 1995 (based on CTAN) and peaked in 2003. Its emergence has opened up a new path for people who use software to get work done by stitching together third-party components. Now, many modern development projects follow this pattern.

Beginning in 2003, almost all common programming languages ​​that have been born since then come with some sort of third-party toolkit library. The creator of this trend is CPAN, which tells the world that “real” programming languages ​​must have a third-party toolkit management strategy.

Side note: backported

Having said this, some friends may ask, since CPAN made Perl better and also allowed the new languages ​​to accept the concept of third-party toolkit managers, why did the previous languages ​​not think about fixing the problem and adding What about package managers?

In fact, they have thought about it, but once the development of the language has passed a certain stage, it seems that it becomes more and more difficult to reach an agreement. I don’t know why this is happening, probably most people don’t like making changes?

Anyway, once the idiomatic expressions, basic patterns and technical communities of programming languages ​​are established, it is very difficult to go back and adjust them. It is because of this that JavaScript has NPCs and Rust has crates, while C++ has its own exclusive dds, cpm, conan, pacm, spakc, buckaroo, hunter and vcpkg. It is because there is no general consensus that eight toolkit managers have emerged on the C++ side.

However, the backward porting of the standard library was relatively smooth. C++ successfully recruited part of the STL under its command, and although it was late, the addition of the standard library was finally completed. Therefore, the old language can also carry tool innovation, but it will be more difficult.

In short, after CPAN, a strong standard library has been able to help developers with most tasks. In addition, third-party toolkit libraries that are easy to use and accept direct contributions are standard. Without these two, language would be lifeless.

Documentation support

With third-party toolkits in place, the next step is to document them in an easy way. The earliest version of documentation I came across was Javadoc. It makes it easier for me to find what I need in Java Classes: it’s just a click away from Javadocs on the web. After that, we can combine Javadoc with IDE integration to quickly use code we haven’t seen before. Thus, exploratory coding becomes possible.

Strongest Documentation Tool: Rust’s docs.rs

Today, Javadocs for Java are no longer the industry standard. Go has godoc, Julia has Documeter.jl, and even hackage has good toolkit documentation. But looking at the world, the strongest documentation tool is Rust’s docs.rs.

Write once, run anywhere

One improvement I’ve seen is the standardization of J2EE and Web servers, the foundation of computing on which we live today. Java and the JVM are pioneers, but I don’t think they are fully recognized. After the popularity of Java, the development platform and the deployment platform have truly achieved non-interference with each other. Everyone is used to this kind of advantage these days, but 20 years ago, it was definitely a revolutionary disruption.

—Cédric Beust

Java and the JVM have really pushed cross-platform development along the way. The development environment no longer needs to closely match the production environment. Using the JVM, we can compile content into a JAR and run it in any environment with a Java Virtual Machine installed at will.

Subsequent virtualization and containerization further broadened the run-anywhere path, but Java was indeed the first major programming language to support this type of run-anywhere workflow.

The Strongest in Running Anywhere: Zig

The Java approach is certainly not perfect, first of all, the JIT code is slow to start, and the other is the inability to easily call code not written in Java. GraalVM claims to be able to solve these problems, but the current mainstream trend is still ahead of time cross-compilation. Both Rust and Go can easily run anywhere, as long as they don’t include C or libc dependencies.

But currently the strongest player in running everywhere seems to be Zig, which can not only easily cross-compile Zig programs, but also be compatible with any code built with Clang or GCC.

Toolkit manager

As long as there is a language, there is a compiler, which provides a large number of tags for flexible invocation, but the use process is also quite cumbersome. So there are tools like Make and AUtotools. The subsequent third-party toolkit ecosystem has increased the complexity by an order of magnitude. To solve the problem, Maven and pip appeared. But correspondingly, we encountered the problem of inconsistent compiler or runtime versions, so different programs need to match different toolkit versions. Python has its own solution, pipenv, ualenv, and conda that I don’t understand at all.

All of this adds to the complexity, making it almost impossible for new users to keep up. Therefore, new languages ​​began to try to centralize all these management, simplifying the development process.

I would say that toolkit management and LSP are the two big things I’ve seen in my programming career that are really game changers.

—Ganesh Sittampalam

Just as the built-in “battery” standard library expands the definition of a language, modern toolkit managers greatly increase the developer’s expectations for the experience. The advantage of this extension is that it is easy to use and the development experience is better. The disadvantage is that the packaging, release and construction of the software will bring corresponding costs. Language authors need to invest a lot of time in tools to address these issues.

The strongest among toolkit managers

I think one of the core strengths of cargo is that it comes with language. Previous active build tools often lack full integration with the entire platform.

—Robert Masen

Toolkit managers are evolving rapidly. So if we are willing to invest the engineering time, we can significantly improve the onboarding and day-to-day experience of our language. As a result, new projects are increasingly investing in this area.

Rust’s cargo and rustup documentation is basically the same size as the rust book, and it’s not enough to cover all cargo plugins. Whether it’s easy to switch language compiler versions, quickly run tests, perform code coverage and performance tests, get vendor code, generate documentation, verify code, or fix verification problems, these stand-alone tools that used to exist in the language ecosystem , are now an out-of-the-box feature in Rust. Go is similar. It is conceivable how much effort will be required for the subsequent new languages ​​to go further.

code formatter

Code formatters have been around long before gofmt, just as there have been third-party toolkits before CPAN, but the final maturity of all this will require a profound change that subverts community standards.

For example, it is impossible for any language that came before Go to achieve almost 100% style consistency like Go. This is because previous languages ​​had to be compatible with legacy code, whereas gofmt enforces a single style and doesn’t offer any adjustment options. Languages ​​after Go are of course standing on the shoulders of giants, so Rust (rustfmt) and Zig (zig fmt) also use a strong default code style and accompanying code formatter, and thus establish a developer experience advantage .

In fact, there is still a lot to talk about, including runtime improvements, which are basically equivalent to direct improvements to the language. IDEs, LSPs, fuzzing support, and refactoring tools, etc., focus on the developer side. However, due to space limitations, we cannot extend indefinitely.

There are also achievements that, in the eyes of the language creators, were bound to change the world, but never ended up being widely adopted, or were only influential in a particular field. Obviously, Jupyter notebooks and REPLs are typical. They are particularly critical in some application areas, but not well known in others. Smalltalk’s image-based approach and the Mathematica/Wolfram Language’s language-integrated data, while distinctive, are also more niche.

Summarize

Tools that help developers get their job done are already an important part of programming language usability. And the tools themselves are constantly changing, and standards are constantly improving.

The whole process is basically this: when new developer innovation tools emerge, younger programming languages ​​have a better chance to integrate the results into their own ecosystems, thereby forming an incremental advantage. Over time, these incremental benefits will drive a qualitative change in the developer experience.

As a result, newer languages ​​can solve problems with clearer and more precise methods, while older languages ​​face a lot of conflicting methods, or even no feasible solutions. Therefore, developers generally believe that the development of traditional programming language tools is slow.

Original link:

https://earthly.dev/blog/programming-language-improvements/

The text and pictures in this article are from InfoQ