Sean Kelly wrote:
retard Wrote:
Thu, 19 Nov 2009 11:47:46 -0800, Bill Baxter wrote:
It seems to me that MS expects C++ to go the way of FORTRAN and
COBAL. Still there, still used, but by an increasingly small number of
people for a small (but important!) subset of things. Note how MS still
hasn't produced a C99 compiler. They just don't see it as relevant to
enough people to be financially worthwhile.
Even the open source community is using more and more dynamic languages
such as Python on the desktop and Web 2.0 (mostly javascript, flash,
silverlight, php, python) is a strongly growing platform. I expect most
of the every day apps to move to the cloud during the next 10 years.
Unfortunately c++ and d missed the train here. People don't care about
performance anymore. Even application development has moved from library
writing to high level descriptions of end user apps that make use of high
quality foss/commercial off-the-shelf components. Cloud computing, real-
time interactive communication, and fancy visual look are the key
features these days.
Performance per watt is a huge issue for server farms, and until all this talk of low
power, short pipeline, massively parallel computing is realized (ie. true "cloud
computing"), systems languages will have a very definite place in this arena. I
know of large-scale Java projects that go to extreme lengths to avoid garbage collection
cycles because they take upwards of 30 seconds to complete, even on top-of-the-line
hardware. Using a language like C remains a huge win in these situations.
This I agree with to a certain degree. This really only applies to
colocated systems. Shared hosting situations, users are often too
stupid to understand the effects of crap code, and shared hosting
providers tend to over commit machines.
Then comes in the virtualization providers, Amazon EC2 being a perfect
example. As long as income is greater then costs, EC2 users rarely get
their code running as well as it could, even tho they'd see the most
direct cost savings from doing so. With today's web languages, the cost
to make something efficient and fast (and maintain, debug, etc) is
higher then the cost to run slow crappy code.
This is amplified by the loss of money in an emerging market where
coming out even a month after your competitors could mean your death.
Languages like D (and even java and erlang to some degree) had the
opportunity to change this trend 10-15 years ago when scalable clusters
were not a common thing. However, with the direction the web has gone
in the past 5-10 years, to more 'web applications' the opportunity might
come again. We just need 'derail' all of those ruby kids, and get some
killer web application framework for D.
Personally, I hate the Interwebs, and I don't care if it collapses under
its own bloated weight. As long as I still have some way of accessing
source code.
Even in this magical world of massively parallel computing there will be a
place for systems languages. After all, that's how interaction with hardware
works, consistent performance for time-critical code is achieved, etc. I think
the real trend to consider is that projects are rarely written in just one
language these days, and ease of integration between pieces is of paramount
importance. C/C++ still pretty much stinks in this respect.
Yes, the days of multi-cpu, multi-core, multi-thread hardware is here.
I recently got a chance to do some work on a 32 hardware thread sun
machine. Very interesting design concepts.
This is where languages like erlang have an advantage, and D is heading
in the right direction (but still quite far off). D at least has the
ability to adapt to these new architectures, where as C/C++ will soon be
dealing with contention hell (they already do in some aspects).
The idea of a single machine with 100+ processing contexts (hardware
threads) is not something in the distant future. I know some of the sun
machines (T5240) already can do 128 hardware threads in a single
machine. Add in certain types of high bandwidth transferring (rdma
infiniband for example), and the concepts of things like Mosix and
erlang and we'll have single processes with multiple threads running on
multiple hardware threads, cores, cpus and even machines.
