2004: Languages Became a Toolbox
· 58 min read · Views --

2004: Languages Became a Toolbox

Author: Alex Xiang

Essays

The previous essays covered 2001 to 2003, when domestic Linux companies in China were at their liveliest. People talked about Linux, the desktop, free software, and homegrown operating systems. Many conversations still carried a touch of idealism. By 2004, the atmosphere began to change.

It was not that ideals disappeared. The systems became heavier.

The browser was no longer merely a tool for opening web pages. Web applications started to show the ambition of desktop software. Search engines were no longer just entrances; they were becoming centers of advertising, data, and infrastructure. Open source was no longer only about whether it could replace Windows. It had entered servers, development tools, language ecosystems, desktop distributions, and the small details of community collaboration.

I was still working at the Linux company that year. My daily work did not have a clean single thread. Sometimes Perl handled logs and text. Sometimes PHP built internal systems. Sometimes Java handled heavier business modules. Sometimes Shell, Makefiles, configuration files, and scripts glued the system together. Python was also entering my toolbox, but it was still far from the everywhere-present Python it would later become.

Looking back, one impression from 2004 remains strong: programming languages were no longer mainly about “which language I like.” They became about “which tool gets this job done fastest, most reliably, and easiest to hand over.”

Programmers Carried a Toolbox

Today, when people say “full stack”, they often mean frontend, backend, database, cloud services, CI/CD, observability, and a pile of frameworks. In 2004, the phrase was not standardized like that, but the engineering site already had a similar flavor, only rougher.

Inside a Linux company, development tasks rarely stayed inside one language.

For handling large amounts of configuration, logs, and text files, Perl was handy. Its syntax now looks a bit like encrypted text, but at the time, being able to process piles of text cleanly in a few lines was an extremely practical skill. Many system administrators, backend developers, and operations people kept Perl nearby.

For internal websites, forums, and admin pages, PHP was natural. Low installation friction, direct deployment, and the Apache plus MySQL combination made it the default choice for many small and medium web systems. I had previously built an internal forum with Perl. Later, seeing more web tools move toward PHP, I felt that the shift did not happen because PHP was elegant, but because it was close enough to the need.

For heavier services, interfaces, and enterprise systems, Java’s position became more obvious. The J2EE stack looks heavy today, but at that time it represented the “regular army”: layering, components, containers, specifications, maintainability, and team collaboration. Once a project entered an enterprise customer site, Java’s presence usually grew stronger.

Shell, Makefiles, configuration templates, and startup scripts were like air. Few people highlighted them on resumes, but without them, the system would not run. Often, what turned a Linux product from source code into a deliverable system was not a beautiful piece of business logic, but a pile of plain, fragile, and critical scripts.

Python was not yet my main language. It felt more like a clean new tool. It was easier to read than Perl, better than Shell for complex logic, and lighter than Java. Nobody would have said “Python is the foundation language of the AI era” back then, but its temperament was already clear: clean syntax, comfortable scripting, and little friction for engineering chores.

But describing that period only with Perl, PHP, Java, and Python would make it too light. I also wrote C in those years. Not classroom C, and not exercise-book C, but C patches for real systems.

I patched things related to Samba and AppleTalk. Samba solved interoperability between Linux/Unix and Windows file sharing. AppleTalk was an old protocol stack from Apple’s early networking era and later became more and more marginal. In recent years, AppleTalk-related code was removed from the Linux kernel, closing a chapter for that class of old network protocols. Looking back, this work was not as visible as a web product, but it says a lot about the real world that Linux companies faced: customer environments were complicated, heterogeneous systems were everywhere, and file sharing, network protocols, old device compatibility, and deployment constraints were part of whether a product could actually land.

Old protocol compatibility and C patches around 2004

The programming language toolbox of 2004

Later, I became less interested in language wars, probably because of this period. In real projects, languages are not flags. They are wrenches, screwdrivers, soldering irons, and multimeters. You can certainly prefer one of them, but when the system is broken somewhere, the first job is to fix it.

After Gmail, the Browser Was No Longer Just a Browser

On April 1, 2004, Google launched Gmail. Because the date looked so much like a joke, many people first assumed it was an April Fools’ product. It was not.

What made Gmail striking was not only the 1GB mailbox. More importantly, it made many people realize for the first time that an application inside a browser did not have to behave like the old “click, reload a page, click again, reload again” web. Mail search, conversation organization, quick operations, and asynchronous interaction pushed web-application experience forward by a large step.

There were no mature frontend frameworks like today’s, and “SPA” had not become an everyday term. But Gmail already showed that browsers could carry more complex interactions. A few years later, AJAX became popular, Web 2.0 became a label, and many of those shadows could already be seen in 2004.

For programmers, this meant the web was no longer only page assembly. Backend, frontend, data, cache, asynchronous interaction, and user experience would become increasingly tangled. The language toolbox became more complex as a result: PHP could quickly produce pages, Java could support large systems, scripting languages could clean data and run jobs, and browser-side JavaScript would slowly move from a small toy into an unavoidable protagonist.

In 1997, I wrote a JavaScript butterfly that flew around a page. Back then, JavaScript was more like a little magic trick inside the browser, and one had to be careful about inconsistent browser standards. By 2004, although JavaScript was not yet as dominant as it later became, the direction had changed. It was no longer only adding dynamic effects to pages. It was moving toward becoming part of application logic.

Firefox and Ubuntu Made Open Source More Everyday

In November 2004, Firefox 1.0 was released. Internet Explorer had a very strong market position in those years, but precisely because it was too dominant, browser innovation slowed down. Firefox’s meaning was not simply that users had another browser choice. It made ordinary users feel that open source software was not only something on servers; it could also be a product they opened and used every day.

In October of the same year, Ubuntu 4.10 was released. Ubuntu later became highly influential for a simple reason: it made Linux desktop installation, daily use, and community support friendlier. In earlier years, installing Linux often turned into a chain of hardware detection, graphics drivers, Chinese input, network configuration, and software repository problems. Ubuntu did not solve everything at once, but it pushed “make Linux usable by ordinary people” forward significantly.

This also stimulated Linux companies at the time. Domestic distributions had opportunities and difficulties. The opportunities came from policy, education, government, and industry customers needing localization and domestic alternatives. The difficulties came from community ecosystems, application ecosystems, driver support, desktop experience, and developer mindshare. These could not be filled by passion alone.

The company I worked for had many excellent engineers from Tsinghua, Peking University, and other top schools. People were very capable. But building an operating system is not something a group of smart people can solve alone. It requires hardware vendors, application developers, communities, business customers, channels, documentation, and training to move together. A distribution is not a collection of code packages. It is the negotiated result of an entire ecosystem.

Firefox and Ubuntu in 2004 both made that clear. When open source truly enters public view, it does not rely only on the words “source code is open.” It needs product experience, community collaboration, and engineering quality at the same time.

Google IPO, MapReduce, and the Prelude to the Data Era

In August 2004, Google went public. Looking at Google’s size today, it is easy to forget that it still had the sharpness of a technology company then. Search quality, advertising systems, infrastructure, and engineering culture together made the story of “changing business through technology” very concrete.

That same year, Google published the MapReduce paper. For many people working on data systems, this paper later became a landmark. It split large-scale data processing into Map and Reduce phases and described, in an engineering-friendly way, how to process huge amounts of data on a cluster.

I had not yet entered the later work of big-data platforms, but looking back, many threads were already laid down in 2004. Search engines needed to process web pages. Advertising systems needed to process clicks and conversions. Social networks would generate relationships and feeds. Mail, maps, video, and games would all accumulate data. Data was no longer just a few tables in a database. It was becoming the fuel of internet products.

This would also change language ecosystems.

Scripting languages handled glue code. Java was suitable for stable services. C/C++ still occupied performance-sensitive areas. SQL managed structured data. Shell sat on system boundaries. Later, Hadoop, Hive, Spark, Flink, Python’s data ecosystem, and machine learning frameworks appeared one after another. They were all related to this line: as data scale grows, languages and tools reorganize around data.

Much of what I did in the company in 2004 was not that grand. But those small scripts, deployment tools, log processing tasks, and internal systems were already training an engineering instinct: a system is not written in one language. It is assembled from many boundaries.

Facebook, Rails, and World of Warcraft

In February 2004, Facebook started on campus. It was of course not yet the global social platform it later became, but the direction of real identity, relationship networks, and feeds had appeared. A few years later, social networks would become one of the core forms of internet traffic and applications.

That same year, Ruby on Rails began to appear. Rails’ impact on web development was not only Ruby as a language, but also an engineering aesthetic: convention over configuration and rapid product construction. It told many developers that web applications did not have to be crushed under heavy enterprise frameworks; they could move forward in a clearer and faster way.

In November, World of Warcraft was released. It is usually discussed in game history, but from an engineering perspective, it was also a sample of a long-running online system: accounts, servers, maps, quests, economy, community, operations, version updates, customer support, and data monitoring. Together, these already resembled the complexity of many later internet services.

Putting these events together, 2004 was not just a year when several new products appeared. It was a hint that software was moving from “release a version” to “operate a system.” After a system went online, the work did not end. In many ways, it had just begun.

This also explains why languages became a toolbox. A long-running online system needs pages, services, scripts, monitoring, data processing, admin tools, deployment, and rollback. One language can do many things, but in reality, teams make choices based on cost, history, talent structure, and ecosystem tools.

Behind Language Wars Was Rising Engineering Complexity

When one is young, it is easy to enjoy language wars. Is C or C++ purer? Is Java too verbose? Is PHP not elegant enough? Is Perl too hard to read? Is Python too slow? Every question can be argued for a long time.

But the engineering site around 2004 gradually taught a different lesson: language wars are often only the surface. The real question is what kind of complexity you are facing.

For text-processing complexity, Perl is suitable. For the delivery complexity of small web systems, PHP works well. For enterprise services and large-team collaboration, Java has advantages. For system automation and deployment complexity, Shell, Makefiles, and configuration management are unavoidable. When business logic and automation tasks need to be expressed quickly, Python becomes increasingly comfortable.

None of these choices is absolutely correct. They depend on context.

If a person only learns one language, they may easily see every problem as a problem that language should solve. If a team chooses technology only from the language angle, it may ignore the real engineering constraints: people, release cadence, failure recovery, customer environments, existing systems, observability, and long-term maintenance cost.

For me, 2004 was a year when this understanding gradually took shape. I started to believe less in statements like “this language represents the future”, and cared more about questions such as “where are the boundaries of this system?”, “which part needs stability and which part needs speed?”, and “which code will still be understandable three months later?”

That sounds less exciting than language faith, but it is closer to real work.

Cola Under the Guomao Tower and Early E-Commerce

There is also a very everyday memory that belongs in this 2004 essay.

The company was in Tower A of China World Trade Center in Beijing. Public information traces JD’s early company back to 1998, while JD.com as an online retail company became clearer in public narratives from 2004 onward. It was of course not the giant it is today. It felt more like a small signal of Zhongguancun electronics retail moving to the internet. In my memory, JD once gave away a pack of cola during early promotions. I cannot strictly verify this detail from public sources, so I can only write it as personal memory.

But the memory is strongly tied to that era.

At that time, e-commerce had not yet become daily infrastructure. Buying things online still had a little experimental flavor. Payment, delivery, trust, and after-sales service were all still being built. Downstairs from offices, in forums, through email, and around office conversations, new websites used very plain methods to pull in their first users. A free pack of cola looks trivial today. Back then, it made people feel that the internet was moving from “reading content” toward “buying things, having them delivered, and forming a fulfillment network.”

Early e-commerce memory inside an office at China World Trade Center Tower A

That line later became enormous: e-commerce, payment, logistics, warehousing, recommendation, advertising, cloud computing, and supply-chain systems all grew from it. In 2004, I could not see that far. I only remember the company in Tower A, early e-commerce, and the fresh feeling that “things can actually be sold online like this.”

The Next Stop Was a Closer Look at Silicon Valley

2004 was still a setup.

Later, I had the chance to spend some time at a company in Mountain View. The boss was friends with Linus in the U.S. I did not meet Linus, but I did receive a baby bottle sterilizer that was said to have been used by Linus’s child. The story sounds a little absurd today, but it fits the open-source community of that era: technology, community, companies, and personal relationships were often woven together.

That experience belongs more naturally in the next essay. In 2005, the flavor of Web 2.0 grew stronger, and open-source commercialization entered a new stage. For me, that year was not only more coding. It was also a closer look at what the technological center looked like.

2004 IT Timeline

  • Facebook started. In February 2004, Facebook started on campus. It later pushed real identity, relationship graphs, feeds, and social advertising into the center of the internet, becoming one of the most important platform prototypes before the mobile internet era.
  • Gmail launched. On April 1, 2004, Gmail launched. With large mailbox capacity, search-based mail management, and stronger browser interaction, it reminded developers that web applications did not have to be simplified versions of traditional desktop software.
  • Google IPO. In August 2004, Google went public. Search, advertising, data centers, and engineering culture formed a new business sample, showing the commercial value of infrastructure capability with unusual clarity.
  • MapReduce paper published. Google published the MapReduce paper in 2004. It clarified an engineering pattern for large-scale data processing and became an intellectual source for Hadoop, Hive, Spark, and a full data-platform ecosystem.
  • Ruby on Rails appeared. Rails emphasized convention over configuration and fast web development, reducing the complexity of building web applications. It represented a trend where frameworks began to organize repetitive engineering details for developers.
  • Ubuntu 4.10 released. Ubuntu entered the Linux world with friendlier installation, desktop experience, and community support. It made the Linux desktop less of an expert-only toy and influenced many developers’ later choice of Linux workstations.
  • Firefox 1.0 released. Firefox 1.0 brought an open-source browser back into mainstream view and reactivated browser competition. Web standards, plugin ecosystems, and browser performance would become more important in the following years.
  • World of Warcraft released. This long-running online service put accounts, servers, social systems, in-game economy, version updates, and operational pressure into one product. Large online games reminded the software industry that continuous operation itself is complex engineering.
  • Web development became more framework-driven. Around 2004, CGI, scripts, templates, Java enterprise applications, and emerging web frameworks coexisted. Software development moved from “make it run” toward clearer engineering layers and framework reuse.
  • Enterprise systems evolved in mixed layers. Old protocols, scripting languages, file sharing, and web applications coexisted. Enterprise software does not switch generations neatly with technology trends. Long-term coexistence of old and new technology is a reality every later engineering migration must face.

References

More in this column

View all posts in "Thirty Years in IT and Me"