Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The future of programming languages in a massively concurrent world

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 33 posts

Re: The future of programming languages in a massively concurrent world

#21

Post by michaelneale »

davidw wrote: post #19
michaelneale wrote: post #18

Earlier quoted context omitted.

I don't think erlang is that great for the scenarios that started this thread - it is designed for 1000's of processes, not dozens. And by all reports its straight line performance is much much much slower then anything else out there. There is of course functional approaches like haskell (but it will take longer to be mainstream).

Erlang is functional, but in any case, you're right about its performance - it's more or less that of a fast interpreted language, rather than a compiled language.

I never thought of it as functional - looked more like little islands of imperative programming to me (I guess I will have to check again).

I think fast interpreted is probably even overstating it, it makes all sorts of compromises. Erlang was also designed for very high availability - so that must cost something as well.

I guess we will see what happens, but I am very skeptical about erlang (not sure why, just a gut feel).

Re: The future of programming languages in a massively concurrent world

#22

Post by staunch »

The server side is already prepared for this. There's nothing much to do. All the big web languages run as multiple processes (or threads) and so do all the big databases. I think we'll see a lot more server consolidation, which we're already seeing with the 4-core and 8-core machines of today.

Re: The future of programming languages in a massively concurrent world

#23

Post by ctkrohn »

axod wrote: post #15

I really hope that if multiple cores increase, they are done in a way which hides them from the programmer. For example a 32 core CPU, but that appears as a very very fast single core. That's where the concurrency/'threading' issues should live, not in everyones code. Threads are usually the problem IMHO not the solution. I don't agree with the suggestion that javascript will need threads either. Javascript works ext…

You're talking about automatic parallelization. There's been quite a bit of research done in this area, but the results aren't that great. Some languages (particularly functional ones) are better suited to automatic parallelization than others, and it's pretty doubtful that you'll see a good automatically parallelizing compiler anytime soon, especially for an imperative interpreted language like Javascript.

See http://en.wikipedia.org/wiki/Automatic_parallelization for more info.

Re: The future of programming languages in a massively concurrent world

#24

Post by nostrademons »

emfle wrote: post #20
nostrademons wrote: post #8

Earlier quoted context omitted.

Concurrency in web languages is a non-issue, because each request is independent (or should be, if you have a proper shared-nothing architecture). You simply run multiple processes and give each process a full core. Most FastCGI/SCGI webserver modules have functionality built-in to multiplex among backend processes. Concurrency in the database is more interesting, particularly since that's where the bottleneck is in…

Well, there is actually a latency gain to be had from parallellizing indidvidual requests, rather than just running several requests in parallel. Think about this example: You have 10 printers each capable of printing 10 pages per minute. Then 10 jobs are submitted each with 10 pages. If you run those jobs in parallel, all of them will finish after 60 seconds. If you parallelize each job and print page 1 on printer 1…

Usually CPU latency for a web request is very tiny compared to network/DB/IO latency, though.

Re: The future of programming languages in a massively concurrent world

#25

Post by tlrobinson »

A common misconception is that Moore's "law" states that processor speed will double every 18 months or so. That's incorrect. In fact, Moore said that the NUMBER of transistors on a processor would double roughly every 18 months.

It turns out that they are correlated, since smaller transistors means both faster transistors and more transistors per unit of area.

My point is that more processor cores require more transistors, and thus the end of Moore's Law also means the end of more processor cores (ignoring things like architectural advancements or more but less powerful cores)

That said, I do agree that we will see an increasing number of cores, at least for awhile.

First of all, it's important to have an OS that efficiently manages the cores and the applications that run on them. This automatically benefits everyone who runs multiple applications on a multi-core machine, since each application gets a larger slice of time and fewer context switches.

Multiple cores could also eliminate dedicated components like GPUs which would bring down the cost of low end machines.

As far as programming languages go, I hear Erlang is good for concurrency, though I've never used it.

Re: The future of programming languages in a massively concurrent world

#26

Post by davidw »

michaelneale wrote: post #21
davidw wrote: post #19

Earlier quoted context omitted.

Erlang is functional, but in any case, you're right about its performance - it's more or less that of a fast interpreted language, rather than a compiled language.

I never thought of it as functional - looked more like little islands of imperative programming to me (I guess I will have to check again). I think fast interpreted is probably even overstating it, it makes all sorts of compromises. Erlang was also designed for very high availability - so that must cost something as well. I guess we will see what happens, but I am very skeptical about erlang (not sure why, just a gut…

Erlang is most definitely functional, although it's not as pure as something like Haskell.

In terms of speed, this is something to look at:

http://shootout.alioth.debian.org/debian/benchmark.php?test=...

It's pretty fast for most things if you use HiPE.

Your skepticism about Erlang is justified in terms of "next big language":

http://journal.dedasys.com/articles/2007/10/09/languages-wor...

However, if you use it for what it was created for, it is very nice - it's the best thing out there.

Re: The future of programming languages in a massively concurrent world

#27

Post by yubrew »

Hexayurt wrote: post #12

Occam. Specifically, http://transterpreter.org Yes, the language it runs (Occam) is 20 years old. But the language was designed for programs running on dozens to thousands of nodes, and in the transterpreter implementation, there's the possibility of doing this on heterogeneous hardware, where the fast nodes do things like splitting and merging the data set, and the smaller "grunt compute" nodes do the actual work. P…

Hi Hexayurt, we're looking at a couple different heathcare IT problems to solve, and creating expert systems for specific medical domains is one of the areas we are currently investigating.

Can I pick your brain a bit? Send me an e-mail, or let me know what your e-mail is.

Re: The future of programming languages in a massively concurrent world

#28

Post by ralph »

I'm surprised the decent solution to this isn't more widely known. People have mentioned Occam and Stackless Python; both interesting. But their ancester is Hoare's CSP and other descendant have included Squeak (not the Smalltalk relation), Newsqueak, Plan 9's Alef, Inferno's Limbo, and now libthread.

Channels with co-operating threads are easy to reason about. See Russ Cox's overview page http://swtch.com/~rsc/thread/ for more.

Re: The future of programming languages in a massively concurrent world

#29

Post by cstejerean »

ralph wrote: post #28

I'm surprised the decent solution to this isn't more widely known. People have mentioned Occam and Stackless Python; both interesting. But their ancester is Hoare's CSP and other descendant have included Squeak (not the Smalltalk relation), Newsqueak, Plan 9's Alef, Inferno's Limbo, and now libthread. Channels with co-operating threads are easy to reason about. See Russ Cox's overview page http://swtch.com/~rsc/threa…

Stackless python does absolutely nothing to help with scaling applications to multiple cores. It allows you to write asynchronous applications to better utilize a single processor for operations that depend heavily on IO (or otherwise waiting for some resource).

Re: The future of programming languages in a massively concurrent world

#30

Post by emfle »

nostrademons wrote: post #24
emfle wrote: post #20

Earlier quoted context omitted.

Well, there is actually a latency gain to be had from parallellizing indidvidual requests, rather than just running several requests in parallel. Think about this example: You have 10 printers each capable of printing 10 pages per minute. Then 10 jobs are submitted each with 10 pages. If you run those jobs in parallel, all of them will finish after 60 seconds. If you parallelize each job and print page 1 on printer 1…

Usually CPU latency for a web request is very tiny compared to network/DB/IO latency, though.

Sure, but I/O can be parallelized too. The argument is not specific to CPU at all.
Post reply on HN