The future of C++

[David Eng]

For many years now enterprise business application development has
been the core area for the use of C++.
Today a significant share to this segment has already been lost to
SUN's Java technology and with MS now abandoning C++ in favour if its
proprietery .NET and C# technology, how long can we except C++ to hold
on against these might competitors?
Has C++ become a dying language?
What is the future of C++?

As I posted in CORBA group, I believe the future of C++ depends on
CORBA (the same is true that the future of CORBA depends on the future
of C++). Applications are built today are distributed applications
instead of stand alone applications. For C++ to success in this
environment, it has to have a middleware platform. C++ has a
disadvantage comparing to Java and C# which both have a middleware
platform. However, CORBA can become the middleware platform for C++.
CORBA's strength is built on programming language independence. There
is need for Java or C# to talk to C++. If C++ doesn't have a future,
why applications need to talk to C++? If no applications talk to C++,
then why people need to use CORBA since Java has EJB middleware and C#
has .NET? The answer is clear, the C++ standard committee and OMG
must work together to create a better mapping and association between
C++ and CORBA. They must understand that the future of C++ and CORBA
is dependent on each other. If they realize this relationship, I
believe the future of C++ and CORBA is bright. The reason is simple:
together, C++ and CORBA can build mission critical applications which
Java and C# cannot even think about.

 

[Edward Diener]

its > proprietery .NET and C# technology, how long can we except C++
to hold > on against these might competitors?

As I posted in CORBA group, I believe the future of C++ depends on
CORBA (the same is true that the future of CORBA depends on the future
of C++).

Hardly.

C++ thrives very well, thank you, for a wide variety of platforms,
compilers, and standard libraries despite Sun's, Microsoft's, and Borland's
attempts to treat it as a second-rate language in order to promote their own
favored computer programming languages. It can adapt itself to CORBA, DCOM,
and most whatever other middleware comes down the road. Getting caught up in
the politics of software development hype is, thankfully, not what C++ is
all about.

 

[Bryan Bullard]

As I posted in CORBA group, I believe the future of C++ depends on
CORBA (the same is true that the future of CORBA depends on the future
of C++). Applications are built today are distributed applications
instead of stand alone applications. For C++ to success in this
environment, it has to have a middleware platform. C++ has a
disadvantage comparing to Java and C# which both have a middleware
platform. However, CORBA can become the middleware platform for C++.
CORBA's strength is built on programming language independence. There
is need for Java or C# to talk to C++. If C++ doesn't have a future,
why applications need to talk to C++? If no applications talk to C++,
then why people need to use CORBA since Java has EJB middleware and C#
has .NET? The answer is clear, the C++ standard committee and OMG
must work together to create a better mapping and association between
C++ and CORBA. They must understand that the future of C++ and CORBA
is dependent on each other. If they realize this relationship, I
believe the future of C++ and CORBA is bright. The reason is simple:
together, C++ and CORBA can build mission critical applications which
Java and C# cannot even think about.

One of the primary strengths of C++ is that it is general purpose and
doesn't try to conform to all the latest bells and whistles (like Java
does). In 10 or 15 years when all the technologies that are built into Java
have become obsolete what good will Java be?

...

 

[Le Chaud Lapin]

As I posted in CORBA group, I believe the future of C++ depends on
CORBA (the same is true that the future of CORBA depends on the future
of C++). [snip]
CORBA's strength is built on programming language independence. [snip]

Yuck. Please don't take this perosonally, but I find distrbuted
polylingual polymorphic objects disgusting. After years of duking it
out with Microsoft COM abominations, I am convinced that some
boundaries are not meant to be blurred, and making an
all-encompassing, super model for "distributed objects" is gross if it
comes with box of duct tape and chicken wire.

Every language has a distinct type space, and no matter what trickery
is employed, if programs written in two different languages must
communicate with each other, at some point, the boundary between the
type spaces must be dealt with. Any attempt to smooth over the
interface without regard for the fact that the type spaces *are*
distinct results in cumbersome tools like data marshallers and weird
compilers that require perturbation of the host languages.

If multilingual interaction is required, it would be much better to
find a way to get data from node A to node B, entirely within the
framework of one prescribed language [why not C++?], then provide
specific mechanisms to translate from the prescribed language to a
target language as necessary, and if possible. After all, the
boundary will have to be crossed by someone at some point anyway, so
why make everyone suffer when it is the polyglot who is asking for it?

You might say, "Well, there is an enormous benefit of having
language-independent objects accessible from any node by any
language." I would agree if it were actually possible to have such a
thing.

No unified typespace can scale to the mode of aggregation that complex
(not complicated) systems demand without the need to think carefully
about what happens when aggregate objects need to cross from the
unified type space to a specific type space. I doubt that it is
possible to go from

Associative_Polyarchy<String_, Associative_List<unsigned int,
Polyarchy<String_> > >

on a node running C++ to the same thing on a node running C# while
keeping the data structure in one piece. The problem is that I use my
source language to construct things, and if the elements of
construction do not exist in the target language, then I must somehow
manually syntesize the construct anyway. If it is stipulated that I
must choose from a particular set of primitives, and use them in a
certain way in my source language, then guess what? I am no longer
speaking my native language. This fact can be seen by reading between
the lines on Microsoft's MSDN site. They openly profess .NET's
language independence while surreptitiously attempting to displace C++
in favor of C#, which, among other things will allow to them to
provide platforms and tools on Unix & Company undermining their market
dominance.

-Chaud Lapin-

By the way, French is language-independent. All you have to do is
learn how to get from French to English, French to German, French to
Swahili...

 

[Asfand Yar Qazi]

<snip>

I consider C++ to be an object-oriented cross-platform assembler, so it
is the only way to go for writing high-performance multi-platform game
(and other real-time) code.

 

[Steven T. Hatton]

One of the primary strengths of C++ is that it is general purpose and
doesn't try to conform to all the latest bells and whistles (like Java
does). In 10 or 15 years when all the technologies that are built into
Java have become obsolete what good will Java be?

Which technologies are those? There is the core Java language as specified
in _The Java Language Specification_, by, James Gosling, Bill Joy, Guy
Steele, Gilad Bracha, and then there is a huge collection of fairly well
integrated supporting libraries. Note: that's the same Guy Steele who
coauthored the highly regarded _C: A Reference Manual, Fifth Edition_.

CORBA should not be part of the C++ language anymore than Enterprise
JavaBeans, or RMI are part of the Java Language Specification.
Nonetheless, CORBA represents the direct C++ counterpart of come of Java's
most successful technologies.

 

[Thomas Richter]

Hi,

As I posted in CORBA group, I believe the future of C++ depends on
CORBA (the same is true that the future of CORBA depends on the future
of C++). Applications are built today are distributed applications
instead of stand alone applications. For C++ to success in this
environment, it has to have a middleware platform. C++ has a
disadvantage comparing to Java and C# which both have a middleware
platform. However, CORBA can become the middleware platform for C++.

Oh well. For that to happen, the OMG should possibly do its homework
first. I'm using CORBA with its C++ bindings here, and I'd to read the
"standard literature" for that task, the Henning/Vinoski book, and the
C++ CORBA bindings are *still* giving me headaches. Does it really
have to be *that* complicated? I wouldn't have problems with two
mappings, or a layered design with a simple, general purpose
top-layer, and a specialized layer that provides all the fancy
extensions I rarely need. Currently, CORBA and its C++ mapping is both
too special and too general at once.

I also feel that CORBA does its job possibly only half the way it could.
For example, it nicely runs new threads for me serving my objects, but
at the same time it doesn't provide necessary services for keeping
object states consistent amongst the threads - there are no "mutex"
specifications in CORBA.

On the plus side, CORBA provides lots of language bindings, so I can
really interact with Java, Python, Perl,..., but the integration into
the C++ language really deserves a cleanup.

The answer is clear, the C++ standard committee and OMG
must work together to create a better mapping and association between
C++ and CORBA.

Bingo.

So long,
Thomas

 

[David Eng]

I also feel that CORBA does its job possibly only half the way it could.
For example, it nicely runs new threads for me serving my objects, but
at the same time it doesn't provide necessary services for keeping
object states consistent amongst the threads - there are no "mutex"
specifications in CORBA.

I blame this for C++. The thread mode should be built into C++
instead of CORBA. I still cannot understand why C++ doesn't have a
standard thread library. We are moving to grid computing, yet C++
committee doesn't think it is important to standardize a thread
library. The another area bothers me is database access layer. All
these database vendors promote JDBC because there is no a standard C++
access library. If these vendors stop to support their proprietary
C++ API, who will use C++ in a distributed environment? I never head
C++ committee even has an initiative to standardize a database access
layer library. No matter how great C++ is, without a standard thread
and data access libraries, C++ will have a hard time to survive in a
distributed computing. Just to imagine how C++ can survive in a
system computing without an I/O library! If the committee thinks
proprietary libraries can do the job, I am sure that C++ will not be a
mainstream programming language; it will downgrade to a third class
language doing some limited applications.

 

[Claudio Puviani]

I blame this for C++. The thread mode should be built into C++
instead of CORBA.

Fortunately, the people on the standards committee are competent enough to not
listen to such absurd advice.

I still cannot understand why C++ doesn't have a standard
thread library.

Because (a) not every platform supports threads and (b) not all platforms that
support do so in the same way, or even in ways that are analogous. C++ is
intended to run on as many platforms as possible, not just on the ones that Mr.
Eng favors.

We are moving to grid computing, yet C++ committee doesn't
think it is important to standardize a thread library.

That's because they're not idiots. And grid computing has nothing to do with
threads, which you'd know if you had a clue as to the meaning of grid
computing.

The another area bothers me is database access layer.

Why, you're just full of little irritants, aren't you?

All these database vendors promote JDBC because there is no
a standard C++ access library.

They advertise JDBC suppport because it's one of their features. Unless you're
blind as a bat, you'll have seen that they also advertise ODBC and other
bindings.

If these vendors stop to support their proprietary C++ API,
who will use C++ in a distributed environment?

Oh, get on prozak! No one but you has ever suggested that database vendors
would ever drop support for C++. They'd have to be complete morons to even have
a passing thought about it.

I never head C++ committee even has an initiative to
standardize a database access layer library.

Again, because they're a competent lot who understand that cluttering a
language definition with libraries that already exist will only make the
standard unmanageable.

No matter how great C++ is, without a standard thread and
data access libraries, C++ will have a hard time to survive in a
distributed computing.

It was doing just fine before you turned paranoid. It will continue to do so
throughout your treatment and into your recovery.

Just to imagine how C++ can survive in a system computing
without an I/O library!

Just imaging how well we'd survive without imbeciles spamming our newsgroup
with their drivel.

If the committee thinks proprietary libraries can do the job,
I am sure that C++ will not be a mainstream programming
language; it will downgrade to a third class language doing
some limited applications.

Hold your breath. Please!

Claudio Puviani

 

[Alf P. Steinbach]

* "Claudio Puviani" write in reply to David Eng:

Fortunately, the people on the standards committee are competent enough to not
listen to such absurd advice.

Because (a) not every platform supports threads and (b) not all platforms that
support do so in the same way, or even in ways that are analogous. C++ is
intended to run on as many platforms as possible, not just on the ones that Mr.
Eng favors.

Why, you're just full of little irritants, aren't you?

They advertise JDBC suppport because it's one of their features. Unless you're
blind as a bat, you'll have seen that they also advertise ODBC and other
bindings.

Oh, get on prozak! No one but you has ever suggested that database vendors
would ever drop support for C++. They'd have to be complete morons to even have
a passing thought about it.

Again, because they're a competent lot who understand that cluttering a
language definition with libraries that already exist will only make the
standard unmanageable.

It was doing just fine before you turned paranoid. It will continue to do so
throughout your treatment and into your recovery.

Just imaging how well we'd survive without imbeciles spamming our newsgroup
with their drivel.

Hold your breath. Please!

I read the above as personal attack only -- please read the FAQ, Claudio.

It seems you do not have a point at all, and know it.

E.g., as you well know, Boost.Threads may just make it into C++0x.

 

[Jorge Rivera]

I read the above as personal attack only -- please read the FAQ, Claudio.

I disagree. He does have some points scattered in the angry response...

It seems you do not have a point at all, and know it.

????? The point is simple enough. C++ does not need more libraries to
survive. Just because Java and MS gigantic .NET framework have a lot of
external libraries does not mean that C++ will not survive.

 

[David Eng]

Fortunately, the people on the standards committee are competent enough to not
listen to such absurd advice.

It is fortunate that the people on the standards committee are
competent enough to understand the importance of thread. I am pretty
sure that the next C++ standard will include thread mode. So who has
absurd idea?

Because (a) not every platform supports threads and (b) not all platforms that
support do so in the same way, or even in ways that are analogous. C++ is
intended to run on as many platforms as possible, not just on the ones that
Mr. Eng favors.

What a fatuous statement! Does every platform support templates or
support in the same way? What a language feature does on a platform
is through the compiler. A language supports a feature so that the
compiler can generate code for underline platform. It is nothing to
do with (a) or (b) Mr. Claudio Puviani stated above. If a platform
doesn't support thread, that means it cannot run thread program. If
it supports thread, the compiler will generate code for the platform
to run the thread. I just want to see thread can built into language
so that compiler can generate more efficient code instead of putting
burden on developers. If C++ has a standard thread library, it also
promote code reuse and portability, instead of each platform
implementing its own libraries. When you switch platform, you only
need recompile instead of rewriting.

That's because they're not idiots. And grid computing has nothing to do with
threads, which you'd know if you had a clue as to the meaning of grid
computing.

The main theme of grid computing is parallel and distributed
computing. Thread is one of the most important features to support
grid computing. That's why thread mode will be in the next C++
standard. I don't know who is idiot and doesn't have a clue?

Why, you're just full of little irritants, aren't you?


They advertise JDBC suppport because it's one of their features. Unless you're
blind as a bat, you'll have seen that they also advertise ODBC and other
bindings.


Oh, get on prozak! No one but you has ever suggested that database vendors
would ever drop support for C++. They'd have to be complete morons to even
have a passing thought about it.


Again, because they're a competent lot who understand that cluttering a
language definition with libraries that already exist will only make the
standard unmanageable.

First, there are no major database vendors support ODBC interface,
they only support ODBC drivers. Most of them provide their own API
instead of ODBC API. Second, ODBC is a C based interface and is
poorly designed by Microsoft (maybe designed by Mr. Claudio Puviani
-. There are proprietary libraries to wrap ODBC into C++ API. The
problem is most companies use several database engines and change
these database engines quite often. If there is no a standard C++
interface, you have to write different code for different database
engines. When a database engine is changed, you have to rewrite your
code. That's why all the major database vendor promote Java instead
of C++. If C++ has a standard database access library, thing will be
different. Database is so important in enterprise environment. A
database access library is analogous to file access library I/O. I am
confident that the C++ standard committee are smart enough to listen
to this suggestion.

It was doing just fine before you turned paranoid. It will continue to do so
throughout your treatment and into your recovery.

Let us see who is paranoid. I can hardly imagine my post will cause
you such anger and hysteric. This is a public forum. People can
voice their opinions. If you don't like it, that fine. What you did
here is personal attack. I don't think a decent person will act like
you. I wish you learn some basic decency before debating a issue.

 

[David Abrahams]

We are moving to grid computing, yet C++
committee doesn't think it is important to standardize a thread
library.

Please. Did you submit a proposal for a standard threads library?
Did anyone? [hint: the answer is no]

The "C++ committee thinks" (as though we are all of one mind, but I'll
play along) that a threading library is important. I don't think we
have any threading experts with the time to bring forward a proposal
on it. If you think you're qualified, please do it yourself.

 

[Jim Melton]

Hi,


Oh well. For that to happen, the OMG should possibly do its homework
first. I'm using CORBA with its C++ bindings here, and I'd to read the
"standard literature" for that task, the Henning/Vinoski book, and the
C++ CORBA bindings are *still* giving me headaches. Does it really
have to be *that* complicated? I wouldn't have problems with two
mappings, or a layered design with a simple, general purpose
top-layer, and a specialized layer that provides all the fancy
extensions I rarely need. Currently, CORBA and its C++ mapping is both
too special and too general at once.

Writing distributed programs is hard. If you have any doubt, just Google
this group for discussions on multi-threading. Distributed programming is
multi-threading with unknown latency and unreliable communication. It takes
more to write a distributed program than to just slap some middleware
between two programs you wrote. The CORBA spec represents 10 years of
experience with what is required to do distributed programming. The stuff
you don't think you need... you'll need it.

The CORBA C++ binding suffers from much of the same baggage as the C++
language: backward compatibility. At the time the binding was specified,
there was no STL, consequently no std::string (one of the biggest disasters
of the binding). To change the binding now would break *all* existing
programs, so it will not be done lightly.

At the risk of straying even farther off-topic for this group, I'll point
out that Michi Henning has gone on to write a middleware designed to work
much more intuitively with C++, and has taken quite a bit of heat from,
among others, Steve Vinoski.

I also feel that CORBA does its job possibly only half the way it could.
For example, it nicely runs new threads for me serving my objects, but
at the same time it doesn't provide necessary services for keeping
object states consistent amongst the threads - there are no "mutex"
specifications in CORBA.

Again, this is off-topic for this group, and you might want to take these
comments to the CORBA group, but "mutex" has no tractable meaning in
distributed programming. CORBA specifies the interface by which clients may
access distributed services, and it defines language bindings by which
programmers may implement (or access) those services.

On the plus side, CORBA provides lots of language bindings, so I can
really interact with Java, Python, Perl,..., but the integration into
the C++ language really deserves a cleanup.
Absolutely.


Bingo.

I don't get the question. From a CORBA programmer's perspective, a better
C++ binding would be desirable. But from a C++ programmer's perspective, why
should I care? Why do you assume that CORBA will triumph over SOAP or EJB or
the next greatest fad in distributed programming? C++ will be integrated
into every middleware for which a vendor can make a business case. C++ will
continue to be required for mission-critical applications where one can't
afford to have the JVM crash, or can't afford the non-determinism of garbage
collection, or requires access to operating system facilities not available
in a virtual machine, or ...

 

[Herb Sutter]

It is fortunate that the people on the standards committee are
competent enough to understand the importance of thread. I am pretty
sure that the next C++ standard will include thread mode. So who has
absurd idea?

Just a note: It is common but incorrect to confuse "standards committee"
with "design team." I frequently see the C++ committee referred to as
though it were the latter, and it really isn't.

In particular, a design team is responsible for making sure important
areas get covered, is much more cohesively organized, and is led by
someone who makes final decisions. A standards committee is driven by
proposals from its members and as a group considers and refines/rejects
such proposals, it is looser, and it makes decisions only by group
consensus. The process generally works well because of the diversity of
the membership which to helps ensure that someone somewhere is likely to
be interested in each of the important things, and because the membership
includes active participation and direction from Bjarne which also helps
avoid "holes" in the design. But the process still can leave holes in
that, if no one has the interest, time, or expertise to write up a
proposal about feature X, then X won't be in the standard no matter how
important it may seem to be.

Besides that, speaking to threading in particular, there's also the
consideration that it's difficult or impossible to standardize something
that varies too greatly across the industry. Threading may or may not fall
into that category.

Herb

---
Herb Sutter (http://blogs.gotdotnet.com/hsutter) (www.gotw.ca)

Convener, ISO WG21 (C++ standards committee) (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal (www.gotw.ca/cuj)
Visual C++ architect, Microsoft (www.gotw.ca/microsoft)

 

[Thomas Richter]

Hi,

I blame this for C++. The thread mode should be built into C++
instead of CORBA.

But then, CORBA *requires* the corresponding ORB/POA implementation to
provide threads one way or another, why doesn't it require from the
implementing library to provide some mutex mechanism as well? Or
rather, to make the internal locking mechanism any suitable
implementation must have anyhow available to the outside as a service?
Whether this should be part of C++ or not is another question, but it
should be definitely mandatory part of the CORBA specifications to
have. A specific implementation could still make use of a potential
"standard" mutex/threading class as soon as we had one.

I still cannot understand why C++ doesn't have a
standard thread library. We are moving to grid computing, yet C++
committee doesn't think it is important to standardize a thread
library.

This is true to some degree, but is another argument.

So long,
Thomas

 

[Steven T. Hatton]

I blame this for C++. The thread mode should be built into C++
instead of CORBA. I still cannot understand why C++ doesn't have a
standard thread library. We are moving to grid computing, yet C++
committee doesn't think it is important to standardize a thread
library.

Is the problem that the committee doesn't think it's important, or is it
that the committee doesn't have the resources? What about
http://www.boost.org/libs/thread/doc/index.html? That seems to have the
unofficial blessing of the committee. I agree that C++ /seems/ a bit
behind the times when it comes to threading, and many other issues. What
about X509, and all the other crypto stuff. Take a look at the standard
Java SDK, and compare that to what you can get with a 'standard' C++ setup.
I haven't looked at C#'s offerings, but I gather it comes with a similar
arsenal of libraries.

The [other] area bothers me is database access layer. All
these database vendors promote JDBC because there is no a standard C++
access library. If these vendors stop to support their proprietary
C++ API, who will use C++ in a distributed environment? I never head
C++ committee even has an initiative to standardize a database access
layer library.

There are many open source libraries available, and for that matter, you
could probably make a C++ to JDBC bridge. I suspect it's already been done.
Nonetheless, I agree that standards are a good thing. I find myself
spending a lot of time hunting around for solutions to things I get as part
of Java either with the JSDK or as a freely available extension. And let
us not forget XML.

No matter how great C++ is, without a standard thread
and data access libraries, C++ will have a hard time to survive in a
distributed computing. Just to imagine how C++ can survive in a
system computing without an I/O library! If the committee thinks
proprietary libraries can do the job, I am sure that C++ will not be a
mainstream programming language; it will downgrade to a third class
language doing some limited applications.

I believe C++ has a lot of problems when it comes to competing with Java and
C#. People who have never coded in Java (I can't comment on C# directly)
really have no idea of the strengths Java has as far as ease of use.

C++ _*needs*_ some kind of module support. It probably also should have
checked exceptions. I have the sense many C++ programmers don't really
understand the concepts of listeners and events as they are used commonly
in Java. All one really needs to do is to pick up _The Java Programming
Language_, by Arnold, Gosling and Holmes, and read the first 10 or so
chapters to see how much Java offers as core features.

Too often C++ programmers become defensive and dismissive of these strengths
of Java. If someone presents an I idea which even hints that it may have
been influence by java, it is automatically rejected.

I've been putting a lot of time into C++ lately, and I know there are
significant strength in the language that Java lacks. But they may not be
sufficient to keep anything but a niche in the emerging environment. One
view I've seen expressed on usenet is that Sun, Microsoft, IBM, Borland,
etc., are a bunch of idiots for shifting their focus to Java (or C#).
There's not much to say to in response to such assertions. They seem to
speak for themselves.

 

[Hyman Rosen]

Writing distributed programs is hard.

And yet, Ada supports it as a built-in feature of
the language, in compilers which support the
Distributed Systems Annex E.

<http://www.adaic.org/standards/95lrm/html/RM-E.html>

 

[Stanley Friesen]

I blame this for C++. The thread mode should be built into C++
instead of CORBA. I still cannot understand why C++ doesn't have a
standard thread library. We are moving to grid computing, yet C++
committee doesn't think it is important to standardize a thread
library. The another area bothers me is database access layer.

I do not see grid computing being so pervasive as you seem to think.
I WILL NOT run distributed apps on my personal computer at home, not
even with a broadband connection. And at work it is unlikely that
many of the main applications I run will be grid apps any time soon.

All
these database vendors promote JDBC because there is no a standard C++
access library. If these vendors stop to support their proprietary
C++ API, who will use C++ in a distributed environment? I never head
C++ committee even has an initiative to standardize a database access
layer library. No matter how great C++ is, without a standard thread
and data access libraries, C++ will have a hard time to survive in a
distributed computing. Just to imagine how C++ can survive in a
system computing without an I/O library! If the committee thinks
proprietary libraries can do the job, I am sure that C++ will not be a
mainstream programming language; it will downgrade to a third class
language doing some limited applications.

C++ is, and will remain, a good language for performance-critical
systems, where the performance cost of grid computing is too high.

 

[kanze]

(e-mail address removed) (David Eng) writes:

Please. Did you submit a proposal for a standard threads library?
Did anyone? [hint: the answer is no]

I was under the impression that the Boost threading library was being
discussed. Internally, of course, and only for inclusion in the next
version of the standard.

The "C++ committee thinks" (as though we are all of one mind, but I'll
play along) that a threading library is important. I don't think we
have any threading experts with the time to bring forward a proposal
on it. If you think you're qualified, please do it yourself.

It's also important to put things in a historical perspective. The C++
standard was published in 1998. That means that most of the features
being including were stabilized at least a year before, and were
proposed many years before that. I think that the cut-off date for a
completely new feature would have been something like 1995, possibly
even earlier. While I don't think that anyone today doubts the
importance of threads, I'm not sure that you could have said the same
thing in 1995. (And BTW, some of the large servers I work on still
don't use threads. All things considered, threads mean extra work, and
unless they otherwise save you more work than they cost, you're better
off without them.)