What Color Is Your Function? • Hacker News Board

Re: What Color Is Your Function?

#41

Post by AgentME » Mon, Feb 02, 2015, 7:51 PM UTC

Nilzor wrote: post #34

His solutions is threads ? Really? Has he read no history? There are problems with threads. That's why async I/O is hot right now. Threads is a limited resource. Threads are expensive to create and dispose. Context switches are espensive. Threads must be synchronized. Threads can have race conditions. Good rant, but I didn't expect him to serve such a shallow conclusion after a solid and insightful introduction.

>Threads is a limited resource. Threads are expensive to create and dispose. Context switches are espensive. ...

Languages like Go with green threads don't have those issues. They execute about the same way languages that expose async IO do.

Re: What Color Is Your Function?

#42

Post by sz4kerto » Mon, Feb 02, 2015, 7:54 PM UTC

echoless wrote: post #14

No actor-model based language has this problem, so perhaps all it comes down to is baking in the right(or even any decent) concurrency support from the start, at the language level.

Of course they have. Well, everything is nice and dandy until your actors never block. As soon as you start blocking, your async model has the same problems as threads have. And you cannot really write real-life systems without blocking actors.

Ask Erlang programmers whether they have dealt with this kind of stuff.

Re: What Color Is Your Function?

#43

Post by drostie » Mon, Feb 02, 2015, 7:56 PM UTC

Nilzor wrote: post #34

His solutions is threads ? Really? Has he read no history? There are problems with threads. That's why async I/O is hot right now. Threads is a limited resource. Threads are expensive to create and dispose. Context switches are espensive. Threads must be synchronized. Threads can have race conditions. Good rant, but I didn't expect him to serve such a shallow conclusion after a solid and insightful introduction.

Since he's a Go fan, he might prefer lightweight threads running in an event loop rather than real threads with their context-switches. Moreover his concern is syntactic, not semantic: so maybe he'd like something which "looks thread-like" but "complies-to-CPS" too.

Some Microsoft engineers are working on a nice solution to the thread-race-condition problem with a somewhat different approach: pretend your threaded environment is a DVCS. When you want to spawn a new lightweight-thread, think of it as a git clone. It makes its own changes to its own state, then you can eventually pull its changes into the present state -- so you get deterministic threading if you've got a deterministic merge algorithm.

http://research.microsoft.com/en-us/projects/revisions/

Re: What Color Is Your Function?

#44

Post by geofft » Mon, Feb 02, 2015, 7:59 PM UTC

Nilzor wrote: post #34

His solutions is threads ? Really? Has he read no history? There are problems with threads. That's why async I/O is hot right now. Threads is a limited resource. Threads are expensive to create and dispose. Context switches are espensive. Threads must be synchronized. Threads can have race conditions. Good rant, but I didn't expect him to serve such a shallow conclusion after a solid and insightful introduction.

Threadpools. Pin threads to processors. Hardware synchronization extensions. Avoid shared state between threads and use language-level primitives to enforce appropriate locking when needed (this isn't really much harder than language-level primitives to make CPS easy). IOCP.

Threadpools and innovative synchronization approaches (RCU) are exactly how the Linux kernel handles IO and interrupts internally. They can be unperformant if used poorly, but they don't have to be.

Re: What Color Is Your Function?

#45

Post by anonymoushn » Mon, Feb 02, 2015, 8:02 PM UTC

I don't really consider this solved in languages or runtimes that lack green threads. If you want to make 300,000 threads in Lua or Go, go right ahead, but if you port that application to Java you're going to have a bad time.

An orthogonal useful thing that is sometimes not solved in languages with green threads is the ability to copy continuations. If you have call/cc or coroutine.clone, you can e.g. use rollback netcode in your fighting game and store state in execution states, but if you cannot copy execution states, you will have to choose one or the other.

Re: What Color Is Your Function?

#46

Post by sbov » Mon, Feb 02, 2015, 8:35 PM UTC

Nilzor wrote: post #34

His solutions is threads ? Really? Has he read no history? There are problems with threads. That's why async I/O is hot right now. Threads is a limited resource. Threads are expensive to create and dispose. Context switches are espensive. Threads must be synchronized. Threads can have race conditions. Good rant, but I didn't expect him to serve such a shallow conclusion after a solid and insightful introduction.

He is talking of threads as an abstraction. Not operating system threads, more like green threads. Different languages call it different things, so I'm fine with the word thread. He even explains that he doesn't mean operating system threads, so your response doesn't make complete sense to me.

I've always wondered why Joyent built Node.js when they already used Erlang. I've tried to research it but there seems to be no articles about it. It's something I would really like to know because it seems like most people's uses for Node.js could easily be done in Erlang, and they were already using Erlang so did it fall short in other important ways? Or Stackless Python if you don't like goofy languages.

Both existed when Node.js first was released. Nowadays Go can fill in many people's use cases too. And I would also argue that green threads are higher level than CPS. So there has to be a reason to use Node.js other than its async stuff.

Re: What Color Is Your Function?

#47

Post by munificent » Mon, Feb 02, 2015, 8:36 PM UTC

nkohari wrote: post #37

Nilzor wrote: post #34

His solutions is threads ? Really? Has he read no history? There are problems with threads. That's why async I/O is hot right now. Threads is a limited resource. Threads are expensive to create and dispose. Context switches are espensive. Threads must be synchronized. Threads can have race conditions. Good rant, but I didn't expect him to serve such a shallow conclusion after a solid and insightful introduction.

> Has he read no history? Considering the author is Bob Nystrom, one of the main engineers of Dart, I'd wager the answer is yes.

> one of the main engineers of Dart, I'd wager the answer is yes.

I should point out that I'm on Dart, but I'm pretty low on the totem pole. I just happen to write more publicly than many of my teammates. :)

Re: What Color Is Your Function?

#48

Post by strictfp » Mon, Feb 02, 2015, 8:36 PM UTC

Nilzor wrote: post #34

His solutions is threads ? Really? Has he read no history? There are problems with threads. That's why async I/O is hot right now. Threads is a limited resource. Threads are expensive to create and dispose. Context switches are espensive. Threads must be synchronized. Threads can have race conditions. Good rant, but I didn't expect him to serve such a shallow conclusion after a solid and insightful introduction.

The problem is not so much threads as the current implementations of threads. So instead of inventing your own crappy thread-like continuation passing style to circumvent threads, we could be spending time fixing them. Linux used to have huge scalability problems with threads. Not so much any more, but the situation could still be improved. I find the culture of circumventing instead of improving problematic and endemic.

Re: What Color Is Your Function?

#49

Post by munificent » Mon, Feb 02, 2015, 8:40 PM UTC

andybak wrote: post #28

z3t4 wrote: post #21

I don't get it ... But hey, it took about six month for me to figure out how to write asynchronous JavaScript ... The key is to not use anonymous functions, it will flatten out the "Christmas tree" of callbacks. And it makes it possible to read what the code does, or at least what the programmer wants the code to do. It's much better then "then", then what, but, then, why complicate things when it's actually possible…

Funny to consider this alongside Guido's refusal to add full anonymous functions to Python. His argument seems to be "If it's too long for a single-line lambda, then it's long enough to deserve a name"

Guido has a different, legitimate reason to not add multi-line lambdas to Python: they are super nasty to integrate with Python's grammar.

Python has a strict grammar where statements (which use indentation) contain expressions, but never vice versa. Allowing statement-body lambdas would give you an expression form that contains significant indentation that could be embedded in the middle of some larger expression, like:

    call(some(function(lambda:
      insideLambda()
      alsoInside()
    ))) # Ugh, where do these go?!

Handling that in a way that's readable and easy to parse is hard, and, I think, there's no solution that would fit naturally with Python's look and feel.

CoffeeScript does handle it, but I think it's one of the hairier corners of its grammar and the Python community isn't quite so gung ho about accommodating grammatical weirdness like that.

Re: What Color Is Your Function?

#50

Post by munificent » Mon, Feb 02, 2015, 8:42 PM UTC

StrykerKKD wrote: post #26

What about isolates in Dart? I mean isolates are isolated processes, which also can be a thread and they also can communicate with each other.

Unfortunately:

1. Isolates can only communicate with each other using asynchronous method calls. So even though you can move some work to another isolate, you can't block waiting for it to complete, so your function still has to be red.

2. Isolates are very limited in what you can send between them, which makes then not very useful in practice for much of anything.