tophercyll, can you give an invite to skynet?
Nice blog post, but you need to give references/links for Spin and Skynet. Otherwise it's just an ad trick...
If you can't make a language fast, make it parallel
11–20 of 33 posts
Re: If you can't make a language fast, make it parallel
#12I'm not convinced that parallelism is something that needs support at the language level. The only languages that do this are Go and Erlang (off the top of my head). Others like Clojure and Scala have more support at the standard library level.
See the paper by Hans Boehm from PLDI 2005, "Threads Cannot Be Implemented as a Library": http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf
A bit further discussion: http://news.ycombinator.com/item?id=939364
Re: If you can't make a language fast, make it parallel
#13tophercyll, can you give an invite to skynet? Nice blog post, but you need to give references/links for Spin and Skynet. Otherwise it's just an ad trick...
Hi nivertech,
I'm sharing one of the lessons we learned building our own programming language. I love how many language designers there are on HN!
We're working on an invite system, so everyone can benefit from Skynet! Skynet is better when you use it with others, so the invites will work for groups of friends.
Re: If you can't make a language fast, make it parallel
#14I'm not convinced that parallelism is something that needs support at the language level. The only languages that do this are Go and Erlang (off the top of my head). Others like Clojure and Scala have more support at the standard library level.
Occam.
And a whole pile of others.
Did you use a parallel programming language?
Re: If you can't make a language fast, make it parallel
#15My favorite features of Erlang/OTP in descending order:
1. built-in distribution (i.e. Erlang distributed RPC)
2. bit-syntax
3. light-weight processes
4. pattern-matching
Re: If you can't make a language fast, make it parallel
#16I'm not convinced that parallelism is something that needs support at the language level. The only languages that do this are Go and Erlang (off the top of my head). Others like Clojure and Scala have more support at the standard library level.
Fortress makes a convincing argument that it must be supported at the language level. It has a smart work splitting algorithm that does for managing parallelism granularity what garbage collection did for managing memory allocation. It works much better when it's baked into the core and is available from the ground up.
Re: If you can't make a language fast, make it parallel
#17It's worth noting we (the team that's building Skynet) didn't set out to build a parallel language, we set out to build a distributed one. It turns out that a lot of the things that make Spin a good distributed language also make it a good parallel one.
Yes, that's the story behind Erlang as well.
Re: If you can't make a language fast, make it parallel
#18I'm not convinced that parallelism is something that needs support at the language level. The only languages that do this are Go and Erlang (off the top of my head). Others like Clojure and Scala have more support at the standard library level.
True, the nice things about libraries is that they can compete and make your ecosystem stronger. But the nice thing about building it into the language is that it becomes a common layer of compatibility. We've gotten comfortable enough with our concurrency model, that we felt it deserved to be in the language. As an aside, some features that benefit parallelism can be tricky to add retroactively, although possible (l…
I believe race conditions can still occur in pure message-passing languages, like Erlang (Joe Armstrong says so in Programming Erlang, p.173). This doesn't get much press, perhaps because it's much easier to get right than shared-memory, and because not that many people are actually doing it yet.
Does Spin address this issue?
Re: If you can't make a language fast, make it parallel
#19I'm not convinced that parallelism is something that needs support at the language level. The only languages that do this are Go and Erlang (off the top of my head). Others like Clojure and Scala have more support at the standard library level.
Fortress makes a convincing argument that it must be supported at the language level. It has a smart work splitting algorithm that does for managing parallelism granularity what garbage collection did for managing memory allocation. It works much better when it's baked into the core and is available from the ground up.
> a smart work splitting algorithm
Not to detract from anything you said (which I agree with), but when Guy Steele gave a guest lecture at my university on Fortress a few months ago, he said that the work splitting algorithm still needed work, in particular the part that decided the right amount of granularity for the given task (i.e. when to stop splitting the task into smaller subtasks).
Re: If you can't make a language fast, make it parallel
#20Earlier quoted context omitted.
? Clojure has deep language support for concurrency - from syntactical constructs to it's core performant immutable data structures.
But the beauty is that because it's a Lisp, it's all implemented in terms of macros - Clojure's complete set of concurrency tools could be written as a library. The only exception is the deref reader macro "@", since Clojure doesn't allow user-defined reader macros by default.
> it's all implemented in terms of macros
This is not true at present. The core data structures, and the STM machinery are implemented in java, not as macros.