6 ms·

I love that we're getting new languages lately, but almost all of them seem to be ignore the significant new requirement of our age: parallelism & concurrency.

by MCRed 11y ago

I love that we're getting new languages lately, but almost all of them seem to be ignore the significant new requirement of our age: parallelism & concurrency. Specifically, you need lightweight processes and no-shared-memroy architecture. While the number of cores on a machine is remaining relatively low, the number of machines in a system are going up. Erlang got this right and build a lot of infrastructure around it (OTP) and while you can't replicate that infrastructure quickly you can get the fundamentals right. Simply getting this wrong rules out a lot of languages from consideration (because why learn a new language that is going to be obsolete, or only chosen by people who don't understand how to build systems?) It's a lot easier to get this in when you're new and can make major changes to the language. Once you start to solidify it would break things- this is why Go's fake concurrency is a tragedy and a huge missed opportunity.

rifung 11y ago
I largely agree with what you are saying, but doesn't it only apply to languages that will be used in back end systems? If you are just making a phone app or something, it doesn't seem like parallelism is nearly as important.
- oconnor0 11y ago
  Phones are getting more and more cores. It won't be long before languages for mobile need to solve the same issues - parallelism and concurrency.
deleted 11y ago
[deleted]
asterite 11y ago
You are right, it wouldn't be wise to create a new language without having concurrency in mind. Starting from the last version there's spawn (lightweight processes) and channels for communications, similar to Go (although it's in a very experimental stage right now). We aren't sure immutability everywhere is the solution for everything, some algorithms and programs are much more efficient with mutable data. I think Go is quite popular and have an amazing concurrency support. It's true, you have to make sure to communicate using channels and not via shared memory, but if you follow that rule than you won't have problems, and you can get pretty efficient programs.
dmgbrn 11y ago
I have to disagree with you on this. A language should be expressive enough that it can easily support correct concurrent programming, and readily expose runtimes (OTP is a great example) that have support for concurrency and distributed programming. However, patterns like message passing instead of shared memory are not a panacea. Deadlocks and non-deterministic behavior can still happen in such systems if programmers do something stupid. Enforcing these patterns at the language level smells of the old "let's make a language that doesn't allow programmers to write bugs!" trap.
westoque 11y ago
>> I love that we're getting new languages lately, but almost all of them seem to be ignore the significant new requirement of our age: parallelism & concurrency. Yes. I expect this to be the norm in future languages. App developers shouldn't have to worry about these kind's of things, and we can just focus on making apps. Parallelism and concurrency should just work out of the box.
anonyfox 11y ago
http://elixir-lang.org http://elixir-lang.org - ruby-like syntax on the erlang VM, -> massivly scalable, really fast and fault tolerant.
seanmcdirmid 11y ago
> Specifically, you need lightweight processes and no-shared-memory architecture. No you don't. I mean, that's one way to do it, but its not the only way and is often not an option if you want real performance. CUDA (a language specifically designed for SIMT parallelism) supports shared memory for good reasons; the threads are also not lightweight in that way (though they rely on memory and branch coherence).
- kayamon 11y ago
  It can be argued that shared memory should be explicit-when-needed rather than everywhere-by-default though.
  - seanmcdirmid 11y ago
    It can also be argued the other way, of course. Do you like eating vegetables or ice cream? It's like garbage collection, some people love it because it frees them from worrying about allocating and freeing memory. Others hate it for the same reason.

by MCRed 11y ago

rifung 11y ago

I largely agree with what you are saying, but doesn't it only apply to languages that will be used in back end systems? If you are just making a phone app or something, it doesn't seem like parallelism is nearly as important.

oconnor0 11y ago
Phones are getting more and more cores. It won't be long before languages for mobile need to solve the same issues - parallelism and concurrency.

deleted 11y ago

[deleted]

asterite 11y ago

You are right, it wouldn't be wise to create a new language without having concurrency in mind. Starting from the last version there's spawn (lightweight processes) and channels for communications, similar to Go (although it's in a very experimental stage right now). We aren't sure immutability everywhere is the solution for everything, some algorithms and programs are much more efficient with mutable data. I think Go is quite popular and have an amazing concurrency support. It's true, you have to make sure to communicate using channels and not via shared memory, but if you follow that rule than you won't have problems, and you can get pretty efficient programs.

dmgbrn 11y ago

I have to disagree with you on this. A language should be expressive enough that it can easily support correct concurrent programming, and readily expose runtimes (OTP is a great example) that have support for concurrency and distributed programming. However, patterns like message passing instead of shared memory are not a panacea. Deadlocks and non-deterministic behavior can still happen in such systems if programmers do something stupid. Enforcing these patterns at the language level smells of the old "let's make a language that doesn't allow programmers to write bugs!" trap.

westoque 11y ago

>> I love that we're getting new languages lately, but almost all of them seem to be ignore the significant new requirement of our age: parallelism & concurrency. Yes. I expect this to be the norm in future languages. App developers shouldn't have to worry about these kind's of things, and we can just focus on making apps. Parallelism and concurrency should just work out of the box.

anonyfox 11y ago

http://elixir-lang.org http://elixir-lang.org - ruby-like syntax on the erlang VM, -> massivly scalable, really fast and fault tolerant.

seanmcdirmid 11y ago

> Specifically, you need lightweight processes and no-shared-memory architecture. No you don't. I mean, that's one way to do it, but its not the only way and is often not an option if you want real performance. CUDA (a language specifically designed for SIMT parallelism) supports shared memory for good reasons; the threads are also not lightweight in that way (though they rely on memory and branch coherence).

kayamon 11y ago
It can be argued that shared memory should be explicit-when-needed rather than everywhere-by-default though.
- seanmcdirmid 11y ago
  It can also be argued the other way, of course. Do you like eating vegetables or ice cream? It's like garbage collection, some people love it because it frees them from worrying about allocating and freeing memory. Others hate it for the same reason.